Händelse-ID 74 i AD CS – Avkodad

Beskrivning

I en Microsoft PKI- miljö signalerar händelse-ID 74 från Microsoft-Windows-CertificationAuthority-källan ett problem som inte bör ignoreras. Denna händelse indikerar att certifikatutfärdaren (CA) misslyckades med att publicera en baslista för återkallade certifikat (CRL) till en av sina distributionspunkter – vanligtvis en Active Directory-plats eller en nätverksresurs.

Det här är inte bara en rutinmässig loggpost; det är i huvudsak din certifikatutfärdare som säger: ”Jag försökte dela den senaste listan över återkallade certifikat, men jag kunde inte.” Och det är en allvarlig varningssignal för alla organisationer som förlitar sig på certifikatbaserad autentisering och kryptering.

Vad är händelse-ID 74 i AD CS? Händelse-ID 74, som loggas av Microsoft-Windows-CertificationAuthority, utlöses när en Windows-certifikatutfärdare misslyckas med att publicera en lista över återkallade certifikat (CRL) till en konfigurerad distributionspunkt, till exempel en Active Directory-plats eller nätverksresurs. Om det inte löses kan det leda till att certifikatvalidering och återkallningskontroll misslyckas när den aktuella CRL-tiden har löpt ut.

Sammanfattning

Den här artikeln förklarar vad som utlöser händelse-ID 74 i Active Directory Certificate Services, varför Microsofts standardklassificering "Låg" underskattar den verkliga operativa risken, de tre vanligaste grundorsakerna (behörighetsproblem, saknade katalogobjekt och problem med nätverksanslutning) och en steg-för-steg-lösningsväg för var och en, inklusive hur man validerar att korrigeringen fungerade och hur man återställer en ändring som introducerar nya problem.

Förutsättningar

Innan du felsöker händelse-ID 74, bekräfta att du har:

• Administrativ åtkomst till CA-servern (lokal administratörsrättighet eller delegerad CA-administratörsrättigheter).
• Åtkomst till händelseloggen under Program- och tjänsteloggar > Microsoft > Windows > CertificateServices-CA > Drift.
• Åtkomst till Active Directory-webbplatser och -tjänster och ADSIEdit (eller dsacls.exe/PowerShell) för att inspektera CDP/AIA-containrarna.
• Nätverksdiagnostikverktyg tillgängliga på CA-servern: ping, nslookup, Test-ComputerSecureChannel, Test-NetConnectionoch PortQry.
• Kunskap om din certifikatutfärdares konfigurerade CRL-distributionspunktssökvägar (CDP), syns på fliken Tillägg i certifikatutfärdarkonsolen.
• En nyligen genomförd säkerhetskopia av CA-databasen och CDP/tilläggskonfigurationen innan några behörighets- eller konfigurationsändringar görs.

Varför är CRL-publicering kritisk?

Certifikatåterkallningslistan (CRL) är en hörnsten i Public Key Infrastructure (PKI) . Den anger för system vilka certifikat som inte längre ska vara betrodda, oavsett om det beror på kompromettering, utgångsdatum eller manuell återkallelse . Utan en uppdaterad CRL kan klienter omedvetet lita på ett återkallat certifikat, vilket kan öppna dörren för säkerhetsrisker som man-in-the-middle-attacker eller obehörig åtkomst.

När CA:n misslyckas med att publicera en CRL – särskilt en bas-CRL – kan det orsaka betydande problem. Klienter kan börja avvisa alla certifikat som utfärdats av den CA:n när den nuvarande CRL:n löper ut. Detta kan störa säker kommunikation, stoppa autentiseringsprocesser och orsaka driftstopp i tjänster som är beroende av CA:n.

Kort sagt, CRL-publicering är inte bara en bakgrundsuppgift; det är en viktig del av att upprätthålla förtroende och drifttid i alla PKI-aktiverade miljöer.

Förstå sammanhanget för händelse-ID 74

Vad utlöser händelse-ID 74?

Händelse-ID 74 visas vanligtvis när Active Directory Certificate Services (AD CS) misslyckas med att publicera en bas-CRL till en av sina konfigurerade platser. Dessa platser definieras i certifikatutfärdarens CRL-distributionspunkter (CDP) och kan inkludera LDAP- sökvägar, HTTP-URL:er eller lokala/nätverksbaserade filsökvägar.

När certifikatutfärdaren försöker uppdatera CRL och något går fel – som ett behörighetsproblem, ett saknat Active Directory-objekt eller ett nätverksproblem – loggas händelse-ID 74 med ett detaljerat meddelande. Händelsen inkluderar vanligtvis:

• CA-nyckelidentifieraren (i huvudsak den som CA försökte publicera),
• Mål-URL:en eller platsen där CRL:en skulle publiceras,
• En felkod (som 0x80072098 för otillräcklig åtkomst eller 0x8007208d för objektet hittades inte),
• Och ibland namnet på värdservern som stötte på problemet.

Så även om det vid första anblicken bara ser ut som ytterligare en logghändelse, är informationen den innehåller avgörande för att fastställa exakt vad som gick fel under publiceringsprocessen.

Problemets svårighetsgrad

Intressant nog klassificerar Microsoft händelse-ID 74 som ett problem med "låg" allvarlighetsgrad i sin officiella PKI-riktlinje. Och även om det tekniskt sett kan vara sant på kort sikt, särskilt om andra CRL-publikationspunkter fortfarande fungerar, kan denna etikett vara lite missvisande.

I verkliga livet, om CRL-publicering ständigt misslyckas och ingen giltig CRL är tillgänglig när den nuvarande löper ut, riskerar man stora avbrott i tjänsten. Klienter som förlitar sig på certifikatvalidering kan sluta fungera. Program som tillämpar återkallningskontroll kan börja avvisa giltiga certifikat helt enkelt för att de inte kan verifiera deras status.

Så ja, allvarlighetsgraden kan vara låg nu när händelsen är loggad, men om den lämnas olöst kan den snöbollsforma sig till ett tillgänglighetsproblem med stor påverkan. Detta gäller särskilt i miljöer med strikt återkallningskontroll eller korta giltighetsperioder för CRL.

Vanliga orsaker till händelse-ID 74

Tillståndsproblem

En av de vanligaste orsakerna till händelse-ID 74 är ett enkelt men kritiskt behörighetsproblem. Mer specifikt har certifikatutfärdaren inte de rättigheter som krävs för att publicera CRL:n i Active Directory.

När detta händer ser du vanligtvis felkoden: 0x80072098 – ERROR_DS_INSUFF_ACCESS_RIGHTS

Det här betyder att CA försökte skriva ett objekt i Active Directory (vanligtvis under CDP- eller AIA-containrarna) men nekades åtkomst. Detta inträffar ofta om:

• CA-serverkontot har inte skrivbehörighet för målkatalogobjektet.
• De nödvändiga säkerhets-ACL:erna konfigurerades inte under installationen eller togs bort av misstag.
• AD-replikering eller policyändringar påverkade behörighetsarvet.

Att kontrollera och ställa in rätt behörigheter på CDP- och AIA- containrarna i AD är ofta allt som krävs för att lösa detta.

Saknade katalogobjekt

En annan vanlig orsak är när Active Directory-objektet som certifikatutfärdaren försöker skriva till inte finns, vilket leder till 0x 8007208D – ERROR_DS_OBJ_NOT_FOUND

Detta kan hända om:

• CDP/AIA-containrarna eller underobjekten skapades aldrig.
• Den förväntade LDAP-sökvägen är felaktig eller föråldrad.
• Något i din miljö, till exempel en misslyckad migrering eller AD-rensning, tog bort dessa objekt.

I dessa fall försöker CA i huvudsak publicera till en destination som inte längre finns eller aldrig konfigurerades korrekt från början.

Problem med nätverksanslutning

Ibland ligger problemet inte i AD eller behörigheter, utan i nätverket. Om CA:n inte kan nå en domänkontrollant, eller om domänkontrollanten inte kan svara i tid, misslyckas CRL-publiceringen.

Detta är särskilt vanligt i:

• Flersitemiljöer med långsamma WAN-länkar.
• Felkonfigurerad DNS.
• Eller domänkontrollanter som är överbelastade eller nere.

Även tillfälliga nätverksproblem kan orsaka att den här händelsen dyker upp ibland, så det är värt att kontrollera anslutning och namnmatchning om de andra orsakerna inte löser sig.

Vanliga felkoder för händelse-ID 74

Felkoden i meddelandetexten för händelse-ID 74 är oftast det snabbaste sättet att avgöra vilken grundorsak det rör sig om:

Felkod	Betydelse	Typisk lösning
0x80072098 (ERROR_DS_INSUFF_ACCESS_RIGHTS)	CA saknar skrivbehörighet på mål-CDP/AIA-behållaren i Active Directory.	Ge certifikatutfärdarens datorkonto skrivbehörighet till containern via AD-webbplatser och -tjänster eller dsacls.exe.
0x8007208D (ERROR_DS_OBJ_NOT_FOUND)	CDP/AIA-objektet som certifikatutfärdaren försöker skriva till finns inte i Active Directory.	Använda adsiedit.msc för att lokalisera eller återskapa den förväntade publiceringspunkten under CN=Public Key Services.
Ingen felkod / timeout	Pekar vanligtvis på nätverksanslutning, inte AD-behörigheter eller saknade objekt.	Kontrollera domänkontrollantens tillgänglighet, DNS-upplösning och åtkomst till brandvägg/RPC-port.

Undersöker händelse-ID 74

Granska händelseloggar

Det första steget i felsökningen av händelse-ID 74 är att gå direkt till Loggboken på din CA-server. Du hittar loggen under: Program- och tjänstloggar > Microsoft > Windows > CertificateServices-CA > Driftsläge

Leta efter händelse-ID 74-poster. När du hittar en, titta noga på meddelandet. Det bör innehålla viktiga detaljer som:

• Distributionspunkten (t.ex. LDAP eller filsökväg)
• CA-nyckelidentifieraren (för att bekräfta vilken CA-instans som loggade händelsen)
• Felkoden och eventuellt en medföljande textbeskrivning
• Värden som var inblandad i operationen

Den här informationen hjälper dig att avgöra om problemet är relaterat till behörigheter, saknade objekt eller nätverksrelaterade problem.

Viktiga parametrar att kontrollera

När du granskar händelsen, var särskilt uppmärksam på följande:

• URL eller sökväg: Pekar den på rätt plats i Active Directory eller på rätt filresurs?
• Felkod: Slå upp den exakta felkoden. Koder som 0x80072098 (behörigheter) och 0x8007208d (föremålet hittades inte) är mycket talande.
• Serverns värdnamn: Användbart om du felsöker i en hierarki med flera servrar i CA.

Även om du har sett händelse-ID 74 tidigare, anta inte att det är samma rotorsak varje gång. Parametrarna kan variera beroende på distributionspunkten eller vad som har ändrats i miljön.

Förstå relaterade fel

Ibland visas händelse-ID 74 tillsammans med andra varningar eller fel, som misslyckad publicering av Authority Information Access (AIA) eller delta-CRL:er . Dessa kan ge ytterligare sammanhang eller ledtrådar.

Om flera publiceringsfel visas tillsammans kan det tyda på ett större problem, som en bruten anslutning till Active Directory eller en felaktig behörighetskonfiguration för flera containrar.

Proffstips: Kontrollera även loggarna för katalogtjänster och DNS-klienter om du misstänker problem med domänkontrollanten eller namnmatchningen.

Löser händelse-ID 74

Nu när du vet vad som utlöste händelse-ID 74 och var du ska leta, låt oss prata om hur du åtgärdar det. Beroende på grundorsaken kan stegen variera, men här är de vanligaste och mest effektiva lösningarna:

Steg 1: Verifiera behörigheter

Om felkoden är 0x80072098 (otillräcklig åtkomst) har din certifikatutfärdare troligen inte de behörigheter som krävs i Active Directory.

Så här fixar du det:

• Öppna Active Directory-webbplatser och -tjänster (aktivera "Visa tjänstnod" om den är dold)
• Navigera till: Tjänster > Tjänster för publika nycklar > CDP och AIA behållare.
• Högerklicka på behållaren > Egenskaper > Säkerhet fliken.
• Se till att certifikatutfärdarens datorkonto (eller den grupp det tillhör) har skrivbehörighet till den relevanta behållaren.

Använd om det behövs dsacls.exe eller PowerShell för att verifiera/ställa in behörigheter på en mer detaljerad nivå.

Steg 2: Validera katalogobjekt

Om du ser 0x8007208d (objektet hittades inte) försöker certifikatutfärdaren publicera ett objekt som inte finns.

För att lösa:

• Använd adsiedit.msc för att bläddra bland CN=CDP- och CN=AIA-containrarna under CN=Public Key Services.
• Leta efter förväntade publiceringspunkter.
• Om de saknas kan du behöva skapa dem manuellt eller konfigurera om certifikatutfärdaren för att använda giltiga, befintliga sökvägar.

Var särskilt försiktig om du återställer eller migrerar till en CA; objekt kanske inte har återskapats eller länkats om korrekt.

Steg 3: Kontrollera nätverksanslutningen

Om allt verkar korrekt på certifikatutfärdaren och i Active Directory, kontrollera om det finns nätverksproblem:

• Kör ping, nslookup eller Test-ComputerSecureChannel för att säkerställa att certifikatutfärdaren kan kontakta domänkontrollanten.
• Använd verktyg som PortQry eller Test-NetConnection för att verifiera att RPC- och LDAP-portarna är öppna.
• Kontrollera tidssynkronisering (Kerberos-problem kan ibland ge konstiga biverkningar)

Långsamma länkar eller felaktig DNS-konfiguration kan tyst avbryta CRL-publicering utan att orsaka uppenbara fel, så glöm inte bort grunderna.

Steg 4: Granska konfigurationen

Öppna certifikatutfärdarkonsolen, högerklicka på certifikatutfärdaren och välj Egenskaper.

• Granska CRL-distributionspunkterna (CDP) på fliken Tillägg.
• Se till att sökvägarna är giltiga och åtkomliga och inte pekar på föråldrade eller felaktiga containrar.
• Om du nyligen har bytt namn på servrar eller omstrukturerat AD kan dessa sökvägar vara inaktuella.

Glöm inte att göra följande efter att du gjort ändringar:

• Starta om CA-tjänsten.
• Publicera en ny CRL manuellt med certutil -crl
• Bekräfta att den visas på rätt plats.

Steg 5: Validera korrigeringen

Efter att ha tillämpat en åtgärd, bekräfta att den faktiskt löste problemet snarare än att anta att den gjorde det:

1. Publicera manuellt en ny CRL med certutil -crl och bekräfta att kommandot slutförs utan fel.
2. Kontrollera Loggboken för en motsvarande lyckad händelse (händelse-ID 75, "Certificate Services publicerade CRL") som loggats kort därefter.
3. Bekräfta att inga nya poster med händelse-ID 74 visas i nästa schemalagda eller manuella publiceringscykel.
4. Bläddra direkt till CDP-platsen (LDAP-sökvägen via ADSIEdit, eller fil-/HTTP-sökvägen) och bekräfta att CRL-filens tidsstämpel återspeglar den senaste publiceringen.
5. Om flera CDP-platser har konfiguerats, upprepa kontrollen för var och en. En korrigering för en distributionspunkt garanterar inte att de andra är felfria.

Återställning: Om en ändring medför nya problem

Om en ändring av behörigheter eller konfiguration orsakar oväntade biverkningar, till exempel att bryta en annan applikations åtkomst till samma AD-behållare, ska du avsiktligt vända på den istället för att lägga till ytterligare en åtgärd ovanpå:

• Återställ CDP/AIA-behållarens ACL:er från din säkerhetskopia före ändringen eller en säkerhetskopia av domänkontrollantens systemtillstånd, istället för att gissa på de ursprungliga behörigheterna.
• Återställ alla ändringar av CDP-sökvägen som gjorts på fliken Tillägg i certifikatutfärdarkonsolen till den tidigare fungerande konfigurationen och starta sedan om certifikatutfärdartjänsten.
• Om ett manuellt skapat CDP/AIA-objekt orsakade konflikter, ta bort det och kör om det ursprungliga konfigurationssteget för CA-katalogen istället för att lämna ett delvis korrigerat objekt kvar.
• Testa igen med certutil -crl och bekräfta att händelse-ID 74 slutar återkomma innan återställningen anses vara klar.

Slutsats

Även om händelse-ID 74 kanske inte ropar "kritiskt" vid första anblicken, kan ignorering av det i tysthet skada din PKI:s tillförlitlighet och trovärdighet. När CRL:er inte publiceras korrekt misslyckas återkallningskontrollen – och det kan få tjänster att sluta fungera, bryta autentiseringen och skapa allvarliga säkerhetsblinda fläckar.

Den viktigaste slutsatsen? Åtgärda det tidigt. För det mesta är det en enkel lösning – behörigheter, saknade AD-objekt eller en felkonfigurerad sökväg. Men om det lämnas okontrollerat kan det eskalera till något som är mycket svårare (och mer smärtsamt) att reda ut.

Därför är proaktiv övervakning och regelbundet underhåll av din AD CS-installation så viktigt. Att ligga steget före problem som detta sparar tid, minskar risker och håller din säkerhetsställning stark.

Och hey – om du hellre inte vill gå djupt in i det här själv, är det precis den typen av sak som vår PKI-konsultfirma för krypteringskonsulting kan hjälpa till med. Oavsett om det handlar om att felsöka en enskild händelse eller göra en fullständig hälsokontroll av din miljö, kan det göra hela skillnaden att låta experter komma in. Ibland räcker det med ett snabbt möte med någon som har sett dessa problem hundra gånger för att få dig tillbaka på rätt spår.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från händelse-ID 74 för PKI-team?

Händelse-ID 74 innebär att en certifikatutfärdare misslyckades med att publicera en bas-CRL till en av sina distributionspunkter. Microsoft loggar det som "Låg" allvarlighetsgrad, men om det inte åtgärdas innan den aktuella CRL:n upphör att gälla kan certifikatvalidering och återkallningskontroll misslyckas i alla tjänster som litar på den certifikatutfärdaren.

Varför är händelse-ID 74 viktigt för PKI-säkerhetsprogram för företag?

CRL:n är det som låter förlitande parter veta att ett certifikat har återkallats. En certifikatutfärdare som inte kan publicera en aktuell CRL skapar ett växande fönster där komprometterade eller återkallade certifikat fortfarande kan behandlas som betrodda, vilket undergräver hela poängen med att köra en PKI.

Vilka är riskerna med att lämna händelse-ID 74 olöst?

När den nuvarande CRL:ens giltighetsperiod löper ut utan att någon ompublicering har lyckats kan klienter som tillämpar återkallningskontroll börja avvisa annars giltiga certifikat, vilket kan förstöra autentisering, VPN-åtkomst och alla tjänster som är beroende av den certifikatutfärdaren.

Vem bör ansvara för att undersöka och lösa händelse-ID 74?

Teamet som hanterar Active Directory Certificate Services, eftersom korrigeringen vanligtvis involverar AD-behörigheter på CDP/AIA-containrar, CA-konfiguration eller nätverksanslutning mellan CA och domänkontrollanter, vilka alla ligger hos PKI/AD-administrationsteamet.

Hur kopplas lösningen av händelse-ID 74 till certifikatlivscykelhantering (CLM)?

En CLM-plattform som utför återkallningskontroll är beroende av att CA publicerar en aktuell CRL. Om händelse-ID 74 inte löses kan ett CLM-verktyg börja rapportera falska återkallningskontrollfel eller inaktuell certifikatstatus som inte har något att göra med själva certifikaten.

Hur kan team mäta om en åtgärd för händelse-ID 74 faktiskt fungerade?

Bekräfta en manual certutil -crl publiceringen lyckas, bekräfta att motsvarande lyckade händelse (händelse-ID 75) visas och bekräfta att CRL-filen vid varje konfigurerad distributionspunkt visar en uppdaterad tidsstämpel, inte bara frånvaron av ytterligare händelse-ID 74-poster.

Vad bör övervakas regelbundet för att upptäcka händelse-ID 74 innan det blir ett problem?

Konfigurera aviseringar för händelse-ID 74 (och dess motsvarighet för lyckade händelse-ID 75) i din SIEM och kontrollera regelbundet att alla konfigurerade CDP-platser, inte bara den primära, är nåbara och aktuella.

Bete sig händelse-ID 74 annorlunda i miljöer med flera webbplatser eller flera CA-certifieringar?

Ja. Ett CDP- eller nätverksproblem som påverkar en webbplats domänkontrollanter kanske inte påverkar en annan, så miljöer med flera webbplatser bör kontrollera om CRL-publiceringen lyckades på varje webbplats separat snarare än att anta att en lösning på en plats täcker alla.

Vilket är det vanligaste misstaget organisationer gör när de felsöker händelse-ID 74?

Förutsatt att varje händelse har samma grundorsak. Felkoden i händelsemeddelandet (behörigheter kontra saknat objekt kontra ingen tydlig kod alls, vilket pekar på nätverksproblem) anger vilken av de tre vanliga orsakerna du faktiskt har att göra med, och att behandla dem omväxlande slösar bort felsökningstid.

Vad bör ingå i en återställningsplan innan CDP/AIA-behörigheter eller konfiguration ändras?

En säkerhetskopia av de aktuella ACL:erna och CDP-konfigurationen, en tydlig förteckning över exakt vad som ändrades och ett valideringssteg (en manuell certutil -crl publicera) körs omedelbart efter ändringen så att eventuella nya problem upptäcks innan de förvärras av det ursprungliga problemet.