Package Details: adcli 0.9.1.r14.g938065a-1

Git Clone URL: (read-only, click to copy)
Package Base: adcli
Description: Active Directory account management tool
Upstream URL:
Keywords: active-directory ldap
Licenses: GPL3
Submitter: grawity
Maintainer: grawity
Last Packager: grawity
Votes: 12
Popularity: 0.000000
First Submitted: 2013-08-19 16:30 (UTC)
Last Updated: 2022-03-08 18:16 (UTC)

Pinned Comments

Latest Comments

marion.deveaud commented on 2022-03-08 16:23 (UTC)

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/ 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

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?

macgeneral commented on 2021-10-29 11:08 (UTC)

@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 :).

grawity commented on 2021-10-28 07:05 (UTC)

@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.

macgeneral commented on 2021-10-28 06:40 (UTC) (edited on 2021-10-28 06:40 (UTC) by macgeneral)

@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 :)

grawity commented on 2021-10-28 05:47 (UTC)

@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.

macgeneral commented on 2021-10-28 05:40 (UTC)

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:

grawity commented on 2020-06-22 14:25 (UTC) (edited on 2020-11-30 09:07 (UTC) by grawity)

@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.

Stepannych commented on 2020-04-14 20:39 (UTC) (edited on 2020-04-15 06:02 (UTC) by Stepannych)

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
It was fixed in new version of this package for debian, centos redhat etc Can you please update package?

backpackjoe commented on 2017-11-15 22:47 (UTC) (edited on 2017-11-15 22:48 (UTC) by backpackjoe)

I tried to build with a minimal system and got a warning: Warning: failed to load external entity "" followed by an error being unable to parse the file. Over at "kde-workspace", i found a fix: installing kdelibs depending on the following packages: kdelibs attica-qt4 ilmbase libdbusmenu-qt4 libmng libutempter media-player-info openexr phonon-qt4 phonon-qt4-gstreamer polkit-qt4 qt4 xdg-utils so i guess something from that list is missing as a build dependency, same goes for adcli-git.

BuZZ-dEE commented on 2017-05-22 14:34 (UTC)

The following command worked for me. ~> gpg --recv-keys --keyserver hkps:// 7BFB1108D92765AF gpg: Schlüssel 7BFB1108D92765AF: Öffentlicher Schlüssel "Stef Walter <>" importiert gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: Tiefe: 0 gültig: 2 signiert: 1 Vertrauen: 0-, 0q, 0n, 0m, 0f, 2u gpg: Tiefe: 1 gültig: 1 signiert: 0 Vertrauen: 0-, 0q, 0n, 0m, 1f, 0u gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2017-08-30 gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1 gpg: importiert: 1

BuZZ-dEE commented on 2017-05-22 14:31 (UTC)

Same problem here, but behind a firewall. ~> gpg --recv-keys --keyserver hkp:// 7BFB1108D92765AF gpg: Keine gültigen OpenPGP-Daten gefunden. gpg: Anzahl insgesamt bearbeiteter Schlüssel: 0

ajzimm3rman commented on 2016-11-15 18:48 (UTC)

" I ran "gpg --recv-keys 7BFB1108D92765AF" and that seemed to fix it." I ran "gpg --recv-keys 7BFB1108D92765AF" and I got gpg: keyserver receive failed: No keyserver available.

jdawg commented on 2015-02-08 19:46 (UTC)

I was having problems because the SHA1 hash verification failed yesterday. I tried it again today and it worked! I also ran in to an error with GPG. I determined that I did not have public key in my keyring. I ran "gpg --recv-keys 7BFB1108D92765AF" and that seemed to fix it. Sorry for any confusion. Package works as expected. Thanks for your work in maintaining the package!

grawity commented on 2015-02-08 15:32 (UTC)

@jdawg: What SHA1 are you seeing? still has 4b4ec635447bd2bed8f73f52a2181242d468aab6 as far as I can see. There was no change since I've uploaded the package.

jdawg commented on 2015-02-08 06:37 (UTC)

According to the download page, this was last updated on 13-Sep-2013. The version number matches, but the SHA1 hash does not.

grawity commented on 2014-06-25 06:19 (UTC)

justin8: Could you export KRB5_TRACE=/dev/stderr, try adcli again, and email me the complete log? (Preferably both working and not-working, to see the diff.)

justin8 commented on 2014-06-25 03:52 (UTC)

Sorry to be annoying, but I've also noticed that this appears to work, but when authing against a domain (tested on 2k8 and 2k12 domains) it fails with this error: adcli: couldn't connect to domain: Couldn't authenticate as: $USER@$DOMAIN: Preauthentication failed unless SSSD is installed. It might only need to be an optdepend, I'm not sure what sort of domains it can authenticate against without it however.

justin8 commented on 2014-06-17 23:44 (UTC)

This is missing a build dep on docbook-xsl