Stuajnht Posted May 2, 2019 Posted May 2, 2019 Hi all, We're currently having a few issues with an Ubuntu 18.04 server being unable to connect / bind over LDAP to our Windows domain controllers. This issue doesn't seem to be apparent on an Ubuntu 16.04 server. The issue has been narrowed down to the new server not liking the certificate that is presented by the DC, but even when setting "TLS_REQCERT never" in /etc/ldap/ldap.conf it is unable to connect. Minimal reproduction steps: # Create 2 servers / VMs - one with Ubuntu 16.04 installed and the other with Ubuntu 18.04 installed # Install LDAP tools sudo apt-get install ldap-utils # Attempt to connect to the server (extra debugging turned on) ldapsearch -H ldap://DC.domain:389 -x -W -D "\teststudent" -b "OU=location,OU=to,DC=user,DC=object" "(sAMAccountName=teststudent)" -d 1 -ZZ The ldapsearch command should fail for both servers. # Ubuntu 16.04 ldap_url_parse_ext(ldap://DC.domain:389) ldap_create ldap_url_parse_ext(ldap://DC.domain:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP DC.domain:389 ldap_new_socket: 4 ldap_prepare_socket: 4 ldap_connect_to_host: Trying 172.16.100.21:389 ldap_pvt_connect: fd: 4 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 4 ldap_result ld 0x564199da17e0 msgid 1 wait4msg ld 0x564199da17e0 msgid 1 (infinite timeout) wait4msg continue ld 0x564199da17e0 msgid 1 all 1 ** ld 0x564199da17e0 Connections: * host: DC.domain port: 389 (default) refcnt: 2 status: Connected last used: Thu May 2 14:52:18 2019 ** ld 0x564199da17e0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x564199da17e0 request count 1 (abandoned 0) ** ld 0x564199da17e0 Response Queue: Empty ld 0x564199da17e0 response count 0 ldap_chkResponseList ld 0x564199da17e0 msgid 1 all 1 ldap_chkResponseList returns ld 0x564199da17e0 NULL ldap_int_select read1msg: ld 0x564199da17e0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 40 contents: read1msg: ld 0x564199da17e0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x564199da17e0 0 new referrals read1msg: mark request completed, ld 0x564199da17e0 msgid 1 request done: ld 0x564199da17e0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (a) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: peer cert untrusted or revoked (0x42) TLS: can't connect: (unknown error code). ldap_err2string ldap_start_tls: Connect error (-11) additional info: (unknown error code) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 4 ldap_free_connection: actually freed # Ubuntu 18.04 ldap_url_parse_ext(ldap://DC.domain:389) ldap_create ldap_url_parse_ext(ldap://DC.domain:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP DC.domain:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.16.100.21:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x56382dd92270 msgid 1 wait4msg ld 0x56382dd92270 msgid 1 (infinite timeout) wait4msg continue ld 0x56382dd92270 msgid 1 all 1 ** ld 0x56382dd92270 Connections: * host: DC.domain port: 389 (default) refcnt: 2 status: Connected last used: Thu May 2 13:55:05 2019 ** ld 0x56382dd92270 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x56382dd92270 request count 1 (abandoned 0) ** ld 0x56382dd92270 Response Queue: Empty ld 0x56382dd92270 response count 0 ldap_chkResponseList ld 0x56382dd92270 msgid 1 all 1 ldap_chkResponseList returns ld 0x56382dd92270 NULL ldap_int_select read1msg: ld 0x56382dd92270 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 40 contents: read1msg: ld 0x56382dd92270 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x56382dd92270 0 new referrals read1msg: mark request completed, ld 0x56382dd92270 msgid 1 request done: ld 0x56382dd92270 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (a) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: can't connect: Key usage violation in certificate has been detected.. ldap_err2string ldap_start_tls: Connect error (-11) additional info: Key usage violation in certificate has been detected. ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_free_connection: actually freed Edit the LDAP client config file on each Ubuntu server to accept any certificates presented to it: echo "TLS_REQCERT never" | sudo tee -a /etc/ldap/ldap.conf Run the ldapsearch command again. For us, it succeeds on the Ubuntu 16.04 server but fails on the Ubuntu 18.04 server. # Ubuntu 16.04 ldap_url_parse_ext(ldap://DC.domain:389) ldap_create ldap_url_parse_ext(ldap://DC.domain:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP DC.domain:389 ldap_new_socket: 4 ldap_prepare_socket: 4 ldap_connect_to_host: Trying 172.16.100.21:389 ldap_pvt_connect: fd: 4 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 4 ldap_result ld 0x5589849897e0 msgid 1 wait4msg ld 0x5589849897e0 msgid 1 (infinite timeout) wait4msg continue ld 0x5589849897e0 msgid 1 all 1 ** ld 0x5589849897e0 Connections: * host: DC.domain port: 389 (default) refcnt: 2 status: Connected last used: Thu May 2 14:52:57 2019 ** ld 0x5589849897e0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x5589849897e0 request count 1 (abandoned 0) ** ld 0x5589849897e0 Response Queue: Empty ld 0x5589849897e0 response count 0 ldap_chkResponseList ld 0x5589849897e0 msgid 1 all 1 ldap_chkResponseList returns ld 0x5589849897e0 NULL ldap_int_select read1msg: ld 0x5589849897e0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 40 contents: read1msg: ld 0x5589849897e0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x5589849897e0 0 new referrals read1msg: mark request completed, ld 0x5589849897e0 msgid 1 request done: ld 0x5589849897e0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (a) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_msgfree Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 36 bytes to sd 4 ldap_result ld 0x5589849897e0 msgid 2 wait4msg ld 0x5589849897e0 msgid 2 (infinite timeout) wait4msg continue ld 0x5589849897e0 msgid 2 all 1 ** ld 0x5589849897e0 Connections: * host: DC.domain port: 389 (default) refcnt: 2 status: Connected last used: Thu May 2 14:53:00 2019 ** ld 0x5589849897e0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x5589849897e0 request count 1 (abandoned 0) ** ld 0x5589849897e0 Response Queue: Empty ld 0x5589849897e0 response count 0 ldap_chkResponseList ld 0x5589849897e0 msgid 2 all 1 ldap_chkResponseList returns ld 0x5589849897e0 NULL ldap_int_select read1msg: ld 0x5589849897e0 msgid 2 all 1 ber_get_next ber_get_next: tag 0x30 len 16 contents: read1msg: ld 0x5589849897e0 msgid 2 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x5589849897e0 0 new referrals read1msg: mark request completed, ld 0x5589849897e0 msgid 2 request done: ld 0x5589849897e0 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_search_ext put_filter: "(sAMAccountName=teststudent)" put_filter: simple put_simple_filter: "sAMAccountName=teststudent" ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 99 bytes to sd 4 ldap_result ld 0x5589849897e0 msgid -1 wait4msg ld 0x5589849897e0 msgid -1 (infinite timeout) wait4msg continue ld 0x5589849897e0 msgid -1 all 0 ** ld 0x5589849897e0 Connections: * host: DC.domain port: 389 (default) refcnt: 2 status: Connected last used: Thu May 2 14:53:00 2019 ** ld 0x5589849897e0 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x5589849897e0 request count 1 (abandoned 0) ** ld 0x5589849897e0 Response Queue: Empty ld 0x5589849897e0 response count 0 ldap_chkResponseList ld 0x5589849897e0 msgid -1 all 0 ldap_chkResponseList returns ld 0x5589849897e0 NULL ldap_int_select read1msg: ld 0x5589849897e0 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 5110 contents: read1msg: ld 0x5589849897e0 msgid 3 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ldap_dn2ufn ldap_dn_normalize ber_scanf fmt ({xx) ber: ldap_get_attribute_ber // // snip... // # extended LDIF # # LDAPv3 # base with scope subtree # filter: (sAMAccountName=teststudent) # requesting: ALL # # Test Student, Test, Students, Curriculum, DC.domain dn: CN=Test Student,OU=Test,OU=Students,OU=Curriculum,DC=****,DC=***** objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: Test Student sn: Student givenName: Test // // snip... // ldap_result ld 0x5589849897e0 msgid -1 wait4msg ld 0x5589849897e0 msgid -1 (infinite timeout) wait4msg continue ld 0x5589849897e0 msgid -1 all 0 ** ld 0x5589849897e0 Connections: * host: DC.domain port: 389 (default) refcnt: 2 status: Connected last used: Thu May 2 14:53:00 2019 ** ld 0x5589849897e0 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x5589849897e0 request count 1 (abandoned 0) ** ld 0x5589849897e0 Response Queue: Empty ld 0x5589849897e0 response count 0 ldap_chkResponseList ld 0x5589849897e0 msgid -1 all 0 ldap_chkResponseList returns ld 0x5589849897e0 NULL read1msg: ld 0x5589849897e0 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 16 contents: read1msg: ld 0x5589849897e0 msgid 3 message type search-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x5589849897e0 0 new referrals read1msg: mark request completed, ld 0x5589849897e0 msgid 3 request done: ld 0x5589849897e0 msgid 3 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 3, msgid 3) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_err2string ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 4 ldap_free_connection: actually freed # search result search: 3 result: 0 Success # numResponses: 2 # numEntries: 1 # Ubuntu 18.04 ldap_url_parse_ext(ldap://DC.domain:389) ldap_create ldap_url_parse_ext(ldap://DC.domain:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP DC.domain:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.16.100.21:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x56422b678270 msgid 1 wait4msg ld 0x56422b678270 msgid 1 (infinite timeout) wait4msg continue ld 0x56422b678270 msgid 1 all 1 ** ld 0x56422b678270 Connections: * host: DC.domain port: 389 (default) refcnt: 2 status: Connected last used: Thu May 2 13:55:26 2019 ** ld 0x56422b678270 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x56422b678270 request count 1 (abandoned 0) ** ld 0x56422b678270 Response Queue: Empty ld 0x56422b678270 response count 0 ldap_chkResponseList ld 0x56422b678270 msgid 1 all 1 ldap_chkResponseList returns ld 0x56422b678270 NULL ldap_int_select read1msg: ld 0x56422b678270 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 40 contents: read1msg: ld 0x56422b678270 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x56422b678270 0 new referrals read1msg: mark request completed, ld 0x56422b678270 msgid 1 request done: ld 0x56422b678270 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (a) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: can't connect: Key usage violation in certificate has been detected.. ldap_err2string ldap_start_tls: Connect error (-11) additional info: Key usage violation in certificate has been detected. ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_free_connection: actually freed I have searched under various different terms, but all of them pretty much suggest changing the ldap.conf file and it should work. I'm beginning to think that there's something else weird happening on our domain, but have run out of ideas for other things to check or change. If anyone can suggest any ideas I'm happy to give them a go. Thanks in advance.
pete Posted May 2, 2019 Posted May 2, 2019 Post a redacted ldap.conf for each? Does the Ubuntu 16.04 already have your inhouse CA as a trusted provider of certificates?
Stuajnht Posted May 2, 2019 Author Posted May 2, 2019 Hi @pete, The ldap.conf files on each server are pretty much the file that is installed with ldap-utils, with the manual addition of TLS_REQCERT at the end of them (given below). I'm not aware of any inhouse CA being added to the Ubuntu 16.04 server. I've also tested with freshly installed VMs. Ubuntu 16.04 works with TLS_REQCERT set to never, whereas 18.04 doesn't. # Ubuntu 16.04 - /etc/ldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ssl/certs/ca-certificates.crt TLS_REQCERT never # Ubuntu 18.04 - /etc/ldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ssl/certs/ca-certificates.crt TLS_REQCERT never
Stuajnht Posted May 9, 2019 Author Posted May 9, 2019 (edited) Hi all, I've been doing quite a bit more digging, and now think it's down to our DC having to multiple certificates installed that provide server authentication. According to a Microsoft Technet article (emphasis mine): When a certificate is selected from the local machine store (as in CertEnumCertificatesInStore) the first valid certificate that can be used for Server Authentication (OID: 1.3.6.1.5.5.7.3.1) is returned for use. In cases where customers have multiple certificates valid for Server Authentication in the LDAP server's (e.g. AD DS domain controller, AD LDS, or ADAM server) local computer certificate store, may see that a different certificate than the one they want is used for LDAPS communications. The best resolution to such an issue is to remove all unnecessary certificates from the local computer certificate store and have only one certificate that is valid for server authentication. The first certificate that seems to be listed in the certificates MMC snap-in is a self-signed one for Veeam, followed by the one issued by our internal CA (see attachment). Only the domain controller that has both of these certificates installed has issues, while our other DC is able to run the LDAP search command on Ubuntu 18.04 without issues. From what I can see, there's a few different options: Ignore the issue and use the other DC for LDAP searches (not ideal, just putting it here as a temporary fix) Exporting the LDAPS Certificate and Importing for use with AD DS (we will need to remember to import the certificate when it renews) Create a new certificate that can be used for Veeam and AD (would we need to create a new certificate template based on the Domain Controller one, and add the additional key usage options?) Export the Veeam self-signed certificate, delete it, then import it again so that it's not the first certificate selected (would this even work?) I'm obviously a bit hesitant to make any changes to the certificates due to not wanting to break AD or backups. Does anyone has any advice / guides on the best way forward, or am I going in the wrong direction? Edited May 9, 2019 by Stuajnht Used quote tags for Technet snippet
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now