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

[Cory Eaton]

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

[Andreas Hasenack (ahasenack)]

> 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

[Andreas Hasenack (ahasenack)]

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

[Sergio Durigan Junior (sergiodj)]

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.

[Andreas Hasenack (ahasenack)]

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.