account inactivation and host login restrictions
Greetings,
I had an incident today where a user was unable to log into any LDAP authenticated hosts for ~40 minutes. It seemed to me like the account was locked out due to having hit the login failure threshold (4 failures, 30 mins lockout). What I could NOT tell, however, was whether that was actually the case. I looked at the users' entry in ldap and nothing looked out of the ordinary.
How can you tell if a user is locked out (i.e. is there something I can search for)? Despite how clear it might be, are lockouts replicated? Is there a way to make lockouts specific to the host on which the attempts were tried?
Thanks,
Patrick
[674 byte] By [
pbeckhelm] at [2007-11-25 19:39:36]
# 1
To verify if an account has been locked, look up for this operational attribute "accountunlocktime", using "Edit With Generic Editor" in SUN ONE Console.
$ ldapsearch -D "cn=Directory manager" -b "dc=example,dc=com" uid=tuser accountunlocktime
Bind Password:
uid=tuser,ou=People,dc=example,dc=com
accountunlocktime=20050713052404Z
It seems to me that the locked account will be unlocked in 5 hour time (as the failed logins occured sometime at 00:24:04).
To unlock this account immediately, select this "accountunlocktime" attribute and click "delete attribute".
Gary
# 2
There are two types of Password Policies.- Global, for all user accts on all hosts- Per user basis, for specific user acct(s), on all hostsSo it looks like per host basis is not there.Gary
# 3
I wrote:
===
To unlock this account immediately, select this "accountunlocktime" attribute and click "delete attribute".
===
I found that this alone is not good enough, I have to also set the "passwordretrycount" back to zero value.
IIRC there are two kind of account LOCKOUTS:
1) locked out by failing password policy check.
Check the EXISTENCE of "accountunlocktime", if present it means account is locked out.
2) locked out by admin's quick account "inactivation".
Check the EXISTENCE of "nsaccountlock", if present it means account is locked out also.
Gary
# 4
> ===
> To unlock this account immediately, select this
> "accountunlocktime" attribute and click "delete
> attribute".
> ===
Interestingly, I can see this attribute only if I use the console to view the user entries. ldapsearch does not show these attributes, which sort of bothers me...is there a way to show all attributes (some ldapsearch flag that's not in the man page?)?
Also, I tried to delete this attribute for a user that was having some problems logging in (it's very existence signifies something, evidently), but was unable to do so for some reason.The error message give by the console was: "No such attribute" -- Clearly something is amiss.
>
> I found that this alone is not good enough, I have to
> also set the "passwordretrycount" back to zero
> value.
This was already set to zero by something, and since I can't delete the "accountunlocktime" attribute, I'm stuck.
> IIRC there are two kind of account LOCKOUTS:
>
> 1) locked out by failing password policy check.
>
> Check the EXISTENCE of "accountunlocktime", if
> present it means account is locked out.
This probably needs qualification somewhere. Does anyone have any documentation on this stuff from Sun?
> 2) locked out by admin's quick account
> "inactivation".
>
> Check the EXISTENCE of "nsaccountlock", if present it
> means account is locked out also.
So, on this item, my assumption is this:
If I "inactivate" an account, that user should be unable to log into any servers that are using LDAP auth, right? I've tested (just now!) with my own account, by doing the following:
1. Inactivate my LDAP account. Verifed that it shows as inactivated.
2. On the host I plan to log into with my account (beckhelm), I logged in as another user, su'd to root, stopped and started nscd, pkill -HUP ldap_cachemgr.
3. Ssh'd to the server in question, and was able to successfully log in (both with password and ssh key).
...so, this strikes me as an extremely ineffective way to block logins :(
Any thoughts? Did I do something wrong?
Patrick
# 5
Well, I've found some info on Sun's site about account inactivation:
http://docs.sun.com/source/817-7619/secure.html
...specifically:
"The account inactivation functionality in Directory Server, which allows you to temporarily inactivate a user account or a set of accounts, is essential to your directory security. Once inactivated, a user cannot bind to Directory Server, and the authentication operation fails. Account inactivation is implemented through an account lock attribute, which, when enabled, causes the server to automatically reject the bind operation."
...so, it looks like this doesn't work for proxy authentication? Under what circumstances do users actually bind to the DS during authentication? My first guess is that once I convert to using pam_ldap (currently using pam_unix because I can't seem to figure out how to make pam_ldap work :( ) this problem may be solved, but I could be wrong.
Patrick
# 6
Hi Patrick,
If you're just using pam_unix, only the proxy account will bind when a user attempts to login.
The user's account will bind if you're using pam_ldap.
On a related point: your proxy account should have a password policy set such that the account never expires and will allow unlimited failed logins. Otherwise, someone can easily bring down your whole LDAP name service by repeatedly binding to your directory server with the proxy account DN and the wrong password.
# 7
You wrote:
===
If I "inactivate" an account, that user should be unable to log into any servers that are using LDAP auth, right? I've tested (just now!) with my own account, by doing the following:
1. Inactivate my LDAP account. Verifed that it shows as inactivated.
2. On the host I plan to log into with my account (beckhelm), I logged in as another user, su'd to root, stopped and started nscd, pkill -HUP ldap_cachemgr.
3. Ssh'd to the server in question, and was able to successfully log in (both with password and ssh key).
...so, this strikes me as an extremely ineffective way to block logins :(
Any thoughts? Did I do something wrong?
===
As explained in your later posting, due to the fact that you did not use "pam_ldap" in /etc/pam.conf, the account inactivation feature failed to work.
I just did an account inactivation test on a Solaris8 Native LDAP Client as it works as per expectation.
I have the latest LDAP patch on this client and I use pam_ldap in /etc/pam.conf, following the sampe at the following url, except that "pam_unix_cred.so.1" lines should be commenting out as it is only for Solaris10.
http://docs.sun.com/app/docs/doc/816-4556/6maort2te?a=view
You need to use this version if you need the Account Management features.
Gary
# 8
> As explained in your later posting, due to the fact
> that you did not use "pam_ldap" in /etc/pam.conf, the
> account inactivation feature failed to work.
>
Actually, I've got pam_ldap in my pam.conf, like so:
loginauth requisite pam_authtok_get.so.1
loginauth requiredpam_dhkeys.so.1
loginauth sufficient pam_unix_auth.so.1
loginauth requiredpam_ldap.so.1 try_first_pass
sshdauth requisite pam_authtok_get.so.1
sshdauth sufficient pam_unix_auth.so.1
sshdauth requiredpam_ldap.so.1 try_first_pass
otherauth requisite pam_authtok_get.so.1
otherauth requiredpam_dhkeys.so.1
otherauth sufficient pam_unix_auth.so.1
otherauth requiredpam_ldap.so.1 try_first_pass
passwd auth sufficient pam_passwd_auth.so.1
passwd auth requiredpam_ldap.so.1 try_first_pass
...and still no dice. Am I doing something wrong?
>http://docs.sun.com/app/docs/doc/816-4556/6maort2te?a=
> view
>
> You need to use this version if you need the Account
> Management features.
What exactly is included in this account management stuff?
Patrick
# 9
Account management features are decribed at:
http://docs.sun.com/source/817-7613/aci.html
The partial pam.conf you shown did not use the "binding" flag and "server_policy" option, therefore password policy may not work.
Be careful when you use "binding" and "server_policy" option, MAKE SURE that the latest kernel and LDAP patch are applied, otherwise these new keywords are not recognized and NO ONE COULD LOGIN due to PAM lib error, you got to repair it in single user mode.
Gary
# 10
> The partial pam.conf you shown did not use the
> "binding" flag and "server_policy" option, therefore
> password policy may not work.
You're right, I wasn't using those. I wasn't aware that they were required for pam_ldap to work properly. Unfortunately, I've changed the pam.conf on a test host to see if I can get things to work right and it seems not. Here's my new pam.conf:
loginauth requisite pam_authtok_get.so.1
loginauth requiredpam_dhkeys.so.1
loginauth bindingpam_unix_auth.so.1 server_policy
loginauth requiredpam_ldap.so.1 use_first_pass
sshdauth requisite pam_authtok_get.so.1
sshdauth bindingpam_unix_auth.so.1 server_policy
sshdauth requiredpam_ldap.so.1 use_first_pass
otherauth requisite pam_authtok_get.so.1
otherauth requiredpam_dhkeys.so.1
otherauth bindingpam_unix_auth.so.1 server_policy
otherauth requiredpam_ldap.so.1 use_first_pass
passwd auth sufficient pam_passwd_auth.so.1
passwd auth requiredpam_ldap.so.1 use_first_pass
Does that look right to you? I'm seriously interested in getting pam_ldap to work properly so that account inactivations actually mean something.
>
> Be careful when you use "binding" and "server_policy"
> option, MAKE SURE that the latest kernel and LDAP
> patch are applied, otherwise these new keywords are
> not recognized and NO ONE COULD LOGIN due to PAM lib
> error, you got to repair it in single user mode.
Solid advice. So far no trouble, but no success either.
Patrick
# 11
The keyword "use_first_pass" or "try_first_pass" are no more needed if you have latest LDAP patches.
This is the version of pam.conf with account management support I am using on Solaris9 (with kernel patch + LDAP patch 112960)
loginauth requisitepam_authtok_get.so.1
loginauth required pam_dhkeys.so.1
loginauth required pam_dial_auth.so.1
loginauth binding pam_unix_auth.so.1 server_policy
loginauth required pam_ldap.so.1
rlogin auth sufficientpam_rhosts_auth.so.1
rlogin auth requisitepam_authtok_get.so.1
rlogin auth required pam_dhkeys.so.1
rlogin auth binding pam_unix_auth.so.1 server_policy
rlogin auth required pam_ldap.so.1
rshauth sufficientpam_rhosts_auth.so.1
rshauth binding pam_unix_auth.so.1 server_policy
rshauth required pam_ldap.so.1
pppauth requisitepam_authtok_get.so.1
pppauth required pam_dhkeys.so.1
pppauth required pam_dial_auth.so.1
pppauth binding pam_unix_auth.so.1 server_policy
pppauth required pam_ldap.so.1
otherauth requisitepam_authtok_get.so.1
otherauth required pam_dhkeys.so.1
otherauth binding pam_unix_auth.so.1 server_policy
otherauth required pam_ldap.so.1
passwd auth binding pam_passwd_auth.so.1 server_policy
passwd auth required pam_ldap.so.1
cronaccount requiredpam_unix_account.so.1
otheraccount requisitepam_roles.so.1
otheraccount bindingpam_unix_account.so.1 server_policy
otheraccount requiredpam_ldap.so.1
othersession requiredpam_unix_session.so.1
otherpassword requiredpam_dhkeys.so.1
otherpassword requisitepam_authtok_get.so.1
otherpassword requisitepam_authtok_check.so.1
otherpassword requiredpam_authtok_store.so.1 server_policy
It is the same pam.conf I use on Solaris8, but make sure that latest kernel + LDAP patch 108993-48 must be applied, otherwise PAM libs of format pam_unix_?.so.1 won't be found and no one can login.
Gary
# 12
Hi guys,
I've just come across this thread, having the same problem Patrick is under Solaris 9 with latest kernel patch and 112960-26. Gary I have followed your advice on the pam.conf and dplicated the settings as per what you pasted, but I can still log in using an inactive account.
Patrick did this end up fixing your problem, or did you find something further? Any other ideas Gary?
Thanks in advance for any assistance :)
Regards
Gryph
# 13
FYI I am using 112960-30
# showrev -p | grep "^Patch: 112960-"
Patch: 112960-11 Obsoletes: Requires: Incompatibles: Packages: SUNWcsl, SUNWcslx, SUNWarc, SUNWarcx, SUNWnisu, SUNWcstl, SUNWcstlx, SUNWhea
Patch: 112960-24 Obsoletes: 113152-01, 113166-01, 113476-13 Requires: 112874-06 Incompatibles: Packages: SUNWcsl, SUNWcslx, SUNWarc, SUNWarcx, SUNWnisu, SUNWcstl, SUNWcstlx, SUNWhea
Patch: 112960-30 Obsoletes: 113152-01, 113166-01, 113476-13 Requires: 112874-06 Incompatibles: Packages: SUNWcsl, SUNWcslx, SUNWarc, SUNWarcx, SUNWnisu, SUNWcstl, SUNWcstlx, SUNWhea
Gary
# 14
Thanks for the prompt reply Gary, I updated to 112960-30 but still no luck, I've also downloaded and applied the latest solaris 9 recommended patch cluster but still no change. I've got the exact same problem across 3 solaris 9 systems (2xE440's and 1xE880). I also have a Solaris 7 system on which I've installed the PADL pam_ldap and nss_ldap on and that system works as expected for inactive accounts.
I'm wondering if this has anything to do with using a proxy configuration. Are you using the proxyagent scenario for authentication? Here's the output from an ldapclient list on the 880 (ip's, password and domain obscured):
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=obscured,dc=com,dc=au
NS_LDAP_BINDPASSWD= {NS1}XXXXXXXXXXXXX
NS_LDAP_SERVERS= xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx
NS_LDAP_SEARCH_BASEDN= dc=obscured,dc=com,dc=au
NS_LDAP_AUTH= tls:simple
NS_LDAP_SEARCH_REF= FALSE
NS_LDAP_SEARCH_SCOPE= sub
NS_LDAP_SEARCH_TIME= 30
NS_LDAP_SERVER_PREF= xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx
NS_LDAP_PROFILE= default
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=People,dc=obscured,dc=com,dc=au?sub
NS_LDAP_SERVICE_SEARCH_DESC= group:ou=Group,dc=obscured,dc=com,dc=au?sub
NS_LDAP_SERVICE_SEARCH_DESC= netgroup:ou=netgroup,dc=obscured,dc=com,dc=au?sub
NS_LDAP_BIND_TIME= 10
NS_LDAP_SERVICE_AUTH_METHOD= pam_ldap:tls:simple
Here's the pam.conf in case you notice something I've missed:
loginauth requisite pam_authtok_get.so.1
loginauth requiredpam_dhkeys.so.1
loginauth requiredpam_dial_auth.so.1
loginauth bindingpam_unix_auth.so.1 server_policy
loginauth requiredpam_ldap.so.1
rlogin auth sufficient pam_rhosts_auth.so.1
rlogin auth requisite pam_authtok_get.so.1
rlogin auth requiredpam_dhkeys.so.1
rlogin auth bindingpam_unix_auth.so.1 server_policy
rlogin auth requiredpam_ldap.so.1
rshauth sufficient pam_rhosts_auth.so.1
rshauth bindingpam_unix_auth.so.1 server_policy
rshauth requiredpam_ldap.so.1
pppauth requisite pam_authtok_get.so.1
pppauth requiredpam_dhkeys.so.1
pppauth requiredpam_dial_auth.so.1
pppauth bindingpam_unix_auth.so.1 server_policy
pppauth requiredpam_ldap.so.1
otherauth requisite pam_authtok_get.so.1
otherauth requiredpam_dhkeys.so.1
otherauth bindingpam_unix_auth.so.1 server_policy
otherauth requiredpam_ldap.so.1
passwd auth bindingpam_passwd_auth.so.1 server_policy
passwd auth requiredpam_ldap.so.1
cronaccount requiredpam_projects.so.1
cronaccount requiredpam_unix_account.so.1
otheraccount requisitepam_roles.so.1
otheraccount requiredpam_projects.so.1
otheraccount binding pam_unix_account.so.1 server_policy
otheraccount requiredpam_ldap.so.1
othersession requiredpam_unix_session.so.1
otherpassword requiredpam_dhkeys.so.1
otherpassword requisitepam_authtok_get.so.1
otherpassword requisitepam_authtok_check.so.1
otherpassword requiredpam_authtok_store.so.1 server_policy
Thanks again for your help on this so far, it is most appreciated.
Best Regards
Gryph
# 15
I just tested again on my Solaris9 Native LDAP Client against Solaris9 SJS/DS5.2 LDAP Server.
When acct is in-activated:
$ ssh tuser@localhost
tuser@localhost's password:
Connection closed by 0.0.0.0
When acct is activated:
$ ssh tuser@localhost
tuser@localhost's password:
Last login: Wed Aug 3 23:31:50 2005 from localhost
Sun Microsystems Inc.SunOS 5.9Generic May 2002
$ ldaplist -l shadow tuser
dn: uid=tuser,ou=People,dc=example,dc=com
givenName: Test
sn: User
loginShell: /bin/sh
uidNumber: 9999
gidNumber: 102
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: tuser
cn: Test User
homeDirectory: /var/tmp
$
Did you define "shadowAccount" objectClass in your LDAP user acct details? and the THREE person objectClasses that I knew DS5.2 like very much.
Note: I had also tried two possibilities, tuser acct is assigned a Per-User Level Password Policy and without Password Policy (Global Password Policy applies in this case), result is the same.
I trust that you DID NOT compile and build PADL's pam_ldap and nss_ldap modules on your Solaris9 Native LDAP Clients, if you do, don't expect them to work well with Solaris LDAP Server in connection with Account Management support as they are not from SUN
Don't ask me why on Solaris7 PADL modules work, Solaris7 is out of SUN's support long ago.
My /var/ldap/ldap_client_file is almost the same as yours execpt that I do have have this line:
NS_LDAP_SERVICE_AUTH_METHOD= pam_ldap:tls:simple
And I have this line which you did not have:
NS_LDAP_SERVICE_SEARCH_DESC= shadow: ou=People,dc=example,dc=com?one
Your /etc/pam.conf looks the same as the one I quoted and it is the one I used.
I have applied latest kernel patch 112233-12 as it is required by 112960-30, I did not apply Recommended Patch cluster.
Gary
# 16
Yes the following object classes are defined for the user I am testing with:
objectClass: mailRecipient
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
objectClass: dspswuser
I dont have a per user password policy defined, it's using the global one, which is only minimal at this stage. I do not have account lockout enabled as of yet, could it be that this is required? (I've assumed it is only necessary if I want accounts locked automatically following a number of failed logins)
No I havent compiled the PADL pam_ldap and nss_ldap on the Solaris 9 machines, I'm using the Native LDAP here only. I use PADL on solaris 7 as the native solaris ldap is not available and I can not upgrade Solaris on that machine due to some legacy applications.
I tried adding the :
NS_LDAP_SERVICE_SEARCH_DESC= shadow: ou=People,dc=example,dc=com?one
line (with my settings of course) to my profile, and then restarted ldap_cachemgr and nscd. The system picked up the new entry ok, but the problem is still there
I have both 112233-12 & 112960-30 and I'm using DS5.2_patch2
Here is the test with the inactive account:
root on test1 [~] > ssh tuser@test2
tuser@test2's password:
Last login: Thu Aug 4 15:01:50 2005 from test1.obscured.com
Sun Microsystems Inc.SunOS 5.9Generic May 2002
tuser on test2 [~] >
Thanks again!
Gryph
# 17
Gryph,
I can tell you that your problem is most likely due to pam_ldap not working properly for you. I had Sun PS at my site last Friday and he gave me a pam.conf that works. I tested it and was able to verify that account inactivation works just as expected.
I'll post it up tomorrow when I'm back at the office.
Patrick
# 18
Thanks Patrick, that would be terrific!RegardsGryph
# 19
Gryph,
I trust that you apply 112233 and 112960 in Single-User mode.
===
Status: RELEASEDPatch Id: 112960-30
Keywords: security libsldap ldap_cachemgr ldap sigbus buffer libldap
Summary: SunOS 5.9: libsldap ldap_cachemgr libldap PatchDate: May/31/2005Installation Requirements:Reconfigure immediately after patch is installed
Install in Single User Mode
===
I think Acct Acitvation feature is independent of Password Policies (Per-User or Global) as I tested with/without PP the result are the same, it is a "quick and dirty" method to disable the account.
I checked that the /etc/pam.conf you posted in your earlier email is the same as mine.
Below are the file size/time stamp of my Solaris9 Native LDAP Client lib files: pam_ldap and nss_ldap.
# ls -ald /usr/lib/security/pam_ldap.so.1
-rwxr-xr-x1 rootbin55888 Apr 27 03:44 /usr/lib/security/pam_ldap.so.1
# ls -ald /usr/lib/security/sparcv9/pam_ldap.so.1
-rwxr-xr-x1 rootbin72824 Apr 27 03:44 /usr/lib/security/sparcv9/pam_ldap.so.1
# ls -ald /usr/lib/nss_ldap.so.1
-rwxr-xr-x1 rootbin78736 Apr 27 03:44 /usr/lib/nss_ldap.so.1
#
You wrote:
===
I have both 112233-12 & 112960-30 and I'm using DS5.2_patch2
===
May be this is the difference, I am using SUN Java System Direcectory Server 5.2 Solaris SPARC version which is actually DS5.2 with Patch_3.
===
# ../stop-slapd
# ../start-slapd
# tail errors
[04/Aug/2005:04:58:06 -0400] - slapd shutting down - waiting for 0 threads to terminate
[04/Aug/2005:04:58:06 -0400] - Waiting for 4 database threads to stop
[04/Aug/2005:04:58:07 -0400] - All database threads now stopped
[04/Aug/2005:04:58:07 -0400] - slapd stopped.
[04/Aug/2005:04:58:15 -0400] - Sun Java(TM) System Directory Server/5.2_Patch_3 B2004.331.1125 (64-bit) starting up
...
===
You may download 117665-02 (Patch 3) and apply it against your DS5.2.
(Interesting Note: after applying this patch, you WON'T see it in "showrev -p")
Gary
# 20
Gryph wrote:
===
I tried adding the :
NS_LDAP_SERVICE_SEARCH_DESC= shadow: ou=People,dc=example,dc=com?one
===
This is incorrect, my line is just for example, you should:
1) Add line something like:
NS_LDAP_SERVICE_SEARCH_DESC= shadow:ou=People,dc=obscured,dc=com,dc=au?sub
2) Also make sure you have this SSD data in LDAP DIT profile data
3) Add also "shadow: files ldap" in /etc/nsswitch.conf
4) Then restart ldap_cachemgr and nscd.
Gary
# 21
I further tested it on a Solaris8 LDAP Client:
When acct is in-activated:
$ ssh tuser@localhost
Password:
LDAP Password:
Password:
LDAP Password:
(It keeps prompting despite entering of correct passwords)
When acct is activated:
$ ssh tuser@localhost
Password:
Last login: Thu Aug 4 19:46:53 2005 from localhost
Sun Microsystems Inc.SunOS 5.8Generic PatchOctober 2001
$
Gary
# 22
Gary,
> I trust that you apply 112233 and 112960 in
> Single-User mode.
Yes both applied in single user mode and reconfigure reboot done straight after.
> Below are the file size/time stamp of my Solaris9
> Native LDAP Client lib files: pam_ldap and nss_ldap.
>
> # ls -ald /usr/lib/security/pam_ldap.so.1
> -rwxr-xr-x1 rootbin55888 Apr 27 03:44
> /usr/lib/security/pam_ldap.so.1
> # ls -ald /usr/lib/security/sparcv9/pam_ldap.so.1
> -rwxr-xr-x1 rootbin72824 Apr 27 03:44
> /usr/lib/security/sparcv9/pam_ldap.so.1
> # ls -ald /usr/lib/nss_ldap.so.1
> -rwxr-xr-x1 rootbin78736 Apr 27 03:44
> /usr/lib/nss_ldap.so.1
> #
Hmm, mine are different they look to be later:
> ls -lad /usr/lib/security/pam_ldap.so.1
-rwxr-xr-x1 rootbin55936 May 4 09:32 /usr/lib/security/pam_ldap.so.1
> ls -lad /usr/lib/security/sparcv9/pam_ldap.so.1
-rwxr-xr-x1 rootbin72896 May 4 09:32 /usr/lib/security/sparcv9/pam_ldap.so.1
> ls -lad /usr/lib/nss_ldap.so.1
-rwxr-xr-x1 rootbin78736 May 4 09:32 /usr/lib/nss_ldap.so.1
> You wrote:
> ===
> I have both 112233-12 & 112960-30 and I'm using
> DS5.2_patch2
> ===
>
> May be this is the difference, I am using SUN Java
> System Direcectory Server 5.2 Solaris SPARC version
> which is actually DS5.2 with Patch_3.
I had considered doing this upgrade but found some other interesting things whilst I've been diagnosing this which suggests the problem is not the Directory Server:
1. When I inactivate an account, not only does it still let me log in, but I noticed that it doesnt even matter whether I get the password correct or not, it lets me in regardless. If I reactivate that account it forces the correct password.
2. I added the debug option to some of the module entries in pam.conf and found something interesting in the debug logs. Firstly if I attempt a log in as per the pam.conf that has been confirmed with the user tuser inactivated, I get the following:
Aug 5 00:28:00 test1 sshd[1255]: [ID 634615 auth.debug] pam_authtok_get:pam_sm_authenticate: flags = 1
Aug 5 00:28:00 test1 sshd[1255]: [ID 285619 auth.debug] ldap pam_sm_authenticate(sshd tuser), flags = 1
Aug 5 00:28:03 test1 sshd[1255]: [ID 634615 auth.debug] pam_authtok_get:pam_sm_authenticate: flags = 1
Aug 5 00:28:03 test1 sshd[1255]: [ID 285619 auth.debug] ldap pam_sm_authenticate(sshd tuser), flags = 1
Aug 5 00:28:03 test1 sshd[1255]: [ID 800047 auth.info] Accepted password for tuser from xxx.xxx.xxx.xxx port 4745 ssh2
As you can see the password is accepted. Now see what happens if I comment out this line from the pam.conf
#otheraccount binding pam_unix_account.so.1 server_policy
I now get this:
Aug 5 00:34:27 test1 sshd[1275]: [ID 634615 auth.debug] pam_authtok_get:pam_sm_authenticate: flags = 1
Aug 5 00:34:27 test1 sshd[1275]: [ID 285619 auth.debug] ldap pam_sm_authenticate(sshd tuser), flags = 1
Aug 5 00:34:30 test1 sshd[1275]: [ID 634615 auth.debug] pam_authtok_get:pam_sm_authenticate: flags = 1
Aug 5 00:34:30 test1 sshd[1275]: [ID 285619 auth.debug] ldap pam_sm_authenticate(sshd tuser), flags = 1
Aug 5 00:34:30 test1 sshd[1275]: [ID 100510 auth.debug] ldap pam_sm_acct_mgmt(tuser), flags = 0
Aug 5 00:34:30 test1 sshd[1275]: [ID 800047 auth.info] PAM rejected by account configuration[17]:User account has expired
Aug 5 00:34:30 test1 sshd[1275]: [ID 800047 auth.info] Failed password for tuser from xxx.xxx.xxx.xxx port 4750 ssh2
As you can see it now recognises the account is inactive. This suggests the tuser account is in the local passwd file, but I double checked this, it is not. I am using netgroups, on this machine but I tested on one of the others without netgroups and get the same thing.
Now although this gets the correct response for ldap accounts, without the line I took out I can no longer use local accounts like root. We are definetly getting closer, I will be interested to see what pam.conf settings Sun PS gave Patrick which got his working.
Regards
Gryph
# 23
> ===
> I tried adding the :
>
> NS_LDAP_SERVICE_SEARCH_DESC= shadow:
> ou=People,dc=example,dc=com?one
> ===
>
> This is incorrect, my line is just for example, you
> should:
Sorry, I did actually put the correct settings in for my suffix, I was just being lazy when I replied and cut and paste your entry. Sorry for the confusion.
> 2) Also make sure you have this SSD data in LDAP DIT
> profile data
Yes, done, I added it to the profile and forced the client to pick up the new entry by restarting ldap_cachemgr and nscd.
> 3) Add also "shadow: files ldap" in
> /etc/nsswitch.conf
Done, here are the relevant entries from my nsswitch.conf
passwd: compat
passwd_compat: ldap
group: files ldap
shadow: files ldap
> 4) Then restart ldap_cachemgr and nscd.
Done. Problem is still there :(
Regards
Gryph
# 24
I wrote:
> Below are the file size/time stamp of my Solaris9
> Native LDAP Client lib files: pam_ldap and nss_ldap.
>
> # ls -ald /usr/lib/security/pam_ldap.so.1
> -rwxr-xr-x 1 root bin 55888 Apr 27 03:44
> /usr/lib/security/pam_ldap.so.1
> # ls -ald /usr/lib/security/sparcv9/pam_ldap.so.1
> -rwxr-xr-x 1 root bin 72824 Apr 27 03:44
> /usr/lib/security/sparcv9/pam_ldap.so.1
> # ls -ald /usr/lib/nss_ldap.so.1
> -rwxr-xr-x 1 root bin 78736 Apr 27 03:44
> /usr/lib/nss_ldap.so.1
> #
My mistake, these lib files' listing were taken from the Solaris9 SJS/DS5.2 LDAP Server with 112233-12 and 112960-24, not from Solaris9 Native LDAP Client with 112233-12 and 112960-30. Therefore there are differences between our "ls -ald" listings.
I double-checked again, my Solaris9 Native LDAP Client is in fact having exactly the same "file size" as your three lib files.
Now I have an important clue for you: about a few months back I encountered exactly the same "interesting" observation you had just described:
===
. When I inactivate an account, not only does it still let me log in, but I noticed that it doesnt even matter whether I get the password correct or not, it lets me in regardless. If I reactivate that account it forces the correct password.
===
I was testing "netgroups" AS WELL AS ACCOUNT INACTIVATION and I used the same "compat" keywords as you did in /etc/nsswitch.conf, and guess what, I ALSO EXPERIENCED the same "suspected" buggy behaviour as you did, i.e. any password would be "valid" to gain access into the system when the account got IN-ACTIVATED?!
I reported this "suspected" bug in an earlier post, which I couldn't locate at the moment, I have a feeling that you and me are not alone.
I will be turning on "netgroups" again to try to "duplicate" your issue, not sure with the latest LDAP lib patch and server Patch_3 this issue is still there. We shall know my next day.
At the same time, may be you could do the REVERSE way, i.e. removing "netgroups" from /etc/passwd and /etc/shadow and removing "compat" keywords from /etc/nsswitch.conf and see if you could get your issue resolved.
If without netgroups you still have the same issue, you have options to continue to make your system identical to mine "without netgroups", i.e.
- Apply DS5.2 Patch_3 at the LDAP Server
- Apply 112960-24 at the LDAP Server
- I use OpenSSH Server 4.1p1 at Solaris9 LDAP Client, no sure if this is the same as yours
Gary
# 25
> I will be turning on "netgroups" again to try to
> "duplicate" your issue, not sure with the latest LDAP
> lib patch and server Patch_3 this issue is still
> there. We shall know my next day.
>
> At the same time, may be you could do the REVERSE
> way, i.e. removing "netgroups" from /etc/passwd and
> /etc/shadow and removing "compat" keywords from
> /etc/nsswitch.conf and see if you could get your
> issue resolved.
Ok, I have disabled netgroups, then restarted ldap_cachemgr and nscd, but problem still continues.
> If without netgroups you still have the same issue,
> you have options to continue to make your system
> identical to mine "without netgroups", i.e.
>
> - Apply DS5.2 Patch_3 at the LDAP Server
> - Apply 112960-24 at the LDAP Server
> - I use OpenSSH Server 4.1p1 at Solaris9 LDAP Client,
I will work on these things, and get back to you.
Gryph
# 26
I have turned on "netgroup" in /etc/passwd and /etc/shadow and edited /etc/nsswitch.conf to use "compat" keyword.
I confirm that THERE IS A SUSPECTED BUG that:
Whenever netgroup is used, an user allowed by netgroup permission to access the LDAP client WILL BE ABLE TO LOGIN USING ANY PASSWORD against the "LDAP Password:" prompt, even though the user is IN-ACTIVATED in LDAP.
When netgroup is on and tuser is activated:
Everything works as per normal
login as: tuser
Using keyboard-interactive authentication.
Password:
Last login: Fri Aug 5 07:31:39 2005 from XXX.XXX.XXX.XXX
Sun Microsystems Inc.SunOS 5.9Generic May 2002
$
When netgroup is on and tuser is in-activated:
First "Password:" prompt will reject any password
Second "LDAP Password:" prompt WILL ACCEPT ANY PASSWORD?!
login as: tuser
Using keyboard-interactive authentication.
Password: <anything>
LDAP Password: <anything> always succeed
Last login: Fri Aug 5 07:24:53 2005 from XXX.XXX.XXX.XXX
Sun Microsystems Inc.SunOS 5.9Generic May 2002
$
I have also tried "telnet" same behaviour as "ssh", i.e. succeed with ANY PASSWORD at 2nd prompt. For "ftp", succeed with ANY PASSWORD at 1st prompt.
Not sure if Patrick could tell us if he is using netgroup and what SUN had helped him to workaround this "suspected" bug.
Gary
# 27
Hello,i have the same problems described in this thread. Is there a solution? Where can i find a working pam.conf file?ThanksKlaus
# 28
Well after working with sun support on this we have finally tracked down the source of the problem.
If you are using both pam_unix and pam_ldap in your pam.conf (as we are as we will maintain some local accounts in the password file for services), it is necessary to deny access to the userPassword attribute in the ldap directory for the proxy user, otherwise pam_unix authenticates the user against the shadow data in the ldap server which is not kept up to date by the directory server.
This was something I missed in the docs but it is definetly there. See the following link, scroll to the very last paragraph:
http://docs.sun.com/app/docs/doc/817-4843/6mkbebdcj?q=Configuring+the+Directory +Server+to+Enable+Password+Management&a=view
If you look at your ACI's you will probably see one that gives read access to this attribute for the proxy user account, removing this fixes the trouble. There is one caveat to this however, keep in mind that if any of your apps are making use of that same account to authenticate directly or if they use getent calls they will no longer authenticate your users once you have made this change. All is not lost though, in a large number of cases apps can be recompiled to use pam_ldap for authentication.
HTH
Gryph
# 29
This doesn't work for me. If i remove the "read" permission for the proxy user no LDAP user can login anymore. Only local accounts can login..
# 30
Please post your pam.conf and nsswtich.conf files along with details of solaris version and ldap directory you are using.
# 31
Yes, attributes such as accountunlocktime and passwordexpirationtime are operational attributes and are not normally returned by a LDAP search. However, you can retrieve them by explicitly requesting them when you use ldapsearch.
# 32
Here is the requested information:
1. I use iPlanet Directory Server 5.1 with service pack 4.
2. uname -a
SunOS bonsai 5.9 Generic_117171-02 sun4u sparc SUNW,Sun-Fire-480R
3. Here is my pam.conf:
loginauth requisite pam_authtok_get.so.1
loginauth requiredpam_dhkeys.so.1
loginauth requiredpam_dial_auth.so.1
loginauth bindingpam_unix_auth.so.1 server_policy
loginauth requiredpam_ldap.so.1
rlogin auth sufficient pam_rhosts_auth.so.1
rlogin auth requisite pam_authtok_get.so.1
rlogin auth requiredpam_dhkeys.so.1
rlogin auth bindingpam_unix_auth.so.1 server_policy
rlogin auth requiredpam_ldap.so.1
rshauth sufficient pam_rhosts_auth.so.1
rshauth requiredpam_unix_auth.so.1
pppauth requisite pam_authtok_get.so.1
pppauth requiredpam_dhkeys.so.1
pppauth requiredpam_unix_auth.so.1
pppauth requiredpam_dial_auth.so.1
otherauth requisite pam_authtok_get.so.1
otherauth requiredpam_dhkeys.so.1
otherauth bindingpam_unix_auth.so.1 server_policy
otherauth requiredpam_ldap.so.1
passwd auth bindingpam_passwd_auth.so.1 server_policy
passwd auth requiredpam_ldap.so.1
cronaccount requiredpam_projects.so.1
cronaccount requiredpam_unix_account.so.1
otheraccount requisitepam_roles.so.1
otheraccount requiredpam_projects.so.1
otheraccount binding pam_unix_account.so.1 server_policy
otheraccount requiredpam_ldap.so.1
othersession requiredpam_unix_session.so.1
otherpassword requiredpam_dhkeys.so.1
otherpassword requisitepam_authtok_get.so.1
otherpassword requisitepam_authtok_check.so.1
otherpassword requiredpam_authtok_store.so.1 server_policy
nsswitch.conf:
-
passwd:files ldap [TRYAGAIN=2]
group:files
hosts:files dns
ipnodes:files
networks:files
protocols: files
rpc:files
ethers:files
netmasks:files
bootparams: files
publickey: files
netgroup:files
automount: files
aliases:files
services:files
sendmailvars:files
printers:user files
auth_attr: files
prof_attr: files
project:files
# 33
These look okay, a couple of thoughts:
1. Have you checked the patch levels as per Gary Tay's postings in this thread?
2. You mentioned that when you removed read access to the userPassword attribute from the proxy-user, users were no longer able to log in except local users.
a) What service are the users logging into? Do you mean via telnet? ssh? connecting to a samba share? Ensure the daemons you are using for these services are compiled to use the PAM and not getent calls as this could cause the symptoms you mentioned. For example with samba you must compile using the --with-pam switch.
b) Check your account lockout and password policy in the directory server for anything that may inadvertantly be locking these accounts. Check the account your testing with for example doesnt have one of the following attributes set (nsaccountlock, nsrole, nsroledn) which would lock the account.
HTH
Gryph
# 34
Hello,
1.The patch levels are OK.
2.a)The users are using ssh.
2.b) nsaccountlock for the revoked test user ist set. That's correct.
I believe the problem is that the bind to the directory server is done by the proxyagent. Therefore the nsaccountlock attribute for a single user will never be used.
# 35
The nsaccountlock attr will be used if you force the use of pam_ldap by sshd:
1. Your ssh daemon is using the pam for authentication
2. your pam.conf is configured for pam_ldap
3. If you are also using pam_unix in the pam.conf as well it is necessary to prevent read access to the userPassword attribute to the proxyagent user.
The standard solaris sshd is configured to use the pam (if you compiled ssh yourself you may need to recompile it to use pam).
pam_ldap only uses proxyagent to bind only it does not need to have read access to the userPassword attr to authenticate the user. pam_unix however uses this attr for authentication but also to know if an account is locked eg. *LK*. The problem is the LDAP server does not set this when locking accounts, instead it uses nsaccountlock, nsrole and nsroledn to designate when an account is locked, so if using the LDAP server for account locking, you must force the use of pam_ldap by your services
So if you want to use the ldap directory for account management as well as authentication, then you have to configure pam_ldap in your pam.conf in both auth and account sections. If you also use pam_unix in your pam.conf, then you will also need to then prevent the proxyagent user from being able to read the userPassword attr in your aci's, this stops pam_unix from being able to read that value and forces authentication to fall thru to pam_ldap, which then uses the nsaccountlock,nsrole,nsroledn attrs to determine if the account is locked prior to authenticating. If you dont do this, pam_unix is able to see this attr which if locked by the LDAP server will still contain a valid password instead of *LK* so it assumes the account is valid and authenticates the user before pam_ldap.
The one gotcha with doing this is that all services you use on the machine will need to be forced to use the pam for authentication otherwise the user will not be able to log in.
Regards
G.
# 36
I wrote in Reply 26:
===
When netgroup is on and tuser is in-activated:
First "Password:" prompt will reject any password
Second "LDAP Password:" prompt WILL ACCEPT ANY PASSWORD?!
login as: tuser
Using keyboard-interactive authentication.
Password: <anything>
LDAP Password: <anything> always succeed
Last login: Fri Aug 5 07:24:53 2005 from XXX.XXX.XXX.XXX
Sun Microsystems Inc. SunOS 5.9 Generic May 2002
$
I have also tried "telnet" same behaviour as "ssh", i.e. succeed with ANY PASSWORD at 2nd prompt. For "ftp", succeed with ANY PASSWORD at 1st prompt.
Not sure if Patrick could tell us if he is using netgroup and what SUN had helped him to workaround this "suspected" bug.
===
Now there is an update: since having DS5.2 Patch 4 (117665-03), this "suspected" bug seems to be gone away.
Gary
