The Samba-Bugzilla – Bug 13124
StartTLS certificate verification broken in ldap ssl ads
Last modified: 2017-12-31 13:33:05 UTC
StartTLS certificate verification broken in ldap ssl ads.
- Windows domain with at least one domain controller with LDAP starttls enabled and valid SSL certificates installed for this service
- winbindd joined to the domain
- windbind configured with /etc/samba/smb.conf with the following:
ldap ssl = start_tls
ldap ssl ads = yes
client ldap sasl wrapping = plain
ldap debug level = 10
- /etc/ldap/ldap.conf (libldap-2.4) configured with the following
Steps to trigger the bug:
Start winbindd as:
windbind -F -S -d 11
winbindd will produce a message like:
[LDAP] TLS: hostname (220.127.116.11) does not match common name in certificate (mavdisk.mnsu.edu).
The problem appears to be in source3/libads/ldap.c, ldap_open() is being supplied with the LDAP server's IP address, instead of hostname.
Reversing the following change fixes this issue:
(In reply to john.workman from comment #0)
thank you for reporting this.
Unfortunately my commit message for the watch was very short and does not point to the reason for the patch in detail.
I assume my intention was to fix 'net rpc join' on systems with a broken dns configuration. This path might not be necessary anymore and should be verified.
If it's working fine, we should reverse my patch and use it as the bug fix.
John, can you verify this? Otherwise I'll try this later.
Ubuntu Xenial test packages with that change reversed are currently building in this PPA if someone wants to test them:
I don't have an AD at hand right now to try it myself.
I have tried this fix.
But i am still getting the same issue.
(In reply to Björn Baumbach from comment #1)
I assumed this was the reason for the change I linked to (where the NetBIOS name cannot be resolved through DNS, so make LDAP just use the IP).
I confirm that reversing the patch fixed the TLS issue for me. I am running production winbind against Active Directory servers with full TLS crypto and certificate verification.
Reverting that commit worked past the certificate issue for me, but I hit something else that looks like a microsoft issue:
[LDAP] res_errno: 53, res_error: <00002029: LdapErr: DSID-0C0904CB, comment: Cannot bind using sign/seal on a connection on which TLS or SSL is in effect, data 0, v3839>, res_matched: <>
I was able to work around that by setting "client ldap sasl wrapping = plain" in smb.conf.