Arch Linux User Repository

This package doesn't build with newer glibc version (>=2.34):

...
/usr/bin/ld: test_ldap-addisco.o: undefined reference to symbol 'ns_get32@@GLIBC_2.9'
/usr/bin/ld: /usr/lib/libresolv.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:737: test-ldap] Error 1

This has been fixed upstream via https://gitlab.freedesktop.org/realmd/adcli/-/merge_requests/44.

Until release 9.2 is out, it would make sense to bump a newer commit version for adcli: 938065a751c0876eb837a27f8c1443fc7d0d2551

@grawity any chance you could update the build spec?

@grawity: I did check back with someone who's more experienced with our AD setup (but unfortunately not on the admin/managing side because that part is managed by another company).

Our keytab stored machine password has a maximum age of 180 days and I assume there's some sort of script in place that disables all machine/keytab passwords which weren't changed longer than that interval ago. Our current "renew" scripts do this every 30 days to be on the safe side.

I'm by far no expert in AD and especially not on the Linux side of things, so thanks for pointing me into the sssd-ad direction and the ad_maximum_machine_account_password_age setting :).

@macgeneral: Hmm, Kerberos keytabs only contain password hashes and nothing else, so the only way they can "expire" is if the actual machine password that the keytab is based on stops being valid. (For example, if SSSD issues the password change due to ad_maximum_machine_account_password_age in sssd-ad(5)...)

But even if expiry is enforced for user passwords, I remember an actual Windows authentication developer (Steve Syfuhs) having written on several occasions that AD DCs deliberately ignore password expiry policies for machine accounts, so I'm not sure how your company is able to enforce that on the AD DC side.

@grawity: Thank you for the fast response. Unfortunately my company enforces keytab expiration after 30 days on the DC side. Having adcli as optional dependency in the community repo might also help to avoid others with similar policies to silently getting their keytab expired :)

@macgeneral: Sure, but note that keytabs do not expire on their own – they only expire if the machine itself (i.e. SSSD or Winbind) sends a password change request, this is not enforced on the DC side. So as a workaround you can configure the client to disable machine password changes, and its keytab will remain valid forever.

Thank you for maintaining this package.

I try to get adcli included in the community repository because it's an optional dependency for sssd and required to renew kerberos keytabs with it: https://bugs.archlinux.org/task/72557

@TheGoliath, there is no guideline about using tarballs instead of repository sources if they both provide the same code, and plenty of official Arch packages build releases from a VCS tag.

There is a guideline about preferring tagged releases instead of arbitrary non-tagged commits, but I chose to ignore it in favor of getting bugfixes and new features without waiting two more years for a release to happen. This is equivalent to backporting those commits via .patch files, and again you'll find many Arch packages doing the same.

(In other words, it's for the same reason as why you just dumped a truckload of patches onto realmd - all that stuff is why it used to build from a #commit= in the first place...)

Note that this is still different from the rule that requires the -git suffix. That suffix actually indicates that the package builds from master/tip/trunk, but that's not the case here - a specific fixed commit is built instead, so the "-git" suffix does not apply.

I try to join AD domain but have error:

adcli join mydomain.dom -U admin -vvvv
 * Using domain name: mydomain.dom.da
 * Calculated computer account name from fqdn: PC-NO
 * Calculated domain realm from name: MYDOMAIN.DOM.DA
 * Discovering domain controllers: _ldap._tcp.mydomain.dom.da
 * Sending NetLogon ping to domain controller: pdc.mydomain.dom.da
 * Sending NetLogon ping to domain controller: sdc.mydomain.dom.da
 * Received NetLogon info from: PDC.mydomain.dom.da
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-7d9dCU/krb5.d/adcli-krb5-conf-ll4K3S
Password for admin@MYDOMAIN.DOM.DA: 
 * Authenticated as user: admin@MYDOMAIN.DOM.DA
 * Looked up short domain name: MYDOMAIN
 * Looked up domain SID: S-1-5-21-2129043xxx-1170727xxx-3678xxxx
 * Using fully qualified name: pc-no
 * Using domain name: mydomain.dom.da
 * Using computer account name: PC-NO
 * Using domain realm: mydomain.dom.da
 * Calculated computer account name from fqdn: PC-NO
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * Found computer account for PC-NO$ at: CN=PC-NO,CN=Computers,DC=mydomain,DC=dom,DC=da
 * Sending NetLogon ping to domain controller: pdc.mydomain.dom.da
 * Received NetLogon info from: PDC.mydomain.dom.da
 * Set computer password
 * Retrieved kvno '12' for computer account in directory: CN=PC-NO,CN=Computers,DC=mydomain,DC=dom,DC=da
adcli: 'code == 0' not true at _adcli_krb5_keytab_test_salt
 ! Couldn't authenticate with keytab while discovering which salt to use: PC-NO$@MYDOMAIN.DOM.DA: Bad encryption type
 ! Couldn't add keytab entries: FILE:/etc/krb5.keytab: Bad encryption type
adcli: joining domain mydomain.dom.da failed: Couldn't add keytab entries: FILE:/etc/krb5.keytab: Bad encryption type