AD CS-sjablonen ontwerpen voor VPN-gateway- en clientrollen

Een bedrijfs-CA kan elk certificaat uitgeven dat een VPN nodig heeft zonder ooit zelf de gateway te zijn. Het ontwerpwerk is beslissen wat elke kant moet aantonen, en daarna welk sjabloon een referentie kan uitgeven die precies dat aantoont. Ik begin met een roltabel, dupliceer een geschikt sjabloon in plaats van er een ter plaatse te bewerken, leg de bron van het onderwerp per rol vast, publiceer het resultaat op de uitgevende CA en schrijf één pilot in voordat iemand het automatiseert. Elke stap hieronder is een plek waar een werkende CA nog steeds een certificaat maakt dat de VPN weigert.

Schrijf de roltabel voordat u de sjabloonconsole opent

Twee rollen, twee doelen. De gateway bewijst een service-identiteit, dus het certificaat heeft Server Authentication (1.3.6.1.5.5.7.3.1) nodig, een sleutelgebruik van digitale handtekening en sleutelversleuteling, en de hostnaam die clients kiezen in een alternatieve onderwerpnaam. Clients die met certificaten authenticeren hebben Client Authentication (1.3.6.1.5.5.7.3.2) nodig en een identiteit die overeenkomt met wat de gateway in zijn tegenpartijcontrole verwacht. Een gebruikerscertificaat en een computercertificaat zijn niet uitwisselbaar, omdat ze in verschillende opslaglocaties staan en door verschillende processen worden gebruikt.

Schrijf vier kolommen per rol: de identiteit die moet verschijnen, het doel, de sleutelgebruiker en of de sleutel de machine mag verlaten. Die tabel bepaalt later elk selectievakje, en het is ook wat u een beoordelaar geeft. Op wachtwoord gebaseerde clientauthenticatie is een aparte tak: als de gateway gebruikers met referenties authenticeert, voegt het verspreiden van clientcertificaten werk toe zonder bewijs toe te voegen.

Dupliceer een sjabloon in plaats van een gedeeld sjabloon te bewerken

Begin met een sjabloon met ongeveer het juiste doel, zoals RAS and IAS Server voor de gateway of Computer voor domeingekoppelde apparaten, dupliceer het en geef de kopie een naam die zegt waarvoor die is. Een sjabloon uitbreiden dat andere services al gebruiken is de wijziging die zes weken later iets ongerelateerds breekt. Stel op de kopie de toepassingsbeleidsregels in op het doel uit de roltabel, houd het sleutelgebruik daarmee consistent, kies het sleutelalgoritme en de lengte die uw gateways accepteren, en markeer de persoonlijke sleutel als niet-exporteerbaar tenzij een apparaat hem moet exporteren om hem te verplaatsen.

Geldigheid en vernieuwing horen ook bij het sjabloon. Een korte levensduur is makkelijker in te trekken en moeilijker te beheren; een lange vermindert het inschrijfwerk en verlengt de blootstelling van een gelekte sleutel. Kies een getal dat u kunt verdedigen, en let op: de geldigheid van de CA zelf en de vernieuwingsperiode van het sjabloon kunnen het resultaat verkorten.

Bepaal waar het onderwerp vandaan komt

Voor een domeincomputer of -gebruiker bouwt u het onderwerp uit adresboekgegevens, zodat de naam niet door de aanvrager kan worden getypt. Voor een gateway die niet domeingekoppeld is, of een apparaat waarvan de identiteit buiten AD wordt toegekend, heeft het sjabloon in plaats daarvan een gecontroleerd aanvraagpad nodig. Door de aanvrager geleverd onderwerp en alternatieve namen inschakelen is een echte beslissing: het is geen licentie voor elke ingeschrevene om om het even welke naam te claimen, en het beleid aan de CA-kant moet nog steeds zeggen wie mag vragen en welk bewijs nodig is.

Windows IKEv2 is hier streng. Een gatewaycertificaat wordt vergeleken met de naam die de client heeft geconfigureerd, dus de DNS-naam moet aanwezig zijn waar de client hem zoekt, meestal een dNSName-vermelding in de alternatieve onderwerpnaam. Naamcontrole of doelcontrole uitschakelen om een niet-overeenkomend certificaat te laten werken, verwijdert de controle die de afwijking in productie had opgevangen.

Publiceer het sjabloon en beperk daarna de machtigingen

Het sjabloonobject in AD DS maken en het op de uitgevende CA publiceren zijn afzonderlijke bewerkingen, uitgevoerd in verschillende consoles. Publiceer de kopie vanuit de Certification Authority-console onder Certificate Templates en controleer daarna vanaf de opdrachtregel dat de CA het nu aanbiedt:

certutil -CATemplates
certutil -TCAInfo

Daarna komen de machtigingen. Geef Read en Enroll aan de groepen die erom moeten vragen en niets meer, houd de eigen leestoegang van de CA intact, en geef Autoenroll alleen waar automatische inschrijving bedoeld is en wordt ondersteund door het implementatiebeleid dat het laat werken. Een selectievakje in een sjabloon schrijft zelf niets in, en een gepubliceerd sjabloon zonder inschrijfmachtiging levert een portaal op dat het certificaat vermeldt en daarna de aanvraag weigert.

Schrijf één pilot in bij de echte verbruiker

Vraag het certificaat aan in de context die het gaat gebruiken en bekijk daarna wat er terugkwam in plaats van de bestandsnaam te vertrouwen. Een gebruikerscertificaat belandt in de opslag van de huidige gebruiker en een computercertificaat in de opslag van de lokale computer, en MMC toont beide, waardoor een inschrijving die “werkte” toch onzichtbaar kan blijven voor de VPN-service.

certlm.msc
certutil -dump vpn-gateway.cer

Lees de dump voor het onderwerp, de alternatieve namen, het uitgebreide sleutelgebruik en de keten. Voor een gateway die geen Windows is, dient u de aanvraag in via de ondersteunde werkstroom in plaats van aan te nemen dat automatische domeininschrijving die bereikt, en bevestig dat het geëxporteerde formaat er een is dat de verbruiker importeert samen met de bijbehorende persoonlijke sleutel. Ten slotte houdt u vertrouwen en autorisatie gescheiden: de VPN moet nog steeds beslissen welke gebruikers of apparaten welke bronnen bereiken, en intrekking verwijdert alleen toegang als de gateway intrekking überhaupt controleert. De Microsoft-handleiding voor het beheren van certificaatsjablonen behandelt de sjabloonconsole, de machtigingen en de afzonderlijke publicatiestap.