[Fedora-directory-users] Account Expiration Warning

[Jim Summers]

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
-------------------------------------------------