I can report success. I’ll need a few days to see if anything weird happens but as of now I can log into TrueNAS shares (it also has AD integration) the same as I do with Windows clients: 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
UPDATE 2: I noticed that when logging in with my AD account, the default GNOME keyring would not unlock automatically. I read the PAM setup section and could not understand why this was not working. It turned out that the answer is described in GNOME’s advanced configuration section, which explains the problem with “sufficient”. My solution was to use substack as per that documentation:
$ diff pam.d/gdm-password pam.d-preRealmD/gdm-password
3c3
< auth substack system-local-login
---
> auth include system-local-login
11c11
< session substack system-local-login
---
> session include system-local-login