Windows Server: Beskyttede privilegerede konti

I denne Spørg Admin, Beskriver jeg nogle af sikkerhedsfunktionerne i Windows Server, der kan bruges til at holde følsomme konti sikkert.

Windows Server indeholder flere teknologier til at sikre, at privilegerede konti er sikre, herunder gruppen Beskyttede brugere og godkendelsessiloer. Før du ser på implementering af en af ​​nedenstående løsninger, skal du sørge for at tjekke ud Hvorfor skal du bruge Microsofts Administrative Directory Tier Administrative Model, Administration af privilegeret adgang til Active Directoryog Windows Server 2016: Forstå Microsofts forbedrede Security Administrative Environment på den Petri IT Knowledgebase.

Det er værd at huske, at de teknologier, jeg vil beskrive i denne artikel, ikke erstatter sikkerheds bedste praksis. For eksempel, i Hvorfor skal du bruge Microsofts Administrative Directory Tier Administrative Model, Forklarer jeg, hvorfor domæneadministratorkonti aldrig skal bruges til at logge ind på slutbrugerenheder. Gruppen Beskyttede brugere kan hjælpe med at afhjælpe nogle af risiciene ved at bruge privilegerede AD-konti på Tier 2-enheder, men det fjerner ikke risiciene helt.

Beskyttede brugere af Active Directory

Gruppen Beskyttede brugere dukkede først op i Windows Server 2012 R2 og kan bruges til at begrænse, hvad medlemmer af Active Directory-privilegerede grupper kan gøre i domænet. Beskyttede brugere er en global sikkerhedsgruppe, og dens primære funktion er at forhindre brugernes legitimationsoplysninger misbruges på de enheder, hvor de logger ind.

Grupper med beskyttede brugere understøttes på enheder, der kører Windows 8.1 og Windows Server 2012 (eller højere). Her er den fulde liste over begrænsninger:

  • Cachelagrede legitimationsoplysninger. Dvs. brugere kan ikke logge ind offline, når der ikke er adgang til en domænecontroller.
  • Kerberos billetgodtgørelsesbillet (TGT) skal modtages, når brugerne logger ind og ikke kan genuddeles automatisk, hvilket forhindrer brugen af ​​langsigtede nøgler.
  • Standard legitimationsdelegation (CredSSP), og stoppe legitimationsoplysninger cached i plaintext, selvom Tillad delegering af standardoplysninger politikken er indstillet.
  • Windows Digest godkendelse.
  • NT LanManager (NTLM) NTOWF - en funktion til generering af nøgler baseret på brugeradgangskoder.

Hvis domæneniveauet er Windows Server 2012 R2 (eller højere), Beskyttede brugere kan ikke:

  • Forny Kerberos billet-tildelende billetter længere end den oprindelige 4-time TTL
  • Log ind ved hjælp af NTLM
  • Brug DES eller RC4 til Kerberos forudautentificering
  • Uddelegeres ved hjælp af begrænset eller ubegrænset delegation

For yderligere oplysninger om brugen af ​​gruppen Beskyttede brugere, se Beskyt privilegerede legitimationsoplysninger i Windows Server 2012 R2 ved hjælp af gruppen Beskyttede brugere on Petri.

Autentificeringspolitikker og siloer

Autentificeringspolitikker blev introduceret i Windows Server 2012 R2 og tilføjer de begrænsninger, der er givet af medlemskab af gruppen beskyttede brugere. Hvor gruppen af ​​beskyttede brugere indeholder et sæt begrænsninger, som ikke kan ændres, tillader autentificeringspolitikker administratorer at konfigurere begrænsningerne for brugerkonti, tjenester og computere. Du kan f.eks. Begrænse en servicekonto til at logge ind på en bestemt server.

Godkendelse politik siloer giver dig mulighed for at etablere et forhold mellem bruger, computer og administrerede service konti. Konti kan kun tilhøre en silo. Autentificeringspolitikker kan anvendes til alle medlemmer af en autentiseringspolitik silo, eller individuelle politikker kan anvendes til forskellige typer af konti i en silo.

Autentificeringspolitikker og siloer er afhængige af Kerberos, krav, sammensat godkendelse og Kerberos armoring. NTLM logons understøttes ikke, og brugere skal være medlem af gruppen beskyttede brugere. For yderligere oplysninger om, hvordan du arbejder med godkendelsespolitikker og siloer, se Sådan opretter du en Windows Server 2012 R2-godkendelsespolitik on Petri.

Credential Guard

Virtualization-based security (VBS) funktioner i Windows 10 og Windows Server 2016 leverer den teknologi, der kører Credential Guard. Når Credential Guard er aktiveret, flyttes en isoleret version af LSA-processen (Local Security Authority) til en virtuel maskine. Windows åbner den beskyttede LSA ved hjælp af fjernproceduresamtaler (RPC).

Credential Guard kan bevare domænekonti mod pass-the-hash eller token-angreb, selv når den logget bruger har administrative eller debug privilegier. Da domæneoplysninger kan bruges til at logge ind på mere end én enhed eller bruges til at få andre legitimationsoplysninger, anbefaler Microsoft at aktivere Credential Guard på enheder, der understøtter det.

For mere information om Credential Guard, se Windows 10 Enterprise Feature: Credential Guard on Petri.

Multifaktor-godkendelse

Multifaktor-godkendelse (MFA) skal bruges til at beskytte privilegerede AD-konti. MFA er en to-trins verifikationsproces, der kan forhindre programmatiske angreb mod privilegerede konti. Ud over et stærkt kodeord understøtter Microsoft MFA følgende faktorer:

  • telefonopkald
  • SMS-beskeder
  • meddelelser om mobil-app
  • bekræftelseskoder for mobil-app
  • Tredjeparts OV-tokens

MFA har været traditionelt dyrt og vanskeligt at oprette og vedligeholde i en lokal AD. Men en af ​​fordelene ved at udvide AD til skyen er en nemmere måde at implementere MFA på for bedre sikkerhed. For mere information om Azure MFA, se Microsofts hjemmeside her.

Read-Only Domain Controllers (RODCs)

Ikke alle domænecontrollere (DC'er) skal skrives. Dette gælder især, hvis de er på steder, der ikke kan sikres fysisk, såsom filialer. Read-Only Domain Controllers har skrivebeskyttede kopier af AD-databaseparitionerne, SYSVOL-mappen og DNS-databasen, så det giver beskadigelse, hvis serveren er kompromitteret. RODC'er skal kontakte en skrivebar DC til brugergodkendelse, da kontooplysninger ikke gemmes lokalt på RODC'er, medmindre du vælger at aktivere funktionen til hurtigere login.

Ikke alle programmer er kompatible med RODC'er, så kontroller, at dine applikationer er kompatible. For yderligere information om arbejde med RODC'er, se Implementer en Read-Only Domain Controller on Petri.

Lokal Administrator Password Solution (LAPS)

Lokale administratorkonti konfigureres ofte med samme adgangskode på tværs af alle brugerenheder, hvilket betyder at en angriber kan kompromittere hver enhed med kun én adgangskode. For at hjælpe IT med at randomisere og regelmæssigt nulstille adgangskoder frigjente Microsoft værktøjet LAPS (Location Administrator Password Solution).

LAPS bruger en klient-sideudvidelse til gruppepolitik til at indstille administratoradgangskoden og gemme den sikkert i Active Directory. Værktøjet kræver en opdatering af dit AD-skema og tilføjer to attributter: ms-MCS-AdmPwd og ms-MCS-AdmPwdExpirationTime. Den første gemmer det lokale administratorkonto kodeord og det andet tidspunkt, hvor det skal nulstilles.

Se Sikre lokale administratorkonti med LAPS-værktøjet (Local Administrator Password Solution Solution) on Petri for flere detaljer om, hvordan du bruger LAPS.

Listen over funktioner til beskyttelse af privilegerede konti i denne artikel er ikke udtømmende, men de værktøjer, jeg har beskrevet, kan hjælpe dig med at håndhæve mange af de bedste fremgangsmåder, som jeg har diskuteret i tidligere artikler. Hvis du ikke er sikker på, hvor du skal starte, skal du bruge de bedste metoder som vejledning til at implementere sikkerhed i din organisation.

Stillingen Windows Server: Beskyttede privilegerede konti dukkede først på Petri.

Giv en kommentar

Dette websted bruger Akismet til at reducere spam. Lær, hvordan dine kommentardata behandles.