[Fedora-directory-users] SSH login and pwd expiration message

[Jo De Troy]

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

[Kyle Tucker]

>  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(a)panix.com   http://www.panix.com/~kylet    
---------------------------------------------

[Steve Rigler]

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

[Kyle Tucker]

>  > 
>  > 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(a)panix.com   http://www.panix.com/~kylet    
---------------------------------------------

[Steve Rigler]

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