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.

2 Answers 2


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
services:   files sss
netgroup:   files sss
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, 2017 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. Nov 2, 2017 at 11:11

A very similar scenario with a different root-cause:

Login with sssd (against LDAP) via console works. Login using the correct password with sssd via ssh fails. Gives about an 8 seconds delay until being denied.

My solution was to remove AllowGroups ssh-login from /etc/ssh/sshd_config. That option restricts which group of users can log into the server. As I have not been a member of that group, I was not allowed to connect. No idea how it got there. I get my servers pre-configured from the VM-peeps. Maybe it is a default of Debian 10. Maybe the IT-department put it there.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .