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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
