Förstå behållare för Active Directory-certifikattjänster

Om du någonsin har hanterat en Windows-miljö och undrat var din certifikatutfärdarkonfiguration egentligen finns i Active Directory, är du inte ensam. De flesta yrkesverksamma vet det. Active Directory-certifikattjänster (AD CS) hanterar certifikatutfärdande, men rörmokeriet under, särskilt uppsättningen specialiserade containrar som lagrar PKI-konfiguration i din skog, förblir ofta ett mysterium.

Den här guiden går igenom varje nyckelbehållare som AD CS använder, förklarar vad den lagrar, varför den är viktig, hur man visar den och vad som kan gå fel om den är felkonfigurerad eller försummad.

Vad du kommer att lära dig

• Vad AD CS-containrar är och var de finns i Active Directory
• Syftet med varje container: Certifieringsmyndigheter, AIA, CDP, registreringstjänster, NTAuthCertificates, KRA, OID och mer
• Hur man visar och hanterar containrar med PKIView, ADSI Edit och certutil

Vad är AD CS och varför är containrar viktiga?

Active Directory Certificate Services (AD CS) är Microsofts inbyggda Lösning för offentlig nyckelinfrastruktur (PKI)Det låter organisationer utfärda och hantera digitala certifikat för saker som användarautentisering, datorautentisering, krypterad e-post, SSL/TLS, inloggning med smartkort och kodsignering.

AD CS förlitar sig starkt på Active Directory för att lagra konfiguration, publicera certifikat, distribuera återkallningsinformation och låta klientdatorer veta vilka certifikatutfärdare de kan lita på. De behållare vi ska utforska är de specifika platserna i Active Directory där all den informationen finns.

Konfigurationsnamngivningskontexten

All AD CS-konfigurationsdata lagras i konfigurationsnamngivningskontexten, under behållaren Public Key Services, som replikeras till varje domänkontrollant i hela skogen. Det är en viktig detalj. Till skillnad från domännamngivningskontexten (som är begränsad till en enda domän) är konfigurationsdata skogsomfattande. Det innebär att en ändring av en certifikatmall eller en CRL-distributionspunkt på en domänkontrollant så småningom kommer att visas på domänkontrollanter i varje domän i skogen.

CN=Public Key Services, CN=Tjänster, CN=Konfiguration, DC={skogens rotdomän}

Allt vi diskuterar i den här artikeln finns någonstans under den vägen. Så varför är säkerhet i hela skogen viktig?

• Eventuella felkonfigurationer i AD CS-behållare påverkar alla domäner i skogen.
• Behörigheter för dessa containrar anges på skogsnivå av företagsadministratörer.
• En komprometterad certifikatutfärdare eller en skadlig certifikatmall kan eskalera privilegier över domängränser.
• Det är därför att härdning av AD CS-behållare är ett säkerhetsproblem för hela skogen, inte bara ett problem per domän.

De viktigaste AD CS-containrarna, en efter en

Låt oss gå igenom varje behållare i detalj.

Certifieringsutfärdares behållare

Den här behållaren innehåller CA-certifikaten för varje rot-CA som din organisation har valt att lita på. När du installerar ett Enterprise-system Rot-CA, publicerar installationsguiden automatiskt CA-certifikatet här. Windows-klienter läser sedan den här behållaren när de bygger certifikatkedjor, vilket är så de vet om de ska lita på ett certifikat som utfärdats av din interna CA.

Du kan manuellt installera rot-CA-certifikatet till den här behållaren genom att köra följande certutil.exe-kommando:

certutil –dspublish –f  RootCA

ersätta  med faktisk sökväg och certifikatnamnsfil. Observera att en kopia av rot-CA-certifikatet också installeras i AIA-behållaren.

Tänk på det som den "officiella listan över betrodda certifikatutfärdare" som hela skogen ärver. När en användare får ett certifikat signerat av din interna certifikatutfärdare kontrollerar Windows den här behållaren (bland andra arkiv) för att bekräfta att den utfärdande certifikatutfärdaren är betrodd.

Behållare för registreringstjänster

Detta är en av de viktigaste containrarna operativt. Varje företagscertifikatutfärdare som ansluter till din skog publicerar ett objekt här. När en Windows-klient vill registrera sig för ett certifikat frågar den den här containern för att ta reda på vilka certifikatutfärdare som är tillgängliga och vilka mallar varje certifikatutfärdare stöder.

Denna identifieringsprocess driver automatisk registrering. När grupprincipen utlöser automatisk certifikatregistrering kontrollerar Windows behållaren för registreringstjänster för att ta reda på vilken certifikatutfärdare som ska kontaktas och vilka mallar som ska begäras. Utan ett giltigt objekt här slutar automatisk registrering helt enkelt att fungera.

pKIEnrollmentService-objektet har också ett attribut som heter certificateTemplates, vilket är en lista över mallar som publicerats på just den CA:n. Det betyder att om du vill veta exakt vilka mallar en specifik CA för närvarande erbjuder, är det här du ska leta.

Visar i PKIView.msc

Kontrollera objekt för registreringstjänster med MMC-snapin-modulen Enterprise PKI

• Öppna PKIView.msc (kör pkiview.msc från Start-menyn)
• Trädvyn till vänster visar din Enterprise PKI-hierarki
• Varje CA-nod representerar ett objekt i behållaren för registreringstjänster
• Högerklicka på en CA och välj Egenskaper för att se dess attribut
• Högerklicka på Företag PKI och välj Hantera AD-behållare för djupare åtkomst

Behållare för certifikatmallar

Certifikatmallar definierar ritning för varje certifikattyp som din PKI kan utfärda. Mallen anger nyckelanvändning, giltighetsperiod, kryptografiska algoritmer, format för ämnesnamn, utökad nyckelanvändning, inställningar för automatisk registrering och vem som har behörighet att begära den typen av certifikat.

Alla mallar, oavsett om de för närvarande är publicerade på en CA eller inte, finns i den här behållaren. Separationen mellan "mallen finns" och "mallen är publicerad" är viktig: en mall kan finnas i den här behållaren utan att någon CA aktivt erbjuder den. Först när en CA-administratör publicerar mallen listas den i objektet Enrollment Services för den CA:n.

Varför mallar är en säkerhetshotspot

Certifikat mallar är den främsta attackytan i de flesta AD CS-distributioner. Forskning från säkerhetsföretag (mest känt ESC1 till ESC16 sårbarhetsklasser dokumenterade av SpecterOps) har visat att felkonfigurerade mallar kan tillåta oprivilegierade användare att begära certifikat som ger domänadministratörsbehörighet.

De farligaste felkonfigurationerna inkluderar:

• Tillåta autentiserade användare att registrera sig i en mall där godkännande av chef har inaktiverat
• Möjliggör alternativa ämnesnamn (SAN) tillhandahålls av begärande part i känsliga mallar
• Bevilja registreringsrättigheter till alltför breda grupper
• Aktivera flaggan "Markera privat nyckel som exporterbar" i onödan
• Använda certifikatmallar med ENROLLEE_SUPPLIES_SUBJECT-flaggan på mallar med hög behörighet

Kritisk säkerhetsvarning

Lämna aldrig "Autentiserade användare" med registreringsbehörighet för mallar som saknar godkännande av chef.

AIA-behållare (Authority Information Access)

AIA-behållaren lagrar certifikaten för underordnade (mellanliggande) CA:er och eventuella korscertifikat som din organisation har upprättat. När en klientdator tar emot ett certifikat och behöver validera det måste den bygga en kedja från slutenhetscertifikatet upp till en betrodd rot. Om klienten inte redan har det mellanliggande CA-certifikatet cachat lokalt använder den AIA-URL:en som är inbäddad i certifikatet för att hämta det.

LDAP-URL:en som pekar till den här behållaren är vanligtvis inbäddad i AIA-tillägget för varje certifikat som din underordnade certifikatutfärdare utfärdar. Så när en maskin frågar "var får jag tag på certifikatet för den certifikatutfärdare som utfärdade detta?", följer det att LDAP URL och landar i den här behållaren.

Verifiera AIA med certutil

Kontrollera vad som publiceras i AIA-behållaren från kommandoraden

• Öppna en förhöjd kommandotolk
• Kör: certutil -store -enterprise SubCA
• Detta listar alla certifikat i den AD-baserade AIA-behållaren
• Jämför utdata med dina förväntade mellanliggande certifikatutfärdare
• För att publicera ett saknat certifikat: certutil -dsPublish -f SubCA.cer SubCA

Ett vanligt problem: om AIA-behållaren saknar den mellanliggande CA:ns certifikat, kommer klienter i andra domäner eller skogar som inte har cachat certifikatet att misslyckas med validering av certifikatkedjan. Detta visas ofta som SSL-fel på webbplatser eller autentiseringsfel i scenarier över flera domäner.

CDP-behållare (CRL-distributionspunkt)

CDP-behållaren är där dina certifikatåterkallningslistor (CRL:er) finns i Active Directory. En CRL är i grunden en signerad lista med serienummer för certifikat som har återkallats före deras utgångsdatum. När en klientapplikation validerar ett certifikat är en av dess kontroller "har detta certifikat återkallats?". Den gör det genom att ladda ner CRL:en från en CDP-URL.

Active Directory är en av flera CDP-platser som stöds (HTTP är en annan vanlig plats). LDAP-URL:en som pekar till den här behållaren är inbäddad i CDP-tillägget för varje utfärdat certifikat. När ett certifikat valideras följer klienten den URL:en och hämtar CRL:en för att kontrollera om den har återkallats.

Varje CA får sin egen underbehållare i CN=CDP. Inuti den underbehållaren hittar du:

• Bas-CRL: Den fullständiga listan över återkallade certifikat, publicerad regelbundet
• Delta CRL: En mindre inkrementell lista över ändringar sedan den senaste bas-CRL:en

Publicera en CRL manuellt

Tvinga CRL-publicering till AD CDP-behållaren

• Öppna en kommandotolk med förhöjda behörighetskrav på CA-servern
• Kör: certutil -crl för att tvinga fram CRL-publicering
• Detta publicerar både bas- och delta-CRL:en till alla konfigurerade CDP-platser
• Verifiera med: certutil -store -enterprise ldap:///CN= ,CN=CDP,….
• I PKIView.msc indikerar en gul ikon bredvid en CA att CRL-giltigheten snart löper ut

Visa från ADSI.edit

NTAuthCertificates Store

Trots att det låter som en container är NTAuthCertificates i själva verket ett enda AD-objekt med ett flervärdesattribut. Det innehåller CA-certifikaten för varje CA som är auktoriserad att utfärda certifikat som används för inloggning med smartkort och arkivering av nyckel.

Här är anledningen till att detta är viktigt: när en användare försöker logga in på Windows med ett smartkort kontrollerar domänkontrollanten inte bara om certifikatet på kortet är giltigt och betrott. Den kontrollerar också om den certifikatutfärdare som utfärdade certifikatet visas i NTAuthCertificates. Om den utfärdande certifikatutfärdaren inte listas där nekas inloggning, även om själva certifikatet är helt giltigt.

Företagscertifikatutfärdare lägger automatiskt till sig själva i NTAuthCertificates under installationen. Tredjepartscertifikatutfärdare eller fristående certifikatutfärdare som används för smartkortscertifikat måste läggas till manuellt.

Kontrollera NTAuthCertificates från kommandoraden

Verifiera vilka CA-certifikat som finns i NTAuthCertificates-arkivet

• Öppna en förhöjd kommandotolk
• Kör: certutil -store -enterprise NTAuth
• Detta listar alla CA-certifikat som för närvarande finns i NTAuthCertificates
• För att lägga till en saknad certifikatutfärdare: certutil -dsPublish -f NTAuthCA
• Efter tillägg, kör: certutil -pulse på domänkontrollanter för att tvinga fram policyuppdatering

KRA-behållare (nyckelåterställningsagent)

KRA-behållaren lagrar KRA-certifikaten. När en CA är konfigurerad för nyckelarkivering använder den den publika nyckeln från ett KRA-certifikat (lagrad i denna behållare) för att kryptera den arkiverade kopian av användarens privata nyckel. Endast innehavaren av den privata KRA-nyckeln kan senare dekryptera och återställa den arkiverade nyckeln.

Detta är en känslig behållare. Om en angripare får kontroll över ett KRA-certifikats privata nyckel kan de dekryptera alla arkiverade användarnycklar och potentiellt få åtkomst till åratal av krypterad e-post, dokument och annan känslig data.

OID-behållare (objektidentifierare)

Objektidentifierare (OID) är globalt unika numeriska identifierare som tilldelas nästan allt i PKI-världen: algoritmer, certifikattillägg, policyer och mer. OID-behållaren i AD är där din organisation registrerar anpassade OID:er som används i certifikatmallar för applikationspolicyer (vad är certifikatet giltigt för?) och utfärdandepolicyer (under vilka villkor utfärdades detta certifikat?).

När du skapar ett anpassat tillägg för programpolicy i MMC-snapin-modulen för certifikatmallar lagras det resulterande OID-objektet här. Det är också i den här behållaren som AD CS känner till de läsbara namnen som ska visas för dessa OID:er i användargränssnittet för certifikatmallar.

Även om den här behållaren medför mindre direkt säkerhetsrisk än de andra, är det värt att granska den för att säkerställa att inga oväntade OID-definitioner har lagts till, vilket kan påverka mallens beteende på subtila sätt.

Verktyg för att visa och hantera AD CS-containrar

Nu när vi vet vad som finns i varje behållare, låt oss prata om hur man faktiskt interagerar med dem. Du har tre huvudverktyg till ditt förfogande, vart och ett anpassat för olika uppgifter.

PKIView.msc: Den användarvänliga utgångspunkten

PKIView (även kallat Enterprise PKI MMC-snapin) är det enklaste sättet att få en överblick över din PKI-hälsa. Den visar CA-hierarkin, flaggar tillgänglighetsproblem för CRL och AIA med färgkodade statusikoner och låter dig navigera i AD-containrarna utan att behöva känna till LDAP-sökvägar.

PKIView.msc – Hälsovy för företags-PKI

Vad du ser när du startar pkiview.msc på en domänansluten dator

• Start > Kör > pkiview.msc
• Vänster ruta: hierarkiskt träd för din Enterprise PKI (rot-CA överst, underordnade CA:er nedan)
• Grön bockmarkeringsikon = behållaren/URL:en är felfri och tillgänglig
• Gul varningsikon = CRL närmar sig utgångsdatumet eller URL:en svarar långsamt
• Röd X-ikon = CRL- eller AIA-URL:en är oåtkomlig eller har löpt ut
• Högerklicka på Enterprise PKI > Hantera AD-containrar för att visa, ta bort eller uppdatera containerobjekt.

PKIView ger dig bra insyn men begränsad möjlighet att göra ändringar utöver att ta bort inaktuella poster. För mer djupgående hantering behöver du verktygen nedan.

ADSI-redigering: Utforskaren på låg nivå

ADSI Edit (adsiedit.msc) är en redigerare för råa kataloger som låter dig bläddra bland och ändra alla objekt i Active Directory, inklusive PKI-behållare. Tänk på det som Utforskaren för Active Directory. Med stor kraft kommer stort ansvar: en felaktig redigering i ADSI Edit kan förstöra din PKI på sätt som är svåra att ångra, så testa alltid i en icke-produktionsmiljö först.

ADSI-redigering – Navigera till publika nyckeltjänster

Bläddra igenom hela PKI-containerstrukturen

• Start > Kör > adsiedit.msc
• Högerklicka på ADSI-redigering i den vänstra rutan > Anslut till…
• Välj "Konfiguration" från den välkända rullgardinsmenyn för namngivningskontext > OK
• Expandera: Konfiguration[DC=…] > CN=Konfiguration > CN=Tjänster > CN=Public Key Services
• Nu ser du alla underbehållare: AIA, CDP, certifieringsmyndigheter, registreringstjänster, KRA, OID
• Högerklicka på valfritt objekt och välj Egenskaper för att visa alla dess attribut och värden

Certutil.exe

Certutil är kommandoradsarbetshästen för allt inom AD CS. Den kan läsa från och skriva till AD CS-containrar, publicera certifikat och CRL:er, verifiera certifikatkedjor och mycket mer. Här är de mest använda kommandona för containerhantering:

Snabbreferenssammanfattning

Här är en samlad referens över alla AD CS-containrar som vi täckte:

Hur krypteringskonsulting kan hjälpa dig med din PKI?

Krypteringskonsulttjänster erbjuder specialiserade tjänster för att identifiera sårbarheter och minska risker genom att tillhandahålla PKI-tjänsterVår strategiska vägledning anpassar PKI-lösningar till organisationens mål, vilket ökar effektiviteten och minimerar kostnaderna. Genom att samarbeta med Encryption Consulting kan organisationer frigöra den fulla potentialen hos PKI-lösningar, realisera konkreta ekonomiska fördelar samtidigt som de upprätthåller starka säkerhetsåtgärder.

Krypteringskonsulttjänster PKIaaS erbjuder en flexibel och säker PKI-lösning skräddarsydd för dina specifika behov, med fördelar som anpassningsbara alternativ, höga säkerhetsstandarder och en lågriskhanteringsmetod. PKIaaS automatiserar nyckel- och certifikathanteringsuppgifter, vilket minskar driftskostnader och minimerar risken för mänskliga fel. Dessutom förbättrar det nätverkssynligheten genom att kräva certifikat för åtkomst. Det tar hand om att bygga PKI-infrastrukturen för att leda och hantera PKI-miljön (moln/hybrid eller lokalt) i din organisation.

CertSecure-hanterare har en omfattande uppsättning funktioner för livscykelhantering. Från identifiering och inventering till utfärdande, driftsättning, förnyelse, återkallelse och rapportering. CertSecure erbjuder en heltäckande lösning. Intelligent rapportgenerering, aviseringar, automatisering, automatisk driftsättning på servrar och certifikatregistrering ger lager av sofistikering, vilket gör den till en mångsidig och intelligent tillgång.

Slutsats

AD CS-containrar är de okända hjältarna (och enstaka skurkarna) inom Windows PKI. När de är korrekt konfigurerade och ordentligt säkrade arbetar de tyst i bakgrunden, vilket möjliggör automatisk certifikatregistrering, inloggning med smartkort, SSL-validering med mera. När de är felkonfigurerade, försummade eller attackerade kan konsekvenserna variera från irriterande (avbrott i automatisk registrering) till katastrofala (skogsomfattande privilegieupptrappning).

De viktigaste lärdomarna från den här guiden:

• All AD CS-konfiguration finns i konfigurationsnamngivningskontexten och replikeras i hela skogen.
• Varje container tjänar ett specifikt syfte i certifikatets livscykel, förstå var och ens roll.
• Certifikatmallar är den yta med högst risk för attacker; granska dem regelbundet
• NTAuthCertificates och KRA-behållaren är värdefulla mål som behöver noggrann åtkomstkontroll och övervakning.
• PKIView, ADSI Edit och certutil ger dig tre kompletterande sätt att inspektera och hantera containrar
• De vanligaste PKI-problemen kan spåras tillbaka till inaktuella, saknade eller utgångna data i en av dessa behållare.

Att ta sig tid att verkligen förstå din PKI:s containerstruktur är en av de bästa investeringarna du kan göra i både tillförlitligheten och säkerheten i din Windows-miljö. En PKI som är väl förstådd är en PKI som kan försvaras ordentligt.