Redhat – Need help understanding PAM directives

freeradiusgoogle-authenticatorldappamredhat

I have the following directives in my /etc/pam.d/sshd file on a RHEL5 box and I'm a bit confused. These directives are there to make LDAP+RADIUS+OTP work. What I'm trying to do is tell pam not to check users UID < 499 for LDAP+RADIUS+OTP and also to exclude UID = 30027 from being checked for the same.

This directive works as intended. It checks if UID >= 499 and if it is, it skips (auth sufficient pam_unix.so nullok_secure).

auth [success=1 default=ignore] pam_succeed_if.so uid >= 499 quiet

I'm confused here. This should do LDAP+RADIUS+OTP since success=1 but somehow it still works. Shouldn't it be skipping the next rule if true?

auth [success=1 default=ignore] pam_succeed_if.so uid eq 30027 quiet
auth sufficient pam_unix.so nullok_secure
auth sufficient  pam_radius_auth.so
auth required /lib/security/pam_google_authenticator.so forward_pass

Although, I've gotten things to work as I want them to, I'm confused behind the logic of it.

Update

Ok, so this is what I get in /var/log/secure when I ssh using a local user that has an uid of 30327 –

Aug  8 08:21:30 journey sshd[9357]: Accepted keyboard-interactive/pam for sidd from 10.1.1.178 port 51242 ssh2
Aug  8 08:21:30 journey sshd[9357]: pam_unix(sshd:session): session opened for user sidd by (uid=0)

This is what I get ssh using root who has a uid of 0 (<499).

Aug  8 08:25:51 journey sshd[9402]: Accepted keyboard-interactive/pam for root from 10.1.1.178 port 51246 ssh2
Aug  8 08:25:51 journey sshd[9402]: pam_unix(sshd:session): session opened for user root by (uid=0)

This is what I get when I use an ldap user with just LDAP password and no OTP –

Aug  8 08:27:04 journey sshd[9447]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=journey  user=schoure
Aug  8 08:27:05 journey sshd(pam_google_authenticator)[9447]: Failed to read "/home/schoure/.google_authenticator"
Aug  8 08:27:07 journey sshd[9445]: error: PAM: Cannot make/remove an entry for the specified session for schoure from journey

This is what I get when I use an ldap user with LDAP + OTP –

Aug  8 08:28:13 journey sshd[9452]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=journey  user=schoure
Aug  8 08:28:13 journey sshd[9450]: Accepted keyboard-interactive/pam for schoure from 10.1.1.178 port 43068 ssh2
Aug  8 08:28:13 journey sshd[9450]: pam_unix(sshd:session): session opened for user schoure by (uid=0)

So you are right – pam_unix does fail for LDAP users but since it's set to "sufficient" it's not terminal. Thanks for clearing that up.

As to your other point of –

auth [success=1 default=ignore] pam_succeed_if.so uid eq 30027 quiet

not getting evaluated, I see that it is getting evaluated. If I comment out that directive, I get

Aug  8 08:34:39 journey sshd(pam_google_authenticator)[9537]: Failed to read "/home/sidd/.google_authenticator"
Aug  8 08:34:42 journey sshd[9535]: error: PAM: Cannot make/remove an entry for the specified session for sidd from journey

So I am still confused as to how this works since clearly 30327 > 499 and hence it should skip the second line. The only reason I can see this working if PAM some how adds an implicit OR between the first two lines.

UPDATE 2

Ah, I see what is happening. That line in effect is just a place holder. I changed that UID to some random UID that doesn't exist and it still worked. So I understand the logic –

Line 1 checks UID. If it's more than 499, it skips to line 3 where it is checked locally. Since UID > 499 are not local, that condition fails but being a non-terminal directive, it moves on to LDAP + RADIUS + OTP.
If I comment out line 2 which has a particular UID set, what happens is PAM completely skips over local authentication because of the success=1.

So in effect, me doing something wrong made it work. I get what I need to do and it's working for me.

I don't want local users to be authenticated via LDAP + RADIUS + OTP, so these three lines should do the job for me. They are working but I would just like confirmation that they are right –

auth sufficient pam_unix.so nullok_secure
auth sufficient  pam_radius_auth.so
auth required /lib/security/pam_google_authenticator.so forward_pass

Best Answer

Are you really sure it's skipping pam_unix.so?

sufficient is a "non-terminal" behavior on failure. Even if the pam_unix.so check fails, authentication will go on to attempt pam_radius_auth.so.

My interpretation is:

The uid eq 30027 check will never return true. The test will only run if the uid is <499, making it impossible for the condition of uid eq 30027 to be true.
pam_unix.so would be attempted in all scenarios, and if it fails, pam_radius_auth.so would be attempted.
pam_google_authenticator.so will be attempted if both of them fail.

Check your logs again. The radius logins may not be failing, but the pam_unix.so check probably is logging a failure. It just isn't preventing your logins.

This answer accurately covers the scope of the original question. Any additional questions that have been posed through updates or comments will not be covered.

Related Solutions

Redhat – passwd for ldap users

Are you using Kerberos or Samba winbind at all? Or are you just trying straight LDAP?

If the latter, your /etc/ldap.conf file should have a series of 'pam_*' parameters that seem to be missing. In particular 'pam_password ad' is necessary to specify ADSI as the password change protocol. You may also need 'pam_login_attribute sAMAccountName' (+ others)

Personally I've always just bound the Linux machine using winbind, then changing passwords is as done with 'net ads password'

Linux (Ubuntu vs CentOS) LDAP Client for 389-ds – password policy

I have been playing around with 389-ds on Ubuntu for a work project and came across the exact same issue.

I'm not sure about copying the config over from CentOS - I didn't have a box handy.

But when I looked and read up on PAM, it turned out to all be in the file /etc/pam.d/common-account.

pam_unix.so was above pam_ldap.so, and it also had [success=2 default=ignore], which means if it succeeds skip the next two rules, and for anything else, ignore the line.

Now since LDAP accounts are valid UNIX accounts since we added ldap to /etc/nsswitch.conf, this rule will return success and the pam_ldap.so module will never get run.

To get around this, my /etc/pam.d/common-account now looks like this:

# here are the per-package modules (the "Primary" block)
account [success=1 default=bad]  pam_succeed_if.so user ingroup auth-access quiet
account [success=reset default=bad]  pam_succeed_if.so uid <= 500 quiet
account [success=2 user_unknown=ignore default=ok]      pam_ldap.so
account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so
# here's the fallback if no module succeeds
account requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

As you can see, I've also added some rules in there to only allow users in either the LDAP group "auth-access", or system users with a UID below 500 to be seen as valid accounts.

And to explain a little:

We hit the first rule

account [success=1 default=bad]  pam_succeed_if.so user ingroup auth-access quiet

Which succeeds if the user is in that group and if so, we skip the next line as we know that'll fail (they're a valid LDAP user, so they won't have a system UID below 500) - if it doesn't succeed, return a fail (bad).

Then the next rule if it wasn't skipped

account [success=reset default=bad]  pam_succeed_if.so uid <= 500 quiet

So if this on succeeds (because the UID is below 500), reset the fail value set by the module above, because they won't be part of that LDAP group.

And the important part

account [success=2 user_unknown=ignore default=ok]      pam_ldap.so

Check the LDAP server for the account status - if it succeeds, we know an LDAP user is a valid UNIX user, so go ahead and skip the next two lines (to take us to pam_permit.so and let the user login). If the user is unknown to the LDAP server, ignore this line and move to the next one - and for all other statuses, "ok" means it's ok to pass those return codes as-is, which will pass things like password expired, etc.

And then:

account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so

We weren't a valid LDAP user if we hit this rule, so check if we're a valid system user - if succeed, skip next 1 line (takes us to pam_permit.so). Otherwise, ignore, which will take us to pam_deny.so.

Hope that helps explain a little more - the document that helped me if I wasn't very easy to understand was: http://uw714doc.sco.com/en/SEC_pam/pam-4.html

Regards, iamacarpet

Update

Best Answer

Related Solutions

Redhat – passwd for ldap users

Linux (Ubuntu vs CentOS) LDAP Client for 389-ds – password policy

Related Topic