To ensure the confidentiality of the user credentials you should make use of an encrypted LDAP connection between the webserver running WordPress and Next Active Directory Integration and your domain controllers.

There are two ways you can enable encryption

Encryption method Port Description
LDAPS 636, 3269 (Global Catalog) It is used on port 636 and 3269 (Global Catalog port) and encrypts the whole communication between both endpoints. Please note that Microsoft has announced that LDAPS is deprecated. The original deprecation date has been postponed to the 2nd half of 2020.
STARTTLS 389 An unencrypted LDAP connection on port 389 can be upgraded to an encrypted connection. The client issues issues a STARTTLS upgrade command. After that the communication between both endpoints is encrypted.

All of these ports (389, 636 and 3269) are by default opened on a Windows Server 2012 R2 installation. From a configuration point of view there is not so much difference between using LDAPS or STARTTLS. Only the encryption type and port differs.

Due the deprecation of LDAPS we urge you to use STARTTLS on port 389.

Requirements

since 2.1.12 NADI can be configured to accept self-signed certificates without having them installed on the host, running WordPress. This might be okay in some situations, put please get in contact with your CISO to talk about using self-signed certificates.

For using an encrypted connection the domain controller must issue a valid certificate during the connection handshake. On a bare Active Directory domain controller installation there are no certificates provided.

  • Install the role Active Directory Certifcate Services
  • Open the Certificates management console, go to Personal > Certificates, Right click and select All Tasks > Request New Certificates

Retrieve domain controller certificate

With OpenSSL installed you can easily show the certificate of the domain controller by executing

# for LDAPS
openssl s_client -debug -connect $DOMAIN_CONTROLLER:636 -showcerts

Newer versions of openssl >= 1.1.1, do also support STARTTLS. You can query the x.509 certificate for STARTTLS LDAP connections with

# for STARTTLS
openssl s_client -debug -connect $DOMAIN_CONTROLLER:389 -starttls ldap -showcerts

If the openssl s_client command fails with

CONNECTED(00000003)     
write to 0xa0276b0 [0xa031e48] (86 bytes => 86 (0x56))
# ...
write:errno=104

the domain controller does not issue a certificate. You will also see the error “No suitable default server credential exists on this system” inside the event log of the domain controller.

Please install a valid certificate (see Requirements above).

If the certificate is available s_client presents you an output like this:

CONNECTED(00000003)                                              
depth=0 /CN=WINDOWS-XXX.test.ad                              
verify error:num=20:unable to get local issuer certificate       
verify return:1                                                  
depth=0 /CN=WINDOWS-XXX.test.ad                              
verify error:num=27:certificate not trusted                      
verify return:1                                                  
depth=0 /CN=WINDOWS-XXX.test.ad                              
verify error:num=21:unable to verify the first certificate       
verify return:1                                                 
Certificate chain                                                
 0 s:/CN=WINDOWS-XXX.test.ad                                 
   i:/DC=ad/DC=test/CN=test-WINDOWS-XXX-CA                   
-----BEGIN CERTIFICATE-----                                      
MIIGBDCCBOygAwIBAgITEgAAAAKcOukOOzy9sAAAAAAAAjANBgkqhkiG9w0BAQUF 
# ....
+k7Ki2Nnm8w2IRr89niPSw0NAVBrejb8i7g6paNx/hrPFG9WWZU+qGagE6NI8DPv 
J3syVivrMK8=                                                     
-----END CERTIFICATE-----                                        
Server certificate                                               
subject=/CN=WINDOWS-XXX.test.ad                              
issuer=/DC=ad/DC=test/CN=test-WINDOWS-XXX-CA                 
No client certificate CA names sent                              
SSL handshake has read 1706 bytes and written 456 bytes          
New, TLSv1/SSLv3, Cipher is AES256-SHA                           

Copy all lines between BEGIN CERTIFICATE and END CERTIFICATE. On Windows put the content into the file c:/openldap/sysconf/dc.crt. On Linux you can save it into /etc/pki/ca-trust/source/anchors/dc.pem.

-----BEGIN CERTIFICATE-----                                      
MIIGBDCCBOygAwIBAgITEgAAAAKcOukOOzy9sAAAAAAAAjANBgkqhkiG9w0BAQUF 
# ....
+k7Ki2Nnm8w2IRr89niPSw0NAVBrejb8i7g6paNx/hrPFG9WWZU+qGagE6NI8DPv 
J3syVivrMK8=                                                     
-----END CERTIFICATE-----  

Make sure that there is no whitespace at the end of any line!

Configure ldap.conf

On a Windows webserver create the file ldap.conf inside the directory c:/openldap/sysconf. The file location is important.

Put the following lines into ldap.conf

TLS_REQCERT never
TLS_CACERT c:\openldap\sysconf\dc.crt

On a Linux webserver create the file ldaprc and your dc.crt inside the directories ../wordpress/ and ../wordpress/wp-admin/. The file location is important.

Put the following lines into ldaprc

TLS_REQCERT never
TLS_CACERT dc.crt

The configuration option TLS_REQCERT forces OpenLDAP to not request the server certificate. This is required for all self-signed certificates.

On Linux webservers multiple locations and variables are checked for configuration values. Please take a look at this site in order to get a better understanding on the configuration read and overwrite order.

If you are trying to setup LDAPS on a Linux webserver hosted by an external webhoster please take a look at our FAQ when running

LDAPS and client certificates

Active Directory does not require a client certificate:

Enabling LDAPS on the client is not necessary to protect credentials passed from the client to the server when LDAPS is already enabled on the server. 
This just allows the client to actually authenticate itself to the server - an extra layer of protection to ensure that the client connecting as COMPUTER_X is actually COMPUTER_X and not some other computer trying to authenticate with COMPUTER_X credentials. 
The client must be using a certificate from a CA that the LDAP server trusts. 

In your ldap.conf you can put the following lines to use your client certificate and private key:

TLS_CERT c:\openldap\client.crt
TLS_KEY c:\openldap\client.key

Configure Next Active Directory Integration

  • Go to Active Directory Integration > Environment
  • For LDAPS select “LDAPS” from Encryption and enter the Port 636.
  • For STARTTLS select “STARTTLS” from Encryption and enter Port 389.
  • Save settings

Test authentication

Go to Active Directory Integration > Test authentication and enter valid credentials. If everything is fine the authentication should succeed. There are two possible errors showing up which should only occur if there has been a prior configuration issue.

Warning: ldap_start_tls() [function.ldap-start-tls]: Unable to start TLS: Server is unavailable

You are presented with this error if your domain controllers does not issue a certificate. See the Requirements above how to set up a basic installation.

Warning: ldap_start_tls(): Unable to start TLS: Connect error

This error is shown if the domain controllers issues a certificate but the client (Next Active Directory Integration) does not know how to handle it. See the Configure ldap.conf section above.