Basisherding

Disable NetBios protokollen

Bakgrunn

NetBios gjør hovedsakelig navneoppslag, slik som DNS gjør idag.

NetBios kom i 1983 og ble vanlig fra 1987 med NBT (Netbios over TCP/IP). Den er dessverre usikker By Design, og ble legacy fra Windows 2000, da DNS tok over alt av navneoppslag.

Risiko hvis man ikke fikser: Høy

Angripere kan utnytte NetBios med grunnleggende gratis-verktøy.

Konsekvens for brukere: Usannsynlig

Dersom dere har noe som benytter kun NetBios vil det slutte å virke når NetBios Disables. Siden NetBios er så gammelt vurderer vi det som usannsynlig. Det er dessverre ingen enkel måte å proaktivt finne ut om noe vil slutte å virke. Dersom dere ønsker å lytte på nettet for å forsøke å finne ut av dette så har vi inkludert en link til Wireshark.

Kompleksitet på endringen: Lav (GPO)

Teknisk beskrivelse av GPO
Benytt eksisterende GPO for Herding, eller opprett ny. Settes for alle Computer objects.

Naviger til :
Computer Configuration > Policies > Windows Settings > Scripts > Startup
Opprett et skript med navn: DisableNETBIOS.ps1

Skriptet skal inneholde følgende kommando:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\netbt\Parameters\interfaces\tcpip_*' -name NetBiosOptions -value 2 -Verbose

Artikler
Microsoft Doc: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/1430ebe9-2ad0-4763-b14f-c720338e0482

Internet artikkel: https://woshub.com/how-to-disable-netbios-over-tcpip-and-llmnr-using-gpo/

Wireshark: https://medium.com/@4ghora/wireshark-traffic-analysis-d934fde9a6d2

Disable LLMNR protokollen

Bakgrunn

LLMNR erstattet i 2007 NetBios og er en failovermetode for navneoppslag når DNS ikke virker. I dagens IT miljøer må alltid DNS virke, så det er ikke noe behov for failover for DNS. LLMNR er Legacy fra 2022.

Risiko hvis man ikke fikser: Høy

Angripere kan utnytte LLMNR med grunnleggende gratis-verktøy

Konsekvens for brukere: Usannsynlig

Dersom dere har noe som benytter kun LLMNR vil det slutte å virke når LLMNR Disables. Siden LLMNR er så gammelt vurderer vi det som usannsynlig. Det er dessverre ingen enkel måte å proaktivt finne ut om noe vil slutte å virke. Dersom dere ønsker å lytte på nettet for å forsøke å finne ut av om LLMNR er I bruk så har vi inkludert en link til informasjon om hvordan benytte Wireshark for dette.

Kompleksitet på endringen: Lav (GPO)

Teknisk beskrivelse av GPO
Benytt eksisterende GPO for Herding, eller opprett ny. Settes for alle Computer objects.

Naviger til : Computer Configuration > Admin Templates > Network > DNS Client
Sett "Turn Off Multicast name Resolution" = Enabled

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-llmnrp/6806998e-034d-4c39-8398-5af8bfd52d7e

Internet artikkel: https://woshub.com/how-to-disable-netbios-over-tcpip-and-llmnr-using-gpo/

Wireshark: https://en.wikiversity.org/wiki/Wireshark/LLMNR

Disable LM og NLTMv1

Bakgrunn

LM, NTLM og NTLMv2 er autentiseringsprotokoller som brukes når Kerberos-autentisering ikke er tilgjengelig.

LM kom i 1987, NTLM kom i 1993, NTLMv2 kom i 1998. LM og NTLM har altså vært legacy i over 25 år.

Risiko hvis man ikke fikser: Høy

Angripere kan utnytte LM og NTLMv1 med grunnleggende gratis-verktøy

Konsekvens for brukere: Muligens

Dersom dere har utstyr eller tjenester som er avhengig av NTLMv1 vil dette slutte å virke når man skrur av NTLMv1. Typiske eksempler er printere/scannere og veldig gamle Windows-servere som må omkonfigureres til å være kompatible med bedre autentisering. For å kjøre innføringen mer kontrollert bør man aktivere GPOen for klienter/servere i batcher først, og starte med å sette dem på nivå 3 (Se internet artikkel nedenfor). Når alle klienter har kjørt på nivå 3 en stund setter man DCene på nivå 3. Til slutt setter man så DCene på nivå 5.

NB: Denne settingen tatoveres i Windows, så man kan ikke slette GPOen for å fjerne settingen på klienter/servere. Dersom noe feiler må man manuelt slette innstillingen fra klienter/servere.

Kompleksitet på endringen: Middels (Tatovert GPO)

Teknisk beskrivelse av GPO
Benytt eksisterende GPO for Herding, eller opprett ny. Settes for DCer.

Naviger til:
Computer Configuration > Policies > Windows Settings > Local Policies/Security Options > Network security

Sett følgende setting:
LAN Manager authentication level = Send NTLMv2 response only. Refuse LM & NTLM

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/windows/win32/secauthn/microsoft-ntlm

Artikkel med mer grundigere informasjon om NTLM: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-1-%E2%80%93-disabling-ntlmv1/3934787

Enforce LDAP Signing

Bakgrunn

LDAP Signing gjør at pakker er signerte og derfor ikke kan endres på veien.

LDAP signing kom i 2003, og i 2019 ble hacking av usignerte pakker inkludert i hackerverktøyene.

Risisko om man ikke fikser: Høy

Angripere utnytter manglende LDAP Signing med grunnleggende gratis-verktøy

Konsekvens for brukere: Usannsynlig
Siden LDAP signing er støttet siden 2003, så er det er usannsynlig at noe skal få problemer med at pakkene blir signert. Microsoft har en artikkel for hvordan man kan verifisere om noe vil bli påvirket av endringen.

Kompleksitet på endringen: Lav (GPO)

Teknisk beskrivelse av GPO
Benytt eksisterende GPO for Herding, eller opprett ny.
Det er forskjellig GPO setting for DCer og for andre servere.

For DC

Naviger til:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options

Sett følgende setting:
Domain Controller: LDAP server signing requirements = Require Signing

For non-DC

Naviger til:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options

Sett følgende setting:
Domain Controller: Network security: LDAP client signing requirements = Require Signing

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server

Internet artikkel: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-3-%E2%80%93-enforcing-ldap-signing/4066233

Verify support for LDAP Signing: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server#how-to-discover-clients-that-do-not-use-the-require-signing-option

Enforce Channel Binding

Bakgrunn

LDAP Channel Binding sikrer LDAP kommunikasjon, selv om en kommunikasjonskanalen blir brutt og restartet.

LDAP Channel Binding kom i RFC5056 i 2007, men ble ikke støttet av Microsoft før i 2019. Støtte ble da inkludert i Windows Update slik at alt som ikke er End Of Life fikk støtte for det.

Risiko om man ikke fikser: Høy

Angripere utnytter manglende LDAP Channel Binding med grunnleggende gratis-verktøy

Konsekvens for brukere: Usannsynlig

LDAP Channel Binding er støttet på Windows7, Windows Server 2008 R2 og alt nyere. Eldre systemer enn disse vil ikke klare å kommunisere med AD lengre etter at LDAP Channel Binding er aktivert. Internet artikkelen nedenfor forklarer hvordan man kan sjekke proaktivt om noe utstyr vil få problemer med Channel Binding.

Kompleksitet på endringen: Lav (GPO)

Teknisk beskrivelse av GPO
Benytt eksisterende GPO for Herding, eller opprett ny. Settes for DCer.

Naviger til:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Sett følgende setting:
Domain controller: LDAP server channel binding token requirements = Always

Artikler

Microsoft Doc: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-5-%E2%80%93-enforcing-ldap-channel-binding/4235497

Microsoft KB: https://support.microsoft.com/en-us/topic/2020-2023-and-2024-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a

Internet artikkel: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-5-%E2%80%93-enforcing-ldap-channel-binding/4235497

Enforce SMB Signing

Bakgrunn

SMB Signing gjør at pakker er signerte og derfor ikke kan endres på veien.

SMB Signing kom i 1996, og har vært anbefalt å benytte siden da.

Risiko om man ikke fikser: Høy

Angripere utnytter manglende SMB Signing til å utføre et standard NTLM Replay angrep.

Konsekvens for brukere: Usannsynlig

Siden SMB Signing er støttet siden 1996, så er det er usannsynlig at noe skal få problemer med at pakkene blir signert. For å sjekke om man har noe som ikke støtter SMB Signing må man først oppgradere alle DCer til 2025. Se beskrivelse i Internet artikkelen nedenfor.

Kompleksitet på endringen: Lav (GPO)

Teknisk beskrivelse av GPO
Benytt eksisterende GPO for Herding, eller opprett ny.
Det er forskjellig GPO setting for DCer og for andre servere.

For DC

Naviger til:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies

Sett følgende setting:
Security Options = Microsoft network server: Digitally sign communications (always)

For non-DC

Naviger til:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies

Sett følgende setting:
Security Options = Microsoft client server: Digitally sign communications (always)

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/overview-server-message-block-signing

Internet artikkel: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-6-%E2%80%93-enforcing-smb-signing/4272168

Enforce Kerberos armoring

Bakgrunn

Kerberos Armoring krypterer Kerberos trafikken, og uten den så går trafikken ukryptert.

Kerberos Armoring kom i 2012, og har vært anbefalt å benytte siden da.

Risiko om man ikke fikser: Høy

Angripere utnytter manglende Kerberos Armoring for å utføre standard Kerberoasting angrep.

Konsekvens for brukere: Usannsynlig

Dersom det er noe som ikke støtter Kerberos Armoring, så vil det slutte å virke når det slås på. Siden Kerberos Armoring kom med Windows Server 2012, så er det usannsynlig at det blir noen problemer. Det er anbefalt å starte med klientene, for å sikre at de har Kerberos Armoring, før man så krever det på DCene. Det vil logges hvis noe feiler fordi det ikke støtter Kerberos Armoring, se internet artikkel nedenfor.

Kompleksitet på endringen: Lav (GPO)

Teknisk beskrivelse av GPO
Benytt eksisterende GPO for Herding, eller opprett ny.

Settes først for non-DC og deretter for DCer.

For non-DC

Naviger til:
Computer Configuration > Policies > Administrative Templates > System > Kerberos

Sett følgende setting:
Kerberos client support for claims, compound authentication and Kerberos armoring = Enabled

For DC

Naviger til:
Computer Configuration > Policies > Administrative Templates > System > KDC

Sett følgende setting:
KDC support for claims, compound authentication, and Kerberos armoring = Fail unarmored authentication requests

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831747(v=ws.11)#support-for-claims-compound-authentication-and-kerberos-armoring

Internet artikkel: https://www.hub.trimarcsecurity.com/post/securing-the-chink-in-kerberos-armor-fast-understanding-the-need-for-kerberos-armoring

Enforce Kerberos AES

Bakgrunn

Kerberos er en autentiseringsprotokoll i Windows Active Directory.

Kerberos kom i 1989 og har vært brukt av Microsoft siden 2000. Kerberos ble da kryptert med DES og RC4, men begge disse kan nå dekrypteres. Kerberos kom derfor med AES kryptering i 2008, og de tidligere protokollene skal ikke lengre brukes.

Risiko om man ikke fikser: Høy

Angripere utnytter DES og RC4 kryptering til å kjøre standard Kerberoasting angrep da disse protokollene kan dekrypteres raskt.

Konsekvens for brukere: Usannsynlig

Dersom dere har noe som kun kan kommunisere på DES eller RC4, så vil det slutte å virke når kun AES blir tillatt. Siden AES kom allerede i 2008, så er det usannsynlig at noe krever DES eller RC4 kryptering. Internet artikkelen nedenfor har mye info om hvordan man kan sjekke om noe benytter RC4.

Kompleksitet på endringen: Lav (GPO)

Teknisk beskrivelse av GPO
Benytt eksisterende GPO for Herding, eller opprett ny. Settes for alle.

Naviger til:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Other

Sett "Network security: Configure encryption types allowed for Kerberos" til:
DES_CBC_CRC = Disabled
DES_CBC_MD5 = Disabled
RC4_HMAC_MD5 = Disabled
AES128_HMAC_SHA1 = Enabled
AES256_HMAC_SHA1 = Enabled
Future encryption types = Enabled

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos

Internet artikkel: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-4-%E2%80%93-enforcing-aes-for-kerberos/4114965

Kerberos Encryption Types explained: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/decrypting-the-selection-of-supported-kerberos-encryption-types/1628797

Disable Kerberos DES

Bakgrunn

Kerberos DES er en krypteringsmetode for passord/tickets, som i dag lett kan dekrypteres og må dermed ikke benyttes. Keberos Armoring disabler DES på alle enheter, men det er viktig å også disable DES på selve brukerobjektene.

DES-kryptering ble legacy i 2008.

Risiko ved bruk: Høy

Angripere dekrypterer DES tickets raskt.

Konsekvens for brukere: Usannsynlig

Kerberos AES kom allerede i 2008, så det er usannsynlig at noe fortsatt krever DES. Vi har imidlertid opplevd i noen få tilfeller at spesielle servicekontoer har gitt applikasjonstrøbbel for eldre applikasjoner etter endringen, så det er viktig å fange opp feilmeldinger i etterkant av denne endringen. Isåfall er det bare sette innstillingen tilbake til opprinnelig verdi.

Kompleksitet på endringen: Lav (ADUC)

Teknisk beskrivelse av GPO
Kjør følgende Powershell kommando for å liste ut alle objekter som benytter DES kryptering:
Get-ADObject -Filter {UserAccountControl -band 0x200000 -or msDs-supportedEncryptionTypes -band 3}

Åpne de relevante objektene i ADUC, åpne Attribute Editor. Noter verdien til attributten msDS-SupportedEncryptionTypes og endre den så til verdi 24

Alternativt åpne objektene i ADUC, åpne tab Account, se under Account Options og kryss av for:
This account support Keberos AES 128bit encryptions
This account support Keberos AES 256bit encryptions

Fjern krysset for følgende:
Use only DES encryption types for this account

Artikler

Microsoft Doc: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/decrypting-the-selection-of-supported-kerberos-encryption-types/1628797

Enforce AES på Kerberos Trusts

Bakgrunn

Kerberos er en autentiseringsprotokoll i Windows Active Directory. Trusts benytter som default DES og RC4. Begge disse kan nå dekrypteres. Man bør derfor konfigurere Trusts til å benytte kun Kerberos AES.

Risiko om man ikke fikser: Høy

Angripere utnytter DES og RC4 kryptering til å kjøre standard Kerberoasting angrep da disse protokollene kan dekrypteres raskt.

Konsekvens for brukere: Usannsynlig

Før man endrer et Trust til å kun benytte AES sikrer man begge domenene/skogene ved å utføre alle de tidligere herdingspunktene. Man har da allerede avviklet DES og RC4 i begge domenene som utgjør Trustet. Siden det da allerede er kun AES trafikk igjennom Trustet vil det ikke være noe konsekvenser ved å kreve dette også på Trustet.

Kompleksitet på endringen: Lav (AD Domains and Trusts)

Teknisk beskrivelse av GPO
Sikre at begge domenene som er på hver side av Trustet allerede er herdet.

Åpne Active Directory Domains and Trusts
Velg domenet, høyreklikk og velg Trusts. Velg Trustet.

Huk av for "The other domain supports Kerberos AES Encryption"

Artikler

Internet artikkel: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-4-%E2%80%93-enforcing-aes-for-kerberos/4114965

Kerberos Encryption Types explained: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/decrypting-the-selection-of-supported-kerberos-encryption-types/1628797

Passord i Group Policy Preferences

Bakgrunn

Group Policy Preferences (GPP) utvider Group Policy utover standardopsjonene.
GPP kom med Windows 2008, og ga også mulighet til å lagre passord i Group Policy med AES 32-kryptering.
Det er for kort med kun 32 bits AES-kryptering, og Microsoft publiserte AES krypteringsnøkkelen for GPP i 2012, slik at hackere etter det lett kan dekrypterere alle passord i GPP.

Microsoft kom med en patch til GPP i 2014 (MS14-025), men patchen hindrer deg kun i legge inn nye passord, den fjerner ikke passordene som allerede er lagt inn. Man må derfor manuelt fjerne alle passord fra GPP.

Teknisk beskrivelse

For å finne passord i GPP kjører man følgende kommando i et CMD vindu:
findstr /S /I cpassword \\<FQDN>\sysvol\<FQDN>\policies\*.xml

Kommandoen vil ikke liste ut passordene, men vil vise om man har noen policies med passord.

Kommandoen vil finne GUID for policyen som inneholder password. Man kan bruke Get-GPO med GUID som input for å få ut navnet på GPOen.

Fjerning av passordet:

Åpne Group Policy Management Console (GPMC)

Editer den aktuelle GPOen og åpne Computer > Preferences eller User > Preferences

Her kan man slette hele settingen, disable den eller gå inn i settingen og slette brukernavn/passord.

Hva man velger å gjøre avhenger om dette er i bruk eller hvordan det benyttes.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-preferences
Microsoft GPP Patch: https://support.microsoft.com/nb-no/topic/ms14-025-sikkerhetsproblem-i-gruppepolicyinnstillingene-kan-tillate-heving-av-tilgangsniv%C3%A5-13-mai-2014-60734e15-af79-26ca-ea53-8cd617073c30
Internet artikkel 1: https://adsecurity.org/?p=384
Internet artikkel 2: https://adsecurity.org/?p=2288

Disable Password not required

Bakgrunn

Det er mulig å tillate kontoer å ha tomt passord med å sette PasswordNotRequired på objektet.

Risiko ved mangel: Middles

Passordpolicy overstyrer innstillingen på objektet når passord byttes, så normalt er det ikke kritisk å fikse denne feilen. Det er imidlertid anbefalte å rette opp i feilen, da den både påvirker sikkerhetsovervåkning og også gir mulighet for framtidige feil som kan utnyttes av en angriper. Dersom man en gang tidligere hadde en passordpolicy og noen brukere den gang satte tomt passord på kontoen sin, så kan de fortsatt ha tomt passord selv om passordpolicyen nå ikke tillater det.

Konsekvens for brukere: Usannsynlig

Brukere må uansett oppfylle sikkerhetskravene i passordpolicyen, så de skal ikke merke noe. Dersom passordpolicy også tillater tomme passord og bruker også har satt en tomt passord, så vil ikke bruker få logget inn etter endringen.

Kompleksitet på endringen: Lav (Powershell)

Teknisk beskrivelse av GPO
Kjør følgende powershell-kommando for å finne alle kontoer som tillater tommepassord:
Get-ADUser -Filter {PasswordNotRequired -eq $true} | ft name, UserPrincipalName

Disable tomme passord med å kjøre følgende kommando for hver av brukerne over:
Set-ADUser -Identity user -PasswordNotRequired $false

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/useraccountcontrol-manipulate-account-properties

Internet artikkel: https://blog.icewolf.ch/archive/2022/01/06/understand-and-remove-passwd_notreqd-flag-from-useraccountcontrol/

Enforce riktig Primary group

Bakgrunn

Active Directory har en attributt som heter "primarygroupid". Verdien på denne skal være "Domain Users" (513) for alle brukere, "Domain Computers" (515) for alle computere og "Domain Controllers" (516) for alle domenekontrollere.

Risiko ved bruk: Lav

Angripere endrer ofte Primary group for å unngå å bli oppdaget. Dersom man har objekter med feil Primary group fra før, så vil ikke deteksjonsverktøy fungere optimalt.

Konsekvens for brukere: Usannsynlig

Det er ingen kjente konsekvenser med å sette riktig Primary group.

Kompleksitet på endringen: Lav (ADUC)

Teknisk beskrivelse av GPO
Kjør følgende to Powershell kommandoer for å liste ut alle objekter med feil Primary group:

$DomainUsersSid = New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::AccountDomainUsersSid,(Get-ADDomain).DomainSID)

Get-ADUser -Filter * -Properties PrimaryGroup | Where-Object { $_.PrimaryGroup -ne (Get-ADGroup -Filter {SID -eq $DomainUsersSid} ).DistinguishedName } | Select-Object UserPrincipalName,PrimaryGroup

Merk at kommandoen vil liste ut Guest kontoen, som har Primary Group "Domain Guests". Dette er riktig, og er det eneste som vil dukke opp dersom alle primary groups er satt riktigi domenet.

Åpne hvert objekt med feil Primary Group i ADUC (Active Directory Users and Computers) og endre atributtet primarygroup til riktig verdi.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/accounts-with-non-default-pgid

Disable at brukere kan joine PCer til domenet

Bakgrunn

Med Windows 2000 fikk alle brukere tillatelse til å opprette 10 PCer i domenet. Tilgang til å opprette Computer objekter i et domene bør begrenses til administratorer eller kjente grupper med brukere.

Risiko ved bruk: Middels

Default tilgangen til å opprette 10 computer objects åpner opp for flere kjente angrepsteknikker og tilgangen bør derfor fjernes

Konsekvens for brukere: Muligens

Normalt skal ikke brukere noen gang opprette PCer i domenet, men avhengig av hvordan dere setter opp PCer så kan det være at dere er avhengig av at brukerne skal kunne ha tilgang til dette. Dersom det er tilfellet bør dere gå over til å benytte grupper istedet og delegere tilgangen på de relevante OUene.

Kompleksitet på endringen: Lav (Powershell, GPMC)

Teknisk beskrivelse
Kjør følgende Powershell kommandoer
Hent ut opprinnelig verdi:
Get-ADObject ((Get-ADDomain).distinguishedname) -Properties ms-DS-MachineAccountQuota

Disable funksjonen:
Set-ADDomain (Get-ADDomain).distinguishedname -Replace @{"ms-ds-MachineAccountQuota"="0"}

Gi tilgangen til en gruppe:
Åpne Group Policy Management Console (GPMC) > Domain Controllers > Default Domain Controllers Policy : Edit
Gå til Computer Configuration > Policies > Windows Settings > Security Settings > User Rights Assignment

Velg Add workstations to domain > Properties
Fjern Authenticated Users og legg til gruppen dere ønsker å gi tilgang til.

Artikler

Microsoft Doc: https://learn.microsoft.com/nb-no/troubleshoot/windows-server/active-directory/default-workstation-numbers-join-domain

Microsoft Group Join: https://learn.microsoft.com/en-us/archive/technet-wiki/5446.active-directory-how-to-prevent-authenticated-users-from-joining-workstations-to-a-domain#2-by-default-domain-controllers-policy

Internet artikkel: https://sid-500.com/2017/09/09/securing-active-directory-who-can-add-computers-to-the-domain-only-the-domain-admin-are-you-sure/

Disable Delegation for alle Admin Accounts

Bakgrunn

Kerberos delegation tillater en service å benytte en bruker til å få tilganger på vegne av brukeren. Det er en nyttig funksjon for tjenester, men skal aldri være mulig for administratorkontoer. Protected Users-gruppen vil også sikre denne innstillingen, men det er uansett anbefalt å også sette den på hvert enkelt objekt.

Risiko ved bruk/mangel: Middels

Dersom en angriper har fått kontrol på en service, og en administrator så authentisere til denne servicen, så kan angriperen benytte denne kontoen til å kontakte andre servere og tjenester på vegne av administratorkontoen. Angriper kan altså operere som angriper har fått full kontrol på administratorkontoen, uten at angriper har kontrol på den, siden angriper kan operere på vegne av administratoren.

Konsekvens for brukere: Usannsynlig

Å fjerne muligheten for delegering på administratorkontoer påvirker kun administratorkontoene og skal ikke kunne påvirke brukerne. Vi har heller ikke opplevd at noen administratorer har hatt noen problemer etter disabling av delegation.

Kompleksitet på endringen: Lav (ADUC)

Teknisk beskrivelse
Start ADUC (Active Directory Users and Computers) og åpne en og en admin konto. For hver av dem:
Velg Accounts og sett på krysset for: Account is sensitive and cannot be delegated

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/ensure-privileged-accounts-with-sensitive-flag

Tøm Enterprise og Schema Admins

Bakgrunn

Enterprise Admins gruppen gir tilgang til alle domener i skogen og Schema Admins gruppen gir tilgang til selve AD skjema som bygger opp domenene. Begge disse gruppene bør som regel være tomme, og brukere kun legges inn når de skal utføre oppgaver som krever rollene.

Risiko ved bruk/mangel: Lav

Det er ingen direkte risiko med å ha kontoer som allerede ligger i Domain Admins i disse gruppene i tillegg, men det er anbefalt å beholde disse gruppene tomme for å minske angrepsflaten. Når gruppene er tomme bør man sette opp alarm dersom noen blir medlem av dem, slik at man får alarm om en angriper legger seg inn.

Konsekvens for brukere: Usannsynlig

Dette har ingen konsekvens for sluttbruker, kun for administratorer.

Kompleksitet på endringen: Lav (ADUC)

Teknisk beskrivelse
Åpne Active Directory Users and Computer (ADUC) og tømgruppene Enterprise Admins og Schema Admins.

Artikler

Microsoft Doc Schema: https://learn.microsoft.com/en-us/services-hub/unified/health/remediation-steps-ad/remove-all-members-from-the-schema-admins-group-unless-you-are-actively-changing-the-schema

Microsoft Doc Enterprise: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-e--securing-enterprise-admins-groups-in-active-directory

Disable Unconstrained Delegation

Bakgrunn

Kerberos Delegation betyr at en applikasjon kan få tilganger på vegne av en annen konto. Unconstrained Delegation betyr at disse tilgangene er gitt generelt til alt, og de er ikke spesifisert til bestemte ting.

Risiko ved bruk/mangel: Høy

Dersom en angriper har fått tilgang til en applikasjon som benytter et objekt som er satt opp med Unconstrained Delegation, og en Domain Admin benytter applikasjonen, så har angriper automatisk Domain Admin tilgang. Dersom en applikasjon må benytte delegation, så er det viktig å ikke sette den opp med unconstrained delegation, men å delegere kun til nøyaktig hva applikasjonen trenger.

Konsekvens for brukere: Usannsynlig

Å endre fra Unconstrained Delegation til Constrained Delegation skal ikke påvirke brukerne, så lenge man får lagt inn alle constraints applikasjonen trenger tilgang til.

Kompleksitet på endringen: Middels (Powershell,ADUC)

(Active Directory Users og Computers (ADUC) har en egen liste over tilganger som er enkel å oppdatere, men det kan være vanskelig å vite hva som skal legges inn.

Teknisk beskrivelse

Powershell kommando for å se alle kontoer som har Delegation:
Get-ADComputer -Filter {(TrustedForDelegation -eq $True) - AND (PrimaryGroupID -eq 515)} - Properties TrustedForDelegation,TrustedToAuthForDelegation,servicePrincipalName,Description

Hvis TrustedForDelegation = True, så har kontoen Unconstrained Delegation
Hvis TrustedToAuthForDelegation = False, så har kontoen Constrained Delegation

Microsoft anbefaler å ikke benytte Delegation hvis det er mulig å unngå det. Vurder om det er mulig å slå av Delegation for objektet. Hvis det ikke er mulig, endre til Constrained Delegation.

Start ADUC, åpne det relevante objektet og endre fra:
Trust this computer for delegation to any service (Kerberos only)
Til:
Trust this computer for delegation to specified services only

Velg "Use Kerberos only"
Legg inn de servicene som kontoen skal kunne delegere til.

Viktig å huske at en angriper vil få tilgang til alle servicene man legger inn i listen, dersom angriper får tilgang til den opprinnelige applikasjonen.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/security-assessment-unconstrained-kerberos

Internet artikkel: https://www.sentinelone.com/blog/detecting-unconstrained-delegation-exposures-in-ad-environment/

Slett delegations til SID

Bakgrunn

Hvis man setter opp Delegation (Constrained eller unconstrained) til en konto som senere slettes, så vil delegeringen fortsatt eksistere etter slettingen, og delegeringen vil vises som en SID. Angripere kan utnytte dette. Se også artikkelen vår om "Unconstrained Delegation".

Delegering til andre domener vil også vises som en SID, men man bør ikke delegere på tvers av domener, så slike delegeringer bør også slettes.

Risiko ved bruk/mangel: Lav

Angripere kan utnytte delegering til slettede objekter til å få flere tilganger.

Konsekvens for brukere: Usannsynlig
Kontoen det var delegert til er allerede slettet, så det vil ikke gi noen konsekvenser å slette selve delegeringen.

Kompleksitet på endringen: Lav (Powershell, ADUC)

Teknisk beskrivelse
Powershell kommando for å se alle kontoer som har delegation:

Get-ADComputer -Filter {(TrustedForDelegation -eq $True) - AND (PrimaryGroupID -eq 515)} - Properties TrustedForDelegation,TrustedToAuthForDelegation,servicePrincipalName,Description

For å verifisere at alle tilhører det relevante domenet:

Get-ADDomain | select DomainSID

Alt etter "S-1-5-" utgjør SID til Domenet. Alle objekter i samme domene vil ha de samme tre bolkene først og så en fjerde bolk som er unik for hvert enkelt objekt.

Dersom man finner delegeringer til andre domener bør man ta en nøye vurdering om slik delegering er nødvendig.

Slett alle delegeringer til SID:

Start ADUC (Active Directory Users and Computers) og åpne de relevante kontoene. For hver av dem velg Delegations og endre til: Do not trust this account for delegation

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/security-assessment-unconstrained-kerberos

Internet artikkel: https://www.sentinelone.com/blog/detecting-unconstrained-delegation-exposures-in-ad-environment/

Enforce Privileged group on RODCs

Bakgrunn

Read Only Domain Controllers (RODC) er domenekontrollere som bare replikerer et lite subsett av kontoer, slik at det ikke er full krise om disse kommer på avveie. Hvis man enten har satt opp slike, eller har satt Kerberos for single sign-on (SSO) to your resources with Microsoft Entra Private Access. Et attributt som heter msDS-NeverRevealGroup sikrer at ingen Privileged Groups skal replikeres.

Risiko ved bruk/mangel: Lav

Hvis gruppen msDS-NeverRevealGroup er feil, så vil det bli replikert grupper som ikke skal være på en RODC.

Konsekvens for brukere: Usannsynlig

Dette skal bare påvirke administratorer, og disse gruppene skulle uansett ikke vært på en RODC.

Kompleksitet på endringen: Lav

Teknisk beskrivelse
Åpne ADUC (Active Directory Users and Computers > Domain Controllers >

Åpne alle RODC objekter og sikre at msDS-NeverRevealGroup attributten er satt til:

Administrators
Server Operators
Account Operators
Backup Operators
Denied RODC Password Replication Group

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust?tabs=intune#microsoft-entra-kerberos-and-cloud-kerberos-trust-authentication

Internet artikkel: https://techcommunity.microsoft.com/blog/itopstalkblog/deep-dive-how-azure-ad-kerberos-works/3070889

Hvordan sette opp AzureADKerberos kontoen: https://msendpointmgr.com/2023/03/04/cloud-kerberos-trust-part-2/

Reset password on AzureADSSOACC

Bakgrunn

Kontoen AZUREADSSOACCgir SSO (Single Sign On) med Azure AD.

Passordet på AZUREADSSOACC bør skiftes regelmessig.

Risiko ved bruk/mangel: Lav

Angripere vil alltid prøve å knekke passordet på AZUREADSSOACC.

Konsekvens for brukere: Usannsynlig

Dette er bare et passordbytte på en spesiell servicekonto, så det skal ikke påvirke brukerne på noen måte.

Kompleksitet på endringen: Lav (Powershell)

Teknisk beskrivelse
NB: Prosedyren nedenfor forutsetter 1 Forest med 1 Domain. For andre konfigurasjoner se artikkel nedenfor.

Åpne Powershell og kjør kommandoene:
cd $env:programfiles"\Microsoft Azure Active Directory Connect"

Import-Module .\AzureADSSO.psd1

$creds = Get-Credential
NB: Brukernavnet må være Domain Admin og må skrives inn på formen: contoso\johndoe

Update-AzureADSSOForest -OnPremCredentials $creds

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/change-password-microsoft-entra-seamless-single-sign-on#why-might-the-microsoft-entra-seamless-sso-computer-account-old-password-be-a-risk
Microsoft Change AzureADSSOAcc passord: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-faq#how-can-i-roll-over-the-kerberos-decryption-key-of-the--azureadsso--computer-account-

Reset AdminCount

Bakgrunn

Når en konto blir Domain Admin så blir attributtet AdminCount satt til 1. Dette for å vise at denne kontoen har, eller har hatt, Domain Admin. Attributtet må resettes manuelt dersom kontoen ikke lengre er Domain Admin.

Risiko ved bruk/mangel: Middels

Angripere kan ikke utnytte AdminCount attributtet direkte, men de tar ut en liste over alle kontoer som har AdminCount=1. Dette vet de er kontoer som enten har Domain Admin tilgang, eller har hatt det tidligere. Dersom en konto ikke lengre er Domain Admin, så kan det være at brukeren f.eks er tatt ut av Protected Users og andre spesielle sikringer som gjelder for Domain Admins. Hvis kontoen fortsatt har andre privileges enn Domain Admin så vil kontoen være et angreps mål.

Konsekvens for brukere: Usannsynlig

AdminCount påvirker kun administratorbrukere.

Kompleksitet på endringen: Lav (Powershell, ADUC)

Teknisk beskrivelse
For å få ut alle objekter

Get-ADObject -LDAPFilter "(adminCount=1)"

Gå igjennom alle kontoer i listen og sett AdminCount til 0 for de vanlige Administratorer som ikke lengre skal være Domain Admins:

Åpne ADUC og Properties for den relevante kontoen, velg Attribute Editor og Edit på adminCount. Velg Clear.

NB: Dersom tabben for "Attribute Editor" ikke vises, velg View > Advanced Features

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/reducing-the-active-directory-attack-surface#protected-accounts-and-groups-in-active-directory

Internet artikkel: https://blog.netwrix.com/2022/09/30/admincount_attribute/

Reset krbtgt password

Bakgrunn

Passordet på kontoen krbtgt (Kerberos Ticket Granting Ticket) benyttes som secret for å signere alle Kerberos tickets.

Risiko ved bruk/mangel: Høy

Angripere forsøker alltid å få tak i passordet på denne kontoen, fordi det dessverre endres sjelden og fordi det gir tilgang til hele domenet uten å være enkelt å oppdage.

Konsekvens for brukere: Usannsynlig

Kompleksitet på endringen: Middels

Teknisk beskrivelse
VIKTIG: Passordet må skiftes to ganger, og det MÅ være minst 10 timer og bør helst være 1 uker mellom passordbyttene. Årsaken til denne kritiske ventetiden er at Kerberos ticket etter det første passordbyttet må ha løpt ut før det neste skjer passordbyttet skjer, ellers kan DCer miste tilgang til domenet!

Anbefaler også å kjøre følgende to kommandoer, for å være sikker på at alle DCer replikerer korrekt før passordet byttes. Åpne Command Prompt og kjør følgende kommandoer:
repadmin /showrepl

Repadmin skal gi svar "Last attempt .... was successful" for alle.

dcdiag /e /test:connectivity

DcDiag skal gi "servername passed test Connectivity for alle.

Åpne ADUC > domene > Users > krbtgt
Høyreklikk og velg Reset Password

Fjern krysset for "User must change password at next logon"

Det er ikke viktig hvilket passord man setter, så lenge det er godkjent av passordpolicy.
ADUC vil automatisk erstatte passordet man lager med en lang random string.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/change-password-krbtgt-account

Microsot Doc: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-reset-the-krbtgt-password