Fedora directory users - Dec 2005 - Account Expiration Warning

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?

Any advice or suggestions?

Also when doing an ldapsearch and binding as an admin user I can not see 
the entries for the passwordXXXXXXX fields.  Is there a certain 
ldapsearch switch to see those?  Possibly an ACI missing on my part?

TIA
-- 
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------

On Dec 21, 2005, at 9:08 AM, Jim Summers wrote
> Also when doing an ldapsearch and binding as an admin user I can  
> not see the entries for the passwordXXXXXXX fields.  Is there a  
> certain ldapsearch switch to see those?  Possibly an ACI missing on  
> my part?
This is by design.  The intent is that certain fields should not be  
returned unless they are explicitly specified.  If you do your search  
like this:

ldapsearch -D admin_user_dn -w admin_user_pw -b base filter *  
passwordexpirationtime

You should get the normal fields plus the passwordexpirationtime.

-jeff

--
Jeff Medcalf
jeff@caerdroia.org

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
and /etc/pam.d/sshd files set up?  Make sure you have 

pam_lookup_policy yes

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

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

> 
> > 
> > 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?
> 
That''s correct, if you can do a ldapsearch and bind as the proxyagent
and you see the userPassword attribute returned, then the directory
server has an ACI that allows read for your proxy agent of the
userPassword attribute.  You can just remove that ACI and it should at
that point not return the userPassword field, and pam_ldap
authentication would take place then.

For example:

ldapsearch -x -h ldapsrv -D "cn=proxyid,dc=blah" -W -b
"ou=people,dc=blah" uid=tulsa

Where -D is the id listed as proxyagent in ldap.conf, and the password
supplied is for that id.  If userPassword is returned then you know what
is going on.

If this is not what is happening, check and make sure you don''t have
rootbinddn and /etc/ldap.secret set up.  If it is actually binding as
your rootdn then that is what it could be as well.


Jamie

Jamie McKnight wrote:
>>>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?
>>
> 
> 
> That''s correct, if you can do a ldapsearch and bind as the
proxyagent
> and you see the userPassword attribute returned, then the directory
> server has an ACI that allows read for your proxy agent of the
> userPassword attribute.  You can just remove that ACI and it should at
> that point not return the userPassword field, and pam_ldap
> authentication would take place then.
> 
> For example:
> 
> ldapsearch -x -h ldapsrv -D "cn=proxyid,dc=blah" -W -b
> "ou=people,dc=blah" uid=tulsa
> 
> Where -D is the id listed as proxyagent in ldap.conf, and the password
> supplied is for that id.  If userPassword is returned then you know what
> is going on.
> 
> If this is not what is happening, check and make sure you don''t
have
> rootbinddn and /etc/ldap.secret set up.  If it is actually binding as
> your rootdn then that is what it could be as well.
Welp, I am stumped.  Running various ldapsearchs I got the results as 
they should be.  Binding as the proxy, no userPassword, binding as an 
admin then I get the userPassword.

I looked in /etc/ and there is not an ldap.secret file, so I guess I do 
not have the rootbinddn setup.

I was thinking of removing the shadowExpire attributes but I am afraid 
if I do that then cron may stop working.

Not sure at this point.

Thanks,
jim

> 
> 
> Jamie
> 
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
-- 
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------

Jim Summers wrote:
>> Where -D is the id listed as proxyagent in ldap.conf, and the password
>> supplied is for that id.  If userPassword is returned then you know
what
>> is going on.
>>
>> If this is not what is happening, check and make sure you
don''t have
>> rootbinddn and /etc/ldap.secret set up.  If it is actually binding as
>> your rootdn then that is what it could be as well.
> 
> 
> Welp, I am stumped.  Running various ldapsearchs I got the results as 
> they should be.  Binding as the proxy, no userPassword, binding as an 
> admin then I get the userPassword.
> 
> I looked in /etc/ and there is not an ldap.secret file, so I guess I do 
> not have the rootbinddn setup.
> 
> I was thinking of removing the shadowExpire attributes but I am afraid 
> if I do that then cron may stop working.
> 
> Not sure at this point.
Was doing some more testing this morning.  Following along in my 
messages file, I noticed that when the testuser logs in, messages are 
being logged with pam_unix as the service, for example:

Dec 22 07:56:03 xxxxxxx sshd(pam_unix)[18339]: check pass; user unknown
Dec 22 07:56:03 xxxxxxx sshd(pam_unix)[18339]: authentication failure; 
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=karp.cs.ou.edu
Dec 22 07:56:03 xxxxxxx sshd(pam_unix)[18342]: session opened for user 
tulsa by (uid=9018)

I did set the following in sshd_config:

PAMAuthenticationViaKbdInt yes

Ideas / Suggestions?

Thanks,
jim




> 
> Thanks,
> jim
> 
> 
>>
>>
>> Jamie
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> 
> 
-- 
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------

On Thu, 2005-12-22 at 08:07 -0600, Jim Summers wrote:
> Jim Summers wrote:
> >> Where -D is the id listed as proxyagent in ldap.conf, and the
password
> >> supplied is for that id.  If userPassword is returned then you
know what
> >> is going on.
> >>
> >> If this is not what is happening, check and make sure you
don''t have
> >> rootbinddn and /etc/ldap.secret set up.  If it is actually binding
as
> >> your rootdn then that is what it could be as well.
> > 
> > 
> > Welp, I am stumped.  Running various ldapsearchs I got the results as 
> > they should be.  Binding as the proxy, no userPassword, binding as an 
> > admin then I get the userPassword.
> > 
> > I looked in /etc/ and there is not an ldap.secret file, so I guess I
do
> > not have the rootbinddn setup.
> > 
> > I was thinking of removing the shadowExpire attributes but I am afraid
> > if I do that then cron may stop working.
> > 
> > Not sure at this point.
> 
> Was doing some more testing this morning.  Following along in my 
> messages file, I noticed that when the testuser logs in, messages are 
> being logged with pam_unix as the service, for example:
> 
> Dec 22 07:56:03 xxxxxxx sshd(pam_unix)[18339]: check pass; user unknown
> Dec 22 07:56:03 xxxxxxx sshd(pam_unix)[18339]: authentication failure; 
> logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=karp.cs.ou.edu
> Dec 22 07:56:03 xxxxxxx sshd(pam_unix)[18342]: session opened for user 
> tulsa by (uid=9018)
> 
That means it has to be getting the user''s encrypted password string
some how.

This is what I would do:

1.  Check the access log and see who the binddn of the connection that
looks up the user is (find the SRCH filter that is looking up the user
id, then grep conn=<that connection number> to see the full connection.
Find the bind associated).  This will verify the proxy account, even
though we have verified that already.

2.  Get a tcpdump of the traffic (tcpdump -i eth0 -s 1500 host ldapsrv
and port ldap ) while you are logging in.  The ''port ldap''
assumes this
is going over 389 unencrypted.  If you are using TLS, you will need to
disable it so you can get a good tcpdump of the LDAP session.  Once you
have this, load it up in ethereal, and start looking at the LDAP
packets.  You will be able to expand out the searches, and results.  The
important thing here is to make sure that when userPassword is requested
(will be several times) that a response is never given in the search
result.

3.  In the console, right-click on the tulsa user, and select "Set
Access Permissions".  When that box comes up, select the "Show
Inherited
ACIs"  Review all those to make sure that some place along the way read
access was not granted to the userPassword attribute.

	If we get this far without figuring it out I will be at a loss.... I am
running out of ideas 8-)

Jamie