LDAPS Configureren

In onze post van vorige week “Securing LDAPSecuring LDAP” hebben we het voornamelijk gehad over LDAP Signing en Channel Binding. Ook hebben we heel even het topic LDAPS ofwel LDAP over Secure SSL aangeraakt. LDAPS is een prima oplossing voor de nodes die geen LDAP Signing of Channel Binding ondersteunen maar je wel al het LDAP verkeer veilig wilt houden. Denk bijvoorbeeld aan Linux-based nodes en legacy applications. LDAPS is een gedistribueerd IP-based directory-protocol welke lijkt op LDAP maar als aanvulling SSL bevat voor meer beveiliging. De standaardpoort voor een LDAPS serviceprovider URL is poort 636. In deze post gaan we LDAPS configureren zodat het binnen ons netwerk gebruikt kan worden.

LDAPS kan worden ingeschakeld door een certificaat met de juiste indeling te installeren van een Microsoft-certificeringsinstantie of een niet-Microsoft-certificeringsinstantie. Ook behoort het gebruik van een self-signed certificaat tot de mogelijkheden. LDAPS-mappen kunnen worden geconfigureerd om individuele referenties of informatie over groepslidmaatschappen te verstrekken voor het authentiseren of autoriseren van gebruikers.

Laten we eens gaan kijken aan welke eisen het certificaat moet voldoen.

• Het certificaat moet geïnstalleerd zijn in het persoonlijke (My) archief.
• Een persoonlijke sleutel die overeenkomt met het certificaat is aanwezig in het archief van de lokale computer en is op de juiste manier gekoppeld aan het certificaat. Voor de persoonlijke sleutel mag geen hoog beveiligingsniveau zijn ingeschakeld.
• De extensie Uitgebreid sleutelgebruik bevat de object-id (ook wel OID genoemd) voor serververificatie (1.3.6.1.5.5.7.3.1). Zie ook deze post: https://jarnobaselier.nl/ldap-lightweight-directory-access-protocolhttps://jarnobaselier.nl/ldap-lightweight-directory-access-protocol
• De FQDN-naam (volledige domeinnaam) van de domeincontroller (bijvoorbeeld, AD01.jarnobaselier.nl) moet voorkomen in de CN (common name) EN in de SAN DNS vermelding (Subject Alternate Name).
• Het certificaat is uitgegeven door een certificeringsinstantie welke door zowel de domeincontroller als de clients vertrouwd wordt.
• Voor het genereren van de sleutel moet CSP als cryptoprovider gebruikt worden.

In dit artikel maken we gebruik van een self-signed certificate. Maar mocht je een certificaat aan willen vragen bij een externe certificate provider dan kan dat uiteraard ook. De CSR die we dan aanmaken mag dan verstrekt worden aan de certificeringsinstantie. Let op, de CSR moet gegenereerd worden met een toepassing welke PKCS10 ondersteund zoals IIS of Certreq.exe.

Laten we dus eerst de self-signed CSR’s gaan maken. In ons voorbeeld hebben we 4 AD servers welke signing moeten doen. Dus maken we ook 4 verschillende certificaten aan. Mocht je gebruik maken van round-robin en dus 1 DNS record om LDAP(S) te gebruiken tegen alle 4 de AD servers en om hier dus ook een failover mogelijkheid te creëren dan kun je deze naam toevoegen aan de SAN DNS naam. HEEL belangrijk in deze is dat de SAN altijd als eerste voorzien moet zijn met de naam van de server en als 2e de round-robin DNS naam en eventuele andere namen. Zonder de CN naam van de server op de eerste plek zal de uiteindelijke verificatie falen. Dus:

• Certificaat 1 – CN = dc01.jarnobaselier.nl & SAN = dc01.jarnobaselier.nl & ldap.jarnobaselier.nl
• Certificaat 2 – CN = dc02.jarnobaselier.nl & SAN = dc02.jarnobaselier.nl & ldap.jarnobaselier.nl
• Certificaat 3 – CN = dc03.jarnobaselier.nl & SAN = dc03.jarnobaselier.nl & ldap.jarnobaselier.nl
• Certificaat 4 – CN = dc04.jarnobaselier.nl & SAN = dc04.jarnobaselier.nl & ldap.jarnobaselier.nl

Om Certreq.exe te gebruiken moet je eerst een INI file maken met de volgende content (pas aan waar nodig zoals het “Subject”).

[Version]
Signature="$Windows NT$"
 
[NewRequest]
Subject = "CN=dc01.jarnobaselier.nl"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
 
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication
 
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=dc01.jarnobaselier.nl&
_continue_ = "dns=ldap.jarnobaselier.nl&

We maken 4 van deze CSR INI files voor alle 4 de DC’s. Nu voeren we voor alle 4 van de INI files het volgende commando uit met CertReq.exe om er CSR bestanden van te maken.

certreq.exe -new c:\users\gebruikersnaam\Desktop\dc01-req.inf c:\users\gebruikersnaam\Desktop\dc01.csr

Nadat we de CSR bestanden gemaakt hebben kunnen we deze indienen bij de CA provider en in het geval van een Self-Signed certificaat kunnen we deze zelf ondertekenen middels OpenSSL of b.v. middels de MS CA server.

OpenSSL:

openssl x509 -req -days 1825 -in dc01.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out dc01.crt

Na het genereren moet dit certificaat nog geaccepteerd worden met certreq.exe:

certreq -accept dc01.crt

Microsoft CA:

Om het certificaat te maken met Microsoft CS moet je gebruik kunnen maken van de juiste certificate template. Het belangrijkste is dat het uiteindelijk certificaat een juiste geldigheidsduur heeft (1, 3 of 5 jaar) en dat het certificaat een zogenaamd “Server Authentication” optie bevat ofwel OID 1.3.6.1.5.5.7.3.1.

Je kunt hiervoor gebruik maken van diverse templates zoals de “kerberos Authentication” template. Ik maak altijd een kopie van deze templates en pas deze aan waar nodig zoals de naam en de geldigheidsduur. Hierbij een aantal screenshots van mijn aanpassingen op de Kerberos Authentication Template.

Wanneer de template compleet en gepubliceerd is completeer ik de CA aanvraag via de MS CA Webinterface:

Wanneer de CSR gegenereerd is op de domaincontroller dan staat de private key hier ook en ben je klaar. Als de CSR gegenereerd is op b.v. een dedicated CA dan moet de private key geëxporteerd worden. Dit doe je door het verkregen publieke (CER) deel te importeren en om nu een export te maken incl. private key.

Sla alle certificaten eventueel veilig op en verwijder de private key nu van de server waar deze gegenereerd is.

Nu alle certificaten gegenereerd zijn plaatsen we deze naar de juiste AD server. Hier importeren we de certificaten in de personal computer hive en markeren we bij voorkeur de private key als “niet exporteerbaar”:

Nadat het certificaat geïnstalleerd verifieer je of poort 636 (en 3269 bij global catalog servers) geopend is in de firewall en herstart de server. Doe dit voor alle AD servers.

De LDAPS configuratie is voltooid. Test of het functioneert met de “ldp.exe” tool van Microsoft en maak hiermee een secure verbinding naar je server.

Wil je alleen testen of poort 636 en/of 3269 open staan dan kun je een poortcheck met Powershell uitvoeren:

test-netconnection dc01.jarnobaselier.nl -port 636

Wil je testen of je nieuwe certificaat 100% functioneert maar zijn er al andere certificaten aanwezig die ook de server authenticatie kunnen doen dan is het een goede tip om de server authenticatie op deze certificatie tijdelijk uit te schakelen via de certificaat properties.

Deze post was wat korter dan je misschien gewend bent maar het is gewoon niet veel moeilijker dan dit. In een nuttshell moet je ervoor zorgdragen dat je LDAP servers over het juiste certificaat beschikken en dat alle clients de root-CA vertrouwen.

Heb je iets aan deze informatie en heb ik je een klein beetje op weg kunnen helpen? Dan zou ik het fantastisch vinden wanneer je deze post zou willen delen of liken! Delen kan uiteraard op je eigen social media kanaal of op je website. Dit helpt mij enorm en houdt mij gemotiveerd om nieuwe posts te blijven schrijven. ★ Alvast enorm bedankt! ★