Integration with Active Directory for login

tuxaholic · September 18, 2023, 4:58pm

Hello,

I’ve been running Samba as an AD controller in my home lab, and wanted to start using it for user authentication in Linux.

There is a 3-year old post of a success story by user @sslhijacker but I have failed to get things to work:

Installed realmd and sssd with yay -Sy realmd sssd
Joined the domain with:

$ sudo realm join -v -U Administrator@AD.HOME.LAN ad.home.lan
 * Resolving: _ldap._tcp.ad.home.lan
 * Performing LDAP DSE lookup on: 192.168.42.201
 * Performing LDAP DSE lookup on: 192.168.9.201
 * Successfully discovered: ad.home.lan
Password for Administrator@AD.HOME.LAN: 
 * LANG=C /usr/sbin/adcli join --verbose --domain ad.home.lan --domain-realm AD.HOME.LAN --domain-controller 192.168.42.201 --login-type user --login-user Administrator@AD.HOME.LAN --stdin-password
 * Using domain name: ad.home.lan
 * Calculated computer account name from fqdn: EOS
 * Using domain realm: ad.home.lan
 * Sending NetLogon ping to domain controller: 192.168.42.201
 * Received NetLogon info from: dc2.ad.home.lan
 * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-oWIvJd/krb5.d/adcli-krb5-conf-THJfh0
 * Authenticated as user: Administrator@AD.HOME.LAN
 * Using GSS-SPNEGO for SASL bind
 * Looked up short domain name: HOME
 * Looked up domain SID: S-1-5-21-3977389702-1060441936-3297101528
 * Received NetLogon info from: dc2.ad.home.lan
 * Using fully qualified name: eos
 * Using domain name: ad.home.lan
 * Using computer account name: EOS
 * Using domain realm: ad.home.lan
 * Calculated computer account name from fqdn: EOS
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * A computer account for EOS$ does not exist
 * Found well known computer container at: CN=Computers,DC=ad,DC=home,DC=lan
 * Calculated computer account: CN=EOS,CN=Computers,DC=ad,DC=home,DC=lan
 * Encryption type [3] not permitted.
 * Encryption type [1] not permitted.
 * Created computer account: CN=EOS,CN=Computers,DC=ad,DC=home,DC=lan
 * Trying to set computer password with Kerberos
 * Set computer password
 * Retrieved kvno '2' for computer account in directory: CN=EOS,CN=Computers,DC=ad,DC=home,DC=lan
 * Checking host/EOS
 *    Added host/EOS
 * Checking RestrictedKrbHost/EOS
 *    Added RestrictedKrbHost/EOS
 * Discovered which keytab salt to use
 * Added the entries to the keytab: EOS$@AD.HOME.LAN: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: host/EOS@AD.HOME.LAN: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/EOS@AD.HOME.LAN: FILE:/etc/krb5.keytab
 ! Enabling SSSD in nsswitch.conf and PAM failed.
realm: Couldn't join realm: Enabling SSSD in nsswitch.conf and PAM failed.

Why is this step failing? What does Enabling SSSD in nsswitch.conf and PAM failed. mean?

Would appreciate any help on getting this to work…

tuxaholic · September 18, 2023, 5:03pm

I should note that a computer account for the machine seems to exist now which I can view in LDAP.

Also, trying to rejoin claims I am already in the domain:

$ sudo realm join -v -U Administrator@AD.HOME.LAN ad.home.lan
 * Resolving: _ldap._tcp.ad.home.lan
 * Performing LDAP DSE lookup on: 192.168.42.201
 * Successfully discovered: ad.home.lan
realm: Already joined to this domain

I am able to leave the domain with:

$ sudo realm leave -v -U Administrator@AD.HOME.LAN ad.home.lan
Password for Administrator@AD.HOME.LAN: 
 * LANG=C /usr/sbin/adcli delete-computer --verbose --domain ad.home.lan --domain-realm AD.HOME.LAN --domain-controller 192.168.42.201 --login-user Administrator@AD.HOME.LAN --stdin-password
 * Found computer name in keytab: EOS
 * Found service principal in keytab: host/EOS
 * Found service principal in keytab: RestrictedKrbHost/EOS
 * Using domain name: ad.home.lan
 * Using computer account name: EOS
 * Using domain realm: ad.home.lan
 * Sending NetLogon ping to domain controller: 192.168.42.201
 * Received NetLogon info from: dc2.ad.home.lan
 * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-tXtCR3/krb5.d/adcli-krb5-conf-l6OsWt
 * Authenticated as user: Administrator@AD.HOME.LAN
 * Using GSS-SPNEGO for SASL bind
 * Looked up short domain name: HOME
 * Looked up domain SID: S-1-5-21-3977389702-1060441936-3297101528
 * Received NetLogon info from: dc2.ad.home.lan
 * Using fully qualified name: eos
 * Using domain name: ad.home.lan
 * Using computer account name: EOS
 * Using domain realm: ad.home.lan
 * Enrolling computer name: EOS
 * Found computer account for EOS$ at: CN=EOS,CN=Computers,DC=ad,DC=home,DC=lan
 * Deleted computer account at: CN=EOS,CN=Computers,DC=ad,DC=home,DC=lan
 * Removing entries from keytab for realm
 ! Flushing the sssd cache failed
 * Removing domain configuration from sssd.conf
 ! Disabling sssd in PAM failed.
 * Successfully unenrolled machine from realm

Notice that again something regarding PAM fails.

After leaving the domain, I am able to rejoin as per my first post, but get the same error.

Needless to say, I am unable to log in with a domain account…

Thanks!

BluishHumility · September 18, 2023, 6:41pm

Are you sure you want sssd? I’m not really familiar with sssd but the ArchWiki Active Directory article suggests it can be used instead of Samba. https://wiki.archlinux.org/title/Active_Directory_integration#Using_SSSD

Configuring PAM is described in this section: https://wiki.archlinux.org/title/Active_Directory_integration#Configuring_PAM_authentication

In general the ArchWiki article seems to have a lot more information than the old thread you linked. If you haven’t read through it yet it seems like it would be a good place to start.

tuxaholic · September 18, 2023, 6:53pm

I chose it mainly because it is present in Fedora and I know it works (my Fedora install can login using the AD credentials). It also seems to be free of some limitations of Samba’s winbindd though I do not know how outdated this info is.

I was unable to complete the install manually but made progress when I found that the AUR package comments mention my issue. Seems like some commands are missing for doing whatever needs doing in the case of Arch. The reply is that the script from the other post addresses this issue.

So as per the original post, I probably need to:

Run the patch to add the missing commands for EOS
Retry the realm join
Hope it works

If all goes well I will post a more verbose list of steps in the forum in case anyone else needs it…

tuxaholic · September 18, 2023, 10:13pm

I can report success. I’ll need a few days to see if anything weird happens but as of now I can log TrueNAS (it also has AD integration) shares works the same as Windows: it does not ask for credentials at all, as the machines seem to be able to exchange them transparently.

Here’s the process:

STEP 1: Install the required software

$ yay -Sy realmd sssd

$ wget https://raw.githubusercontent.com/robinrosenberger/realmd-arch-helper/master/realmd-arch-helper.s

$ sha256sum realmd-arch-helper.sh 
ace08ecbca79c16fdc5f0100dba14b14f0d6a5ea3acc3b5a0f58ff1b110edfea  realmd-arch-helper.sh

STEP 2: Backup everything that will be modified / patched

cp /usr/lib/realmd/realmd-distro.conf /usr/lib/realmd/realmd-distro.conf-preRealmD
cp -R /etc/pam.d /etc/pam.d-preRealmD
cp /etc/nsswitch.conf /etc/nsswitch.conf-preRealmD

STEP 3: Download the script and run it to patch the realmd configuration

[root@eos ~]# ./realmd-arch-helper.sh --patch-config
Patched realmd-config, restarting sssd

[testuser@eos ~]$ ls -l /usr/local/sbin/realmd-arch-helper.sh 
-rwxr--r-- 1 root root 2152 Sep 18 21:48 /usr/local/sbin/realmd-arch-helper.sh

As you can see, and defines some commands that are implemented by invoking the script.

[root@eos ~]# diff /usr/lib/realmd/realmd-distro.conf /usr/lib/realmd/realmd-distro.conf-preRealmD
35,38d34
< sssd-disable-service = /usr/bin/systemctl disable sssd
< sssd-enable-service = /usr/bin/systemctl enable sssd
< sssd-disable-logins = /usr/local/sbin/realmd-arch-helper.sh --disable-pam-nss
< sssd-enable-logins = /usr/local/sbin/realmd-arch-helper.sh --enable-pam-nss

STEP 4: Join the domain

[root@eos ~]# realm join -U Administrator@AD.HOME.LAN -v ad.home.lan
 * Resolving: _ldap._tcp.ad.home.lan
 * Performing LDAP DSE lookup on: 192.168.42.201
 * Performing LDAP DSE lookup on: 192.168.9.201
 * Successfully discovered: ad.home.lan
Password for Administrator@AD.HOME.LAN: 
 * LANG=C /usr/sbin/adcli join --verbose --domain ad.home.lan --domain-realm AD.HOME.LAN --domain-controller 192.168.42.201 --login-type user --login-user Administrator@AD.HOME.LAN --stdin-password
 * Using domain name: ad.home.lan
 * Calculated computer account name from fqdn: EOS
 * Using domain realm: ad.home.lan
 * Sending NetLogon ping to domain controller: 192.168.42.201
 * Received NetLogon info from: dc2.ad.home.lan
 * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-nXjzvU/krb5.d/adcli-krb5-conf-EC04B4
 * Authenticated as user: Administrator@AD.HOME.LAN
 * Using GSS-SPNEGO for SASL bind
 * Looked up short domain name: HOME
 * Looked up domain SID: S-1-5-21-3977389702-1060441936-3297101528
 * Received NetLogon info from: dc2.ad.home.lan
 * Using fully qualified name: eos
 * Using domain name: ad.home.lan
 * Using computer account name: EOS
 * Using domain realm: ad.home.lan
 * Calculated computer account name from fqdn: EOS
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * A computer account for EOS$ does not exist
 * Found well known computer container at: CN=Computers,DC=ad,DC=home,DC=lan
 * Calculated computer account: CN=EOS,CN=Computers,DC=ad,DC=home,DC=lan
 * Encryption type [3] not permitted.
 * Encryption type [1] not permitted.
 * Created computer account: CN=EOS,CN=Computers,DC=ad,DC=home,DC=lan
 * Trying to set computer password with Kerberos
 * Set computer password
 * Retrieved kvno '2' for computer account in directory: CN=EOS,CN=Computers,DC=ad,DC=home,DC=lan
 * Checking host/EOS
 *    Added host/EOS
 * Checking RestrictedKrbHost/EOS
 *    Added RestrictedKrbHost/EOS
 * Discovered which keytab salt to use
 * Added the entries to the keytab: EOS$@AD.HOME.LAN: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: host/EOS@AD.HOME.LAN: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/EOS@AD.HOME.LAN: FILE:/etc/krb5.keytab
 * /usr/bin/systemctl enable sssd
 * /usr/local/sbin/realmd-arch-helper.sh --enable-pam-nss
Enabled SSSD in PAM
Enabled SSSD in NSS
 ! Flushing name caches failed
 * Successfully enrolled machine in realm

As you can see, this time it does not complain about problems updating sssd/PAM but instead invokes /usr/local/sbin/realmd-arch-helper.sh --enable-pam-nss that implements the PAM configuration for Arch, as well as /usr/bin/systemctl enable sssd that enables the service.

STEP 5: Enable the realm service

systemctl enable realmd

I also restarted my machine, but after that, I was able to login.

IMPORTANT NOTE: It seems that in order to login you need to add the domain user. It’s not a “any domain user can login” sort of thing. You need to explicitly allow domain users. I did this similar to Fedora by using Gnome’s settings:

Settings / Users / Unlock / Add user / Enterprise Login (bottom button) / Enter username/password of user to allow access.

After this I could login using my AD credentials.

I am now looking for a way to allow all users (or at least a certain AD group) to login without explicitly adding them.

UPDATE:* The permit/deny commands allow you to configure who logs in. As per the documentation for realmd you can allow everyone to login with command: realm permit --realm domain.example.com --all

tuxaholic · September 20, 2023, 7:55am

One more update: you can configure sudo to allow members of an AD group to use it. Simply create a group in your Samba DC (I used sudoers@ad.home.lan) and configure the system by adding:

# cat /etc/sudoers.d/20-ad_home_lan
%sudoers@ad.home.lan ALL=(ALL) ALL

After adding your account to the group, you may need to logout (or even reboot) to get the new group membership to be visible. I’m not sure if a restart of the sssd or realmd service would help pick up the change without a reboot, but after logging out and back in I ran id and the new group membership was still not present. Rebooting picked it up and after that I was able to sudo from my domain account.

EDIT: sudoers does not work perfectly, ended up using “wheel”

Unfortunately this does not work well because most applications check for “wheel” group specifically. For example running eos-update --yay comes back with the error “User is not in sudoers” even though I am able to use sudo without issue because of the AD group membership.

Similarly, in Gnome’s settings if I go to “Sharing” and try to toggle “Remote login” instead of asking me for the password of my AD account (myuser@ad.home.lan) what happens instead is I get prompted for my old local user (myuser) because it seems that Gnome checks if you are in “wheel”. Since my AD account is not in “wheel” it instead lists the group members and picks the first one?

Either way I’ve ended up using:

usermod -a -G wheel myuser@ad.home.lan

This avoids the issues mentioned…