[Win Srv 2019] Active Directory LDAP certificaat, non .local

[Urk]

Ik ben heel erg benieuwd naar het volgende: Ik heb bij een klant vanuit de historie helaas nog een .local AD.
In AD DNS heb ik een zone opgezet, namelijk ad.publiekdomein.nl.
Voor dat domein heb ik een wilcard certificaat die alles van *.ad.publiekdomein.nl kan beveiligen.
Ik heb dus bijv een A-record aangemaakt welke point van adserver.ad.publiekdomein.nl naar het interne IP van deze AD server.

Nu heb ik bijv een Sonicwall Firewall welke met LDAP/AD praat. Deze connectie loopt via TLS.
De voorkeur heeft het om te verbinden naar adserver.ad.publiekdomein.nl via TLS, op de server is voor die hostnaam een certificaat beschikbaar van Sectigo.

Het enige wat nu werkt is vanuit de Sonicwall te connecten naar adserver.bedrijf.local en dan in de Certificate store van de Sonicwall de CA cert van het lokale domein toe te voegen (aangezien we gelukkig ook nog een lokale AD CA draaien).
Is het mogelijk te connecten naar adserver.ad.publiekdomein.nl wat natuurlijk niet de officiele hostname van die servers is (dat is adserver.bedrijf.local) en dan AD/LDAP het TLS verkeer te laten verlopen via het Sectigo certificaat voor *.ad.publiekdomein.nl?

Volgens het volgende artikel bepaald AD zelf werk certificaat hij aanbiedt aan de client voor communicatie.
https://docs.microsoft.co...d-certification-authority

[Hero of Time]

Uit datzelfde artikel staat ook dit:

• 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.

Als je bij een SSL uitgever een certificaat aanvraagt, is dat standaard een webserver certificaat. Je moet apart de extra extensions opgeven. Heb je dat gedaan? Zo niet, dan is het certificaat niet geschikt voor Server Authentication en zal het nooit gekozen worden voor LDAPS.

Dan is het tweede punt wat ik quote, de domein namen. Je hebt een wildcard voor ad.domein.nl. Je AD zelf is domein.local. Als je bij de CSR geen alternative subject name voor domein.local hebt opgegeven (als dat überhaupt mogelijk is, ik denk eigenlijk van niet), gaat je certificaat niet werken. Het mist de domein.local identificatie en wordt daarom als niet-vertrouwd gezien als je het toch zou opgeven, want de hostnaam komt niet overeen met wat het certificaat bevat.

[Urk]

Hero of Time schreef op woensdag 14 oktober 2020 @ 21:32:
Uit datzelfde artikel staat ook dit:

[...]

Als je bij een SSL uitgever een certificaat aanvraagt, is dat standaard een webserver certificaat. Je moet apart de extra extensions opgeven. Heb je dat gedaan? Zo niet, dan is het certificaat niet geschikt voor Server Authentication en zal het nooit gekozen worden voor LDAPS.

Dan is het tweede punt wat ik quote, de domein namen. Je hebt een wildcard voor ad.domein.nl. Je AD zelf is domein.local. Als je bij de CSR geen alternative subject name voor domein.local hebt opgegeven (als dat überhaupt mogelijk is, ik denk eigenlijk van niet), gaat je certificaat niet werken. Het mist de domein.local identificatie en wordt daarom als niet-vertrouwd gezien als je het toch zou opgeven, want de hostnaam komt niet overeen met wat het certificaat bevat.

Dank voor je antwoorden

Wat betreft het eerste punt:
Onder Enhanced Key Usage van het Sectigo certificaat staat:
Server Authentication (1.3.6.1.5.5.7.3.1)
Client Authentication (1.3.6.1.5.5.7.3.2)
Dus dat moet kloppen en voldoen dan volgens mij, toch?

Wat betreft je tweede punt:
Dat is het hem juist, ik connect niet naar de .local hostname. Ik laat de Sonicwall connecten naar adserver.ad.publiekdomein.nl. Die resvoled intern gewoon netjes naar het IP van de AD server. RDP bijv doe ik dat ook en gaat prima en laat dan het juiste certificaat zien omdat ik die aan RDP gekoppeld heb.
En, nee, dat klopt inderdaad. Een .local domein is niet meer te krijgen in een certificaat van een publieke Certification Authority.

[Hero of Time]

En daarom ga je niet je wildcard certificaat krijgen. Ik snap niet helemaal waarom je deze vragen stelt, aangezien alle informatie (en je antwoorden) gewoon in het document staan dat je hebt gelinkt. Inclusief wat het zou doen mocht er wél een geldig certificaat zijn:

Multiple SSL certificates
Schannel, the Microsoft SSL provider, selects the first valid certificate that it finds in the local computer store. If there are multiple valid certificates available in the local computer store, Schannel may not select the correct certificate.

Het pakt de eerste, geldige en beschikbaar certificaat. Daarmee heb je nog steeds geen garantie dat het certificaat dat jij wilt dat er gebruikt wordt, ook echt wordt gebruikt. Maar je certificaat is niet geldig voor je domein, dus het zal nooit gebruikt worden.

Je zegt tevens dat je een interne CA hebt. Wat weerhoud je ervan om het publieke certificaat daarvan in de Sonicwall te importeren zodat het daarmee je AD certificaat kan valideren? Als dat werkt, waarom dan met een (gekocht) wildcard certificaat aan de gang? Vanuit een security oogpunt is dat eigenlijk minder veilig omdat deze op meer plekken gebruikt wordt en dus ook meer plekken zijn waar de private key kan lekken en je alsnog het versleutelde verkeer naar je AD kan onderscheppen.

Er zijn trouwens meerdere methoden om te controleren welk certificaat er aangeboden wordt. O.a. door gebruik te maken van het openssl commando vanaf een Linux machine.

[ElCondor]

Verdere verduidelijking, het gaat hier mis:

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.

In jouw certificaat staat *.ad.publiekdomein.nl. Dat komt NIET overeen met adserver.ad.publiekdomein.nl (Dit moet namelijk EXACT overeenkomen en wordt niet gecoverd door een wildcard). Ook heeft de server intern nog steeds de FQDN (waarschijnlijk) adserver.interndomein.local en heeft daar een certificaat voor. Deze mag wél gebruikt worden volgens bovenstaande regel, dus dat zal gebeuren en vandaar dat jouw SonicWall een verbinding op adserver.ad.publiekdomein.nl weigert, maar een verbinding op adserver.interndomein.local accepteert.