Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

She attempts to change the password, which the system accepts... Then tries to log in with the new password, and again gets the "You are required to change your password immediately (password aged)" message. This will continue on in an endless loop...

Centos 5 is derived from RHEL5. I don't think the password changing PAM modules are LDAP-capable in that version. You probably need to upgrade to something that supports LDAP password changing, like SuSe (or possibly RHEL/Centos6).

1. What is the method to completely eliminate password ageing and checking in RH/Centos5? That would solve this issue as well... Normally it would involve modifying "/etc/pam.d/system-auth"'s "password requisite pam_cracklib.so try_first_pass retry=3" line, adding the testing requirement options, but for some reason in this case this is not true, as the testing is happening even without those changes...

2. Why would most admins have *no* problem logging in, but this one account does? That is neither logical nor consistent, and seems to point to a problem with the account settings rather than PAM itself (as other admins are indeed able to log in using PAM LDAP authentication).

3. I have a very hard time accepting the "PAM is not LDAP-capable in that OS" argument, since there are pam_ldap.so libs being referenced in /etc/pam.d/system-auth. Obviously, PAM is LDAP-capable if the libraries exist. There may be bugs, but those bugs should be widely confirmed and discussed on the web, and a quick grep on google shows this is not the case.

I could move to 6.3 (I have 20 other servers running 6.3 without a problem), even though this particular box is hosting over 100 websites and would require a flash cut, but I am also trying to learn what is happening here. I would like to understand the login/PAM/LDAP interaction at a deeper level, because it's in my nature to absolutely HATE mysteries like this, especially when it's Linux. I haven't seen many unsolved mysteries with Linux: it ain't Windows, where those problems occur daily and people just tend to shrug them off.

It isn't clear to me from this post so-far why the password change request did not work; hence, why changing the expiration-settings fixed it. I suspect that this post is going to be referred-to frequently in the future. Therefore, could you please elaborate on your findings? What was wrong .. what mechanism was causing it to be wrong .. what you changed .. why the change fixed the problem .. how you demonstrated that the problem was now gone.

What was wrong?
By this question, I assume you are asking what the symptoms were. An admin would log into the system via SSH, and be immediately given the message "You are required to change your password immediately (password aged)" and be taken through a password change process, then logged out automatically. When the admin reconnected, they were presented with the same process again. The password had indeed changed to the new password the admin had selected, as they needed to confirm their existing password before setting the new one, so the actual password change process had completed successfully. This process would repeat ad infinitum.

What mechanism was causing it to be wrong?
Whatever mechanism that the login process uses to determine password ageing. I don't understand enough about this process to give an informed answer to this question, but I would love to learn more about it.

What did you change?
I added a "shadowmax" field to the LDAP entry for this admin, and set the value to -1. This field did not exist in the user's LDAP entry prior to my change.

Why did the change fix the problem?
Since I don't fully understand the login processes, my answer here is only an assumption. However, what I believe has happened is that the login mechanism does not have the ability to *add* the "shadowmax" field to an LDAP entry, though it does have the ability to *read* the value of this entry, and therefore make the decision (based on the value of -1) that the user's password should never expire. The login process may be able to *change* the value also, to effectively reset the value to the whatever the system has configured to be a proper "reset" value, though I have not confirmed this. Again, I would love to learn more about this process.

How you demonstrated that the problem was now gone.
The admin was able to successfully log in to the CLI via SSH with no password change process being triggered.

Now here's a request that I have: is there a resource that fully explains, step-by-step, the low-level processes (like the login process) that we normally take for granted as admins?

Actually, looking at the title of this post, a better title would be "SSH login impaired based on percieved password expiry". If a mod would like to change the title of the post, it would probably make more sense for future searchers...