Performing verification of adcli on Focal

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

Firstly, I installed adcli 0.9.0-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.9.0-1ubuntu0.20.04.1.

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 Administrator@TESTING.LOCAL: 
 * Authenticated as user: Administrator@TESTING.LOCAL
 * 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: host/UBUNTU@TESTING.LOCAL: 
FILE:/etc/krb5.keytab
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/UBUNTU@TESTING.LOCAL: 
FILE:/etc/krb5.keytab
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: 
RestrictedKrbHost/ubuntu.testing.local@TESTING.LOCAL: FILE:/etc/krb5.keytab
 * Cleared old entries from keytab: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: host/ubuntu.testing.local@TESTING.LOCAL: 
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 looks good. Happy to mark adcli for Focal verified.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1868703

Title:
  Support "ad_use_ldaps" flag for new AD requirements (ADV190023)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cyrus-sasl2/+bug/1868703/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to