Servicedesken får tre opkald på en halv time fra brugere, der ikke kan logge ind, og der er en test i gang. Låste konti er en af de mest synlige måder, en penetrationstest kan påvirke hverdagen på, og de kan ramme mere end brugerne, hvis en tjenestekonto bliver låst. Svaret hviler på to dele: forebyggelse i aftalen og i jeres kendskab til egne låsepolitikker, og en håndtering, der er klar, før det sker. Microsoft beskriver i sin dokumentation af låsepolitikken i Windows, at en politik, der låser konti, skal ledsages af en proces for at låse dem op igen.
Hvorfor konti bliver låst
Kontolåsning er en beskyttelse. Efter et antal forkerte forsøg spærres kontoen i en periode, så ingen kan blive ved med at gætte. Den samme beskyttelse kan ramme den rigtige bruger, hvis forsøgene kommer fra en anden.
Under en test kan det ske på flere måder: testeren afprøver, om adgangskoder kan gættes, en testkonto bruges forkert, eller en tjeneste forsøger at logge ind igen og igen efter en ændring. Microsoft gør selv opmærksom på, at en låsepolitik kan misbruges til at låse alle konti, hvis en angriber kender kontonavnene. Det er netop derfor, at spørgsmålet skal afklares før testen og ikke under den.
Forebyggelse i aftalen
Det første skridt er at aftale, om testen må omfatte forsøg mod rigtige konti, og i givet fald hvordan. Det er en beslutning for opgavens ejer, men driften skal levere grundlaget.
- Hvilke konti · om forsøg kun må ske mod testkonti, mod en udvalgt gruppe eller mod alle brugere.
- Tempo · at testeren holder sig under jeres låsegrænse, så forsøg ikke udløser spærring.
- Undtagne konti · tjenestekonti, nødadgangskonti og konti til kritiske systemer, der ikke må låses. → Nødadgangskonti
- Tidspunkt · om den del af testen skal ligge, når servicedesken er bemandet.
- Stop · at testeren stopper med det samme, hvis kontaktpersonen melder om låste konti.
Testeren kan kun holde sig under grænsen, hvis grænsen er kendt. Driften skal derfor oplyse, hvordan jeres låsepolitikker er sat op, også selv om testen skal afprøve dem. Skriv aftalen ind i det materiale, servicedesken og vagten har, så de ved, hvornår den del af testen ligger, og hvilke konti den kan ramme.
Kend jeres egne låsepolitikker
Et miljø kan have mere end én låsepolitik, og det er ikke altid klart, hvilken der gælder hvor. Gennemgå dem før testen.
- Den lokale katalogtjeneste · grænse, varighed og hvornår tælleren nulstilles.
- Undtagelser · grupper eller konti med en anden politik end standarden. → Adgangskodepolitikken i Active Directory
- Cloudidentitet · Microsoft Entra ID har sin egen smarte låsning, som ifølge Microsoft forsøger at skelne mellem den rigtige bruger og ukendte kilder, men ikke garanterer, at den rigtige bruger aldrig bliver låst.
- Samspillet · i en hybrid opsætning skal politikkerne i skyen og lokalt passe sammen, så forsøg mod cloudlogin ikke låser de lokale konti. Microsoft beskriver, hvordan forholdet mellem de to bør være ved visse former for hybrid login. → Hybrid identitet
- Andre systemer · fjernadgang, forretningssystemer og webapplikationer kan have deres egne grænser.
Gennemgangen er nyttig i sig selv. Hvis ingen kan svare på, hvilken politik der gælder for en gruppe, er det en oplysning, der hører hjemme i jeres egen opfølgning.
Tjenestekonti er den store risiko
En låst bruger er en irritation. En låst tjenestekonto kan stoppe et system. Tjenester, der logger ind automatisk, opdager ikke selv, at kontoen er låst, og fejlen kan vise sig et helt andet sted, fx som en integration, der holder op med at sende data.
Lav en liste over tjenestekonti i de systemer, testen rører, og aftal, at de holdes uden for forsøg på at gætte adgangskoder. Er en tjenestekonto omfattet af en låsepolitik, er det værd at vide, uanset testen. Notér for hver konto, hvilket system der stopper, hvis den låses, og hvem der skal have besked. → Tjenestekonti
Når det sker: håndteringen
Selv med en god aftale kan konti blive låst. Håndteringen skal være kendt af servicedesken og kontaktpersonen, før testen begynder.
- Servicedesken genkender mønsteret · flere låste konti på kort tid i testperioden meldes til kontaktpersonen, ikke kun løst enkeltvis. → Servicedesken under testen
- Kontaktpersonen spørger testeren · om aktiviteten passer med det, testeren laver. Passer det, stopper testeren den del. Passer det ikke, behandles det som en mulig hændelse.
- Kontiene låses op · efter jeres normale procedure. Selvbetjening kan hjælpe, hvis den findes.
- Forløbet noteres · hvor mange konti, hvornår og hvordan det blev løst.
Lås ikke konti op i stor stil, før det er bekræftet, at det er testen, og hold kontaktpersonen orienteret om, hvor mange der stadig venter. Er det ikke testen, er en bølge af låste konti et tegn, der skal undersøges.
Efter testen
Gennemgå forløbet, når testen er slut. Hvor mange konti blev låst, hvilke systemer blev ramt, og hvor lang tid tog det at få brugerne i gang igen? Svarene siger noget om jeres egen evne til at håndtere en bølge af låste konti, uanset hvem der står bag.
Kontrollér samtidig, at ingen konti er blevet stående låst, og at testkonti, der blev låst undervejs, lukkes sammen med de øvrige. Har testen afsløret, at en tjenestekonto er omfattet af en låsepolitik, eller at politikkerne i skyen og lokalt ikke passer sammen, hører det med i listen over rettelser. → Oprydning efter testen
Det skal I lade være med
- At slå låsningen fra i testperioden. Så afprøves en anden opsætning end den, I har.
- At holde låsegrænsen hemmelig for testeren. Så kan testeren ikke undgå at ramme den.
- At glemme tjenestekontiene. De kan stoppe systemer, og ingen ringer til servicedesken om dem.
- At låse op i blinde. Bekræft først, at det er testen.
- At overse politikkerne i skyen. Lokal og cloud kan låse hver for sig.
Hvad kan og ikke kan konkluderes
At testen kunne låse konti, siger noget om, hvordan politikkerne virker, men det er ikke i sig selv et fund om svage adgangskoder. At ingen konti blev låst, betyder kun, at aftalen og tempoet holdt, ikke at politikkerne er gode. Er låsning af mange konti en risiko, I ikke har en plan for, er det værd at tage op uafhængigt af testen.
Tjekliste til låste konti
- ☐ Er det aftalt, om testen må omfatte forsøg mod rigtige konti?
- ☐ Kender testeren jeres låsegrænser?
- ☐ Er tjenestekonti og nødadgangskonti holdt uden for forsøgene?
- ☐ Er politikkerne lokalt og i skyen gennemgået?
- ☐ Ved servicedesken, at flere låste konti skal meldes til kontaktpersonen?
- ☐ Er der en procedure for at låse konti op?
Kilder
- Microsoft Learn: Account lockout threshold: låsegrænsen er en afvejning; politikken kan misbruges til at låse konti; en låsepolitik skal ledsages af en proces for oplåsning.
- Microsoft Learn: Smart lockout in Microsoft Entra ID: smart låsning skelner kendte og ukendte placeringer, garanterer ikke, at den rigtige bruger aldrig låses, og skal passe sammen med lokale politikker ved hybrid login.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Brugere under testen · Kontaktpersonen i IT under testen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
