Well, this makes sense, but I'm using the Sun-recommended pam_ldap
configuration, straight from their documentation for Solaris 10. I
don't have a machine in front of me, but if memory serves, their
configuration includes pam_unix_auth, pam_unix_cred as well as
pam_ldap. I've read about the changes with server_policy and the like,
but even those example (again, iirc) use pam_unix. <br>
<br>
If you have a working pam.conf for solaris 10 that doesn't exhibit this
behavior, I'd be happy not so much to see it, but to know what doc you
referenced to develop it! <br>
<br>
Thanks, <br>
brian<br><br><div><span class="gmail_quote">On 8/30/05, <b class="gmail_sendername">George Holbert</b> <<a href="mailto:gholbert@broadcom.com">gholbert@broadcom.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Brian,<br>It sounds like you're using the pam_unix module for authentication on<br>the Solaris 10 client instead of the pam_ldap module.  The bind as the<br>proxy user is to retrieve the crypted password hash of the account,
<br>which is then compared with the password given at login.<br><br>If you want LDAP account deactivation to affect logins to Solaris<br>clients, those clients must use pam_ldap to authenticate against the<br>LDAP server, instead of pam_unix.
<br><br>Note also that deactivating a LDAP account will not prevent<br>password-less rsh login with that account.<br><br>-- George<br><br><br>Brian K. Jones wrote:<br><br>>Anyone experiencing a similar issue should see this Sun forum thread
<br>><a href="http://forum.sun.com/thread.jspa?threadID=24568&tstart=0">http://forum.sun.com/thread.jspa?threadID=24568&tstart=0</a><br>><br>>On Tuesday 30 August 2005 4:42 pm, Brian K. Jones wrote:<br>>
<br>><br>>>Well, I'm running nscd, but before I go shutting that off, I should share<br>>>this new info:<br>>><br>>>I found that the solaris machine *does* try to bind as the user, and the<br>>>server returns err=53, just like it does to the linux clients! However, it
<br>>>*then* does a search for the shadowaccount objectclass and the inactive<br>>>user's uid, and memberUID=<inactive user>, and in the end, it lets the user<br>>>in.<br>>><br>>>Baffling. And scary that a failed bind request can potentially lead to
<br>>>users getting logged in anyway.<br>>><br>>>On Tuesday 30 August 2005 4:24 pm, <a href="mailto:aly.dharshi@telus.net">aly.dharshi@telus.net</a> wrote:<br>>><br>>><br>>>>Hi Brian,
<br>>>><br>>>>     Is the nscd caching the query ? I guess try restarting nscd and<br>>>>see if that fixes your problem, if you aren't running nscd this is a<br>>>>useless suggession.<br>
>>><br>>>>     Cheers,<br>>>><br>>>>     Aly.<br>>>><br>>>>On Tue, 30 Aug 2005, Brian K. Jones wrote:<br>>>><br>>>><br>>>>>Hi all,<br>>>>>
<br>>>>>I'm running FDS (binary rpm) on rhel4. I have rhel4 and solaris 10<br>>>>>clients.<br>>>>><br>>>>>If I inactivate a user account in the FDS admin GUI, then try to log in
<br>>>>>via ssh as that inactivated user on any ol' random Linux client, the<br>>>>>BIND operation fails with err=53 (unwilling to perform). This, I should<br>>>>>think, is the expected behaviour.
<br>>>>><br>>>>>Solaris 10, on the other hand, lets the user in (again, ssh). The only<br>>>>>BIND I can correllate in the logs come from the solaris proxy user.<br>>>>>Then a search is done for "shadowaccount=<username>", and then a search
<br>>>>>is done for the group memberships of that user (presumably I'm already<br>>>>>in when this is done). There's never a BIND operation as the inactive<br>>>>>user at all!<br>>>>>
<br>>>>>Can someone explain what's happening?<br>>>>><br>>>>>brian.<br>>>>><br>>>>>--<br>>>>>Fedora-directory-users mailing list<br>>>>><a href="mailto:Fedora-directory-users@redhat.com">
Fedora-directory-users@redhat.com</a><br>>>>><a href="https://www.redhat.com/mailman/listinfo/fedora-directory-users">https://www.redhat.com/mailman/listinfo/fedora-directory-users</a><br>>>>><br>>>>>
<br>>>--<br>>>Fedora-directory-users mailing list<br>>><a href="mailto:Fedora-directory-users@redhat.com">Fedora-directory-users@redhat.com</a><br>>><a href="https://www.redhat.com/mailman/listinfo/fedora-directory-users">
https://www.redhat.com/mailman/listinfo/fedora-directory-users</a><br>>><br>>><br>><br>>--<br>>Fedora-directory-users mailing list<br>><a href="mailto:Fedora-directory-users@redhat.com">Fedora-directory-users@redhat.com
</a><br>><a href="https://www.redhat.com/mailman/listinfo/fedora-directory-users">https://www.redhat.com/mailman/listinfo/fedora-directory-users</a><br>><br>><br>><br><br><br><br>--<br>Fedora-directory-users mailing list
<br><a href="mailto:Fedora-directory-users@redhat.com">Fedora-directory-users@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/fedora-directory-users">https://www.redhat.com/mailman/listinfo/fedora-directory-users
</a><br></blockquote></div><br>