• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 6010
  • Last Modified:

"You are required to change your password immediately (password aged)"

All, I have an LDAP server (RHEL 5) working with two clients. However, I keep getting the "You are required to change your password immediately (password aged)" message every so often at login on my LINUX client (RHEL 5). I then change the password. It sticks for a while and then a few logins later, I get this same message prompting me to change the password. What's going on here? I explicitly set the password age/length etc in PAM on the client. Does this have something to do with the shadowPassword settings/permissions? Any suggestions? Thanks.
0
jazzki
Asked:
jazzki
  • 11
  • 8
1 Solution
 
arnoldCommented:
Double check to what the password aging is set to on the LDAP server.
Password aging in PAM looks at the age of password in the shadow file as you reference, but you are using LDAP for user authentication.
See whether the password change you make propagates back to the LDAP server.

http://www.openldap.org/lists/openldap-software/200510/msg00416.html

0
 
omarfaridCommented:
the password expiry date is in the /etc/shadow file in the fifth field. you may set it to 99999, and aging will stop
0
 
jazzkiAuthor Commented:
I did setup password aging on the server in the slapd.conf file using the proper:

"access to attrs=shadowLastChange" lines
I also set the "shadowMax" attribute in the ldif file when running slapadd to create the LDAP accounts in the LDAP server's DB. What else could I be doing wrong??
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
arnoldCommented:
When you change the password, the date for the password might not be resetting to the new date.

There should not be any password expire rule on the local system unless you want it to enforce local user password expiration.

Check the current age of the password for the user on the LDAP server to see whether the expiry notice is coming from the LDAP setting or from the local system.
0
 
jazzkiAuthor Commented:
I must be really missing something here, because neither my /etc/shadow and /etc/passwd files are showing different dates on either the client OR the LDAP server after I've changed the LDAP server. I also got rid of the password expiration rules I put into /etc/login.defs on the client. That made no difference.
0
 
jazzkiAuthor Commented:
Excuse me, to clarify my last comment, the dates are not changing when I change the password. That is what I meant to say.
0
 
jazzkiAuthor Commented:
FYI, I don't know if this would have any adverse effect, but in the ldif file that I used slapadd on, I have a MD5-encrypted password entry for each of the users in there.
0
 
arnoldCommented:
the passwords are encrypted in LDAP, but when the password is changed, does the password's age also altered?  
http://linux.derkeiler.com/Mailing-Lists/RedHat/2008-02/msg00007.html
http://webui.sourcelabs.com/centos/mail/user/threads/password_aging_for_openldap_in_Centos_4.5.meta

The change password process might not be adding the new effective date of the password on the LDAP server.
0
 
jazzkiAuthor Commented:
All, I am totally confused now and don't know what to think now. I tried something different. As root, I logged into the LDAP server and using ldappasswd as a test, changed the password for a test user to "password1". I then did the same on the client terminal except the password was changed to just "foobar" using system-config-users. This user has an account on the server and the client, and I am simply using the LDAP server for authentication so that the user may access their resources on the client. Now when I tried to login to the client terminal this time, I tried 4 things:

1) Login to the client terminal with a password that is neither on the client OR the server for that user
2) Login to the client terminal with the password that was set on the client
3) Login to the client terminal with the password that was set on the LDAP server
4) Change the password on the client via command line with the "passwd" command.

Here is what happened:

1) When I used a bad password that was neither the client's OR the server's, it correctly rejected the login attempt. I later logged into the LDAP server to look at /var/log/ldap.log and the attempt showed up.

2) AND 3) It accepted EITHER password that was set on the client or the one that was set through ldappasswd on the server. In either case, it showed the attempt and successful login, in /var/log/ldap.log.

4) This was where it got interesting. When issuing the passwd command in a terminal window on the client, 2 different prompts came up. The first prompt seemed to be for the local machine and the second prompt seemed to be for the ldap server. I confirmed this by using different passwords. Specifically, if I put in the password that was set on the client machine, then I was able to get to the second prompt without being rejected. Once I did this, I would put in the SAME password for the second prompt, which specifically said, "Enter current password(LDAP)". It would then reject it. Now if I entered the client password for this user at the first prompt and then the ldap server's password for this user at the second prompt, then I would be allowed to change the password with "new password:" and "confirm new password:". I confirmed that the password change went through on the ldap server's logs as described above. Sorry if this all sounds confusing as I've described it as best I can.

I am confused by all of this because I don't see a timestamp change on either the /etc/passwd or the /etc/shadow files on the client OR the ldap server. WHERE on earth is this change being propagated to? LDAP database files? If that's the case, I thought that LDAP USES the /etc/passwd and /etc/shadow files. As an FYI I am also using PAM. Admittedly I am a newbie to using LDAP so you'll have to pardon my ignorance if I am missing something fundamental here.

Finally, the other thing I suspected was that this has to do with the /etc/nsswitch.conf file. My nsswitch.conf file reads as follows:

passwd:   files   ldap
shadow:   files   ldap
group:       files   ldap

So the way I understood this change I made to be, was that it checks to local system first for authentication credentials, and then checks the ldap server. Is that why when I try to login to the client terminal, it accepts one of two different passwords? Secondly, if I were to simply change it to

passwd:     ldap
shadow:     ldap
group:         ldap

Would that not force the client to authenticate STRICTLY  off of the LDAP server alone?  Just as an FYI, I have read all of the horror stories of trying to get OpenLDAP running on RHEL 5 and that I probably should know better. I also upgraded to OpenLDAP 2.3.43 on my server and client. Any insight you all have would be greatly appreciated. Thanks.
0
 
arnoldCommented:
LDAP has its own file structure likely under /var/ldap.

The /etc/shadow and /etc/passwd are local user settings.
LDAP is a directory.


The issue is that you have two users with the same prefix
i.e. local username and username@LDAP
These are two distinct and separate users
You of course can configure both to have the same UID and home directory.

You should not have username in both local and LDAP at the same time.
0
 
jazzkiAuthor Commented:
Arnold,
    Thanks so much for the clarification. I have a couple questions though. I have already set up accounts both on the server AND clients for users. These users have data and resources that they need AND use on both. That being said, I don't want to have to wipe out their accounts on either the clients or the server. If I were to simply change the UID on the same name (from client to server), would that change things for me? Or is it strictly username dependent? Thanks.
0
 
arnoldCommented:
Did not pay enough attention to your nsswitch portion of the prior post.
files should always be included in as an option for the shadow,passwd, group and hosts just in case the ldap/dns server becomes inaccessible by the system you will still have a local account that you can use to login into the system to see what the problem is. i.e. the network interface become disabled.

Actually the system is more uid, gid, homedir dependent. Files store the numeric UID/GID.  The system using nsswitch gets the username/group when listing files either from /etc/passwd or a directory service.

Test it out on a user that exists in both LDAP and local.
Double check which entries the user has:
UID, GID, Homedir, Shell in LDAP and /etc/passwd.

You can match the LDAP to the /etc/passwd and then remove the entry from /etc/passwd and /etc/shadow.
You can always chown -Rh UID:GID /home/username to match the settings in LDAP if you do not want to alter the UID/GID to match the settings from /etc/passwd.

Once you are satisfied, you can repeat the above for all others users.
I would suggest that various services (mail, ftp, http, etc.)  and the root account should remain local on the system rather than LDAP based.

To your points dealing with client/server.
The client being their workstation?
The server being a shared space? Or do they actually login into the server?

LDAP provides for a central point from which User accounts can be managed.
i.e. LDAP users would be able to login into any LDAP dependent system unless the system is configured with restrictions i.e. only allow members of groupA to login.

If you use NFS share mount /home/, on each client/server the user's homedirectory will be availble on every system to which they login.

0
 
jazzkiAuthor Commented:
Thanks for your prompt response. VERY helpful information....the most helpful so far. To answer your question, you are correct. The clients are the workstations and the server is a server that they also login to from time to time to take advantage of it's "horsepower" and parallel processing capability that the workstations don't have. It just so happens that I configured this SAME server to also serve as the LDAP server. I wanted it to be a "one-stop shop" for authentication. So once they authenticated via LDAP on the clients, they could access the server, remotely, as well

I understand your explanation about the nsswitch.conf file. Although I suspect it might not be advisable, if I were to switch the order of "files ldap" to "ldap files", would that not force lookups to occur on the LDAP directory first, and if the network was not accessible it would failover to the local filesystem? Just an idea. Don't know if it would work as desired.

I will definitely try what you suggested.
0
 
jazzkiAuthor Commented:
Arnold, FYI, I don't know if I mentioned, I AM running PAM with this.
0
 
arnoldCommented:
Altering the order will get the system to check with the LDAP directory first.
If the Network was down, the local user login will take longer based on the timeout i.e. ldap auth timeout could be three seconds.

Not sure whether you would need to add a parameter to ldap i.e.
ldap [NOTFOUND=return] files
to get the process to failover or not.

If I am not mistaken, pam loads in/uses the pam_ldap component.
I think PAM might be needed if there are multiple authentication schemes, i.e. local, LDAP, and possibly other directory services.
0
 
jazzkiAuthor Commented:
Arnold, Just for giggles, I tried changing the search order in the nsswitch.conf file to search for LDAP first. When I did that, my linux client machine hung on bootup. What do you think that's all about?
0
 
arnoldCommented:
Not sure.  Mount/fsck operations could trigger credential checks.
The file option should remain first.
0
 
jazzkiAuthor Commented:
Arnold, last question. So how exactly to I get the "passwd" command on the client to change BOTH the local client's password files AND the LDAP DB? I've got it so that it changes the password in the LDAP DB on the server, but it does not make the same "syncing" change to the local password files. I modified my /etc/pam.d/password config file (I believe) appropriately. Some guy at RedHat told me this cannot be done. Say it ain't so. If that's the case, then how in the world do you have failover to the local client when an LDAP server is down? You just use TWO valid passwords for the client machine?!?!?! Thanks.
0
 
arnoldCommented:
That is the whole point, you should not be using the same username  local in the passwd file and on LDAP.
Pick one.
LDAP based username provided the home dir, shell, is set correctly will behave the same way as if the user is entered in the local passwd/shadow file.

As far as the system sees, usera in /etc/passwd is not the same as usera@LDAP.
The overlay of UID and GID in the LDAP to match those setting in the passwd/shadow files are beyond the scope of the check.

You could setup a cron that will go through the passwd file collecting the usernames, then querying the LDAP directory for these user's password and then using the usermod -p 'password' username.

I suggested earlier, root, apache, mail, etc. should remain local to the system.
usera, userb, userc, should be LDAP based.
The home dirs of the LDAP users should be based on a NFS share that is mounted /home/.

This way the user can login into any workstation and have full access to their home dir and any and all changes they may have previously made.
0
 
jazzkiAuthor Commented:
Thanks for the clarification. I misunderstood you earlier. The way I had it setup was to blow away the usera account on the server, leave the usera account intact on the client, and have usera's credentials in the LDAP DB on the server (without it actually being an account on the server). Thanks.
0

Featured Post

How to Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.

  • 11
  • 8
Tackle projects and never again get stuck behind a technical roadblock.
Join Now