Comment 76 for bug 1868703

Performing verification of adcli on Bionic

The patches for Bionic are a bit more involved, as it adds the whole --use-ldaps ecosystem.

Firstly, I installed adcli 0.8.2-1 from -updates. The manpage did not have any mention of --use-ldaps, and if I ran a command with --use-ldaps, it would complain it was unrecongized.

# adcli join --use-ldaps --verbose --domain WIN-SB6JAS7PH22.testing.local --domain-controller WIN-SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL
join: unrecognized option '--use-ldaps'
usage: adcli join

I then enabled -proposed and installed adcli 0.8.2-1ubuntu1.

The man page now talks about --use-ldaps

$ man adcli | grep -i ldaps
       --use-ldaps
           Connect to the domain controller with LDAPS. By default the LDAP port is used and SASL GSS-SPNEGO or GSSAPI is used for authentication and to establish encryption. This should
           satisfy all requirements set on the server side and LDAPS should only be used if the LDAP port is not accessible due to firewalls or other reasons.
               $ LDAPTLS_CACERT=/path/to/ad_dc_ca_cert.pem adcli join --use-ldaps -D domain.example.com

I then enabled a firewall rule to block ldap connections:

# ufw deny 389
# ufw deny 3268

And tried the join command.

# adcli join --use-ldaps --verbose -U Administrator --domain WIN-SB6JAS7PH22.testing.local --domain-controller WIN-SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL
 * Using domain name: WIN-SB6JAS7PH22.testing.local
 * Calculated computer account name from fqdn: UBUNTU
 * Using domain realm: WIN-SB6JAS7PH22.testing.local
 * Sending NetLogon ping to domain controller: WIN-SB6JAS7PH22.testing.local
 * Received NetLogon info from: WIN-SB6JAS7PH22.testing.local
 * Using LDAPS to connect to WIN-SB6JAS7PH22.testing.local
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-ihG1h9/krb5.d/adcli-krb5-conf-bt9nd8
Password for <email address hidden>:
 * Authenticated as user: <email address hidden>
 * Using GSS-API for SASL bind
 * Looked up short domain name: TESTING
 * Looked up domain SID: S-1-5-21-960071060-1417404557-720088570
 * Using fully qualified name: ubuntu
 * Using domain name: WIN-SB6JAS7PH22.testing.local
 * Using computer account name: UBUNTU
 * Using domain realm: WIN-SB6JAS7PH22.testing.local
 * Calculated computer account name from fqdn: UBUNTU
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * Found computer account for UBUNTU$ at: CN=UBUNTU,CN=Computers,DC=testing,DC=local
 * Sending NetLogon ping to domain controller: WIN-SB6JAS7PH22.testing.local
 * Received NetLogon info from: WIN-SB6JAS7PH22.testing.local
 * Set computer password
 * Retrieved kvno '13' for computer account in directory: CN=UBUNTU,CN=Computers,DC=testing,DC=local
 * Checking RestrictedKrbHost/ubuntu.testing.local
 * Added RestrictedKrbHost/ubuntu.testing.local
 * Checking host/ubuntu.testing.local
 * Added host/ubuntu.testing.local
 * Checking RestrictedKrbHost/UBUNTU
 * Added RestrictedKrbHost/UBUNTU
 * Checking host/UBUNTU
 * Added host/UBUNTU
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Discovered which keytab salt to use
 * Added the entries to the keytab: UBUNTU$@TESTING.LOCAL: FILE:/etc/krb5.keytab
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: <email address hidden>: FILE:/etc/krb5.keytab
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: <email address hidden>: FILE:/etc/krb5.keytab
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: <email address hidden>: FILE:/etc/krb5.keytab
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: <email address hidden>: FILE:/etc/krb5.keytab

I couldn't catch the open port with netstat, so I used strace, and 636 was being used:

connect(3, {sa_family=AF_INET, sin_port=htons(636), sin_addr=inet_addr("192.168.122.66")}, 16) = 0

I then went through all the other sub commands and did a quick test to ensure they all took --use-ldaps and did not complain about "being unrecognized". All commands except "info" took the flag fine, and "info" was never intended to use --use-ldaps anyway.

Everything seems okay. Happy to mark adcli for Bionic verified.