Kerberos RC4 udfasning: undgå login-fejl og nedetid

Hvis I har on-premise eller hybrid Active Directory, kan en Microsoft-opdatering få ældre systemer til at miste login fra den ene dag til den anden. Det rammer typisk scannere, NAS, ældre ERP/integrationer og servicekonti, der stadig bruger svag kryptering (RC4). Resultatet er ikke “en sikkerhedsdetalje” – det er driftstop. Med en kort audit og en styret overgang til AES kan I undgå panik-fejlfinding i juli.

Key takeaways til Kerberos RC4 udfasning

• Kortlæg RC4-brug nu: Brug logs og/eller en audit til at finde de konti og enheder, der stadig bruger Active Directory RC4.
• Prioritér systemer med servicekonti: De skaber ofte “skjult” afhængighed og giver legacy IT systemer login fejl først.
• Test før I håndhæver: Lav et kontrolleret testvindue, så I kan udbedre uden nedetid i produktion.
• Skift til AES og ryd op: Planlæg Kerberos AES opdatering og oprydning i msDS-SupportedEncryptionTypes for at undgå overraskelser.
• Knyt det til NIS2: RC4 er svag kryptografi og passer dårligt til NIS2 krypteringskrav. Dokumentér beslutninger og ændringer.

Hvorfor udfaser Microsoft RC4 – og hvad betyder det for jer?

RC4 er en ældre krypteringsmetode, som længe har været vurderet som svag. Microsoft fjerner den i Kerberos, fordi svag kryptering gør det lettere for angribere at misbruge legitimationsoplysninger – bl.a. via kerberoasting, hvor billetter kan knækkes offline (CrowdStrike, u.å.). NIST forbyder også RC4 i moderne sammenhænge (NIST SP 800-52r2).

For jer handler det om to ting:

1. Drift: Når RC4 ikke længere accepteres, kan enkelte systemer pludselig ikke autentificere mod jeres AD.
2. Compliance og risiko: Hvis jeres identitetsfundament (AD) hviler på svag kryptering, er det svært at argumentere for “stærk kryptografi” og moden sikkerhedspraksis (CISA, u.å.).

Hvornår rammer det? Microsofts tidslinje I skal styre efter

Microsoft har kommunikeret en 3-faset udrulning (Microsoft Tech Community, 2026):

• Januar 2026 (Audit Phase): Nye event logs (Event ID 201–209) til at spore RC4-brug. Intet bliver blokeret endnu.
• April 2026 (Soft Enforcement): RC4 slås fra som standard. I kan midlertidigt rulle tilbage (registry), hvis noget knækker.
• Juli 2026 (Hard Enforcement): RC4 blokeres permanent. Ingen rollback.

Teknisk ændrer Domain Controllers standard til AES (Microsoft Learn, 2026). Konti/systemer, der ikke kan forhandle AES, ender som login-fejl.

Hvilke systemer knækker typisk først, når RC4 bliver væk?

Det er sjældent “brugernes laptops”. Det er det udstyr og de integrationer, der har stået uændret i årevis:

• NAS og filplatforme: Ældre NAS/SMB-implementeringer kan miste AD-tilknytning uden AES-understøttelse (NetApp KB, 2026).
• Scannere/MFP’er: Enheder der gemmer scan-to-folder eller mail-relay med ældre auth-stakke.
• Ældre ERP/produktionsintegrationer: Især hvor en tredjepartsconnector kører på gammel Windows eller hardkoder RC4 (National CIO Review, 2025).
• Servicekonti: Konti med uklare indstillinger eller “blanke” krypteringsfelter kan trigge nedbrud (VisuaFusion, 2026).
• Hybrid miljøer med Entra ID Connect: Jeres Microsoft 365 kan være “fin”, men kompromitteres on-prem AD, kan det påvirke hele identitetskæden (hybrid-paradokset).

Micro “Før → Efter” #1 (drift)

Før: En scanner sender til en netværksmappe via en gammel servicekonto. Fejler først, når Microsoft håndhæver.

Efter: I finder afhængigheden i audit, opdaterer enhed/firmware eller skifter metode, og tester i et planlagt vindue. Resultat: ingen driftsstop i produktionen ved juli-håndhævelse.

Tjekliste: Sådan finder I RC4-afhængigheder før de bliver til nedetid

Brug tjeklisten som beslutningsværktøj. Målet er at komme fra “vi tror det går” til en liste over konkrete systemer og ejere.

Check	Hvad I kigger efter	Beslutningsregel
1) Saml hændelser fra domænecontrollere	Event ID 201–209 (audit) samt Kerberos-hændelser som 4769, hvor RC4 ofte vises med krypteringstype 0x17 (AdminDroid, 2026)	Hvis en konto/enhed optræder i logs med RC4, skal den have en ejer og en plan.
2) Find “hårde” afhængigheder	NAS, scannere, gamle Windows-servere, appliance-bokse, ERP-connectors	Hvis leverandøren ikke kan bekræfte AES-understøttelse, planlæg opgradering/udskiftning eller isolér.
3) Gennemgå servicekonti	Konti med gamle passwordpolitikker, “blanke”/uklare krypteringsindstillinger, høj privilegiering	Servicekonti med høj privilegiering skal enten moderniseres (AES) eller erstattes (gMSA/managed identities hvor muligt).
4) Kortlæg krypteringsindstillinger i AD	msDS-SupportedEncryptionTypes på brugere/computere/servicekonti	Hvis kontoen kun accepterer RC4, planlæg ændring + test. Undgå “masseændring” uden pilot.
5) Test “soft enforcement” scenarier	Staging/afgrænset pilot: udvalgte DC’er/OU’er, kritiske flows (print/scan/fil/ERP)	Hvis en kritisk integration fejler, stop udrulning og udbedr før næste bølge.
6) Dokumentér til compliance	Hvad blev fundet, hvad blev ændret, hvornår blev det testet, og hvem accepterede evt. risici	Hvis I ikke kan dokumentere det, kan I heller ikke forsvare det ved audit/NIS2-spørgsmål.

Micro “Før → Efter” #2 (sikkerhed/compliance)

Før: “AD kører bare” uden løbende kontrol af svag kryptografi, og servicekonti lever i årevis.

Efter: Fast audit-cyklus: log-indsamling, ændringskontrol og dokumentation. Resultat: færre blinde vinkler og bedre evidens ift. NIS2 og leverandørkrav.

Sådan vælger I mellem opgradering, udskiftning eller isolation

Når I har listen over afhængigheder, skal I vælge en realistisk løsning pr. system. Brug denne beslutningsregel:

1. Opgradering hvis leverandøren kan dokumentere AES-understøttelse (firmware/software) og I kan teste i god tid.
2. Udskiftning hvis systemet er fastlåst til RC4 eller er ude af support. “Microsoft RC4 end of life” er ofte det, der afslører, at IT-gælden er blevet for dyr.
3. Isolation kun som kortvarig bro: segmentér netværk, begræns adgang, stram konto-rettigheder og logning. Isolation er en nødplan, ikke en sluttilstand.

Hvis I kører hybrid identitet, så behandl on-prem AD som en sikkerhedskritisk komponent for hele jeres Microsoft 365. Planlæg ændringer sammen med jeres Microsoft 365– og Azure-setup, så I undgår at løse ét problem og skabe et andet.

Fejl der koster jer mest i juli: det vi typisk ser i SMB-miljøer

• Ingen ejer på “små” systemer: Scanner/NAS står uden ansvarlig, så ingen tager beslutningen om opgradering.
• Masseændringer uden pilot: Ændringer i krypteringstyper udrulles bredt uden test – og rammer uforudsete integrationer.
• Servicekonti med for høje rettigheder: Når noget fejler, gives der “bare flere rettigheder”. Det øger både risiko og oprydningsomkostning.
• Ingen log-opsamling: I ser først problemet, når brugerne ringer. Med logs kan I finde det i januar/april.

FAQ: Kerberos RC4 udfasning i Active Directory

Hvad er Kerberos RC4 udfasning helt kort?

Det er Microsofts stop for den gamle RC4-kryptering i Kerberos i Active Directory. Når RC4 ikke længere accepteres, kan systemer, der kun kan bruge RC4, ikke logge på.

Hvilken deadline er den kritiske?

Juli 2026 er “hard enforcement”, hvor RC4 blokeres permanent. April 2026 er jeres bedste testperiode, fordi RC4 her slås fra som standard, men kan rulles tilbage midlertidigt ved driftkritiske fejl (Microsoft Tech Community, 2026).

Hvordan finder vi ud af, om vi bruger RC4?

Start med domænecontroller-logs fra audit-fasen (Event ID 201–209). Kig også efter Kerberos-hændelser som Event ID 4769, hvor RC4 ofte ses som krypteringstype 0x17 (AdminDroid, 2026). Alt der dukker op, skal have en ejer og en plan.

Hvilke “usynlige” enheder er mest risikable?

NAS, scannere/MFP’er og appliances, der er joinet til domænet eller bruger en servicekonto. Netop de bliver sjældent patch’et og har ofte gammel SMB/auth-understøttelse (NetApp KB, 2026).

Er Microsoft 365 sikker, hvis vores on-prem AD ikke er det?

Ikke nødvendigvis. I hybride miljøer kan et kompromis eller svagheder i on-prem AD påvirke hele identitetskæden (konti, grupper, synk). Behandl derfor AD on-premise sikkerhed som en del af jeres M365-sikkerhed.

Hvordan hænger det sammen med NIS2 krypteringskrav?

NIS2 lægger pres på stærk kryptografi og moden risikostyring. RC4 er bredt betragtet som svag kryptografi (CISA, u.å.; NIST SP 800-52r2). En praktisk tommelfingerregel: Hvis I ikke kan dokumentere, at kritiske autentificeringsflows bruger moderne kryptering, bør I behandle det som et compliance-gap.

Skal vi “bare” deaktivere RC4 i Active Directory nu?

Nej – ikke som et enkelt klik. Slå først fast hvem der bruger RC4 (logs/audit), og test derefter i afgrænsede bølger. Målet er at nå “RC4 kan ikke bruges” uden at jeres forretning opdager det.

Sådan kommer I i mål uden nedetid (konkrete skridt)

1. Indsaml logs fra DC’er og lav en første liste over konti/enheder med RC4-hits (inkl. event-kilder og tidspunkter).
2. Udpeg en ejer pr. system (scanner, NAS, ERP-connector, filservice) og aftal en deadline for beslutning: opgrader/udskift/isolér.
3. Gennemgå servicekonti: formål, rettigheder, passwordpraksis og krypteringsindstillinger (msDS-SupportedEncryptionTypes).
4. Planlæg et pilotforløb i et afgrænset scope og test alle kritiske flows (login, filadgang, print/scan, integrationer).
5. Udrul i bølger med ændringslog og rollback-plan til soft enforcement-vinduet – og fjern midlertidige undtagelser igen.
6. Dokumentér til compliance (fund, ændringer, testresultater, accepterede risici) og gem det som del af jeres NIS2/ISMS-materiale.

Kilder: Microsoft Tech Community (2026), Microsoft Learn (2026), AdminDroid (2026), CISA (u.å.), NetApp Knowledge Base (2026), National CIO Review (2025), VisuaFusion (2026), CrowdStrike (u.å.), NIST SP 800-52r2.