Redhat – SUDO Keeps promting for password, when using SSSD with AD

active-directorypamredhatsssdsudo

Hi I am trying to setup SSSD to authenticate to AD on RHEL.

I able able to login with my AD user and password and see my groups when I run id. But when I try to use sudo, it just keeps prompting for my password (Sorry, please try again). Any ideas why? I know it is not the sudoers file because when I run sudo -U myUser -l I see (root) ALL But I can su to root no problem, and I don't get prompted for a password.

My assumption is it has something to do with PAM.

pam.d/system-auth-ac

auth        required      pam_env.so
auth        sufficient    pam_localuser.so
auth        [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    sufficient    pam_krb5.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so
session     optional      pam_krb5.so

pam.d/password-auth-ac

auth        required      pam_env.so
auth        [default=1 success=ok] pam_localuser.so
auth        [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

sssd.conf

[sssd]
config_file_version = 2
domains = myDomain
services = nss, pam, pac

[domain/myDomain]
id_provider = ad
access_provider = ad
ad_server = adSer2.ca,adSer1.ca
ad_access_filter = memberOf=CN=IT - Shared Services,OU=Infrastructure,OU=CompanyGrps,DC=company,DC=ca
default_shell = /bin/bash
fallback_homedir = /home/%u
ignore_group_members = true
debug_level = 1

[nss]

[pam]
debug_level = 1
pam_verbosity = 3

[pac]

nsswitch.conf

passwd:     files sss ldap
shadow:     files sss ldap
group:      files sss ldap
#initgroups: files

#hosts:     db files nisplus nis dns
hosts:      files dns

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss

netgroup:   files sss ldap

publickey:  nisplus

automount:  files sss ldap
aliases:    files nisplus

sudoers

root  ALL=(ALL)   ALL

%it\ -\ shared\ services ALL = (root) ALL

Update

I got it to work by removing kerberos from the PAM configuration, but I am not sure by doing this if I have introduced a security risk.

Best Answer

In my experience, I've had to qualify the domain of the group in /etc/sudoers

So my sudoers declaration would look more like this:

%adgroup@domain.local ALL = (root) ALL

Since you've got spaces in the group name, something like:

%it\ -\ shared\ services@domain.local ALL = (root) ALL

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

Best Answer

Related Solutions

Redhat – passwd for ldap users

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

Related Topic