AD-herding

Domain Administrator kontoen er Break Glass konto

Bakgrunn

Den innebyggde domeneadministrator-kontoen "administrator" skal normalt aldri benyttes til pålogging.

Den skal kun benyttes i et "Break Glass"-tilfelle, for å unngå at passord og Tickets for denne kontoen spres.

Risiko ved bruk/mangel: Middels

Domenekontoen "administrator" er innebygged i alle Active Directory, og er derfor den første kontoen angripere søker etter når de kommer inn på en klient eller server. Det er derfor anbefalt å aldri logge inn på noe med kontoen "administrator", men å ha denne kontoen reservert for katastrofer og at den kun benyttes i et Break Glass senario. Det er også anbefalt å sette opp alarmer som utløses dersom kontoen benyttes, slik som for andre Break Glass kontoer.

Konsekvens for brukere: Usannsynlig

Dette er kun en prosedyre endring og ingen teknisk endring.

Kompleksitet på endringen: Lav (Prosedyre)

Teknisk beskrivelse
Bytt passord på administrator kontoen og lagre det på en trygg måte.
Informer alle om at denne kontoen ikke skal benyttes mere, og at det fra nå av er en Break Glass konto.
Inkluder administrator kontoen i eksisterende Break Glass alarmer.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-d--securing-built-in-administrator-accounts-in-active-directory

Disable Computer objects som er End Of Life (EOL)

Bakgrunn

PCer og servere vil ikke lenger få sikkerhetsoppdateringer når de er "End of Life", eller EOL.

Risiko ved bruk: Høy

Angripere benytter alltid kjente feil på EOL systemer til å ta første steget inn i systemene.

Konsekvens for brukere: Sannsynlig

Normalt står gamle systemer fortsatt aktive fordi de kjører noe som fortsatt er nødvendig å bruke. Det er viktig å starte overgangen til moderne systemer så fort som mulig, fordi jo eldre slike systemer blir desto større sikkerhetsrisiko utgjør de for resten av systemene.

Kompleksitet på endringen: Høy
Ofte vil de gamle systemene være vanskelige å oppgradere. Typisk har leverandøren forsvunnet for lenge siden og det er ikke mulig å få tak i programvaren lengre for å sette opp på ny server.

Nedenfor har vi lagt med link både til Microsoft sin offisielle liste, og også til en mye mere oversiktlig liste fra Internet som viser oppdatert info både for servere og klienter.

Konklusjon

Til tross for utfordringene med konsekvenser for brukerne og høy kompleksistet anbefaler vi på det sterkeste å avvikle alle systemer som er EOL så snart som mulig. Hvis man utfører alle de andre sikkerhetstiltakene, men fortsatt har EOL systemer, så vil hackeren benytte disse for å få tilgang.

Artikler:

Microsoft Doc: https://learn.microsoft.com/en-us/services-hub/unified/health/remediation-steps-ad/upgrade-computers-running-an-unsupported-operating-system

Microsoft Lifecycle: https://learn.microsoft.com/en-us/lifecycle/products/

Internet Server: https://endoflife.date/windows-server

Internet Clients: https://endoflife.date/windows

Windows LAPS

Windows LAPS (Local Administrator Password Solution) er en tjeneste som automatisk skifter passord på Builtin Local Administrator kontoen på alle servere og klienter. Windows LAPS kom i 11 april 2023 og erstatter den tidligere løsningen som nå heter "Legacy Microsoft LAPS".

Windows LAPS er innebygd i operativsystemet og konfigureres normalt i Intune, mens Microsoft LAPS måtte installeres på alle klienter og ble konfigurert med GPO.

Windows LAPS krever at alle DCer er på minst Windows Server 2019, og klientene må minst være Windows 10 oppdatert til 11 April 2023 .

Teknisk beskrivelse av LAPS konfigurering

Utvid skjema med:

Update-LapsADSchema

Gi Computers rettighet til å oppdatere passordet sitt i AD:

Set-LapsADComputerSelfPermission -Identity "OU=YourComputerContainer,DC=yourdomain,DC=no"

Nedenfor beskrives to måter å konfigurere LAPS på, avhengig av om dere benytter kun AD, eller om dere benytter Intune.

Konfigurerering av LAPS hvis du ikke har Intune og klientene ligger i on-prem AD:

Åpne Group Policy Management Tool og enten lag en ny policy eller bruk en eksisterende. Åpne følgende setting:

Computer Configuration > Policies > Administrative Templates > System > LAPS

Hvis du ikke finner LAPS under System, kopier ADMX filene fra

C:\Windows\PolicyDefinitions

til central store

:\\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions

Sett Scope til gruppen med enheter som skal ha Windows LAPS (test gjerne med en liten gruppe først)

Vår anbefalte LAPS konfigurasjon for AD:

• Configure password backup directory = Active Directory
• Password Settings = Enable
• Name of administrator account to manage = [Blank verdi for Administrator, men oppdater hvis dere har endret navn på lokal administrator]

Vurder om dere ønsker å sette noen av de andre innstillingene.

For å raskt oppdatere en enhet under testing av LAPS, kjør:

Invoke-LapsPolicyProcessing

Konfigurerering av LAPS hvis du har Intune og klientene ligger i Azure AD/Entra ID:

Åpne portal.azure.com og naviger til

Microsoft Entra ID > Devices > Device Settings

Sett følgende setting:

Enable Microsoft Entra Local Administrator Password Solution (LAPS) = Yes

Åpne intune.microsoft.com og naviger til

Endpoint Security > Account Protection

Create a new policy:

• Platform = Windows
• Profile = Local admin password solution (Windows LAPS)
• Name = [ønsket navn]

Vår anbefalte LAPS konfigurasjon for Intune:

• Backup Directory > Backup the password to Azure AD only
• Password Age Days > 30
• Administrator Account Name > Endre kun hvis Administrator er renamet
• Password Complexity > Passphrase (long words)
• Passphrase Length > 3 (tre ord)
• Password Length > 8 (tre ord på åtte tegn hver gir 24 tegn)
• Post Authentication Actions > Reset password and log off the managed account
• Post Authentication Reset Delay > 1
• Scope Tags > Sett som ønsket eller skip
• Assignments > Legg til gruppen med devices som skal ha Windows LAPS (test gjerne med en liten gruppe først)

Det er mange steder å se passordet:

• portal.azure.com > Microsoft Entra ID > Devices > Local Administrator Password Recovery
• portal.azure.com > Microsoft Entra ID > Devices > All Devices > [device] > Local administrator Password Recovery
• intune.microsoft.com > Devices > All Devices > [device] > Local Admin Password

Det er også mulig å bruke Powershell og Microsoft Graph, men disse krever litt konfigurering som vi ikke tar med her.

Konfigurerering av LAPS hvis du har både Intune og Azure AD/Entra ID:

Vi anbefaler å kun konfigurere Intune og sende passordene til Azure AD.
Det er også mulig å ha f.eks klienter i Intune gruppen og serverene i AD gruppen. Viktig at ikke både Intune og GPO konfigurer samme enhet.

Artikler

Microsoft doc: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview
Microsoft installering: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-windows-server-active-directory

Internet artikkel: https://lazyadmin.nl/it/windows-laps/

Det er helt normalt at det ved en Pentest blir avdekket passord. Vi anbefaler følgende for å løse denne problemstillingen.

Endre passordpolicy

Passord policyen må sikre at alle nye passord oppfyller anbefalte krav:
Minimum14 tegn, fjerne kompleksitetskrav, ikke utløpsdato

NHN Passordanbefalinger: https://www.nhn.no/tjenester/helsecert/anbefalte-sikkerhetstiltak/autentisering

Aktiver "Password Protection for Windows Server Active Directory" i Entra ID.

Alle passord vil da sjekkes av Entra ID om de er gode. Entra ID sjekker veldig mange ting som f.eks om brukernavnet er del av passord, om passordet er et typisk passord som mange bruker, om passordet allerede er kjent i Brute Force angrep, osv

Viktig å starte med Audit-modus slik at man får verifisert at sjekken fungerer som forventet.

Beskrivelse av Entra ID Password Protection: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad

OnPrem Password Protection Microsoft doc: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-password-ban-bad-on-premises-deploy

Bytt ALLE passord på absolutt alle kontoer

Når Passordpolicy og Protection er på plass, så må man skifte alle passordene på alle brukerne. Det er først når passordene byttes at den nye policyen og Entra ID sjekken aktiveres.

Det er som regel veldig greit å bytte passord på alle normale brukere, mens det vanligvis er mye arbeid å bytte passord på alle servicekontoer og systembrukere. Man bør benytte muligheten til å dokumentere alle spesielle kontoer mens man bytter passord på dem, slik at man har bedre kontroll til senere.

Deaktiver kontoer som ikke er i bruk

Kontoer som ikke har logget inn på lenge må deaktiveres. Dette gjelder spesielt kontoer som aldri har vært logget inn før, da disse ikke har fått aktivert MFA og kun beskyttes av passord.

Sikre SPN kontoer

Bakgrunn

SPN (Service Principal Name) er en unik identifikasjon på en service som benyttes av autentiseringstjenesten Kerberos.

Risiko

SPN skal kun benyttes på kontoer med reelt behov for SPN og slike kontoer skal ikke ha noen administrative rettigheter. Hackerverktøy vil alltid hente ut alle kontoer med SPN og forsøke å knekke passordet på disse, siden kontoer med SPN ofte har administrative rettigheter i tillegg. Denne metoden heter Kerberoasting.

Konsekvens for brukere: Usannsynlig

Brukere blir ikke direkte påvirket om man fjerner SPN, men applikasjonene som benytter SPN kan feile dersom SPN var i bruk. Fjerning av administrative rettigheter vil kun påvirke administratorerer dersom rettigheten var satt ut fra et administrativt behov. Dersom det var en applikasjon som trengte rettigheten kan applikasjonen feile når rettighetene fjernes.

Kompleksitet på endringen: Middels (Powershell, ADUC)

Teknisk beskrivelse

Start med å liste ut alle SPN kontoer:
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName | Select-Object name, samaccountname, ServicePrincipalName

Gå igjennom alle kontoene og sjekk om SPN er i bruk. Normalt slettes ikke SPN når en tjeneste avvikles, så det er helt normalt at det finnes kontoer med SPN hvor applikasjonen som krevde SPN ikke lengre er i bruk. Kontoer som ikke er i bruk bør enten slettes helt, eller at SPN slettes fra kontoen i tillegg til at kontoen deaktiveres.

Gå så igjennom resterende kontoer etter ryddingen over, og sjekk om noen kontoer med SPN har noen administrative rettigheter. Slike rettigheter bør absolutt fjernes, men det må selvfølgelig avveies om dette kan gi problemer med tjenesten kontoen tilhører. Dersom hverken SPN eller administrative rettigheter kan fjernes bør man starte et arbeid med å få endret hvordan denne tjenesten er satt opp.

Microsoft doc: https://learn.microsoft.com/en-us/windows/win32/ad/service-principal-names

Internet artikkel: https://www.semperis.com/blog/how-to-defend-against-spn-scanning/

Admins medlem av Protected Users

Bakgrunn

Protected Users gruppen er en spesiell gruppe i Active Directory som aktiverer mange sikkerhetsinnstillinger. Alle privilegerte brukere, altså alle administratorkontoer, må være medlem av Protected Users group.

Protected Users group kom med Windows 2012 R2, og sikrer følgende:

• Passord lagres aldri i klartekst (CredSSP, Digest, etc)

• NTLM er deaktivert

• Kun Kerberos AES kryptering, ingen DES/RC4

• Cached Credentials er avslått

Risiko: Middels

Protected Users group innfører alle de mest kritiske sikkerhetstiltakene som Microsoft anbefaler og gir på en veldig enkel og rask måte massevis av sikkerhet. Uten denne må man implementere hvert enkelt tiltak. Hvis administratorer ikke ligger i Protected Users group vil angripere alltid sjekke om de kommer inn med noen av metodene som Protected Users group beskytter mot.

Konsekvens for brukere: Usannsynlig

Endringen gjelder kun administratorer og påvirker ikke brukere.

Kjente konsekvenser for administratorer er:

• RDP kan ikke gjøres mot IP nummer lengre (IP nummer støttes ikke av Kerberos)

• Brukernavn kan ikke lengre skrives som domain\username men må skrives enten bare som username eller som UPN: username@fqdndomainname

• RDP sesjoner varer bare 4 timer (Kerberos TGTs er maksimalt på 4t og fornyes ikke)

• Ingen autentisering med NTLM/DES/RC4 lengre som kan føre til at man må oppdatere noen systemer.

• Administratorkontoer som ikke har endret passord siden Active Directory ble oppgradert til Windows 2008, vil ikke få logget inn før passordet resettes.

Kompleksitet på endringen: Lav (Gruppemedlemsskap)

Teknisk beskrivelse
Legg alle administratorer inn i "Protected Users" gruppen.

Vi anbefaler å starte forsiktig med å først legge inn enkeltkontoer i Protected Users, og sjekke om det har noen påvirkning på de når de benyttes i daglig arbeid. Når man føler at man lenge nok har testet mange nok enkelt kontoer kan man legge inn hele "Domain Admins" gruppen og fjerne enkeltkontoene. Slik fortsetter man å legge inn kontoer til man til slutt har fått alle administratorerer inn som medlem av Protected Users.

Artikler

Microsoft Doc 1: https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
Microsoft Doc 2: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/how-to-configure-protected-accounts#BKMK_AddtoProtectedUsers

Internet artikkel: https://4sysops.com/archives/secure-privileged-active-directory-accounts-using-the-protected-users-group/