Fedora directory users - Nov 2006 - Re: Linux password change/expiration issue

Hi Kyle,

as far as I understand you should not be using the shadowAccount
objectClass attributes to get this behaviour but you should be
configuring the password policies instead.

Best Regards,
Jo

> as far as I understand you should not be using the shadowAccount
> objectClass attributes to get this behaviour 
Thanks. This goes against a lot of the documentation out there.
> but you should be
> configuring the password policies instead.
Are the PADL PAM modules written to be aware of these policies as well as 
the shadowAccount attributes?

-- 
- Kyle 
---------------------------------------------
kylet@panix.com   http://www.panix.com/~kylet    
---------------------------------------------

> 
> as far as I understand you should not be using the shadowAccount
> objectClass attributes to get this behaviour but you should be
> configuring the password policies instead.
Okay, I have spent a couple hours with DS''s password policy and 
do not like it. Why are shadowAccount attributes in the schema
and allowed if not to be used? It seems OpenLDAP supports them.

-- 
- Kyle 
---------------------------------------------
kylet@panix.com   http://www.panix.com/~kylet    
---------------------------------------------

On Wed, Nov 01, 2006 at 02:50:14PM +0100, Jo De Troy
wrote:
> 
> as far as I understand you should not be using the shadowAccount
> objectClass attributes to get this behaviour but you should be
> configuring the password policies instead.
Hi all,
	Sorry to be a pest with this, but I am so close. I went back
to using shadowAccount and have it all behaving just as I need with
one acception. When a client uses successfully changes their password,
the userPassword attribute is changed in LDAP, but the shadowLastChange
is not updated to the current day, and the password is still being
interpreted as expired. This occurs with FDS 1.0.2 and 1.0.3. So I am
not chasing an unattainable goal, should shadowLastChange be getting
updated at the same time and procedure as is userPassword? Thanks.

-- 
- Kyle 
---------------------------------------------
kylet@panix.com   http://www.panix.com/~kylet    
---------------------------------------------

One possible issue:
Does your ACI set allow shadowLastChange to be written?
To test, you could add a very permissive ACI that allows anyone to write 
shadowLastChange.  If that helps, then hone down the ACI.  I think all you 
should need is self-write for shadowLastChange, but I''m not 100% sure.


----- Original Message ----- 
From: "Kyle Tucker" <kylet@panix.com>
To: "General discussion list for the Fedora Directory server project."
<fedora-directory-users@redhat.com>
Sent: Saturday, November 04, 2006 11:11 AM
Subject: Re: [Fedora-directory-users] Linux password change/expiration issue
> Hi all,
> Sorry to be a pest with this, but I am so close. I went back
> to using shadowAccount and have it all behaving just as I need with
> one acception. When a client uses successfully changes their password,
> the userPassword attribute is changed in LDAP, but the shadowLastChange
> is not updated to the current day, and the password is still being
> interpreted as expired. This occurs with FDS 1.0.2 and 1.0.3. So I am
> not chasing an unattainable goal, should shadowLastChange be getting
> updated at the same time and procedure as is userPassword? Thanks.
>
> -- 
> - Kyle
> ---------------------------------------------
> kylet@panix.com   http://www.panix.com/~kylet
> ---------------------------------------------

Bingo. In the admin console, I manually edited the top domain in the
Directory tab using Set Access Permissions and Enable self write for
common attributes, and added shadowLastChange and it updates fine 
along with userPassword now. Thanks so much.

aci: (targetattr = "carLicense ||description ||displayName
||facsimileTelephon
 eNumber ||homePhone ||homePostalAddress ||initials ||jpegPhoto ||labeledURL |
 |mail ||mobile ||pager ||photo ||postOfficeBox ||postalAddress ||postalCode |
 |preferredDeliveryMethod ||preferredLanguage ||registeredAddress ||roomNumber
  ||secretary ||seeAlso ||st ||street ||telephoneNumber ||telexNumber ||title
 ||userCertificate ||userPassword ||shadowLastChange ||userSMIMECertificate ||
 x500UniqueIdentifier") (version 3.0;acl "Enable self write for common
attribu
 tes";allow (write)(userdn = "ldap:///self");)

> One possible issue:
> Does your ACI set allow shadowLastChange to be written?
> To test, you could add a very permissive ACI that allows anyone to write 
> shadowLastChange.  If that helps, then hone down the ACI.  I think all you 
> should need is self-write for shadowLastChange, but I''m not 100%
sure.
> 
> 
> ----- Original Message ----- 
> From: "Kyle Tucker" <kylet@panix.com>
> To: "General discussion list for the Fedora Directory server
project."
> <fedora-directory-users@redhat.com>
> Sent: Saturday, November 04, 2006 11:11 AM
> Subject: Re: [Fedora-directory-users] Linux password change/expiration
issue
> 
> > Hi all,
> > Sorry to be a pest with this, but I am so close. I went back
> > to using shadowAccount and have it all behaving just as I need with
> > one acception. When a client uses successfully changes their password,
> > the userPassword attribute is changed in LDAP, but the
shadowLastChange
> > is not updated to the current day, and the password is still being
> > interpreted as expired. This occurs with FDS 1.0.2 and 1.0.3. So I am
> > not chasing an unattainable goal, should shadowLastChange be getting
> > updated at the same time and procedure as is userPassword? Thanks.
> >
> > -- 
> > - Kyle
> > ---------------------------------------------
> > kylet@panix.com   http://www.panix.com/~kylet
> > ---------------------------------------------
> 
> 
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> 

-- 
- Kyle 
---------------------------------------------
kylet@panix.com   http://www.panix.com/~kylet    
---------------------------------------------

Kyle Tucker wrote:
> Bingo. In the admin console, I manually edited the top domain in the
> Directory tab using Set Access Permissions and Enable self write for
> common attributes, and added shadowLastChange and it updates fine 
> along with userPassword now. Thanks so much.
>
> aci: (targetattr = "carLicense ||description ||displayName
||facsimileTelephon
>  eNumber ||homePhone ||homePostalAddress ||initials ||jpegPhoto
||labeledURL |
>  |mail ||mobile ||pager ||photo ||postOfficeBox ||postalAddress
||postalCode |
>  |preferredDeliveryMethod ||preferredLanguage ||registeredAddress
||roomNumber
>   ||secretary ||seeAlso ||st ||street ||telephoneNumber ||telexNumber
||title
>  ||userCertificate ||userPassword ||shadowLastChange ||userSMIMECertificate
||
>  x500UniqueIdentifier") (version 3.0;acl "Enable self write for
common attribu
>  tes";allow (write)(userdn = "ldap:///self");)
>   
Good to see you got this working, could I per chance persuade you to 
write this up for the wiki?

:)

-- 
Pete