Fedora directory users - Dec 2006 - SSH login and pwd expiration message

Hello,

I''ve configured a RHEL3 as LDAP client to my FedoraDS 1.0.2 on RHEL4.
When I login via ssh with an LDAP account on the ldapclient I immediately get
You are required to change your password immediately (password aged)
Your password has expired, the session cannot proceed.
You must change your password now and login again!

After that I change the password and login again and I get the same error again.
Any idea what''s causing this? Is it an ACL that''s preventing
some
attributes to be updates? Which attributes? If I just for testing
delete these attributes I should get rid of this message, shouldn''t I?

Thanks in advance,
Jo

> I''ve configured a RHEL3 as LDAP client to my FedoraDS 1.0.2 on
RHEL4.
> When I login via ssh with an LDAP account on the ldapclient I immediately
get
> You are required to change your password immediately (password aged)
> Your password has expired, the session cannot proceed.
> You must change your password now and login again!
> 
> After that I change the password and login again and I get the same error
again.
> Any idea what''s causing this? Is it an ACL that''s
preventing some
> attributes to be updates? Which attributes? If I just for testing
> delete these attributes I should get rid of this message,
shouldn''t I?
Assuming you''re using shadowAccount attributes for your password
expiry, you
are seeing just what I saw until "write for self" access was given to
users
to up the shadowLastChange attribute. Here''s how I fixed it in admin
console.

In Directory tab, select root domain

Right click and select "Set Access Permissions"

Select "Enable self-write for common attributes" and click on Edit

After "userPassword", insert "|| shadowLastChange " and
click on OK and
again on OK on the parent window.

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

On Tue, 2006-12-05 at 12:28 -0500, Kyle Tucker wrote:
> Assuming you''re using shadowAccount attributes for your password
expiry, you
> are seeing just what I saw until "write for self" access was
given to users
> to up the shadowLastChange attribute. Here''s how I fixed it in
admin console.
> 
> In Directory tab, select root domain
> 
> Right click and select "Set Access Permissions"
> 
> Select "Enable self-write for common attributes" and click on
Edit
> 
> After "userPassword", insert "|| shadowLastChange " and
click on OK and
> again on OK on the parent window.
The problem we had with using the shadow attributes is that not all
platforms honor them (I don''t recall seeing Solaris update
shadowLastChange).  You''d also need to remember to update the
shadowLastChange attribute manually if you reset a user''s password by
some mechanism outside of PAM (from the Administrator''s Console, for
example).

-Steve

> > 
> > After "userPassword", insert "|| shadowLastChange
" and click on OK and
> > again on OK on the parent window.
> 
> The problem we had with using the shadow attributes is that not all
> platforms honor them (I don''t recall seeing Solaris update
> shadowLastChange). 
Well that''s unsettling. I''d have thought the nss_ldap would
provide
adherence to RFC2307, where I believe shadowAccount to be outlined,
across platforms. And I''d have thought Solaris to support it foremost.
My implementations have been all Linux, but I know what I am going to 
test next.
> You''d also need to remember to update the
> shadowLastChange attribute manually if you reset a user''s password
by
> some mechanism outside of PAM (from the Administrator''s Console,
for
> example).
Yes, I set this to today''s date in my management scripts for command
line account maintenance. 

FWIW, these scripts, and their templates, are here if anyone finds any use 
for them.

http://www.panix.com/~kylet/ldap

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

On Tue, 2006-12-05 at 13:31 -0500, Kyle Tucker wrote:
> > The problem we had with using the shadow attributes is that not all
> > platforms honor them (I don''t recall seeing Solaris update
> > shadowLastChange). 
> 
> Well that''s unsettling. I''d have thought the nss_ldap
would provide
> adherence to RFC2307, where I believe shadowAccount to be outlined,
> across platforms. And I''d have thought Solaris to support it
foremost.
> My implementations have been all Linux, but I know what I am going to 
> test next.
I was testing in conjunction with password policies enforced by the
directory since I don''t consider using the shadow attributes a full-
proof means of handling password aging (nothing to stop the user from
updating shadowLastChange if they don''t feel like changing their
password every x days).  IIRC, Solaris wanted every account to be a
shadowAccount, but it didn''t seem to care about any of the values that
shadow provides.  Maybe it ignores shadow if their is a password policy
in place...

All of the platforms I''ve tested (RHEL 3, RHEL 4, Solaris 8/9, and
Irix)
were happy with the password policies enforced by the directory.

-Steve