Always asked to update password at login Utopia

[Rafael A Barrero]

Hi all;

I've done my best to find a solution on my own, but I haven't found  
the help I'm looking for. I'm hoping I can get this easily resolved  
by throwing this out to the community.

After creating the user with the below schema, the system ALWAYS  
prompts the user to change his/her password at any login (local or  
remote)... at every login attempt. I can see that 'shadowLastChange'  
is updated properly, but somehow this is making no difference. I've  
found that if I set 'shadowMax' to '99999', I don't get this  
behaviour - however, that isn't really a password policy. I need the  
90 password update policy in place to deploy my OpenLDAP system.

I want the system to bug the user about requiring a password change  
IF the password is really aged and within the 'shadowWarning' threshold.

Am I missing attributes? How can I get my desired password policy to  
work?

Please help!!  Much Appreciated!

-Rafael.

Below is the schema I'm using for our users:

###
dn: uid=testuser,ou=Sys Eng,dc=xxx,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
sn: User
cn: Test User
title: Test Engineer
telephoneNumber: [phone]
street: 1111 Hope St
postalCode: 99999
physicalDeliveryOfficeName: Utopia
ou: Sys Eng
st: CA
l: Utopia
displayName: Test User
employeeType: DIRECT
givenName: Test
jpegPhoto: ~
mail: testuser@...
manager: cn=Test Manager,ou=Users,ou=Utopia,ou=Sites,dc=xxx,dc=com
mobile: [phone]
uid: testuser
userPassword:: e01ENX1DWTlyelVZaDAzUEszazZESmllMDlnPT0=
loginShell: /bin/bash
uidNumber: 502
gidNumber: 100
homeDirectory: /home/testuser
gecos: Test User
shadowLastChange: 1
shadowMax: 90
shadowMin: 14
shadowWarning: 14
description: test user
###

[Christopher J. Stephens]

Is the shadowLastChange really set to "1"? This should be the number of
days since the epoch that the password was changed (we're at around
13450ish now.)
Chris

Rafael A Barrero wrote:

> Hi all;
>
> I've done my best to find a solution on my own, but I haven't found
> the help I'm looking for. I'm hoping I can get this easily resolved
> by throwing this out to the community.
>
> After creating the user with the below schema, the system ALWAYS
> prompts the user to change his/her password at any login (local or
> remote)... at every login attempt. I can see that 'shadowLastChange'
> is updated properly, but somehow this is making no difference. I've
> found that if I set 'shadowMax' to '99999', I don't get this
> behaviour - however, that isn't really a password policy. I need the
> 90 password update policy in place to deploy my OpenLDAP system.
>
> I want the system to bug the user about requiring a password change
> IF the password is really aged and within the 'shadowWarning' threshold.
>
> Am I missing attributes? How can I get my desired password policy to
> work?
>
> Please help!!  Much Appreciated!
>
> -Rafael.
>
> Below is the schema I'm using for our users:
>
> ###
> dn: uid=testuser,ou=Sys Eng,dc=xxx,dc=com
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: posixAccount
> objectClass: shadowAccount
> sn: User
> cn: Test User
> title: Test Engineer
> telephoneNumber: [phone]
> street: 1111 Hope St
> postalCode: 99999
> physicalDeliveryOfficeName: Utopia
> ou: Sys Eng
> st: CA
> l: Utopia
> displayName: Test User
> employeeType: DIRECT
> givenName: Test
> jpegPhoto: ~
> mail: testuser@...
> manager: cn=Test Manager,ou=Users,ou=Utopia,ou=Sites,dc=xxx,dc=com
> mobile: [phone]
> uid: testuser
> userPassword:: e01ENX1DWTlyelVZaDAzUEszazZESmllMDlnPT0=
> loginShell: /bin/bash
> uidNumber: 502
> gidNumber: 100
> homeDirectory: /home/testuser
> gecos: Test User
> shadowLastChange: 1
> shadowMax: 90
> shadowMin: 14
> shadowWarning: 14
> description: test user
> ###
>
>
>

--
-----------------------------------
Chris Stephens
Unix Systems Administrator
-----------------------------------
Phone: [phone]
Pager: 104-2526
Email: chriss@...
-----------------------------------

[Rafael A Barrero]

Chris,

Correct, this is an incorrect value. However, it does update properly when 'passwd' is called AND makes no difference regarding my issue of asking to update the password at every login.

It seems shadowMax isn't being respected and therefore giving the "password aged" error not matter what values I place for shadowLastChange.

Thanks,

-Rafael.

Sent via BlackBerry from T-Mobile  

-----Original Message-----
From: "Christopher J. Stephens" <chriss@...>
Date: Tue, 31 Oct 2006 10:20:55
To:Rafael A Barrero <rafa@...>
Cc:pamldap@...
Subject: Re: [pamldap] Always asked to update password at login  Utopia

Is the shadowLastChange really set to "1"? This should be the number of
days since the epoch that the password was changed (we're at around
13450ish now.)
Chris

Rafael A Barrero wrote:

> Hi all;
>
> I've done my best to find a solution on my own, but I haven't found
> the help I'm looking for. I'm hoping I can get this easily resolved
> by throwing this out to the community.
>
> After creating the user with the below schema, the system ALWAYS
> prompts the user to change his/her password at any login (local or
> remote)... at every login attempt. I can see that 'shadowLastChange'
> is updated properly, but somehow this is making no difference. I've
> found that if I set 'shadowMax' to '99999', I don't get this
> behaviour - however, that isn't really a password policy. I need the
> 90 password update policy in place to deploy my OpenLDAP system.
>
> I want the system to bug the user about requiring a password change
> IF the password is really aged and within the 'shadowWarning' threshold.
>
> Am I missing attributes? How can I get my desired password policy to
> work?
>
> Please help!!  Much Appreciated!
>
> -Rafael.
>
> Below is the schema I'm using for our users:
>
> ###
> dn: uid=testuser,ou=Sys Eng,dc=xxx,dc=com
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: posixAccount
> objectClass: shadowAccount
> sn: User
> cn: Test User
> title: Test Engineer
> telephoneNumber: [phone]
> street: 1111 Hope St
> postalCode: 99999
> physicalDeliveryOfficeName: Utopia
> ou: Sys Eng
> st: CA
> l: Utopia
> displayName: Test User
> employeeType: DIRECT
> givenName: Test
> jpegPhoto: ~
> mail: testuser@...
> manager: cn=Test Manager,ou=Users,ou=Utopia,ou=Sites,dc=xxx,dc=com
> mobile: [phone]
> uid: testuser
> userPassword:: e01ENX1DWTlyelVZaDAzUEszazZESmllMDlnPT0=
> loginShell: /bin/bash
> uidNumber: 502
> gidNumber: 100
> homeDirectory: /home/testuser
> gecos: Test User
> shadowLastChange: 1
> shadowMax: 90
> shadowMin: 14
> shadowWarning: 14
> description: test user
> ###
>
>
>

--
-----------------------------------
Chris Stephens
Unix Systems Administrator
-----------------------------------
Phone: [phone]
Pager: 104-2526
Email: chriss@...
-----------------------------------

[Rafael A Barrero]

Wow, that easy, eh?

I guess the error messages saying 'days' really mislead me. Plus, the nis.schema should really include this bit of information... Not to mention shadowLastChange is done in days.

Well, after making that change, it seems to work now! :-) I ran a quick test by changing the values around and did get the appropriate warnings.

How does nss_ldap keep track of shadowMax? What is its reference? Does it update it occasionally?

Thanks for the help!

-Rafael.



Sent via BlackBerry from T-Mobile  

-----Original Message-----
From: "Kevin Babcock" <Kevin_Babcock@...>
Date: Tue, 31 Oct 2006 11:05:47
To:"Rafael A Barrero" <rafa@...>
Subject: Re: [pamldap] Always asked to update password at login  Utopia

> I've done my best to find a solution on my own, but I haven't found
> the help I'm looking for. I'm hoping I can get this easily resolved
> by throwing this out to the community.
>
> After creating the user with the below schema, the system ALWAYS
> prompts the user to change his/her password at any login (local or
> remote)... at every login attempt. I can see that 'shadowLastChange'
> is updated properly, but somehow this is making no difference. I've
> found that if I set 'shadowMax' to '99999', I don't get this
> behaviour - however, that isn't really a password policy. I need the
> 90 password update policy in place to deploy my OpenLDAP system.
>
> I want the system to bug the user about requiring a password change
> IF the password is really aged and within the 'shadowWarning' threshold.
>
> Am I missing attributes? How can I get my desired password policy to
> work?
>
> Please help!!  Much Appreciated!

Under pam_ldap, the shadowMax and shadowWarning attributes store values in seconds.  For 90 days, you need to use 90 * 86400 = 7776000.

-Kevin

[Piotr KUCHARSKI]

On Tue, Oct 31, 2006 at 08:05:17PM +0000, rafa@... wrote:
> Under pam_ldap, the shadowMax and shadowWarning attributes store
> values in seconds.  For 90 days, you need to use 90 * 86400 = 7776000.

Since when? :o

pam_ldap-182 obviously is doing it in days:

  currentday = (long int) (currenttime / SECSPERDAY);

      if (currentday >= session->info->shadow.expire)
          return PAM_ACCT_EXPIRED;

      if (currentday >= (session->info->shadow.lstchg +
                         session->info->shadow.max +
                         session->info->shadow.inact))
          return PAM_ACCT_EXPIRED;

      if (currentday >= (session->info->shadow.lstchg +
                         session->info->shadow.max))
          session->info->policy_error = POLICY_ERROR_PASSWORD_EXPIRED;

p.

--
Beware of he who would deny you access to information, for in his
heart he dreams himself your master.   -- Commissioner Pravin Lal

[Rafael A Barrero]

Hi guys;

Interesting comment... can't really disagree with you by looking at  
that particular snippet of code. Practically speaking, if it's doing  
it in days, it doesn't seem to respect the threshold I'm setting  
(shadowMax: 90).

At least in seconds, it appears to be behaving as expected.

I would appreciate any other insightful feedback to determine a  
definitive answer to the topic.

Thanks,

- Rafael.



On Oct 31, 2006, at 3:36 PM, Piotr KUCHARSKI wrote:

> On Tue, Oct 31, 2006 at 08:05:17PM +0000, rafa@... wrote:
>> Under pam_ldap, the shadowMax and shadowWarning attributes store
>> values in seconds.  For 90 days, you need to use 90 * 86400 =  
>> 7776000.
>
> Since when? :o
>
> pam_ldap-182 obviously is doing it in days:
>
>   currentday = (long int) (currenttime / SECSPERDAY);
>
>       if (currentday >= session->info->shadow.expire)
>           return PAM_ACCT_EXPIRED;
>
>       if (currentday >= (session->info->shadow.lstchg +
>                          session->info->shadow.max +
>                          session->info->shadow.inact))
>           return PAM_ACCT_EXPIRED;
>
>       if (currentday >= (session->info->shadow.lstchg +
>                          session->info->shadow.max))
>           session->info->policy_error = POLICY_ERROR_PASSWORD_EXPIRED;
>
> p.
>
> --
> Beware of he who would deny you access to information, for in his
> heart he dreams himself your master.   -- Commissioner Pravin Lal

[Howard Chu]

Rafael A Barrero wrote:

> Hi guys;
>
> Interesting comment... can't really disagree with you by looking at
> that particular snippet of code. Practically speaking, if it's doing
> it in days, it doesn't seem to respect the threshold I'm setting
> (shadowMax: 90).
>
> At least in seconds, it appears to be behaving as expected.
>
> I would appreciate any other insightful feedback to determine a
> definitive answer to the topic.

Read the shadow(5) manpage. All times are in days. The RFC2307 schema
just puts that data straight into LDAP, with no conversion to anything
else. (Although it really ought to have converted to seconds, for full
compatibility with other Unix password security implementations.)

>
> Thanks,
>
> - Rafael.
>
>
>
> On Oct 31, 2006, at 3:36 PM, Piotr KUCHARSKI wrote:
>
>> On Tue, Oct 31, 2006 at 08:05:17PM +0000, rafa@... wrote:
>>> Under pam_ldap, the shadowMax and shadowWarning attributes store
>>> values in seconds.  For 90 days, you need to use 90 * 86400 = 7776000.
>>
>> Since when? :o
>>
>> pam_ldap-182 obviously is doing it in days:
>>
>>   currentday = (long int) (currenttime / SECSPERDAY);
>>
>>       if (currentday >= session->info->shadow.expire)
>>           return PAM_ACCT_EXPIRED;
>>
>>       if (currentday >= (session->info->shadow.lstchg +
>>                          session->info->shadow.max +
>>                          session->info->shadow.inact))
>>           return PAM_ACCT_EXPIRED;
>>
>>       if (currentday >= (session->info->shadow.lstchg +
>>                          session->info->shadow.max))
>>           session->info->policy_error = POLICY_ERROR_PASSWORD_EXPIRED;
>>
>> p.
>>
>> --
>> Beware of he who would deny you access to information, for in his
>> heart he dreams himself your master.   -- Commissioner Pravin Lal
>

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/

[Rafael A Barrero]

Okay, let's say it's in days. Why does my initial setup not work?
-Rafael.


On Oct 31, 2006, at 8:27 PM, Howard Chu wrote:

> Rafael A Barrero wrote:
>> Hi guys;
>>
>> Interesting comment... can't really disagree with you by looking  
>> at that particular snippet of code. Practically speaking, if it's  
>> doing it in days, it doesn't seem to respect the threshold I'm  
>> setting (shadowMax: 90).
>>
>> At least in seconds, it appears to be behaving as expected.
>>
>> I would appreciate any other insightful feedback to determine a  
>> definitive answer to the topic.
>
> Read the shadow(5) manpage. All times are in days. The RFC2307  
> schema just puts that data straight into LDAP, with no conversion  
> to anything else. (Although it really ought to have converted to  
> seconds, for full compatibility with other Unix password security  
> implementations.)
>>
>> Thanks,
>>
>> - Rafael.
>>
>>
>>
>> On Oct 31, 2006, at 3:36 PM, Piotr KUCHARSKI wrote:
>>
>>> On Tue, Oct 31, 2006 at 08:05:17PM +0000, rafa@... wrote:
>>>> Under pam_ldap, the shadowMax and shadowWarning attributes store
>>>> values in seconds.  For 90 days, you need to use 90 * 86400 =  
>>>> 7776000.
>>>
>>> Since when? :o
>>>
>>> pam_ldap-182 obviously is doing it in days:
>>>
>>>   currentday = (long int) (currenttime / SECSPERDAY);
>>>
>>>       if (currentday >= session->info->shadow.expire)
>>>           return PAM_ACCT_EXPIRED;
>>>
>>>       if (currentday >= (session->info->shadow.lstchg +
>>>                          session->info->shadow.max +
>>>                          session->info->shadow.inact))
>>>           return PAM_ACCT_EXPIRED;
>>>
>>>       if (currentday >= (session->info->shadow.lstchg +
>>>                          session->info->shadow.max))
>>>           session->info->policy_error =  
>>> POLICY_ERROR_PASSWORD_EXPIRED;
>>>
>>> p.
>>>
>>> --
>>> Beware of he who would deny you access to information, for in his
>>> heart he dreams himself your master.   -- Commissioner Pravin Lal
>>
>
>
> --
>  -- Howard Chu
>  Chief Architect, Symas Corp.  http://www.symas.com
>  Director, Highland Sun        http://highlandsun.com/hyc
>  OpenLDAP Core Team            http://www.openldap.org/project/
>

[Luke Howard]

>Read the shadow(5) manpage. All times are in days. The RFC2307 schema
>just puts that data straight into LDAP, with no conversion to anything
>else. (Although it really ought to have converted to seconds, for full
>compatibility with other Unix password security implementations.)

And/or used generalizedTime...

Oh well.

-- Luke

--
www.padl.com | www.lukehoward.com