kan jeg tillade, at en administratorkonto bruger “Kør som”, men ikke logger på skrivebordet?

Use case

nogle kunder vil kun bruge en administratorkonto til “forhøjede” opgaver, ligesom hvordan unikke systemer understøtter begrebet “sudo”. Desuden er Univ-systemer ofte konfigureret til at blokere direkte logon af administratorkonti. Den etablerede procedure er at logge på med en upriviligeret bruger og derefter hæve opgaver med kommandoen “sudo”, hvor det er nødvendigt.

der er ikke en nøjagtig kortlægning af disse begreber til vinduer miljø. Microsoft lavede nogle trin i denne retning med Brugerkontokontrol. Kommandoen” Kør som ” tillader også et lignende adfærdsmønster som den unikke “sudo” (selvom den ikke er identisk).

da mange kunder har bedste praksis for at undgå brug af administratorkonti, hvor det er muligt, lad os undersøge, om vi kan tillade, at en konto bruges med kommandoen “Kør som”, men blokere den konto fra at logge ind interaktivt på skrivebordet.

Internals

godkendelser til vinduer desktop (enten via konsol eller Remote desktop access) er kendt som “interaktive” logons. Gruppepolitik giver os mulighed for at begrænse, hvem der kan logge på interaktivt, men den samme politik styrer også brugen af kommandoen “Kør som”. (Vinduer bruger den samme logontype, når du opretter en sekundær godkendelse, selvom der ikke vises noget ekstra skrivebord.) Således er der ikke nogen direkte måde (via politik) at begrænse en, men ikke den anden.

Gruppepolitik tillader en brugerkonto at have en anden “shell” specificeret (den normale skal er “Stifinder.eks”). Vi kan bruge denne funktion til at tvinge en interaktiv session til at logge af med det samme i stedet for at vise skrivebordet.

Procedure

  • Opret eller vælg en organisatorisk enhed, der holder dine logonbegrænsede brugere.
  • Flyt brugere ind i gruppen (om nødvendigt).
  • Opret et gruppepolitikobjekt og anvend på OU
  • Rediger gruppepolitikobjektet. Naviger til:
    User Configuration > Policies > Administrative Templates > System

    og sæt politikken med navnet “brugerdefineret brugergrænseflade” til “logoff.bemærk, at denne politik ikke gælder med det samme; du bliver nødt til at bruge “gpupdate” på dine systemer, hvis du agter at teste med det samme.

advarsler

  • Brug kun sand Gruppepolitik til denne indstilling. Anvend ikke denne politik ved hjælp af det “lokale” gruppepolitikobjekt for specifikke maskiner, fordi det derefter gælder for alle brugere. Effektivt vil ingen brugere være i stand til at logge på maskinen (hvilket sandsynligvis ikke er det, du ønsker).
  • hvis du anvender denne politik på brugerkonti til domæneadministratorer, skal du sørge for også at ændre den politik, der kun tillader administratorer at godkende til domænecontrollere. Ellers vil de eneste brugere, der har tilladelse til at logge på DCs, straks blive logget af (hvilket sandsynligvis ikke er det, du vil have).

begrænsninger

formålet med denne procedure er kun at styre legitime brugeres adfærd ved at forhindre utilsigtet (eller doven) brug af deres forhøjede konto til desktop-sessioner. Det begrænser ikke, hvad en angriber eller ondsindet administrator kan gøre med deres legitimationsoplysninger. Husk, at godkendelse til det interaktive skrivebord ikke er nødvendigt for at ændre nogen indstilling, herunder at ændre deres skal tilbage til “Stifinder.eks”.

det er derfor stadig vigtigt at sikre administrative brugere med 2-faktor legitimationsoplysninger.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.