Ubuntu
adcli package

domain join with --use-ldaps still uses port 389 for "LDAP ping"

Bug #1979081 reported by Cory Eaton on 2022-06-17

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	ADC	Fix Released	Unknown	auto-gitlab.freedesktop.org-realmd-adcli-- #31
	adcli (Ubuntu)	Triaged	Low	Unassigned

Bug Description

Attempting to join an Active Directory domain with realmd / adcli on Ubuntu 22.04 with the --use-ldaps switch (to force 636) still results with communication trying to happen over port 389. This appears to affect adcli version 0.9.1-1ubuntu2 that comes with Ubuntu 22.04 LTS, as an attempt on Ubuntu 20.04 LTS (with adcli version 0.9.0-1ubuntu0.20.04.1) works as-expected.

Based steps off of AWS-documented process to manually join a Linux machine to Active Directory, found here:
https://docs.aws.amazon.com/directoryservice/latest/admin-guide/join_linux_instance.html

For the sake of simplifying things and not dragging realmd into this, we'll just use adcli for the join instead of realmd (as realmd just calls adcli under the covers anyway).

What I expected to happen:
The domain join process communicates with the domain controllers over port 636 and proceeds normally.

What happened instead:
The domain join process hangs on sending the NetLogon ping to each domain controller with the error "Couldn't perform discovery search: Can't contact LDAP server". Firewall logs show outbound traffic to the domain controllers over port 389.

Steps to reproduce:
1. Block port 389 with ufw: sudo ufw allow ssh; sudo ufw deny out 389; sudo ufw enable. Could also just confirm the 389 traffic by monitoring network/cloud firewall logs.
2. Install required packages: sudo apt -y install adcli sssd realmd krb5-user samba-common packagekit
3. Update krb5.conf as shown in the AWS document.
4. Execute the adcli join command: sudo adcli join --use-ldaps example.com -U example_user --verbose

Revision history for this message

Andreas Hasenack (ahasenack) wrote on 2022-06-17:

> This appears to affect adcli version 0.9.1-1ubuntu2 that comes with Ubuntu 22.04 LTS, as an
> attempt on Ubuntu 20.04 LTS (with adcli version 0.9.0-1ubuntu0.20.04.1) works as-expected.

Turns out focal is also affected, but you didn't capture it in your network sniffer, or by the iptables block, because in focal openldap has CLDAP support (connection-less ldap), which means said NetLogon ping happens via UDP:

root@f-adcli-realmd:~# adcli join --verbose --use-ldaps INTERNAL.EXAMPLE.FAKE
* Using domain name: INTERNAL.EXAMPLE.FAKE
* Calculated computer account name from fqdn: F-ADCLI-REALMD
* Calculated domain realm from name: INTERNAL.EXAMPLE.FAKE
* Discovering domain controllers: _ldap._tcp.INTERNAL.EXAMPLE.FAKE
* Sending NetLogon ping to domain controller: win-kriet1e5elo.internal.example.fake
* Received NetLogon info from: WIN-KRIET1E5ELO.internal.example.fake
* Using LDAPS to connect to win-kriet1e5elo.internal.example.fake
* Wrote out krb5.conf snippet to /tmp/adcli-krb5-6keyvY/krb5.d/adcli-krb5-conf-0PSljW
! Couldn't authenticate as machine account: F-ADCLI-REALMD: Client 'F-ADCLI-REALMD$@INTERNAL.EXAMPLE.FAKE' not found in Kerberos database
Password for <email address hidden>:

root@f-adcli-realmd:~# tcpdump -i any -n -p port 389
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
20:22:52.902443 IP 10.0.16.12.56068 > 10.0.16.5.389: UDP, length 89
20:22:52.902920 IP 10.0.16.5.389 > 10.0.16.12.56068: UDP, length 205

I will file an issue with adcli upstream, because it will fallback[1] to "ldap" (instead of "ldaps" if --use-ldaps was given) if CLDAP is not supported.

For what is worth, the NetLogon ping/discovery is this type of query, and it seems to work fine via ldaps:

root@j-adcli-realmd:~# ldapsearch -o ldif_wrap=no -x -LLL -s base -b "" -H ldaps://WIN-KRIET1E5ELO.internal.example.fake '(&(DnsDomain=INTERNAL.EXAMPLE.FAKE)(NtVer=\06\00\00\02))' NetLogon
dn:
netlogon:: FwAAAP3zAwBx2l+9Hl8GSramUWvHAA/iCGludGVybmFsB2V4YW1wbGUEZmFrZQDAGA9XSU4tS1JJRVQxRTVFTE/AGApJTlRFWEFNUExFAA9XSU4tS1JJRVQxRTVFTE8AABdEZWZhdWx0LUZpcnN0LVNpdGUtTmFtZQDAYQUAAAD/////

1. https://gitlab.freedesktop.org/realmd/adcli/-/blob/master/library/addisco.c#L543
2. https://gitlab.freedesktop.org/realmd/adcli/-/blob/master/library/addisco.c#L563

> This appears to affect adcli version 0.9.1-1ubuntu2 that comes with Ubuntu 22.04 LTS, as an 
> attempt on Ubuntu 20.04 LTS (with adcli version 0.9.0-1ubuntu0.20.04.1) works as-expected.

root@f-adcli-realmd:~# adcli join --verbose --use-ldaps INTERNAL.EXAMPLE.FAKE
 * Using domain name: INTERNAL.EXAMPLE.FAKE
 * Calculated computer account name from fqdn: F-ADCLI-REALMD
 * Calculated domain realm from name: INTERNAL.EXAMPLE.FAKE
 * Discovering domain controllers: _ldap._tcp.INTERNAL.EXAMPLE.FAKE
 * Sending NetLogon ping to domain controller: win-kriet1e5elo.internal.example.fake
 * Received NetLogon info from: WIN-KRIET1E5ELO.internal.example.fake
 * Using LDAPS to connect to win-kriet1e5elo.internal.example.fake
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-6keyvY/krb5.d/adcli-krb5-conf-0PSljW
 ! Couldn't authenticate as machine account: F-ADCLI-REALMD: Client 'F-ADCLI-REALMD$@INTERNAL.EXAMPLE.FAKE' not found in Kerberos database
Password for Administrator@INTERNAL.EXAMPLE.FAKE:

I will file an issue with adcli upstream, because it will fallback[1] to "ldap" (instead of "ldaps" if --use-ldaps was given) if CLDAP is not supported.

For what is worth, the NetLogon ping/discovery is this type of query, and it seems to work fine via ldaps:

root@j-adcli-realmd:~# ldapsearch -o ldif_wrap=no  -x -LLL -s base -b "" -H ldaps://WIN-KRIET1E5ELO.internal.example.fake '(&(DnsDomain=INTERNAL.EXAMPLE.FAKE)(NtVer=\06\00\00\02))' NetLogon
dn:
netlogon:: FwAAAP3zAwBx2l+9Hl8GSramUWvHAA/iCGludGVybmFsB2V4YW1wbGUEZmFrZQDAGA9XSU4tS1JJRVQxRTVFTE/AGApJTlRFWEFNUExFAA9XSU4tS1JJRVQxRTVFTE8AABdEZWZhdWx0LUZpcnN0LVNpdGUtTmFtZQDAYQUAAAD/////

1. https://gitlab.freedesktop.org/realmd/adcli/-/blob/master/library/addisco.c#L543
2. https://gitlab.freedesktop.org/realmd/adcli/-/blob/master/library/addisco.c#L563

summary:	- domain join with --use-ldaps using port 389 + domain join with --use-ldaps still uses port 389 for NetLogon ping
summary:	- domain join with --use-ldaps still uses port 389 for NetLogon ping + domain join with --use-ldaps still uses port 389 for "LDAP ping"
Changed in adcli (Ubuntu):
status:	New → Triaged
importance:	Undecided → Medium
importance:	Medium → Low

Revision history for this message

Andreas Hasenack (ahasenack) wrote on 2022-06-17:

Upstream issue I just filed: https://gitlab.freedesktop.org/realmd/adcli/-/issues/31

no longer affects:

adc

Bug Watch Updater (bug-watch-updater) on 2022-09-01

Changed in adc:
status:	Unknown → New

Bug Watch Updater (bug-watch-updater) on 2022-09-27

Changed in adc:
status:	New → Fix Released

Revision history for this message

Sergio Durigan Junior (sergiodj) wrote on 2022-09-28:

I see that upstream has fixed the issue on their end.

Since this is a low priority bug, we can think about SRUing it along with other more important fixes for adcli.

Revision history for this message

Andreas Hasenack (ahasenack) wrote on 2022-09-28:

I think upstream fixed it in a slightly different way, according to the description (I didn't check the code). It looks like ldap will still be attempted, and ldaps only used if the former attempt failed. The intent of this bug I think was that if --use-ldaps was specified, then that's what should be used: no attempt on ldap, but just on ldaps.