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-terms<http://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-terms<http://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.