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.
