How to Avoid AD Login Issues After Moving RHEL 8.10 Systems to a Different OU?
Asked by
CuriousCat74
I recently noticed that some of our Red Hat Enterprise Linux (RHEL) 8.10 systems were still in the default Computers organizational unit (OU) in Active Directory (AD). I usually don't have issues moving systems between OUs, especially with Windows, but moving these specific RHEL systems has caused their AD logins to break. I powered down the systems, changed their OU, and powered them back up, but they still don't allow AD logins. Can anyone offer advice on how to correct this and move these servers to the appropriate OU without losing AD integration?
I've also considered the possibility that the issue might be related to the sssd.conf configuration file, but I haven't spotted anything off. Here's the current content of the file for reference.
Answers
First off, you should definitely check the /etc/sssd/sssd.conf file for potential issues. Sometimes the configuration can affect AD logins after moving OUs. For example, you might need to force the SSSD cache to reset using the command `sss_cache -E`. Just be sure you have a local account available, so you can log in if anything goes wrong.
Reply to this answer
If you're using AD with Kerberos, there could be a line in your sssd.conf like `ad_gpo_access_control = enforcing`. This means that the GPOs (Group Policy Objects) applied to that OU may be affecting logins. You might need to change it to permissive instead, at least temporarily, to see if that resolves the issue. Just remember that this will allow broader access, so don’t leave it that way permanently!
CuriousCat74: The sssd.conf seems pretty basic, and I haven’t seen anything regarding GPOs or ignoring unreadable settings. Also, the OU I'm moving these servers to already contains other Linux servers that were integrated without any issues.
Reply to this answer
Have you considered simply joining the computer to the domain with the correct OU from the start? You can use 'adcli' for this. It might be the simplest way to avoid these problems altogether.
CuriousCat74: That was my backup plan! I thought about disconnecting the network, leaving the realm, and then rejoining when the network is back up. I'm just cautious because some of the software could be sensitive to changes, but if I can’t find a better solution, I’ll give that approach a shot next week.
Reply to this answer
Add your answer
Answers are reviewed before publication.
CuriousCat74: I appreciate the tip! I'm not too worried about getting locked out since I have console and root access. I’ll dive into the sssd.conf tomorrow and see if I notice anything unusual.