4

We are using OpenLDAP server as a proxy to AD by adding AD as subordinate to OpenLDAP.

I've secured OpenLDAP traffic by using StartTLS connection, Now I've been told to use LDAPS protocol for the bind which we do to connect to AD Server(We are using simple bind).

So my question was, Is it necessary to use LDAPS for communication with AD as OpenLDAP is already using StartTLS?

I don't have much knowledge about OpenLDAP and AD so just wanted the suggestions.

I've used below configuration for adding backend ldap[Lightweight Directory Access Protocol (Proxy) backend] database.

dn: olcDatabase=ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: ldap
olcSuffix: ou=xyz,dc=xyz,dc=xyz
olcSubordinate: TRUE
olcAccess: to dn.subtree="ou=xyz,dc=xyz,dc=xyz"  by * read
olcAddContentAcl: FALSE
olcLastMod: FALSE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
olcDbURI: "ldap://xx.xx.xx.xx"
olcDbStartTLS: none starttls=no
olcDbACLBind: bindmethod=simple timeout=0 network-timeout=0 binddn="cn=xyz,ou=xyz,dc=xyz,dc=xyz" credentials="xxxxxxxxxxxxxxxxxxxxxx"
olcDbIDAssertBind: mode=legacy flags=prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="cn=xyz,ou=xyz,dc=xyz,dc=xyz" credentials="xxxxxxxxxxxxxxxxxxxxxx"
olcDbRebindAsUser: TRUE
olcDbChaseReferrals: TRUE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
  • And with addition to what Rayan Ries said: do the traffic dump and do not guess. – Michal Sokolowski Dec 6 '17 at 17:07
3

LDAP simple binds that are not protected by SSL/TLS are very insecure, as it involves sending username and password credentials in clear-text over the network.

LDAP simple binds are acceptable only over SSL/TLS/LDAPS.

All you have to do to enable LDAPS on an Active Directory domain controller is install a suitable certificate with private key on the AD domain controller:

https://support.microsoft.com/en-us/help/321051/how-to-enable-ldap-over-ssl-with-a-third-party-certification-authority

Be sure and read the requirements section of the article above to see what constitutes an acceptable certificate.

Once you've installed an acceptable certificate on the domain controller, Active Directory will automatically sense its presence and enable LDAPS over port 636.

You may source the certificate from any Certification Authority you wish, as long as it is trusted by all parties who will participate in the communication. It can be an existing AD-integrated PKI, or it can be a non-Microsoft CA on your corporate network, or it may even be a public, globally-trusted CA like Godaddy, Symantec, etc., as long as it is capable of producing a certificate that meets the requirements:

  • The LDAPS certificate is located in the Local Computer's Personal certificate store (programmatically known as the computer's MY certificate store).
  • A private key that matches the certificate is present in the Local Computer's store and is correctly associated with the certificate. The private key must not have strong private key protection enabled.
  • The Enhanced Key Usage extension includes the Server Authentication (1.3.6.1.5.5.7.3.1) object identifier (also known as OID).
  • The Active Directory fully qualified domain name of the domain controller (for example, DC01.DOMAIN.COM) must appear in one of the following places:
    • The Common Name (CN) in the Subject field.
    • DNS entry in the Subject Alternative Name extension.
  • The certificate was issued by a CA that the domain controller and the LDAPS clients trust. Trust is established by configuring the clients and the server to trust the root CA to which the issuing CA chains.
  • You must use the Schannel cryptographic service provider (CSP) to generate the key.

(Technically, it may even be a self-signed certificate, though this isn't a secure solution.)

Once you install this certificate, the domain controller will automatically enable LDAPS service on port 636. (And global catalog service on 3269.)

So far I have only described LDAPS but not specifically StartTLS.

You may use startTLS against a Microsoft LDAP server if you wish:

https://msdn.microsoft.com/en-us/library/aa366997(v=vs.85).aspx

It doesn't require any additional configuration on the server. It just involves the client sending the correct LDAP controls (commands) to the server. (The control OID for startTLS is "1.3.6.1.4.1.1466.20037".)

  • Thanks Ryan!! I will try it.. Can you please confirm if it is a good idea to add AD database as a subordinate to OpenLDAP database for querying AD through OpenLDAP? – Vishal Dec 6 '17 at 17:18
  • @Vishal I can't answer that as I don't understand your business needs or requirements. It's not an implementation I would be likely to recommend though, as Active Directory was not designed with this scenario in mind. But if you can make it work, then more power to you. – Ryan Ries Dec 6 '17 at 17:22
0

There are two network segment you have to secure:

  • from clients to OpenLDAP;
  • from OpenLDAP to AD.

They both have to be secure.

The first part has already been done with StartTLS.

You only need to put security on the second network hop. I think it would be enougth to modify:

olcDbURI: "ldap://xx.xx.xx.xx"
olcDbStartTLS: none starttls=no

to:

olcDbURI: "ldaps://xx.xx.xx.xx"
olcDbStartTLS: false

(because of course it's not possible to have both StartTLS and LDAPS)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.