Inzicht in Active Directory-certificaatservicecontainers

Als u ooit een Windows-omgeving hebt beheerd en u zich hebt afgevraagd waar uw certificeringsinstantieconfiguratie zich nu eigenlijk bevindt in Active Directory, bent u niet de enige. De meeste professionals weten dat wel. Active Directory-certificaatservices (AD CS) Het systeem regelt de uitgifte van certificaten, maar de onderliggende infrastructuur, met name de gespecialiseerde containers die de PKI-configuratie in uw forest opslaan, blijft vaak een mysterie.

Deze handleiding doorloopt alle belangrijke containers die AD CS gebruikt, legt uit wat erin wordt opgeslagen, waarom het belangrijk is, hoe u de gegevens kunt bekijken en wat er mis kan gaan als deze verkeerd geconfigureerd of verwaarloosd zijn.

Wat je leert

• Wat AD CS-containers zijn en waar ze zich in Active Directory bevinden.
• Het doel van elke container: Certificeringsinstanties, AIA, CDP, Inschrijvingsdiensten, NTAuthCertificates, KRA, OID en meer.
• Hoe containers te bekijken en te beheren met PKIView, ADSI Edit en certutil

Wat is AD CS en waarom zijn containers belangrijk?

Active Directory Certificate Services (AD CS) is de ingebouwde service van Microsoft. Public Key Infrastructure (PKI)-oplossingHet stelt organisaties in staat om digitale certificaten uit te geven en te beheren voor zaken als gebruikersauthenticatie, computerauthenticatie, versleutelde e-mail, SSL/TLS, smartcardaanmelding en codeondertekening.

AD CS is sterk afhankelijk van Active Directory voor het opslaan van configuraties, het publiceren van certificaten, het verspreiden van intrekkingsinformatie en het laten weten aan clientcomputers welke CA's ze kunnen vertrouwen. De containers die we gaan onderzoeken, zijn de specifieke locaties binnen Active Directory waar al die informatie zich bevindt.

De configuratienaamgevingscontext

Alle AD CS-configuratiegegevens worden opgeslagen in de naamgevingscontext 'Configuratie', onder de container 'Public Key Services', die wordt gerepliceerd naar elke domeincontroller in het gehele forest. Dat is een belangrijk detail. In tegenstelling tot de naamgevingscontext 'Domein' (die beperkt is tot één domein), zijn configuratiegegevens forestbreed. Dit betekent dat een wijziging in een certificaatsjabloon of een CRL-distributiepunt op één domeincontroller uiteindelijk zichtbaar zal zijn op domeincontrollers in elk domein in het forest.

CN=Openbare sleutelservices, CN=Services, CN=Configuratie, DC={forest root domein}

Alles wat we in dit artikel bespreken, bevindt zich ergens onder dat pad. Dus waarom is beveiliging van het hele bos zo belangrijk?

• Elke verkeerde configuratie in AD CS-containers heeft gevolgen voor elk domein in het forest.
• De machtigingen voor deze containers worden op forestniveau ingesteld door Enterprise Admins.
• Een gecompromitteerde CA of een kwaadaardig certificaatsjabloon kan de bevoegdheden over domeingrenzen heen vergroten.
• Daarom is het beveiligen van AD CS-containers een beveiligingskwestie voor het hele forest, en niet alleen voor elk domein.

De belangrijkste AD CS-containers, één voor één.

Laten we elke container eens nader bekijken.

Certificeringsinstanties Container

Deze container bevat de CA-certificaten van elke root-CA die uw organisatie vertrouwt. Wanneer u een Enterprise-pakket installeert, wordt dit opgeslagen in de container. Root-CADe installatiewizard publiceert het CA-certificaat hier automatisch. Windows-clients lezen deze container vervolgens bij het opbouwen van certificaatketens, waardoor ze weten of ze een certificaat van uw interne CA kunnen vertrouwen.

U kunt het root-CA-certificaat handmatig in deze container installeren door de volgende certutil.exe-opdracht uit te voeren:

certutil –dspublish –f  RootCA

vervangen  met het daadwerkelijke pad en de naam van het certificaatbestand. Merk op dat een kopie van het root-CA-certificaat ook in de AIA-container is geïnstalleerd.

Zie het als de "officiële lijst van vertrouwde CA's" die het hele forest overneemt. Wanneer een gebruiker een certificaat ontvangt dat is ondertekend door uw interne CA, controleert Windows deze container (naast andere opslaglocaties) om te bevestigen dat de uitgevende CA vertrouwd is.

Container voor inschrijvingsdiensten

Dit is een van de operationeel belangrijkste containers. Elke Enterprise CA die zich bij uw forest aansluit, publiceert hier een object. Wanneer een Windows-client een certificaat wil aanvragen, raadpleegt deze deze container om te achterhalen welke CA's beschikbaar zijn en welke sjablonen elke CA ondersteunt.

Dit ontdekkingsproces maakt automatische certificaatinschrijving mogelijk. Wanneer Groepsbeleid automatische certificaatinschrijving activeert, controleert Windows de container 'Inschrijvingsservices' om te bepalen met welke certificeringsinstantie (CA) contact moet worden opgenomen en welke sjablonen moeten worden aangevraagd. Zonder een geldig object op deze locatie stopt de automatische certificaatinschrijving simpelweg met werken.

Het pKIEnrollmentService-object bevat ook een attribuut genaamd certificateTemplates, een lijst met sjablonen die door die specifieke CA worden aangeboden. Dit betekent dat als u precies wilt weten welke sjablonen een bepaalde CA momenteel aanbiedt, u hier moet kijken.

Weergave in PKIView.msc

Controleer de objecten van de inschrijvingsservice met de Enterprise PKI MMC-module.

• Open PKIView.msc (start pkiview.msc vanuit het Startmenu)
• De boomstructuur aan de linkerkant toont uw Enterprise PKI-hiërarchie.
• Elk CA-knooppunt vertegenwoordigt een object in de container van de inschrijvingsservices.
• Klik met de rechtermuisknop op een CA en kies Eigenschappen om de attributen ervan te bekijken.
• Klik met de rechtermuisknop op Enterprise PKI en kies 'AD-containers beheren' voor uitgebreidere toegang.

Container voor certificaatsjablonen

Certificaatsjablonen definiëren de blauwdruk voor elk certificaattype dat uw PKI kan uitgeven. Het sjabloon specificeert het sleutelgebruik, de geldigheidsperiode, cryptografische algoritmen, de indeling van de onderwerpnaam, het uitgebreide sleutelgebruik, de instellingen voor automatische inschrijving en wie bevoegd is om dat type certificaat aan te vragen.

Alle sjablonen, ongeacht of ze momenteel op een CA zijn gepubliceerd of niet, bevinden zich in deze container. Het onderscheid tussen "sjabloon bestaat" en "sjabloon is gepubliceerd" is belangrijk: een sjabloon kan in deze container staan ​​zonder dat een CA deze actief aanbiedt. Pas wanneer een CA-beheerder het sjabloon publiceert, wordt het weergegeven in het object 'Inschrijvingsservices' voor die CA.

Waarom sjablonen een beveiligingsrisico vormen

Certificaat Sjablonen vormen het grootste aanvalsoppervlak in de meeste AD CS-implementaties. Onderzoek door beveiligingsbedrijven (waarvan de bekendste de ESC1 tot en met ESC16 Uit onderzoek naar kwetsbaarheidsklassen (gedocumenteerd door SpecterOps) is gebleken dat verkeerd geconfigureerde sjablonen het mogelijk kunnen maken voor gebruikers zonder beheerdersrechten om certificaten aan te vragen die domeinbeheerdersrechten verlenen.

De gevaarlijkste verkeerde configuraties zijn onder andere:

• Het toestaan ​​dat geauthenticeerde gebruikers zich inschrijven voor een sjabloon waarvoor goedkeuring door de manager is uitgeschakeld.
• inschakelen alternatieve onderwerpnamen (SAN's) aangeleverd door de aanvrager in gevoelige sjablonen
• Het toekennen van inschrijvingsrechten aan te brede groepen.
• Het onnodig inschakelen van de optie "Privésleutel als exporteerbaar markeren"
• Certificaatsjablonen gebruiken met de vlag ENROLLEE_SUPPLIES_SUBJECT op sjablonen met hoge privileges.

Kritieke veiligheidswaarschuwing

Laat "Geverifieerde gebruikers" nooit de machtiging 'Inschrijven' hebben op sjablonen die niet door de manager zijn goedgekeurd.

AIA (Authority Information Access) Container

De AIA-container slaat de certificaten van ondergeschikte (tussenliggende) CA's en alle kruiscertificaten op die uw organisatie heeft ingesteld. Wanneer een clientmachine een certificaat ontvangt en dit moet valideren, moet deze een certificaatketen opbouwen van het eindgebruikerscertificaat tot een vertrouwde root. Als de client het certificaat van de tussenliggende CA nog niet lokaal in de cache heeft opgeslagen, gebruikt deze de AIA-URL die in het certificaat is opgenomen om het op te halen.

De LDAP-URL die naar deze container verwijst, is doorgaans opgenomen in de AIA-extensie van elk certificaat dat uw ondergeschikte CA uitgeeft. Dus wanneer een machine vraagt: "Waar vind ik het certificaat van de CA die dit heeft uitgegeven?", volgt daaruit dat... LDAP De URL komt in deze container terecht.

Verifieer AIA met certutil

Controleer via de commandoregel wat er in de AIA-container is gepubliceerd.

• Open een verhoogde opdrachtprompt
• Uitvoeren: certutil -store -enterprise SubCA
• Hier worden alle certificaten in de op Active Directory gebaseerde AIA-container weergegeven.
• Vergelijk de uitvoer met uw verwachte tussentijdse CA's.
• Om een ​​ontbrekend certificaat te publiceren: certutil -dsPublish -f SubCA.cer SubCA

Een veelvoorkomend probleem: als het AIA-containercertificaat van de intermediaire CA ontbreekt, zullen clients in andere domeinen of forests die het certificaat niet in de cache hebben, de certificaatketenvalidatie niet kunnen uitvoeren. Dit uit zich vaak in SSL-fouten op websites of authenticatiefouten in scenario's met meerdere domeinen.

CDP (CRL Distribution Point) container

De CDP-container is de locatie waar uw certificaatintrekkingslijsten (CRL's) zich bevinden binnen Active Directory. Een CRL is in principe een ondertekende lijst met serienummers van certificaten die zijn ingetrokken vóór hun vervaldatum. Wanneer een clienttoepassing een certificaat valideert, controleert deze onder andere of het certificaat is ingetrokken. Dit doet de toepassing door de CRL te downloaden van een CDP-URL.

Active Directory is een van de verschillende ondersteunde CDP-locaties (HTTP is een andere veelgebruikte locatie). De LDAP-URL die naar deze container verwijst, is opgenomen in de CDP-extensie van elk uitgegeven certificaat. Wanneer een certificaat wordt gevalideerd, volgt de client die URL en haalt de CRL op om te controleren of het certificaat is ingetrokken.

Elke CA krijgt zijn eigen subcontainer binnen CN=CDP. Binnen die subcontainer vindt u het volgende:

• Basis-CRL: De volledige lijst met ingetrokken certificaten, die regelmatig wordt gepubliceerd.
• Delta CRL: Een kleinere, stapsgewijze lijst met wijzigingen sinds de laatste basis-CRL.

Een CRL handmatig publiceren

Forceer de publicatie van CRL naar de AD CDP-container

• Open op de CA-server een opdrachtprompt met beheerdersrechten.
• Voer het commando `certutil -crl` uit om de publicatie van de CRL af te dwingen.
• Hiermee worden zowel de basis- als de delta-CRL naar alle geconfigureerde CDP-locaties gepubliceerd.
• Controleer met: certutil -store -enterprise ldap:///CN= ,CN=CDP,….
• In PKIView.msc geeft een geel pictogram naast een CA aan dat de geldigheid van de CRL bijna is verlopen.

Weergave vanuit de ADSI.edit

NTAuthCertificates Store

Hoewel het klinkt als een container, is NTAuthCertificates in werkelijkheid een enkel AD-object met een attribuut met meerdere waarden. Het bevat de CA-certificaten voor elke CA die gemachtigd is om certificaten uit te geven die worden gebruikt voor smartcardaanmelding en sleutelarchivering.

Dit is waarom het belangrijk is: wanneer een gebruiker probeert in te loggen op Windows met een smartcard, controleert de domeincontroller niet alleen of het certificaat op de kaart geldig en vertrouwd is. De controller controleert ook of de certificeringsinstantie (CA) die het certificaat heeft uitgegeven, voorkomt in NTAuthCertificates. Als de uitgevende CA daar niet in staat, wordt de aanmelding geweigerd, zelfs als het certificaat zelf perfect geldig is.

Enterprise CA's worden tijdens de installatie automatisch toegevoegd aan NTAuthCertificates. CA's van derden of zelfstandige CA's die worden gebruikt voor smartcardcertificaten moeten handmatig worden toegevoegd.

Controleer NTAuthCertificates via de opdrachtregel

Controleer welke CA-certificaten zich in de NTAuthCertificates-opslag bevinden.

• Open een verhoogde opdrachtprompt
• Uitvoeren: certutil -store -enterprise NTAuth
• Deze lijst bevat alle CA-certificaten die momenteel in NTAuthCertificates zijn opgenomen.
• Om een ​​ontbrekende CA toe te voegen: certutil -dsPublish -f NTAuthCA
• Na het toevoegen, voer je op de domeincontrollers het volgende commando uit: `certutil -pulse` om het beleid te vernieuwen.

KRA (Key Recovery Agent) Container

De KRA-container slaat de KRA-certificaten op. Wanneer een CA is geconfigureerd voor sleutelarchivering, gebruikt deze de publieke sleutel van een KRA-certificaat (opgeslagen in deze container) om de gearchiveerde kopie van de privésleutel van de gebruiker te versleutelen. Alleen de houder van de KRA-privésleutel kan die gearchiveerde sleutel later ontsleutelen en herstellen.

Dit is een gevoelige container. Als een aanvaller de privésleutel van een KRA-certificaat in handen krijgt, kan hij alle gearchiveerde privésleutels van gebruikers decoderen en zo mogelijk toegang krijgen tot jaren aan versleutelde e-mails, documenten en andere gevoelige gegevens.

OID (Object Identifier) ​​Container

Objectidentificatoren (OID's) OID's zijn wereldwijd unieke numerieke identificaties die worden toegekend aan vrijwel alles in de PKI-wereld: algoritmen, certificaatextensies, beleidsregels en meer. De OID-container in Active Directory is de plek waar uw organisatie aangepaste OID's registreert die worden gebruikt in certificaatsjablonen voor toepassingsbeleid (waarvoor is het certificaat geldig?) en uitgiftebeleid (onder welke voorwaarden is dit certificaat uitgegeven?).

Wanneer u een aangepaste toepassingsbeleidsuitbreiding maakt in de MMC-module Certificaatsjablonen, wordt het resulterende OID-object hier opgeslagen. Deze container wordt ook gebruikt door AD CS om de leesbare namen te bepalen die voor die OID's in de gebruikersinterface van Certificaatsjablonen moeten worden weergegeven.

Hoewel deze container minder directe beveiligingsrisico's met zich meebrengt dan de andere, is het de moeite waard om te controleren of er geen onverwachte OID-definities zijn toegevoegd die het gedrag van de sjabloon op subtiele wijze kunnen beïnvloeden.

Hulpmiddelen voor het bekijken en beheren van AD CS-containers

Nu we weten wat er in elke container zit, gaan we het hebben over hoe je er daadwerkelijk mee omgaat. Je hebt drie belangrijke hulpmiddelen tot je beschikking, elk geschikt voor verschillende taken.

PKIView.msc: Het gebruiksvriendelijke startpunt

PKIView (ook wel de Enterprise PKI MMC-module genoemd) is de meest toegankelijke manier om een ​​overzicht te krijgen van de status van uw PKI. Het toont de CA-hiërarchie, markeert CRL- en AIA-toegankelijkheidsproblemen met kleurgecodeerde statuspictogrammen en stelt u in staat om door de AD-containers te navigeren zonder dat u LDAP-paden hoeft te kennen.

PKIView.msc – Enterprise PKI-statusweergave

Dit ziet u wanneer u pkiview.msc start op een computer die is aangesloten op een domein.

• Start > Uitvoeren > pkiview.msc
• Linkerpaneel: hiërarchische structuur van uw Enterprise PKI (Root CA bovenaan, ondergeschikte CA's eronder)
• Groen vinkje = container/URL is gezond en toegankelijk
• Geel waarschuwingspictogram = CRL nadert de vervaldatum of de URL reageert traag
• Rood kruisje = CRL- of AIA-URL is onbereikbaar of verlopen
• Klik met de rechtermuisknop op Enterprise PKI > AD-containers beheren om containerobjecten te bekijken, te verwijderen of te vernieuwen.

PKIView biedt een goed overzicht, maar de mogelijkheden om wijzigingen aan te brengen die verder gaan dan het verwijderen van verouderde gegevens zijn beperkt. Voor een meer gedetailleerd beheer hebt u de onderstaande tools nodig.

ADSI Edit: De Low-Level Explorer

ADSI Edit (adsiedit.msc) is een editor voor onbewerkte mappen waarmee u elk object in Active Directory kunt bekijken en wijzigen, inclusief de PKI-containers. Zie het als Verkenner voor Active Directory. Met grote macht komt grote verantwoordelijkheid: een verkeerde bewerking in ADSI Edit kan uw PKI op onherstelbare wijze beschadigen, dus test altijd eerst in een niet-productieomgeving.

ADSI Edit – Navigeren naar Public Key Services

Bekijk de volledige PKI-containerstructuur

• Start > Uitvoeren > adsiedit.msc
• Klik met de rechtermuisknop op ADSI Edit in het linkerdeelvenster > Verbinden met…
• Selecteer 'Configuratie' in het bekende naamgevingsmenu > OK
• Uitbreiden: Configuratie[DC=…] > CN=Configuratie > CN=Services > CN=Openbare sleutelservices
• Je ziet nu alle submappen: AIA, CDP, Certificeringsinstanties, Inschrijvingsdiensten, KRA, OID
• Klik met de rechtermuisknop op een object en kies Eigenschappen om alle attributen en waarden ervan te bekijken.

Certutil.exe

Certutil is hét commandoregelprogramma voor alles wat met Active Directory CS te maken heeft. Het kan gegevens lezen uit en schrijven naar AD CS-containers, certificaten en CRL's publiceren, certificaatketens verifiëren en nog veel meer. Hieronder vindt u de meest gebruikte commando's voor containerbeheer:

Snelle referentiesamenvatting

Hier vindt u een samenvattend overzicht van alle AD CS-containers die we hebben behandeld:

Hoe kan encryptieconsulting u helpen met uw PKI?

Encryption Consulting biedt gespecialiseerde diensten om kwetsbaarheden te identificeren en risico's te beperken door: PKI-dienstenOnze strategische begeleiding stemt PKI-oplossingen af ​​op organisatiedoelstellingen, verbetert de efficiëntie en minimaliseert kosten. Door samen te werken met Encryption Consulting kunnen organisaties het volledige potentieel van PKI-oplossingen benutten en tastbare financiële voordelen realiseren, terwijl ze tegelijkertijd sterke beveiligingsmaatregelen handhaven.

Encryptie Consulting's PKIaaS biedt een flexibele en veilige PKI-oplossing, afgestemd op uw specifieke behoeften, met voordelen zoals aanpasbare opties, hoge betrouwbaarheidsnormen en een beheerde aanpak met een laag risico. PKIaaS automatiseert sleutel- en certificaatbeheer, waardoor de operationele overhead wordt verlaagd en het risico op menselijke fouten wordt geminimaliseerd. Bovendien verbetert het de netwerkzichtbaarheid door certificaten te vereisen voor toegang. Het zorgt voor de ontwikkeling van de PKI-infrastructuur om de PKI-omgeving (cloud/hybride of on-premises) van uw organisatie te beheren.

CertSecure Manager CertSecure beschikt over een uitgebreide reeks functies voor lifecyclemanagement. Van detectie en inventarisatie tot uitgifte, implementatie, verlenging, intrekking en rapportage. CertSecure biedt een allesomvattende oplossing. Intelligente rapportage, waarschuwingen, automatisering, automatische implementatie op servers en certificaatregistratie voegen extra functionaliteit toe, waardoor het een veelzijdig en intelligent hulpmiddel is.

Conclusie

AD CS-containers zijn de onbezongen helden (en soms ook de boosdoeners) van Windows PKI. Wanneer ze correct geconfigureerd en goed beveiligd zijn, werken ze geruisloos op de achtergrond en maken ze automatische certificaatinschrijving, aanmelding met smartcards, SSL-validatie en meer mogelijk. Wanneer ze verkeerd geconfigureerd, verwaarloosd of aangevallen worden, kunnen de gevolgen variëren van vervelend (automatische inschrijving stopt) tot catastrofaal (privilege-escalatie in het hele forest).

De belangrijkste punten uit deze gids:

• Alle AD CS-configuratie bevindt zich in de naamgevingscontext 'Configuratie' en wordt in het hele forest gerepliceerd.
• Elke container vervult een specifieke functie in de certificaatlevenscyclus; begrijp de rol van elke container.
• Certificaatsjablonen vormen het grootste aanvalsoppervlak; controleer ze regelmatig.
• NTAuthCertificates en de KRA-container zijn waardevolle doelwitten die strikte toegangscontrole en monitoring vereisen.
• PKIView, ADSI Edit en certutil bieden u drie complementaire manieren om containers te inspecteren en te beheren.
• De meest voorkomende PKI-problemen zijn terug te voeren op verouderde, ontbrekende of verlopen gegevens in een van deze containers.

De tijd nemen om de containerstructuur van uw PKI echt te begrijpen, is een van de beste investeringen die u kunt doen in zowel de betrouwbaarheid als de beveiliging van uw Windows-omgeving. Een goed begrepen PKI is een PKI die goed beveiligd kan worden.