Bug#1002697: adcli 0.9.1-1 not joining domain with insufficient permissions message.

Sérgio Machado

unread,

Dec 27, 2021, 12:00:05 PM12/27/21

to

Package: adcli

Version: 0.9.1-1

Hi,

While using Debian Testing the following package:

We are unable to join Domain (Samba4 AD 4.13.13)
realm join --membership-software=adcli -U sergio domain.local -vvv
* Resolving: _ldap._tcp.domain.local
* Performing LDAP DSE lookup on: 192.168.1.253
* Performing LDAP DSE lookup on: 192.168.2.253
* Successfully discovered: domain.local
Password for sergiom:
* Unconditionally checking packages
* Resolving required packages
* LANG=C /usr/sbin/adcli join --verbose --domain domain.local --domain-realm DOMAIN.LOCAL --domain-controller 192.168.1.253 --login-type user --login-user sergio --stdin-password
* Using domain name: domain.local
* Calculated computer account name from fqdn: TESTSRV
* Using domain realm: domain.local
* Sending NetLogon ping to domain controller: 192.168.1.253
* Received NetLogon info from: srv01.domain.local
* Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-XXXXX/krb5.d/adcli-krb5-conf-xxxxx
* Authenticated as user: sergio@DOMAIN.LOCAL
* Using GSS-SPNEGO for SASL bind
! Couldn't authenticate to active directory: SASL(-4): no mechanism available: No worthy mechs found
adcli: couldn't connect to domain.local domain: Couldn't authenticate to active directory: SASL(-4): no mechanism available: No worthy mechs found
! Insufficient permissions to join the domain
realm: Couldn't join realm: Insufficient permissions to join the domain

If use adcli 0.9.0 from bullseye then all work ok:
realm join --membership-software=adcli -U sergio domain.local -vvv

* Resolving: _ldap._tcp.domain.local
* Performing LDAP DSE lookup on: 192.168.1.253
* Performing LDAP DSE lookup on: 192.168.2.253
* Successfully discovered: domain.local
Password for sergiom:
* Unconditionally checking packages
* Resolving required packages
* LANG=C /usr/sbin/adcli join --verbose --domain domain.local --domain-realm DOMAIN.LOCAL --domain-controller 192.168.1.253 --login-type user --login-user sergio --stdin-password
* Using domain name: domain.local
* Calculated computer account name from fqdn: TESTSRV
* Using domain realm: domain.local
* Sending NetLogon ping to domain controller: 192.168.1.253
* Received NetLogon info from: srv01.domain.local
* Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-XXXXX/krb5.d/adcli-krb5-conf-XXXXX
* Authenticated as user: sergio@DOMAIN.LOCAL
* Looked up short domain name: DOMAIN
* Looked up domain SID: S-1-5-21-...
* Using fully qualified name: testsrv
* Using domain name: domain.local
* Using computer account name: TESTSRV
* Using domain realm: domain.local
* Calculated computer account name from fqdn: TESTSRV
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Found computer account for TESTSRV$ at: CN=TESTSRV,CN=Computers,DC=domain,DC=local
* Sending NetLogon ping to domain controller: 192.168.1.253
* Received NetLogon info from: srv01.domain.local
* Set computer password
* Retrieved kvno '3' for computer account in directory: CN=TESTSRV,CN=Computers,DC=domain,DC=local
* Checking host/TESTSRV
* Added host/TESTSRV
* Checking RestrictedKrbHost/TESTSRV
* Added RestrictedKrbHost/TESTSRV
* Discovered which keytab salt to use
* Added the entries to the keytab: TESTSRV$@DOMAIN.LOCAL: FILE:/etc/krb5.keytab
* Added the entries to the keytab: host/TESTSRV@DOMAIN.LOCAL: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/TESTSRV@DOMAIN.LOCAL: FILE:/etc/krb5.keytab
! Failed to update Kerberos configuration, not fatal, please check manually: Setting attribute standard::type not supported
* /usr/sbin/update-rc.d sssd enable
* /usr/sbin/service sssd restart
* Successfully enrolled machine in realm

Additional information:
Domain SAMBA4 ADDC configuration:
(Debian Stable latest)
# Global parameters
[global]
netbios name = SRV01
realm = DOMAIN.LOCAL
workgroup = DOMAIN
dns forwarder = 1.1.1.1
server role = active directory domain controller
idmap config domain_name:unix_nss_info = yes
idmap_ldb:use rfc2307 = yes
template shell = /bin/bash
template homedir = /home/DOMAIN/%U
winbind use default domain = true
winbind offline logon = false
winbind nss info = rfc2307
winbind enum users = yes
winbind enum groups = yes
dsdb:schema update allowed = yes
tls enabled = yes
tls keyfile = tls/ADk.pem
tls certfile = tls/ADc.pem
tls cafile = tls/CA.pem
usershare allow guests = no
acl allow execute always = yes
printcap name = /dev/null
load printers = no
printing = bsd
ntlm auth = ntlmv2-only
tls priority = SECURE256:+SECURE192:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.3
restrict anonymous = 2
allow dns updates = secure only
[netlogon]
path = /var/lib/samba/sysvol/domain.local/scripts
vfs objects = full_audit
read only = No

[sysvol]
path = /var/lib/samba/sysvol
vfs objects = full_audit
read only = No
case sensitive = no
vfs objects = dfs_samba4 acl_xattr
browseable = no

kerberos client:
(client with latest Debian testing)
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = DOMAIN.LOCAL
rdns = false
dns_lookup_realm = true
dns_lookup_kdc = true
default_ccache_name = KEYRING:persistent:%{uid}
ticket_lifetime = 24h
forwardable = yes
ignore_acceptor_hostname = true
udp_preference_limit = 0

[realms]
DOMAIN.LOCAL = {
kdc = srv01.domain.local
kdc = srv02.domain.local
}

[domain_realm]
.DOMAIN.LOCAL = DOMAIN.LOCAL
DOMAIN.LOCAL = DOMAIN.LOCAL

domain.local = DOMAIN.LOCAL
.domain.local = DOMAIN.LOCAL
[appdefaults]
pam = {
debug = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
krb4_convert = false
}

Thank you in advance.

Happy new Year!
Best Regards,
Sérgio Machado

leonardo

unread,

Jan 3, 2022, 10:50:03 AM1/3/22

to

Hi, same problem is on sssd, when I upgrade from 2.5.2 to 2.6.1,
probably the bug is not adcli related.

I tried to unjoin because I had some authentication problems, in
/var/log/sssd/sssd_<MYDOMAIN>.log

   * (2022-01-02 0:01:25): [be[MYDOMAIN]] [sasl_bind_send] (0x0100):
Executing sasl bind mech: GSS-SPNEGO, user: PCLEONOVO$
   * (2022-01-02 0:01:25): [be[MYDOMAIN]] [ad_sasl_log] (0x0040):
SASL: No worthy mechs found
********************** BACKTRACE DUMP ENDS HERE
*********************************

(2022-01-02 0:01:25): [be[MYDOMAIN]] [sasl_bind_send] (0x0020):
ldap_sasl_interactive_bind_s failed (-6)[Unknown authentication method]
(2022-01-02 0:01:25): [be[MYDOMAIN]] [sdap_cli_connect_recv] (0x0040):
Unable to establish connection [1432158227]: Authentication Failed
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING
BACKTRACE:
   * (2022-01-02 0:01:25): [be[MYDOMAIN]] [sasl_bind_send] (0x0020):
ldap_sasl_interactive_bind_s failed (-6)[Unknown authentication method]
   * (2022-01-02 0:01:25): [be[MYDOMAIN]] [sasl_bind_send] (0x0080):
Extended failure message: [SASL(-4): no mechanism available: No worthy
mechs found]
   * (2022-01-02 0:01:25): [be[MYDOMAIN]] [sdap_cli_connect_recv]
(0x0040): Unable to establish connection [1432158227]: Authentication Failed
********************** BACKTRACE DUMP ENDS HERE
*********************************

now, when i try to join again:

* Using GSS-SPNEGO for SASL bind
! Couldn't authenticate to active directory: SASL(-4): no mechanism
available: No worthy mechs found

adcli: couldn't connect to MYDOMAIN domain: Couldn't authenticate to

Leonardo Lorenzetti - ESTAR

unread,

Jan 4, 2022, 5:40:03 AM1/4/22

to

this is caused by cyrus-sasl2, see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000152

--

Leonardo Lorenzetti
U.O.C. Reti e Sistemi Area Nord-Ovest
Dipartimento Tecnologie Informatiche
ESTAR

Ex Ospedale Campo di Marte - Padiglione C - 55100 Lucca (LU)
tel: 0583.970826 - mail ufficio: operation.l...@estar.toscana.it

Se possibile non stampare questa mail!

Le informazioni contenute nella presente comunicazione ed in ogni eventuale file allegato possono essere riservate
e sono comunque destinate esclusivamente alla persona o Ente/Azienda in indirizzo. Le informazioni contenute nella presente
comunicazione ed in ogni eventuale file allegato non sono da considerarsi comunicazioni personali, quindi eventuali risposte
potranno essere conosciute da persone appartenenti ad Estar. La diffusione, distribuzione e/o copiatura del documento trasmesso
da parte di persona diversa dal destinatario è proibita ai sensi dell'art. 616 c.p. I dati forniti verranno trattati ai sensi
dell'art. 5 del Regolamento Generale sulla protezione dei dati UE 2016/679 del Parlamento Europeo e del Consiglio del 27 aprile 2016.
Se ha ricevuto per errore questa comunicazione, La invitiamo a distruggerla e ad informare immediatamente il mittente.