AD-herding

Domain Administrator kontoen er Break Glass konto

Bakgrunn

Den innebyggde domeneadministrator-kontoen "administrator" skal ikke benyttes til vanlig pålogging.

Den skal kun benyttes i et "Break Glass"-tilfelle. Årsaken til at man ikke skal bruke den er for å unngå at passord og Tickets for denne kontoen spres rundtom.

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/

Enable AD Backup

Bakgrunn

Det er kritisk å ha backup av AD, slik at man kan raskt kan komme tilbake etter angrep.
Ping Castle rapporterer at backup mangler dersom den innebygde kommandoen repadmin viser at backup mangler av noen DCer.

Risiko hvis man ikke fikser: Høy

Angripere kan kryptere eller slette alt, og uten AD backup får man ikke noe tilbake ved restore.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Dette er bare en backup av AD, så det vil ikke kunne påvirke brukerne å starte med backup.

Kompleksitet på endringen: Lav

Man kan benytte det innebyggede backup programmet i Windows. Vi anbefaler å benytte tredjepartsprogrammvare for bedre kontroll på backupene og flere restoremuligheter. Det er også viktig å lagre backup eksternt, slik at en angriper ikke kan slette backupene.

Teknisk beskrivelse:
Sjekk om backup blir tatt av DCene ved å kjøre kommandoen:

REPADMIN /showbackup *

Dersom noen (eller alle) DCer mangler backup bør man sette opp dette så raskt som mulig. Enklest mulig backup er å benytte den innebyggede wbadmin kommandoen og kjøre systemstatebackup. Dette kan gjøres på følgende måte:

wbadmin.exe START SYSTEMSTATEBACKUP –backupTarget:<Volumnavn>

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin

Internet artikkel:

Bakgrunn

Det er helt normalt at det ved en Pentest blir avdekket svake passord. Anbefalingene i denne artikkelen sikrer at ingen svake passord finnes.

Endre passordpolicy for Active Directory

Passord policyen må sikre at alle nye passord oppfyller anbefalte krav: 14 tegn, fjerne kompleksitetskrav, ikke utløpsdato. NHN anbefaler følgende innstillinger:

Åpne GPMC (Group Policy Management) og gå til

Forest FQDN > Domains > FQDN > Default Domain Policy

Naviger til: Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Password Policy

Sett følgende:

Maximum password age: 0
Minimum password length: 14
Password must meet complexity requirements: Disabled

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

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

Alle passordbytter i Active Directory vil 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 før den settes til Enforce.

Teknisk beskrivelse for aktivering av Entra ID Password Protection for Windows Server Active Directory.

Verifiser at miljøet støtter Entra ID Password Protection

Verifiser at .Net 4.7.2 er installert på alle DCene

Kjør Powershell kommando:
(Get-ItemPropertyValue -LiteralPath 'HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' -Name Release) -ge 461808

Resultat "True" betyr at .Net 4.7.2 er installert. Resultat "False" betyr at det mangler og må legges inn.

Artikkel: https://learn.microsoft.com/en-us/dotnet/framework/install/how-to-determine-which-versions-are-installed#use-powershell-to-check-for-a-minimum-version

Log inn på PDC (Primary Domain Controller)

Kjør kommandoen "netdom query FSMO" på hvilken som helst DC, for å sjekke hvilken DC som har PDC rollen.

Verifiser at replikering mellom DCene skjer med DFRS og ikke lengre med FRS

Åpne command prompt og kjør: dfsrmig /getglobalstate
State må være lik Eliminated for å kunne benytte Entra ID Password protection.

Artikkel for å oppdatere fra FRS til DFRS: https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr

Verifiser at TLS1.2 er enablet på alle DCene.

Åpne command prompt og kjør følgende to kommandoer:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client\DisabledByDefault"

Hvis nøkkelen ikke finnes er TLS 1.2 disablet. Hvis nøkkelen finnes skal verdien 0 returneres.

reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client\Enabled"

Hvis nøkkelen ikke finnes er ikke TLS 1.2 enablet. Hvis nøkkelen finnes skal verdien 1 returneres.

Artikkel for å aktivere TLS 1.2: https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-configure-connectors#transport-layer-security-tls-requirements

NB: Det kreves restart etter installasjon av TLS1.2

Verifiser konfigurasjonen av Entra ID Password Policy

Logg inn i Entra ID som Global Administrator

Åpne portalen for entra.microsoft.com og gå til Entra ID > Authentication methods > Password Protection

Verifiser "Custom banned password" og "Custom banned password list" er satt som ønsket.

NB: På dette tidspunktet skal man ikke endre settingene for "Password Protection for Windows Server Active Directory"

Installer proxy og agent

Installering av Password Protection Proxy:

Logg inn på PDC (Primary Domain Controller)

Last ned både agent (exe) og proxy (msi): https://www.microsoft.com/en-us/download/details.aspx?id=57071

Kjør: AzureADPasswordProtectionProxySetup.exe

Åpne Powershell som en Administrator og kjør: Import-Module AzureADPasswordProtection

Verifiser at Proxy kjører med følgende kommando: Get-Service AzureADPasswordProtectionProxy | select Name, Status
Status skal være: Running

Registrer agenten med å kjøre de to kommandoene nedenfor:

NB: Oppgi en Global Administrator konto i Tenant, ikke AD kontoen!

$globalAdminCredentials = Get-Credential

Register-AzureADPasswordProtectionProxy -AzureCredential $globalAdminCredentials

Verifiser at Proxy registrerte seg med å kjøre: Test-AzureADPasswordProtectionProxyHealth -TestAll

Forventet resultat er: Passed

Registrer AD Forest med å kjøre kommandoen: Register-AzureADPasswordProtectionForest -AzureCredential $globalAdminCredentials

Verifiser at AD Forest ble registrert med å kjøre: Test-AzureADPasswordProtectionProxyHealth -TestAll

Forventet resultat er: Passed

Installering av Password Protection Agent:

Logg inn på PDC

Kjør: AzureADPasswordProtectionDCAgentSetup.msi

NB: Det kreves restart etter installering av agenten.

NB: Gjenta så akkurat samme installasjonen av Agent på alle andre DCer også.

Audit Entra Password Protection i Entra ID

Logg inn i Entra ID som Global Administrator

Åpne entra.microsoft.com og gå til Entra ID > Authentication methods > Password Protection

Sett "Enable password protection on Windows Server Active Directory" til: Yes
Sett Mode til Audit

Åpne EventViewer og gå til:

\Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin

Sjekk at loggen er ok, og sjekk at forventede log innslag kommer inn når dere bytter passord.

Verifiser med å bytte til et passord som er godkjent onprem men ikke er godkjent i Entra ID, og se at forventet resultat vises i loggen.

Enforce Entra Password Protection i Entra ID

Når dere har kjørt med Audit en stund (f.eks 1 uke), så går dere igjennom loggene og hvis de ser ok ut så bytter dere Mode til Enforced.

Det kan ta noen timer før Enforced aktiveres.

Verifiser med å bytte til et passord som er godkjent onprem, men ikke er godkjent i Entra ID, og se at dere ikke får byttet passord.

Artikler
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

Bytte passord på absolutt ALLE kontoer

Når Passord policy og Protection er på plass, så må man skifte alle passordene på alle kontoene. 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.

For å sjekke hvem som ikke har byttet passord siden Policy ble satt kan man benytte følgende kommando. Husk å fylle inn Distinguished Name for domenet og antall dager siden passordpolicy ble satt:

get-aduser -Filter * -SearchBase "DistinguishedNameOfDomain" -Properties PasswordLastSet | Where-Object {$_.PasswordLastSet -lt (Get-Date).adddays(-NumberOfDaysSincePolicyWasSet)} | sort PasswordLastSet | select samaccountname,PasswordLastSet

PS: For å finne Distinguished Name kjøres følgende kommando: Get-ADDomain | fl DistinguishedName

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.

Kjør følgende kommando for å liste ut alle brukerkontoer som aldri har logget på:

Get-ADUser -Filter {(Enabled -eq $true) -and -not (lastlogontimestamp -like "*") -and -not (isCriticalSystemObject -eq $true)} -Properties SamAccountName, Enabled, LastLogonDate | Select-Object SamAccountName, Enabled, LastLogonDate

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.

Konsekvens for Administratorer: Sannsynlig

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/

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 relativt raskt.

Konsekvens for brukere: Muligens

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, men det tjenester som fortsatt støtter RC4 som basis krypteringsalgoritme per 2025. Internettartikkelen nedenfor har mye info om hvordan man kan sjekke om noe benytter RC4.

Konsekvens for Administratorer: Muligens

Dersom man tidligere har lagt alle administratorer inn i Protected Users Group skal ikke denne herdingen ha noen konsekvenser. Anbefaler derfor å utføre herdingen Protected Users group før man utfører denne.

Kompleksitet på endringen: Lav (GPO)

Teknisk beskrivelse av GPO
Anbefaler å benytte GPO som er opprettet for herding, og å benytte Pilot GPO på økende mengder av klienter først og så samme på servere før DCene tas til slutt.
Settes for Klienter, Servere og DC.

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

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

Internettartikkel: 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