adcli issueshttps://gitlab.freedesktop.org/realmd/adcli/-/issues2023-06-27T13:57:50Zhttps://gitlab.freedesktop.org/realmd/adcli/-/issues/18Failure to delete computer objects that have subobjects2023-06-27T13:57:50ZSxderpFailure to delete computer objects that have subobjects```
OS:
Red Hat Enterprise Linux Server release 7.6 (Maipo)
Kernel:
3.10.0-957.10.1.el7.x86_64 # 1 SMP Thu Feb 7 07:12:53 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
adcli package:
adcli-0:0.8.1-6.el7_6.1.x86_64
```
The issue cropped up w...```
OS:
Red Hat Enterprise Linux Server release 7.6 (Maipo)
Kernel:
3.10.0-957.10.1.el7.x86_64 # 1 SMP Thu Feb 7 07:12:53 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
adcli package:
adcli-0:0.8.1-6.el7_6.1.x86_64
```
The issue cropped up when we tried to delete a computer entry that was previously built as a Windows machine with BitLocker encryption. Seems like a child object is created to store metadata for BitLocker drive recovery. When removing the object from the Active Directory console a warning pops up about deleting child objects which we must confirm before the computer, and children, are deleted. Attempting `adcli delete-computer` returns with the following error (replaced with placeholders for brevity):
```
adcli: deleting $hostname in $domain domain failed: Couldn't delete computer account: $distingushedName: 00002015: UpdErr: DSID-031A12A5, problem 6003 (CANT_ON_NON_LEAF), data 0
```https://gitlab.freedesktop.org/realmd/adcli/-/issues/35LDAP server requires correct hostname to answer2023-10-09T16:18:49ZRobert SchneiderLDAP server requires correct hostname to answerThe AD discovery performs an (unauthenticated) query for NetLogon to LDAP servers. The connection is established with `ldap_initialize`, using the _IP_ address of the server (`ldap_disco()` in addisco.c). Later, when we `ldap_search_ext`...The AD discovery performs an (unauthenticated) query for NetLogon to LDAP servers. The connection is established with `ldap_initialize`, using the _IP_ address of the server (`ldap_disco()` in addisco.c). Later, when we `ldap_search_ext` using that connection, the LDAP object has never been told the hostname.
I've encountered an AD which does not answer (timeout in `ldap_disco_poller`) unless you include the hostname in the query. I'm not sure about the LDAP protocol details here, but I've spotted the difference between a succeeding `ldapsearch` and the failing connection attempt from `adcli`. When using `ldap_init_fd` instead of `ldap_initialize`, it is possible to supply both the IP (via the socket fd) and the hostname (via URI argument). This particular AD then does respond.
This might be related to my DNS issues mentioned in #34 (e.g. if OpenLDAP performs a reverse DNS search on the supplied IP, that DNS answer might also be affected in my case); however, I think it is beneficial to use `ldap_init_fd` anyway: it is used in the `ldaps_disco` and it allows implementing a connecting timeout because we gain control over the `connect()` call.
Please note that `ldap_init_fd` is available from `<openldap.h>`; no need to manually declare it.https://gitlab.freedesktop.org/realmd/adcli/-/issues/34Discovery could be improved for DCs with multiple IPs2023-10-04T18:04:36ZRobert SchneiderDiscovery could be improved for DCs with multiple IPs`ldap_disco` deals with situations where a DC has multiple IP addresses, or rather, multiple DNS A records. However, there are some aspects that could be improved:
- it uses the default connection timeout, which can be 20-30 s per IP (th...`ldap_disco` deals with situations where a DC has multiple IP addresses, or rather, multiple DNS A records. However, there are some aspects that could be improved:
- it uses the default connection timeout, which can be 20-30 s per IP (this would require a non-blocking connection attempt plus something like `select()` with a timeout)
- it does not tell the later stages which IP is used during the connection test; e.g. `connect_to_address()` (from adconn.c) performs another iteration through all DNS responses (again, with default timeout)
I'm not even sure if multiple DNS A records for a single DC are legal, considering the reverse DNS lookup performed by Kerberos. I encountered this issue when a DNS proxy had a bug and inserted additional answers. Those are not reachable for LDAP, which seems to break `adcli` even if the correct IP is part of the (bloated) DNS answer.https://gitlab.freedesktop.org/realmd/adcli/-/issues/33adcli update does not update keytab-file when new SPNs was added via AD2023-07-20T12:02:39ZStefan Baueradcli update does not update keytab-file when new SPNs was added via ADHaving a domain-joined Debian 12 System (adcli 0.9.1-2)
Adding an additonal SPN-attribute to machine-account on local domain controller.
Running adcli update -v shows the additional records, but does not update local keytab file. Thats ...Having a domain-joined Debian 12 System (adcli 0.9.1-2)
Adding an additonal SPN-attribute to machine-account on local domain controller.
Running adcli update -v shows the additional records, but does not update local keytab file. Thats leads to failing kerberos-authentication as application does not know about the new SPNs.
```
# adcli update -v
* Found realm in keytab: DOMAIN.LOCAL
* Found computer name in keytab: KERBEROS-TEST
* Found service principal in keytab: host/KERBEROS-TEST
* Found service principal in keytab: host/kerberos-test.domain.intern
* Found host qualified name in keytab: kerberos-test.domain.intern
* Found service principal in keytab: RestrictedKrbHost/KERBEROS-TEST
* Found service principal in keytab: RestrictedKrbHost/kerberos-test.domain.intern
* Calculated domain name from host fqdn: domaingmbh.intranet
* Using computer account name: KERBEROS-TEST
* Using domain realm: domaingmbh.intranet
* Discovering domain controllers: _ldap._tcp.domaingmbh.intranet
* Sending NetLogon ping to domain controller: ox.domaingmbh.intranet
* Sending NetLogon ping to domain controller: ox.domaingmbh.intranet
* Received NetLogon info from: ox.domaingmbh.intranet
* Wrote out krb5.conf snippet to /tmp/adcli-krb5-qCsk5n/krb5.d/adcli-krb5-conf-IQIFDI
* Authenticated as default/reset computer account: KERBEROS-TEST
* Using GSS-SPNEGO for SASL bind
* Looked up short domain name: MUSTERGMBH
* Looked up domain SID: S-1-5-21-2666612435-3853467678-3725716476
* Using fully qualified name: kerberos-test.domaingmbh.intranet
* Using domain name: domaingmbh.intranet
* Using computer account name: KERBEROS-TEST
* Using domain realm: domaingmbh.intranet
* Using fully qualified name: kerberos-test.domain.intern
* Enrolling computer name: KERBEROS-TEST
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Found computer account for KERBEROS-TEST$ at: CN=KERBEROS-TEST,CN=Computers,DC=domaingmbh,DC=intranet
* Retrieved kvno '2' for computer account in directory: CN=KERBEROS-TEST,CN=Computers,DC=domaingmbh,DC=intranet
* Password not too old, no change needed
* Sending NetLogon ping to domain controller: ox.domaingmbh.intranet
* Sending NetLogon ping to domain controller: ox.domaingmbh.intranet
* Received NetLogon info from: ox.domaingmbh.intranet
* Checking host/KERBEROS-TEST
* Added host/KERBEROS-TEST
* Checking host/kerberos-test.domain.intern
* Added host/kerberos-test.domain.intern
* Checking RestrictedKrbHost/KERBEROS-TEST
* Added RestrictedKrbHost/KERBEROS-TEST
* Checking RestrictedKrbHost/kerberos-test.domain.intern
* Added RestrictedKrbHost/kerberos-test.domain.intern
* Checking HTTP/KERBEROS-TEST
* Added HTTP/KERBEROS-TEST
* Checking HTTP/KERBEROS-TEST.domain.intern
* Added HTTP/KERBEROS-TEST.domain.intern
```
```
# klist -ek /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 KERBEROS-TEST$@DOMAIN.LOCAL (DEPRECATED:arcfour-hmac)
2 KERBEROS-TEST$@DOMAIN.LOCAL (aes128-cts-hmac-sha1-96)
2 KERBEROS-TEST$@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96)
2 host/KERBEROS-TEST@DOMAIN.LOCAL (DEPRECATED:arcfour-hmac)
2 host/KERBEROS-TEST@DOMAIN.LOCAL (aes128-cts-hmac-sha1-96)
2 host/KERBEROS-TEST@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96)
2 host/kerberos-test.domain.intern@DOMAIN.LOCAL (DEPRECATED:arcfour-hmac)
2 host/kerberos-test.domain.intern@DOMAIN.LOCAL (aes128-cts-hmac-sha1-96)
2 host/kerberos-test.domain.intern@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/KERBEROS-TEST@DOMAIN.LOCAL (DEPRECATED:arcfour-hmac)
2 RestrictedKrbHost/KERBEROS-TEST@DOMAIN.LOCAL (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/KERBEROS-TEST@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/kerberos-test.domain.intern@DOMAIN.LOCAL (DEPRECATED:arcfour-hmac)
2 RestrictedKrbHost/kerberos-test.domain.intern@DOMAIN.LOCAL (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/kerberos-test.domain.intern@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96)
```
However adding the SPN via adcli, updates the keytab file and keytab now contains all records:
```
# adcli update -v --add-service-principal=ldap/kerberos-test.domain.intern@MUSTER.LOCAL
* Found realm in keytab: MUSTER.LOCAL
* Found computer name in keytab: KERBEROS-TEST
* Found service principal in keytab: host/KERBEROS-TEST
* Found service principal in keytab: host/kerberos-test.domain.intern
* Found host qualified name in keytab: kerberos-test.domain.intern
* Found service principal in keytab: RestrictedKrbHost/KERBEROS-TEST
* Found service principal in keytab: RestrictedKrbHost/kerberos-test.domain.intern
* Calculated domain name from host fqdn: mustergmbh.intranet
* Using computer account name: KERBEROS-TEST
* Using domain realm: mustergmbh.intranet
* Discovering domain controllers: _ldap._tcp.mustergmbh.intranet
* Sending NetLogon ping to domain controller: ox.mustergmbh.intranet
* Sending NetLogon ping to domain controller: ox.mustergmbh.intranet
* Received NetLogon info from: ox.mustergmbh.intranet
* Wrote out krb5.conf snippet to /tmp/adcli-krb5-zIw7G5/krb5.d/adcli-krb5-conf-thrPSB
* Authenticated as default/reset computer account: KERBEROS-TEST
* Using GSS-SPNEGO for SASL bind
* Looked up short domain name: MUSTERGMBH
* Looked up domain SID: S-1-5-21-2666612435-3853467678-3725716476
* Using fully qualified name: kerberos-test.mustergmbh.intranet
* Using domain name: mustergmbh.intranet
* Using computer account name: KERBEROS-TEST
* Using domain realm: mustergmbh.intranet
* Using fully qualified name: kerberos-test.domain.intern
* Enrolling computer name: KERBEROS-TEST
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Found computer account for KERBEROS-TEST$ at: CN=KERBEROS-TEST,CN=Computers,DC=mustergmbh,DC=intranet
* Retrieved kvno '2' for computer account in directory: CN=KERBEROS-TEST,CN=Computers,DC=mustergmbh,DC=intranet
* Password not too old, no change needed
* Sending NetLogon ping to domain controller: ox.mustergmbh.intranet
* Sending NetLogon ping to domain controller: ox.mustergmbh.intranet
* Received NetLogon info from: ox.mustergmbh.intranet
* Checking host/KERBEROS-TEST
* Added host/KERBEROS-TEST
* Checking host/kerberos-test.domain.intern
* Added host/kerberos-test.domain.intern
* Checking RestrictedKrbHost/KERBEROS-TEST
* Added RestrictedKrbHost/KERBEROS-TEST
* Checking RestrictedKrbHost/kerberos-test.domain.intern
* Added RestrictedKrbHost/kerberos-test.domain.intern
* Checking HTTP/KERBEROS-TEST
* Added HTTP/KERBEROS-TEST
* Checking HTTP/KERBEROS-TEST.domain.intern
* Added HTTP/KERBEROS-TEST.domain.intern
* Cleared old entries from keytab: FILE:/etc/krb5.keytab
* Added the entries to the keytab: KERBEROS-TEST$@MUSTER.LOCAL: FILE:/etc/krb5.keytab
* Cleared old entries from keytab: FILE:/etc/krb5.keytab
* Added the entries to the keytab: host/KERBEROS-TEST@MUSTER.LOCAL: FILE:/etc/krb5.keytab
* Cleared old entries from keytab: FILE:/etc/krb5.keytab
* Added the entries to the keytab: host/kerberos-test.domain.intern@MUSTER.LOCAL: FILE:/etc/krb5.keytab
* Cleared old entries from keytab: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/KERBEROS-TEST@MUSTER.LOCAL: FILE:/etc/krb5.keytab
* Cleared old entries from keytab: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/kerberos-test.domain.intern@MUSTER.LOCAL: FILE:/etc/krb5.keytab
* Added the entries to the keytab: ldap/kerberos-test.domain.intern@MUSTER.LOCAL: FILE:/etc/krb5.keytab
* Added the entries to the keytab: HTTP/KERBEROS-TEST@MUSTER.LOCAL: FILE:/etc/krb5.keytab
* Added the entries to the keytab: HTTP/KERBEROS-TEST.domain.intern@MUSTER.LOCAL: FILE:/etc/krb5.keytab
(reverse-i-search)`kt': kinit ssotest -^C test.keytab
root@kerberos-test:/etc/apache2# klist -ek /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 KERBEROS-TEST$@MUSTER.LOCAL (DEPRECATED:arcfour-hmac)
2 KERBEROS-TEST$@MUSTER.LOCAL (aes128-cts-hmac-sha1-96)
2 KERBEROS-TEST$@MUSTER.LOCAL (aes256-cts-hmac-sha1-96)
2 host/KERBEROS-TEST@MUSTER.LOCAL (DEPRECATED:arcfour-hmac)
2 host/KERBEROS-TEST@MUSTER.LOCAL (aes128-cts-hmac-sha1-96)
2 host/KERBEROS-TEST@MUSTER.LOCAL (aes256-cts-hmac-sha1-96)
2 host/kerberos-test.domain.intern@MUSTER.LOCAL (DEPRECATED:arcfour-hmac)
2 host/kerberos-test.domain.intern@MUSTER.LOCAL (aes128-cts-hmac-sha1-96)
2 host/kerberos-test.domain.intern@MUSTER.LOCAL (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/KERBEROS-TEST@MUSTER.LOCAL (DEPRECATED:arcfour-hmac)
2 RestrictedKrbHost/KERBEROS-TEST@MUSTER.LOCAL (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/KERBEROS-TEST@MUSTER.LOCAL (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/kerberos-test.domain.intern@MUSTER.LOCAL (DEPRECATED:arcfour-hmac)
2 RestrictedKrbHost/kerberos-test.domain.intern@MUSTER.LOCAL (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/kerberos-test.domain.intern@MUSTER.LOCAL (aes256-cts-hmac-sha1-96)
2 ldap/kerberos-test.domain.intern@MUSTER.LOCAL (DEPRECATED:arcfour-hmac)
2 ldap/kerberos-test.domain.intern@MUSTER.LOCAL (aes128-cts-hmac-sha1-96)
2 ldap/kerberos-test.domain.intern@MUSTER.LOCAL (aes256-cts-hmac-sha1-96)
2 HTTP/KERBEROS-TEST@MUSTER.LOCAL (DEPRECATED:arcfour-hmac)
2 HTTP/KERBEROS-TEST@MUSTER.LOCAL (aes128-cts-hmac-sha1-96)
2 HTTP/KERBEROS-TEST@MUSTER.LOCAL (aes256-cts-hmac-sha1-96)
2 HTTP/KERBEROS-TEST.domain.intern@MUSTER.LOCAL (DEPRECATED:arcfour-hmac)
2 HTTP/KERBEROS-TEST.domain.intern@MUSTER.LOCAL (aes128-cts-hmac-sha1-96)
2 HTTP/KERBEROS-TEST.domain.intern@MUSTER.LOCAL (aes256-cts-hmac-sha1-96)
```https://gitlab.freedesktop.org/realmd/adcli/-/issues/32Tune `connect()` if libldap does not support connectionless LDAP2023-01-26T12:13:30ZSumit BoseTune `connect()` if libldap does not support connectionless LDAPIf libldap does not support connectionless LDAP adcli might hang for 2 minutes during the CLDAP ping discover phase. The related timeouts should be tuned so that `connect()` does not wait for too long before returning an error. See https...If libldap does not support connectionless LDAP adcli might hang for 2 minutes during the CLDAP ping discover phase. The related timeouts should be tuned so that `connect()` does not wait for too long before returning an error. See https://github.com/SSSD/sssd/issues/6537 for additional details.https://gitlab.freedesktop.org/realmd/adcli/-/issues/30Feature Request: Allow adding Groups to Groups2022-05-17T10:26:40ZNoldFeature Request: Allow adding Groups to GroupsI wanted to use `adcli add-member` to add groups to a group. sadly it only supports users.
Any reason `adcli` can't support groups, too?I wanted to use `adcli add-member` to add groups to a group. sadly it only supports users.
Any reason `adcli` can't support groups, too?https://gitlab.freedesktop.org/realmd/adcli/-/issues/25How to remove CNF entries from active directory using SSSD realm/adcli?2021-03-30T10:33:00ZParimala BandiHow to remove CNF entries from active directory using SSSD realm/adcli?We are using ubuntu configured with SSSD(realm) active directory
Currently, we have implemented power shell script from windows server for deleting the duplicate computer entries. Is there any command to remove the duplicate entries from...We are using ubuntu configured with SSSD(realm) active directory
Currently, we have implemented power shell script from windows server for deleting the duplicate computer entries. Is there any command to remove the duplicate entries from ubuntu SSSD to delete these duplicates.
Eg: Below is the example of duplicate computer
CNF Entry exists for : CN=osd6-molecule-2\0ACNF:3fd1f177-a8c3-4d48-af17-e9c49ab27c69,OU=Osd-clients,OU=Applications,DC=APAC,DC=bosch,DC=comhttps://gitlab.freedesktop.org/realmd/adcli/-/issues/23Is there a way to tell adcli testjoin what domain to use via the keytab or ot...2020-12-17T14:33:18ZKodiak FiresmithIs there a way to tell adcli testjoin what domain to use via the keytab or other means?I think our site might be somewhat common in that we have an AD domain that differs from our DNS domain slightly.
DNS domain: college.edu
AD domain: ADMIN.COLLEGE.EDU
Using msktutil with --no-reverse-lookups allows me to create a well...I think our site might be somewhat common in that we have an AD domain that differs from our DNS domain slightly.
DNS domain: college.edu
AD domain: ADMIN.COLLEGE.EDU
Using msktutil with --no-reverse-lookups allows me to create a well tailored keytab and principals, but things like 'adcli testjoin' don't work afterward despite all the other trimmings working fine such as SSSD-based auth, kinit of the keytab, etc.
So I guess what I'm trying to work out is how I would explain to adcli to either find or calculate the right domain name from the principals in the keytab, or how to manually specify it somewhere.
Here's an example testjoin operation:
```bash
adcli -vvv testjoin
* Found realm in keytab: ADMIN.COLLEGE.EDU
* Found computer name in keytab: BRIGGS
* Found service principal in keytab: host/briggs.college.edu
* Found host qualified name in keytab: briggs.college.edu
* Found service principal in keytab: host/briggs
* Calculated domain name from host fqdn: college.edu
* Calculated computer account name from fqdn: BRIGGS
* Using domain realm: college.edu
* Discovering domain controllers: _ldap._tcp.college.edu
! No LDAP SRV records for domain: _ldap._tcp.college.edu: Name or service not known
! Couldn't find usable domain controller to connect to
adcli: couldn't connect to college.edu domain: Couldn't find usable domain controller to connect to
```https://gitlab.freedesktop.org/realmd/adcli/-/issues/22adcli update adding FQDN entries to keytab from not joined domain2020-10-16T16:49:37ZLuiz Angelo Daros de Lucaadcli update adding FQDN entries to keytab from not joined domainHello,
I migrate a machine from domain subdomain.example.com to example.com. Both trust each other but they do not belong to the same forest. I'm using adcli-0.9.0+git.0.1b15280
As long as mymachine entry exists inside subdomain.exampl...Hello,
I migrate a machine from domain subdomain.example.com to example.com. Both trust each other but they do not belong to the same forest. I'm using adcli-0.9.0+git.0.1b15280
As long as mymachine entry exists inside subdomain.example.com AD, adcli is adding
host\mymachine.subdomain.example.com to my keytab (although those entries are not really valid and colide with subdomain.example.com REALM).
```
# adcli update --domain=subdomain.example.com
```
I needed to remove mymachine object from subdomain.example.com AD in order to adcli correctly fail to update keytab.
Also, it seems that testjoin does not check if the machine is really joined to the target domain or if it is from a trusted domain. Both are sucessfully validated joins:
```
# adcli testjoin --domain=example.com
# adcli testjoin --domain=subdomain.example.com
```
Even after I removed the machine account. It should have failed even before I removed the object.https://gitlab.freedesktop.org/realmd/adcli/-/issues/11Port to HEIMDAL2021-10-18T08:13:47ZBugzilla Migration UserPort to HEIMDAL## Submitted by Mikhail T.
Assigned to **Stef Walter**
**[Link to original bug (#96558)](https://bugs.freedesktop.org/show_bug.cgi?id=96558)**
## Description
Created attachment 124563
Port outside of Linux -- and allow both MIT an...## Submitted by Mikhail T.
Assigned to **Stef Walter**
**[Link to original bug (#96558)](https://bugs.freedesktop.org/show_bug.cgi?id=96558)**
## Description
Created attachment 124563
Port outside of Linux -- and allow both MIT and Heimdal kerberos implementations to work
Attached are patches I had to implement to port adcli to FreeBSD. A few hunks deal with general porting (some headers must be explicitly #include-ed on BSD, which are implicitly loaded on Linux), but the vast majority is for Heimdal compatibility.
Tested on FreeBSD-10.3 using both MIT Kerberos libraries and Heimdal GSSAPI, that comes with the OS. `make check' passes too, but I do not know, how comprehensive that is:
adcli-0.8.1 % make check
Making check in build
Making check in library
make test-seq test-util test-ldap test-attrs
`test-seq' is up to date.
`test-util' is up to date.
`test-ldap' is up to date.
`test-attrs' is up to date.
make check-TESTS
PASS: test-seq
PASS: test-util
PASS: test-ldap
PASS: test-attrs
============================================================================
Testsuite summary for adcli 0.8.1
============================================================================
# TOTAL: 4
# PASS: 4
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
Making check in tools
Making check in doc
mkdir -p ./html && cp ./static/* ./html/
true html -m ./gtk-doc.xsl -o ./html --searchpath .:. ./adcli-docs.xml
The very first hunk patches configure, which is included in the source tarball (0.8.1). You'll probably patch configure.ac instead.
The rest should be applicable straight. I had to disable the use/creation of custom krb5.conf in Heimdal case -- the Heimdal does not support includedir and include directives. Fortunately, it seems like it is not necessary anyway...
Detecting Heimdal (and adding -DHEIMDAL to CFLAGS) would be nice too, but I'm not well-versed with configure/libtool et. al.
I'd also like to request, that the prebuilt manual-page (adcli.8) be bundled with the release and installed regardless of --disable-doc. (man-pages are special.) Building it from the XML-source requires xsltproc, which may be too heavy a dependency for some. A minor point...
~~**Patch 124563**~~, "Port outside of Linux -- and allow both MIT and Heimdal kerberos implementations to work":
[patch-adcli-combined](/uploads/8d3ac1bfe66657c4f4fe185a80a2a83c/patch-adcli-combined)https://gitlab.freedesktop.org/realmd/adcli/-/issues/2Improve user creation / account provisioning2019-03-22T10:46:51ZBugzilla Migration UserImprove user creation / account provisioning## Submitted by Mark Felder
Assigned to **Stef Walter**
**[Link to original bug (#96640)](https://bugs.freedesktop.org/show_bug.cgi?id=96640)**
## Description
It would be great if adcli could provide a few more things for account ...## Submitted by Mark Felder
Assigned to **Stef Walter**
**[Link to original bug (#96640)](https://bugs.freedesktop.org/show_bug.cgi?id=96640)**
## Description
It would be great if adcli could provide a few more things for account provisioning:
- Set First (GivenName) and Last (Surname)
- Set NISDomain (msSFU30NisDomain)
- Set PrimaryGroupID
- Set Password
- Set ChangePasswordAtLogon
- Set PasswordNeverExpires
This would make adcli the ultimate tool for bulk account provisioning.