Jamie McKnight wrote: > On Wed, 2005-12-21 at 09:08 -0600, Jim Summers wrote: > >>Hello List, >> >>Having been troubled in the past with account expiration on an >>iplanet5.1 server with linux clients, I wanted to get this working >>during my evaluation / testing of FDS. >> >>I have enabled the password policy on the FDS and set the ldap.conf >>entries necessary to get this working. Upon doing this and then >>logging in and out, new fields appear in the people container for that >>account. Such as passwordexpirationtime, passwordretrycount, etc... All >>is working, such as, a passwd change will update the necessary fields >>for the correct length of time reset counts, etc... >> >>When testing the password expiration warning I stumbled onto the issue, >>that I do not get an actual "Your password will expire in XX days" >>message. I do see where the field, passwordexpwarned is set to "1", but >>I do not ever get an actual message. >> >>The way I am testing is to set the policy to warn the user, 3 days in >>advance. Then I set the passwordexpiratontime to a date less than three >>days away. Then attempt to log in. Login is ok, but no warning of the >>impending doom about to strike the account. >> >>If I actually set the expirationtime to a time less than the current, >>then I can login until passwordusergracetime is GE the allowed number of >>logins after the password expiration. At which time I get a message >>that the password expired and it must be changed immediately, at which >>time the connection immediately closes and the password cannot be changed! >> >>No log entries in error, so I am not sure what I have overlooked? >> > > > I just tested this against FDS 1.0.1 with CentOS 4.2 as the client. I > can get it to spit out the "Your LDAP password will expire in blah days" > message. How is your /etc/ldap.conf and /etc/pam.d/system-auth =SYSTEM_AUTH= #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/$ISA/pam_ldap.so password required /lib/security/$ISA/pam_cracklib.so retry=3 type= password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_ldap.so use_authtok password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_ldap.so ============= > and /etc/pam.d/sshd files set up? =SSHD= #%PAM-1.0 auth required pam_stack.so service=system-auth auth required pam_nologin.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_selinux.so session required pam_stack.so service=system-auth session required pam_limits.so session optional pam_console.so ============= Make sure you have > > pam_lookup_policy yes Verified. > > in /etc/ldap.conf, and that your pam stack is set up for pam_ldap > authentication. Also, if you are using a proxy agent, the proxy agent > must not be able to see the userPassword attribute, or you will end up > authenticating via pam_unix, and not pam_ldap. This could be the problem. I am using a proxy and not sure how to test what you are saying. If I do an ldasearch such as: ldapsearch -x -ZZ '(uid=tulsa)' then that should bind via the entries in ldap.conf hence use the config'd proxy, correct? Then if that search shows a userPassword then that would confirm pam_unix usage? Not sure how to stop it if it is using pam_unix? Thanks, jim If you have all of this > setup this way already, I am not sure why you don't see the warning. > > In my testing however, I did notice something happening that should not > be. I set the time in passwordexpirationtime to tomorrow, and the > password policy is set to warn 14 days before the password expires. On > my first login I get the message: > > Your LDAP password will expire in 14 days. > > Which is not correct, it should have said '1 day'. After this message > is sent, my next login shows this: > > Your LDAP password will expire in 13 days. > > Which is still not correct. Looking at the entry at this point shows > that it reset the passwordexpirationtime to something in the future > (roughly looks like 14 days, which matches what I put in for warn days), > which is also not something that should be done. passwordexpirationtime > attribute should only be modified when the user actually > modifies/changes their password. > > Not sure how to start helping with getting info to the right folks to > help troubleshoot/fix this, but I am willing to help out as much as I > can. > > I know this works in SunOne Directory Server 5.2 with RHEL3/4 and > Solaris 8/9 clients so I am pretty certain this is not an issue on the > client end (although I have been know to be wrong on occasion 8-). > > Jamie > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -- Jim Summers School of Computer Science-University of Oklahoma -------------------------------------------------
