Can't login with domain user account

Latest response

RHEL 7.7 (Maipo)

I've been trying for hours to be able to login to a Red Hat 7 Virtual Machine with a Windows 2012r2 Active Directory user account.

I followed this guide: https://access.redhat.com/articles/3023951

The steps went exactly as described in that guide. I can see that my machine has successfully joined the domain. It is listed in Active Directory Users & Computers. But whatever I do I can not login with a user account that I created in Active Directory. I've made sure that the clocks are in sync. I've made sure that DNS is set correctly.

If I enter "dnsdomainname" it properly returns my domain.

Whenever I attempt to login it simply returns, "Login incorrect."

I'm not even sure what additional information to provide for this post.

I've been able to do this successfully with a Redhat 6 VM and the same version Windows domain controller.

Any help that anyone can provide would be huge. Thanks!

Responses

Hi Jonathan,

There are a variety of possibilities here. A few questions:

  • Did this work on a system and it ceased to function recently?
  • If this worked previously, is there any knowledge on what changed since the time it worked?
  • Is there any chance the password has expired in Active Directory for the account?
  • Is there any chance the account is locked in Active Directory?
  • Are you by chance using an IDM server, and if so, use ipactl status to see if Kerberos is failing?
  • Are you (yes/no) able to log into the server in question that is uncooperative and yet able to log into a different system (is it systemic or not?)
  • Is anyone else (or a local account) able to log into the server in question and examine the logs?
  • Sometimes it does really help to run the following on the system (as root) /sbin/pam_tally2 --reset and then faillock --reset and you can restrict that to a specific user if you do not want to clear all failures.
  • I would really recommend examining having a tail -f /var/log/{messages,secure} while attempting to log in to watch what happens in the logs.
  • Is there any chance the system itself is not joined to the domain? - Some admins I know have found un-joining then rejoining a troubled system helps, annoying yet true. Yes, it shouldn't have to go like that, but in our experience sometimes it does (maybe submit a case first if you wish).
  • If you are in an environment where password synchronization (maybe two different domains), are the passwords you expect correct?
  • Can other users log into that system?
  • Can other users log into other systems at all (is it systemic or not)?
  • What version of RHEL 6 are you using?
  • What version of Windows Server (for Active Directory domain controllers) is running?
  • Have you made a sosreport and submitted a case to Red Hat?
  • Have you cleared the SSSD cache on the RHEL 6 Linux system?

Kind Regards,
RJ
(not a Red Hat employee)

I made some edits for clarity. Please refresh this page to see the updates to the last post, thanks.

  • Did this work on a system and it ceased to function recently?
    • No, this is a fresh install of both the RHEL VM and the Domain Controller. I intend to use this VM as a TACACS+ server that'll authenticate with Active Directory. This is a test environment.
  • If this worked previously, is there any knowledge on what changed since the time it worked?
    • See above. Fresh install.
  • Is there any chance the password has expired in Active Directory for the account?
    • I was sure to change the password and ensure that the account isn't locked. I've also logged into the DC with the user account that I'm testing with.
  • Is there any chance the account is locked in Active Directory?
    • See above. Made sure it wasn't locked.
  • Are you by chance using an IDM server, and if so, use ipactl status to see if Kerberos is failing?
    • Definitely not using an IDM server. ipactl is not installed on the machine.
  • Are you (yes/no) able to log into the server in question that is uncooperative and yet able to log into a different system (is it systemic or not?)
    • I'm able to login to my RHEL machine with local user accounts. I'm also able to log into the DC with the AD account that I'm using for testing. Can not log into the RHEL machine with the AD account.
  • Is anyone else (or a local account) able to log into the server in question and examine the logs?
    • See above. I can log into either machine with local accounts. Which logs would you like me to look at?
  • Sometimes it does really help to run the following on the system (as root) /sbin/pam_tally2 --reset and then faillock --reset and you can restrict that to a specific user if you do not want to clear all failures.
    • Just ran those commands as root and then logged out and attempted to login again with my AD account and it still failed.
  • I would really recommend examining having a tail -f /var/log/{messages,secure} while attempting to log in to watch what happens in the logs.
    • tailing /var/log/messages revealed nothing. But tailing /var/log/secure is showing the following messages:
      • login: pam_sss(login:auth): authentication success; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=jbrown
      • login: pam_ldap(login:account): error opening connection to nslcd: No such file or directory
      • login: Authentication service cannot retrieve authentication info
      • crond[18427]: pam_ldap(crond:session): error opening connection to nslcd: No such file or directory
  • Is there any chance the system itself is not joined to the domain? - Some admins I know have found un-joining then rejoining a troubled system helps, annoying yet true. Yes, it shouldn't have to go like that, but in our experience sometimes it does (maybe submit a case first if you wish).
    • "realm join -v MYDOMAIN.COM" returns the message: "realm: Already joined to this domain"
    • "adcli testjoin" returns "Successfully validated join to domain mydomain.com"
  • If you are in an environment where password synchronization (maybe two different domains), are the passwords you expect correct?
    • Only one domain controller is in use in this environment.
  • Can other users log into that system?
    • No this is a fresh install of both the RHEL VM and the DC. I've only created one AD user account for testing.
  • Can other users log into other systems at all (is it systemic or not)?
    • See above. Test environment. Only one AD user account created.
  • What version of RHEL 6 are you using?
    • This is on a RHEL 7.7 VM. I had previously accomplished this with a RHEL 6.8 VM but with a different instance of a test Domain Controller.
  • What version of Windows Server (for Active Directory domain controllers) is running?
    • I'm using a Windows 2012r2 domain controller.
  • Have you made a sosreport and submitted a case to Red Hat?
    • No I haven't. Thought I'd try the community first.
  • Have you cleared the SSSD cache on the RHEL 6 Linux system?
    • Just tried. No change.

I'm thinking the messages in the /var/log/secure log file are significant. I'll be chasing down the error message regarding nslcd next.

I appreciate your help.

Hi Jonathan,

I think you're right on the significance of the errors you found in /var/log/secure.

Sorry for the things I missed - I think you're right regarding what you found with /var/log/secure.

  • Check out the logs in /var/log/sssd as well. SSSD produces a log file for each domain, as well as an sssd_pam.log and an sssd_nss.log file.
  • Just for reference, examine the troubleshooting sssd info in the documentation
  • Another troubleshooting guide is here and examine "Troubleshooting User Information" at that location.
  • This solution here is a bit of a WAG, but I'm curious if it may or may not help along with this solution.
  • As a test, log into the system with a local account and become root and see if you can (from root) become the user with su - jbrown, or see what errors are produced on the screen or in the logs.
  • You can also turn on debugging in /etc/sssd/sssd.conf (use caution, make sure to turn off debugging because this will likely fill up /var/log or whatever mountpoint /var is on).
  • To enable debugging persistently across SSSD service restarts, enter the directive debug_level=N where N typically stands for a number between 1 and 10 into the particular section. We generally used debug_level=9.
  • You can examine more on the output of failed ssh using strace ssh jbrown@yourservername. Perhaps run script -a /tmp/sshoutput.txt prior and then run the exit command or ctrl-d to end the recording of the output.

I think opening a case with a sosreport would probably be more efficient though. The sosreport will give Red Hat quite a lot to go with.

I wish you well with this.

Kind Regards,
RJ

Jonathan

Just as a test, temporarily deactivate selinux and attempt login again (maybe restart sssd too)setenforce 0;getenforce

Regards,
RJ

For me, I had a fun issue. I have zero control over my domain policies. I attached my RHEL 8.4 test VM to a remote domain controller (trying to create a demo of why this is a bad idea) using my "user" account. I was able to join the domain but couldn't log in. I checked, and adding a WINDOWS host to the remote domain worked fine, and I could log in as the same user that did both domain joins. I had 2 things set up that may have done it:

  1. FIPS mode was enabled, which may have blocked password authentication. I was getting all kinds of weird "system error" messages.

  2. The access provider was "ad" and I got a PAM preauth rejection when trying to ssh in as the domain user.

Killing FIPS mode and changing my "access_provider=" line to "access_provider = simple" let me in without issue via ssh and the console. Thank heaven I didn't need to dig into the VPN/Firewall configuration, because in my org that is a massive rathole...

Hi Brian,

Good that you resolved your issues, albeit we do not have full details why you had to disable FIPS.

In strict environment where I work, FIPS is fully enabled on RHEL 8.4 and 8.5 systems. AD authentication works without any problems through AD provider in SSSD. We also use PAM ACLs to control AD groups and users connecting from remote servers.

My guess is that PAM files, especially /etc/pam.d/system-auth and /etc/pam.d/password-auth might be the root of your problems.

Best wishes,

Dusan Baljevic (amateur radio VK2COT)

I'm not entirely sure I needed to. It was just one of the differences between this test host and the RHEL 8.4 host I had attached to my local AD DC VM. (Yes, this is all with VirtualBox, making things more fun.) Re-enabling FIPS mode didn't break anything.

This means that using "access_provider = simple" is what worked for me. I don't know what policies are set on the domain I don't have control over, and an "Out Of the Box" Domain didn't exhibit this issue, even with "ad" as the access provider.

My pam files are straight OOTB default, unless adding ad authentication changes them somehow. But even then they are the same as the connection to my "sandbox" domain.

So, I guess I need to figure out what the DEFAULT behavior of the AD access provider is. When I have time to do that. I'm just glad I can log in and get to the real meat of my testing.

Hi Brian,

Did you run any of these checks:

# klist -ekt /etc/krb5.keytab 

# sssctl config-check

# sssctl domain-status mydomain.dom

# adcli info mydomain.dom -v

# stat /var/lib/sss/db/config.ldb /var/lib/sss/db/cache_mydomain.dom.ldb

# ldbsearch -H /var/lib/sss/db/config.ldb

Maybe compare the results with the server where AD authentication works and also ensure that SSSD debug level is increased to log more events.

Best wishes,

Dusan Baljevic (amateur radio VK2COT)