Good morning to you,

I have a question regarding the user of LDAP_* calls while programming in C. I am on an Oracle/Sun Solaris machine running Solaris 11.3. I am writing my code via Oracle Solaris Studio version 12.4. I do have OpenLdap v2.4.30 installed on my machine. ( /user/lib/slapd -VV returns: @(#) $OpenLDAP: slapd 2.4.30 (Feb 9 2017 12:37:50) $ @ul11sru-build:/builds/ul11u3sru-gate/components/openldap/build/sparcv7/servers/slapd)

NOTE: the services are NOT up and running. I have no ldap server running on this machine. I am simply writing code using the LDAP_* service calls.

In previous releases, there were some calls available to the effect of LDAP_START_TLS or LDAP_START_SSL and some others. All of those calls are now gone and as far as I can tell, not available in any form.

With that said, my current code runs correctly and executes if I use port 389 to talk to an Active Directory Server. There is no problem, and I get back a valid response from my code, and I have gone through a pretty substantial set of testing to verify that the code is indeed accurate and valid. I even raided a site that had a sample code set for a bind and copied/modified that and tested it as well. My code and my raided code work correctly.

If, however, I change the default port to be port 636, the code fails when I attempt to bind via LDAP_SIMPLE_BIND_S. The specific error code returned to me is an Error Code 91 and the LDAP_ERR2STRING result is: "Can't connect to the LDAP server". The Error Code implies that the system is down - OR - it is not available. If I change the default port back to 389, the code works. My conclusion is that I am having difficulty with the remote Active Directory Server "trusting" my server.

I have OpenSSL on my machine, and I have the Private Certificate from the remote Active Directory Server installed along with the appropriate CA certificates and L1R chain. If I issue an "openssl s_client -showcerts -connect tbdca.gvl.gtech.pri:636" I do get a valid connection and get the following output result:

CONNECTED(00000004) depth=2 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-termshttp://www.entrust.net/legal-terms, OU = "(c) 2012 Entrust, Inc. - for authorized use only", CN = Entrust Root Certification Authority - G3 verify return:1 depth=1 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-termshttp://www.entrust.net/legal-terms, OU = "(c) 2014 Entrust, Inc. - for authorized use only", CN = Entrust Certification Authority - L1R verify return:1 depth=0 C = US, ST = South Carolina, L = Greenville, O = Greenville Technical College, CN = gtech.pri verify return:1

The certificate named gtech.pri is the Certificate loaded on the Active Directory Domain Controllers. It is a Private SSL certificate with Subject Alternative Names. I forget precisely where I read this and I've tried to locate the document again - but perhaps one of you may know. It seems that the document was indicating that in order to connect to the Active Directory server, the CN and DN of the certificates had to exactly match. (I can't find the document now, so I can't recall the wording. If that is the case, it makes a private certificate rather worthless and makes a SAN certificate worthless from the outset - but OpenSSL does in fact verify the connection)

Since there are no longer any LDAP_START_* for security, I have a dilemma of sorts. I have noticed in the ldap.conf man pages that it is possible to create a .ldaprc file in a user's local directory. Given that I could do that, will it work? Will that give me the access capability that I'm seeking? (again, I am NOT running an LDAP server on this machine. I'm simply coding a program in C that will make a connection to an Active Directory Server and it must be a secure connection) There are several parameters inside of the ldap.conf file that can point back to the certificate base and the certificate directory. There has to be some sort of mechanism to do this since the LDAP_START_TLS commands and so forth have been removed.

Many thanks for your input and thanks for your patience in reading this!

All the best, Howard

This electronic mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. To the best of our ability and knowledge, this mail message has been scanned and is free of viruses and malware.