2

So, I have a RHEL server that is ad joined. Users are not able to login, even when using the correct passwords.

I can login through console, but only with root, none of the AD accounts will work. I cannot use root to login via Putty, it only works via console. No AD user can login via console, only root login works.

Logs have been frustratingly unhelpful.

When trying to access via SSH/Putty and an AD account (Two factor is turned on) I get the Duo prompt, so can verify that it's reaching out. I was getting a your password expires in 7 days message, so I updated my password in AD and now no longer get the your password expires in 7 days message. This tells me that the server is able to reach AD and read AD info. Below is the text when trying to login with an AD account:

Passcode or option (1-3): 1 Using keyboard-interactive authentication. Success. Logging you in... Access denied

When logging in with root (no two factor setup for root ironically) it just goes straight to access denied.

I've cleared SSSD cache, verified the SSSD settings, compared the SSSD settings to one of our other servers that isn't having the issue, and they are the same.

Since root is also getting denied SSH login, I don't really believe the problem is related to AD though.

Any help would be greatly appreciated.

1

Off the top of my head, these are the 3 things that have caused me pain in joining CentOS to AD and using sssd with ssh:

  1. Do you have pam_sss.so listed in the password portion of /etc/pam.d/password-auth, or otherwise called in /etc/pam.d/sshd? Sshd will use PAM to validate the password, and if PAM isn't configured to talk to sssd, that will break the ability to use ssh with AD auth.

  2. Do you have an /etc/security/access.conf that maybe has a line like -:ALL:ALL in it? You may need to explicitly allow users, with +:USERNAME:ALL, or you can allow anyone who passes authentication with +:ALL:ALL

    The access.conf man page has some good information on the formats of entries and the meanings of the fields in the file.

  3. In your domain stanza in /etc/sssd/sssd.conf, do you have a line for auth, like auth_provider = ad?


Edit 2017-11-02 13:48

/etc/nsswitch.conf is another file that can be problematic. You need to confirm that sss is configured as lookup target for passwd, shadow, group, netgroup, automount, and services:

passwd:     files sss
shadow:     files sss
group:      files sss
<snip>    
services:   files sss
netgroup:   files sss
<snip>
aoutomount: files sss

Although the "Success .... Access Denied" makes me think it has something to do with access.conf. Like authentication is passing, but then being blocked else where. Or... OP said this is Red Hat. It could be missing HBAC rules. They're not mentioned anywhere in the SSSD documentation that I recall.

I don't have a RH server to check with, and the CentOS servers I have that are domain joined don't have the ipa command.

  • 1
    FWIW, I've also been tripped up by time issues. KRB is pretty picky about the timing for issuing krb tickets... I think 15 seconds of difference between client and server is enough to fail. – Thomas N Nov 1 '17 at 21:42
  • From the OP’s deleted answer... Local users, including root, can’t login using SSH either. sssd.conf matches another server’s working sssd.conf. Every line in access.conf is commented out. password-auth does have pam_sss.so in the password section, which also matches another working server’s setup. – Stephen Kitt Nov 2 '17 at 11:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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