Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We've got some RHEL 5 servers joined to AD using Winbind/Kerberos which is working well overall.

I've specified an AD security group in PAM to restrict which domain users can login.

auth        requisite     pam_succeed_if.so user ingroup ad_group debug

I've also specified the same group in sudoers so they can attain root access.

%ad_group ALL=(ALL)     ALL

These work as expected.

However, I've noticed that "su -" will allow me to become a domain user that is not in the security group.

Let's say jdoe is not in the "ad_group":

[kernelpanic@server01 ~]$ sudo su - jdoe
[sudo] password for user:
Creating directory '/home/jdoe'.
Creating directory '/home/jdoe/.mozilla'.
Creating directory '/home/jdoe/.mozilla/plugins'.
Creating directory '/home/jdoe/.mozilla/extensions'.
[jdoe@server01 ~]$

Here's the /var/log/secure output:

Oct 25 09:42:42 server01 su: pam_unix(su-l:session): session opened for user jdoe by kernelpanic(uid=0)
Oct 25 09:43:53 server01 su: pam_unix(su-l:session): session closed for user jdoe

Is there a way to restrict users from an "su -" to a domain user who is not allowed to login to the box in the first place?

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

I believe the first line in /etc/pam.d/su looks like this:

auth            sufficient      pam_rootok.so

In other words, when you su tries to authorize your to become jdoe, everything looks okay.

What you can do is either add your pam_succeed_if line to /etc/pam.d/su, or much better, add an entry to /etc/pam.d/system-auth, but modify it so the auth becomes session like so:

session requisite pam_succeed_if.so user ingroup ad_group debug

This will get triggered even in the situation that you described and will not let a user from the non ad_group to ever open a shell. This would also have the unfortunate side effect of restricting root from opening a shell (as pointed out in the comments), so you may need to only apply it for user ids in the correct range:

session [default=1 success=ignore] pam_succeed_if.so quiet uid >= 1000
session requisite pam_succeed_if.so user ingroup ad_group debug

By the way, ssh may also bypass PAM if you are authenticating with a public key, so it is still better to use session instead of auth.

share|improve this answer
    
I replaced auth with session for that line in system-auth but it caused "sudo su -" to break. –  kernelpanic Oct 25 '12 at 20:07
    
Fair point. I updated my answer to accommodate for this. –  chutz Oct 26 '12 at 0:23
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.