Vägledning om hur du konfigurerar skyddade konton

Genom PtH-attacker (Pass-the-hash) kan en angripare autentisera till en fjärrserver eller tjänst med hjälp av den underliggande NTLM-hashen för en användares lösenord (eller andra derivat av autentiseringsuppgifter). Microsoft har tidigare publicerat vägledning för att minimera pass-the-hash-attacker. Windows Server 2012 R2 innehåller nya funktioner som hjälper dig att minimera sådana attacker ytterligare. Mer information om andra säkerhetsfunktioner som hjälper till att skydda mot stöld av autentiseringsuppgifter finns i Skydd och hantering av autentiseringsuppgifter. I den här artikeln beskrivs hur du konfigurerar följande nya funktioner:

• Skyddade användare

• Autentiseringsprinciper

• Silor för autentiseringspolicy

Det finns ytterligare åtgärder som är inbyggda i Windows 8.1 och Windows Server 2012 R2 för att skydda mot stöld av autentiseringsuppgifter, som beskrivs i följande artiklar:

• Begränsat administratörsläge för fjärrskrivbord

• LSA-skydd

Skyddade användare

Skyddade användare är en ny global säkerhetsgrupp som du kan lägga till nya eller befintliga användare i. Windows 8.1-enheter och Windows Server 2012 R2-värdar har särskilt beteende hos medlemmar i den här gruppen för att ge bättre skydd mot stöld av autentiseringsuppgifter. För en medlem i gruppen cachelagrar inte en Windows 8.1-enhet eller en Windows Server 2012 R2-värd autentiseringsuppgifter som inte stöds för skyddade användare. Medlemmar i den här gruppen har inget ytterligare skydd om de är inloggade på en enhet som kör en version av Windows tidigare än Windows 8.1.

Medlemmar i gruppen Skyddade användare som är inloggade på Windows 8.1-enheter och Windows Server 2012 R2-värdar kan inte längre använda:

• Standarddelegering av autentiseringsuppgifter (CredSSP) – autentiseringsuppgifter i klartext cachelagras inte ens när principen Tillåt delegering av standardautentiseringsuppgifter är aktiverad

• Windows Digest – autentiseringsuppgifter i klartext cachelagras inte ens när de är aktiverade

• NTLM – NTOWF har inte cachats

• Kerberos långsiktiga nycklar – Kerberos biljettbeviljande biljett (TGT) förvärvas vid inloggning och kan inte förvärvas på nytt automatiskt

• Inloggning offline – den cachelagrade inloggningsverifieraren skapas inte

Om domänfunktionsnivån är Windows Server 2012 R2 kan medlemmar i gruppen inte längre:

• Autentisera med NTLM-autentisering

• Använd Data Encryption Standard (DES) eller RC4-krypteringssviter i Kerberos-förautentisering

• Delegera med obegränsad eller begränsad delegering

• Förnya användarbiljetter (TGT) efter den första 4-timmarslivslängden

Om du vill lägga till användare i gruppen kan du använda gränssnittsverktyg som Active Directory Administrationscenter (ADAC) eller Active Directory Användare och datorer, eller ett kommandoradsverktyg som Dsmod-gruppen eller windows PowerShell-cmdletenAdd-ADGroupMember . Konton för tjänster och datorer bör inte vara medlemmar i gruppen Skyddade användare. Medlemskap till dessa konton ger inget lokalt skydd eftersom lösenordet eller certifikatet alltid är tillgängligt på värdmaskinen.

Medlemmar i gruppen Skyddade användare måste kunna autentisera med hjälp av Kerberos med AES (Advanced Encryption Standards). Den här metoden kräver AES-nycklar för kontot i Active Directory. Den inbyggda administratören har ingen AES-nyckel om inte lösenordet har ändrats på en domänkontrollant som kör Windows Server 2008 eller senare. Dessutom är alla konton, som har ett lösenord som har ändrats på en domänkontrollant som kör en tidigare version av Windows Server, utelåst. Följ därför dessa metodtips:

• Testa inte i domäner om inte alla domänkontrollanter kör Windows Server 2008 eller senare.

• Ändra lösenord för alla domänkonton som skapades innan domänen skapades. Annars kan dessa konton inte autentiseras.

• Ändra lösenordet för varje användare innan du lägger till kontot i gruppen Skyddade användare eller se till att lösenordet nyligen har ändrats på en domänkontrollant som kör Windows Server 2008 eller senare.

Krav för att använda skyddade konton

Skyddade konton har följande distributionskrav:

• För att kunna ange begränsningar på klientsidan för skyddade användare måste värdarna köra Windows 8.1 eller Windows Server 2012 R2. En användare behöver bara logga in med ett konto som är medlem i en grupp skyddade användare. I det här fallet kan gruppen Skyddade användare skapas genom att den primära domänkontrollantens (PDC) emulatorroll överförs till en domänkontrollant som kör Windows Server 2012 R2. När gruppobjektet har replikerats till andra domänkontrollanter kan PDC-emulatorrollen finnas på en domänkontrollant som kör en tidigare version av Windows Server.

• Om du vill ange begränsningar på domänkontrollantsidan för skyddade användare, dvs. för att begränsa användningen av NTLM-autentisering och andra begränsningar, måste domänfunktionsnivån vara Windows Server 2012 R2. Mer information om funktionsnivåer finns i Förstå funktionsnivåer för Active Directory Domain Services (AD DS).

Felsöka händelser som rör skyddade användare

Det här avsnittet beskriver nya loggar som hjälper dig att felsöka händelser relaterade till skyddade användare och hur dessa användare kan påverka förändringar när man felsöker antingen utgången av biljettbeviljande biljetter (TGT) eller delegeringsproblem.

Nya loggar för skyddade användare

Det finns två nya administrativa loggar för drift som hjälper dig att felsöka händelser som är relaterade till skyddade användare: Skyddad användare – klientlogg och skyddade användarfel – Domänkontrollantlogg. Dessa nya loggar finns i Händelseloggaren och är inaktiverade som förvalt. Om du vill aktivera en logg klickar du på Program- och tjänstloggar, klickar på Microsoft, klickar på Windows, klickar på Autentisering och klickar sedan på namnet på loggen och klickar på Åtgärd (eller högerklickar på loggen) och klickar på Aktivera logg.

Mer information om händelser i dessa loggar finns i Autentiseringsprinciper och Silos för autentiseringsprincip.

Felsöka TGT-förfallodatum

Normalt anger domänkontrollanten TGT-livslängden och förnyelsen baserat på domänprincipen enligt följande fönster i redigeraren för grupprinciphantering.

För skyddade användare är följande inställningar hårdkodade:

• Maximal livslängd för användarbiljett: 240 minuter

• Maximal livslängd för förnyelse av användarbiljett: 240 minuter

Felsökning av problem med delegering

Tidigare, om en teknik som använde Kerberos-delegering misslyckades, kontrollerades klientkontot för att se om kontot är känsligt och inte kunde delegeras hade angetts. Men om kontot är medlem i Skyddade användare kanske den inte har den här inställningen konfigurerad i Active Directory Administrationscenter (ADAC). Därför kontrollerar du inställningen och gruppmedlemskapet när du felsöker delegeringsproblem.

Granska autentiseringsförsök

Om du vill granska autentiseringsförsök explicit för medlemmarna i gruppen Skyddade användare kan du fortsätta att samla in granskningshändelser för säkerhetsloggar eller samla in data i de nya administrativa loggarna för drift. Mer information om dessa händelser finns i Autentiseringsprinciper och Silos för autentiseringsprincip

Tillhandahålla DC-skydd på domänkontrollantsidan för tjänster och datorer

Konton för tjänster och datorer kan inte vara medlemmar i skyddade användare. I det här avsnittet beskrivs vilka domänkontrollantbaserade skydd som kan erbjudas för dessa konton:

• Avvisa NTLM-autentisering: Kan endast konfigureras via NTLM-blockeringsprinciper

• Avvisa datakrypteringsstandard (DES) i Kerberos förautentisering: Windows Server 2012 R2-domänkontrollanter accepterar inte DES för datorkonton om de inte har konfigurerats för DES endast eftersom varje version av Windows som släpps med Kerberos också stöder RC4.

• Avvisa RC4 i Kerberos-förautentisering: kan inte konfigureras.

  Anmärkning

  Även om det är möjligt att ändra konfigurationen av krypteringstyper som stöds rekommenderar vi inte att du ändrar inställningarna för datorkonton utan att testa i målmiljön.

• Begränsa användarbiljetter (TGT) till en inledande livslängd på 4 timmar: Använd autentiseringsprinciper.

• Neka delegering med obegränsad eller begränsad delegering: Om du vill begränsa ett konto öppnar du Active Directory Administrationscenter (ADAC) och markerar kryssrutan Konto är känsligt och kan inte delegeras .

  

Autentiseringsprinciper

Autentiseringsprinciper är en ny container i AD DS som innehåller autentiseringsprincipobjekt. Autentiseringsprinciper kan ange inställningar som hjälper till att minska exponeringen för stöld av autentiseringsuppgifter, till exempel att begränsa TGT-livslängden för konton eller lägga till andra anspråksrelaterade villkor.

I Windows Server 2012 introducerade Dynamic Access Control en Active Directory-objektklass för skogsomfattning med namnet Central Access Policy för att ge ett enkelt sätt att konfigurera filservrar i en organisation. I Windows Server 2012 R2 kan en ny objektklass med namnet Authentication Policy (objectClass msDS-AuthNPolicies) användas för att tillämpa autentiseringskonfiguration på kontoklasser i Windows Server 2012 R2-domäner. Active Directory-kontoklasser är:

• Användare

• Dator

• Hanterat tjänstkonto och grupphanterat tjänstkonto (GMSA)

Snabb Kerberos-uppdatering

Kerberos-autentiseringsprotokollet består av tre typer av utbyten, även kallade subprotokoler:

• Autentiseringstjänsten (AS) Exchange (KRB_AS_*)

• Ticket-Granting Service (TGS) Exchange (KRB_TGS_*)

• Client/Server (AP) Exchange (KRB_AP_*)

AS-utbytet är där klienten använder kontots lösenord eller privata nyckel för att skapa en förautentisering för att begära en biljettbeviljande biljett (TGT). Detta sker vid användarinloggning eller första gången ett serviceärende behövs.

TGS-utbytet är platsen där kontots TGT används för att skapa en autentisering för att begära en tjänstbiljett. Detta inträffar när en autentiserad anslutning behövs.

AP-utbytet sker lika normalt som data i programprotokollet och påverkas inte av autentiseringsprinciper.

Mer detaljerad information finns i Så här fungerar Kerberos Version 5 Authentication Protocol.

Översikt

Autentiseringsprinciper kompletterar skyddade användare genom att tillhandahålla ett sätt att tillämpa konfigurerbara begränsningar på konton och genom att ange begränsningar för konton för tjänster och datorer. Autentiseringsprinciper tillämpas antingen under AS-utbytet eller TGS-utbytet.

Du kan begränsa den inledande autentiseringen eller AS-utbytet genom att konfigurera:

• En TGT-livslängd

• Åtkomstkontrollvillkor för att begränsa användarens inloggning, som måste uppfyllas av enheter från vilka AS-utbytet kommer

Du kan begränsa begäranden om tjänstbiljett via ett TGS-utbyte (ticket-granting service) genom att konfigurera:

• Åtkomstkontrollvillkor som måste uppfyllas av klienten (användare, tjänst, dator) eller enhet som TGS-utbytet kommer från

Krav för att använda autentiseringsprinciper

Begränsa ett användarkonto till specifika enheter och värdar

Ett konto med högt värde med administratörsbehörighet bör vara medlem i gruppen Skyddade användare . Som standard är inga konton medlemmar i gruppen Skyddade användare . Innan du lägger till konton i gruppen konfigurerar du stöd för domänkontrollanten och skapar en granskningsprincip för att säkerställa att det inte finns några blockeringsproblem.

Konfigurera stöd för domänkontrollant

Användarens kontodomän måste finnas på windows Server 2012 R2-domänens funktionsnivå (DFL). Kontrollera att alla domänkontrollanter är Windows Server 2012 R2 och använd sedan Active Directory Domains and Trusts för att höja DFL till Windows Server 2012 R2.

Så här konfigurerar du stöd för dynamisk åtkomstkontroll

1. I standardprincipen för domänkontrollanter klickar du på Aktiverad för att aktivera KDC-klientstöd (Key Distribution Center) för anspråk, sammansatt autentisering och Kerberos-skydd i Datorkonfiguration | Administrativa mallar | System | KDC.

   

2. Under Alternativ, i listrutan, välj Ange alltid anspråk.

   Anmärkning

   Stöds kan också konfigureras, men eftersom domänen finns på Windows Server 2012 R2 DFL kan användaranspråksbaserade åtkomstkontroller utföras när icke-anspråksmedvetna enheter och värdar ansluter till anspråksmedvetna tjänster.

   

   Varning

   Om du konfigurerar misslyckade obeväpnade autentiseringsbegäranden resulterar det i autentiseringsfel från alla operativsystem som inte stöder Kerberos-skydd, till exempel Windows 7 och tidigare operativsystem, eller operativsystem som börjar med Windows 8, som inte uttryckligen har konfigurerats för att stödja det.

Skapa en användarkontogranskning för autentiseringsprincip med ADAC

1. Öppna Active Directory Administrationscenter (ADAC).

   

   Anmärkning

   Den valda autentiseringsnoden är synlig för domäner som finns på Windows Server 2012 R2 DFL. Om noden inte visas försöker du igen med ett domänadministratörskonto från en domän som finns på Windows Server 2012 R2 DFL.

2. Klicka på Autentiseringsprinciper och sedan på Nytt för att skapa en ny princip.

   

   Autentiseringsprinciper måste ha ett visningsnamn och framtvingas som standard.

3. Om du vill skapa en princip endast för granskning klickar du på Endast granskningsprincipbegränsningar.

   

   Autentiseringsprinciper tillämpas baserat på Active Directory-kontotypen. En enskild princip kan tillämpas på alla tre kontotyperna genom att konfigurera inställningar för varje typ. Kontotyper är:

   • Användare

   • Dator

   • Hanterat tjänstkonto och grupphanterat tjänstkonto

   Om du har utökat schemat med nya huvudkonton som kan användas av Key Distribution Center (KDC) klassificeras den nya kontotypen från närmaste härledda kontotyp.

4. Om du vill konfigurera en TGT-livslängd för användarkonton markerar du kryssrutan Ange en Ticket-Granting Biljettlivslängd för användarkonton och anger tiden i minuter.

   

   Om du till exempel vill ha en maximal TGT-livslängd på 10 timmar anger du 600 som visas. Om ingen TGT-livslängd har konfigurerats är TGT-livslängden och förnyelsen 4 timmar om kontot är medlem i gruppen Skyddade användare . I annat fall baseras TGT-livslängden och förnyelsen på domänprincipen enligt följande fönster i redigeraren för grupprinciphantering för en domän med standardinställningar.

   

5. Om du vill begränsa användarkontot till att välja enheter klickar du på Redigera för att definiera de villkor som krävs för enheten.

   

6. I fönstret Redigera villkor för åtkomstkontroll klickar du på Lägg till ett villkor.

   

Lägga till datorkonto- eller gruppvillkor

1. Om du vill konfigurera datorkonton eller grupper går du till listrutan och väljer listrutan Medlem för var och en och ändrar till Medlem i valfri.

   Skärmbild som lyfter fram medlemmen i varje listruta.

   Anmärkning

   Den här åtkomstkontrollen definierar villkoren för den enhet eller värd som användaren loggar in från. I terminologin för åtkomstkontroll är datorkontot för enheten eller värden användaren, vilket är anledningen till att Användaren är det enda alternativet.

2. Klicka på Lägg till objekt.

   

3. Om du vill ändra objekttyper klickar du på Objekttyper.

   

4. Om du vill välja datorobjekt i Active Directory klickar du på Datorer och sedan på OK.

   

5. Ange namnet på datorerna för att begränsa användaren och klicka sedan på Kontrollera namn.

   

6. Klicka på OK och skapa andra villkor för datorkontot.

   

7. När du är klar klickar du på OK och de definierade villkoren visas för datorkontot.

   

Lägga till villkor för datoranspråk

1. För att konfigurera datoranspråk, använd listrutan Grupp för att välja anspråket.

   

   Anspråk är endast tillgängliga om de redan har etablerats i skogen.

2. Ange namnet på organisationsenheten. Användarkontot bör begränsas till inloggning.

   

3. När du är klar klickar du sedan på OK och rutan visar de definierade villkoren.

   

Felsök saknade datorreklamationer

Om anspråket har tillhandahållits men inte är tillgängligt kan det vara konfigurerat endast för datorklasser.

Anta att du ville begränsa autentiseringen baserat på organisationsenheten (OU) för datorn, som redan har konfigurerats, men bara för datorklasser .

Om anspråket ska vara tillgängligt för att begränsa användarens inloggning till enheten markerar du kryssrutan Användare .

Etablera ett användarkonto med en autentiseringsprincip med ADAC

1. Från användarkontot klickar du på Princip.

   

2. Markera kryssrutan Tilldela en autentiseringsprincip till det här kontot .

   

3. Välj sedan den autentiseringsprincip som ska tillämpas på användaren.

   

Konfigurera stöd för dynamisk åtkomstkontroll på enheter och värdar

Du kan konfigurera TGT-livslängder utan att konfigurera DAC (Dynamic Access Control). DAC behövs bara för att kontrollera AllowedToAuthenticateFrom och AllowedToAuthenticateTo.

Aktivera Kerberos-klientstöd för anspråk, sammansatt autentisering och Kerberos-skydd i Datorkonfiguration med hjälp av antingen grupprincip eller redigerare för lokal grupprincip | Administrativa mallar | System | Kerberos:

Felsöka autentiseringsprinciper

Fastställ de konton som är direkt tilldelade en autentiseringsprincip

Avsnittet "konton" i autentiseringspolicyn visar de konton som direkt har tillämpat policyn.

Använd administrationsloggen för fel i autentiseringspolicyer – domänkontrollant

Ett nytt autentiseringsprincipfel – Domänkontrollantens administrativa logg under Program- och tjänstloggar>Microsoft>Windows-autentisering> har skapats för att göra det enklare att identifiera fel på grund av autentiseringsprinciper. Loggen är inaktiverad som standard. Om du vill aktivera det högerklickar du på loggnamnet och klickar på Aktivera logg. De nya händelserna liknar de befintliga granskningshändelserna för Kerberos TGT och servicebegäran. Mer information om dessa händelser finns i Autentiseringsprinciper och Silos för autentiseringsprincip.

Hantera autentiseringsprinciper med hjälp av Windows PowerShell

Det här kommandot skapar en autentiseringsprincip med namnet TestAuthenticationPolicy. Parametern UserAllowedToAuthenticateFrom anger de enheter som användarna kan autentisera med en SDDL-sträng i filen med namnet someFile.txt.

PS C:\> New-ADAuthenticationPolicy testAuthenticationPolicy -UserAllowedToAuthenticateFrom (Get-Acl .\someFile.txt).sddl

Det här kommandot hämtar alla autentiseringsprinciper som matchar filtret som parametern Filter anger.

PS C:\> Get-ADAuthenticationPolicy -Filter "Name -like 'testADAuthenticationPolicy*'" -Server Server02.Contoso.com

Det här kommandot ändrar egenskaperna för beskrivningen och UserTGTLifetimeMins för den angivna autentiseringsprincipen.

PS C:\> Set-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1 -Description "Description" -UserTGTLifetimeMins 45

Det här kommandot tar bort den autentiseringsprincip som identitetsparametern anger.

PS C:\> Remove-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1

Det här kommandot använder cmdleten Get-ADAuthenticationPolicy med parametern Filter för att hämta alla autentiseringsprinciper som inte tillämpas. Resultatuppsättningen skickas till cmdleten Remove-ADAuthenticationPolicy .

PS C:\> Get-ADAuthenticationPolicy -Filter 'Enforce -eq $false' | Remove-ADAuthenticationPolicy

Silo för autentiseringsprinciper

Silos för autentiseringsprincip är en ny container (objectClass msDS-AuthNPolicySilos) i AD DS för användar-, dator- och tjänstkonton. De hjälper till att skydda konton med högt värde. Även om alla organisationer måste skydda medlemmar i företagsadministratörer, domänadministratörer och schemaadministratörsgrupper eftersom dessa konton kan användas av en angripare för att komma åt vad som helst i skogen, kan andra konton också behöva skydd.

Vissa organisationer isolerar arbetsbelastningar genom att skapa konton som är unika för dem och genom att tillämpa grupprincipinställningar för att begränsa lokala och fjärranslutna interaktiva inloggnings- och administratörsbehörigheter. Autentiseringspolisilor kompletterar det här arbetet genom att skapa ett sätt att definiera ett förhållande mellan användar-, dator- och hanterade tjänstkonton. Konton kan bara tillhöra en silo. Du kan konfigurera autentiseringsprincip för varje typ av konto för att styra:

1. Livslängd för icke-förnybar TGT

2. Åtkomstkontrollvillkor för att returnera TGT (Obs! kan inte tillämpas på system eftersom Kerberos-skydd krävs)

3. Åtkomstkontrollvillkor för att returnera tjänstbiljett

Dessutom har konton i en autentiseringspolicy-silo ett siloanspråk som kan användas av resurser som hanterar anspråk, som filservrar, för att kontrollera åtkomst.

En ny säkerhetsbeskrivning kan konfigureras för att styra utfärdande av serviceticket baserat på:

• Användare, användarens säkerhetsgrupper och/eller användarens anspråk

• Enhetens, enhetens säkerhetsgrupp och/eller enhetens anspråk

För att få den här informationen till resursens domänkontrollanter krävs Dynamisk Åtkomstkontroll.

• Användaranspråk:

  • Windows 8 och senare klienter som stöder dynamisk åtkomstkontroll

  • Kontodomänen stöder dynamisk åtkomstkontroll och anspråk

• Enhet och/eller enhetens säkerhetsgrupp:

  • Windows 8 och senare klienter som stöder dynamisk åtkomstkontroll

  • Resurs konfigurerad för sammansatt autentisering

• Enhetsanspråk:

  • Windows 8 och senare klienter som stöder dynamisk åtkomstkontroll

  • Enhetsdomänen stöder dynamisk åtkomstkontroll och anspråk

  • Resurs konfigurerad för sammansatt autentisering

Autentiseringsprinciper kan tillämpas på alla medlemmar i en silo för autentiseringsprinciper i stället för enskilda konton, eller så kan separata autentiseringsprinciper tillämpas på olika typer av konton i en silo. Till exempel kan en autentiseringsprincip tillämpas på användarkonton med hög behörighet och en annan princip kan tillämpas på tjänstkonton. Minst en autentiseringsprincip måste skapas innan en silo för autentiseringsprinciper kan skapas.

Du kan skapa en silo för autentiseringsprinciper med hjälp av Active Directory Administrationscenter eller Windows PowerShell. Som standard granskar en silo för autentiseringsprinciper endast siloprinciper, vilket motsvarar att ange parametern WhatIf i Windows PowerShell-cmdletar. I det här fallet gäller inga policybegränsningar, men revisioner utförs för att visa huruvida fel uppstår om begränsningarna genomförs.

Skapa en silo för autentiseringsprinciper med hjälp av Active Directory Administrationscenter

1. Öppna Active Directory Administrationscenter, klicka på Autentisering, högerklicka på Silos för autentiseringsprincip, klicka på Ny och klicka sedan på Silo för autentiseringsprincip.

   

2. I Visningsnamn skriver du ett namn för silon. I Tillåtna konton klickar du på Lägg till, skriver namnen på kontona och klickar sedan på OK. Du kan ange användare, datorer eller tjänstkonton. Ange sedan om du vill använda en enskild princip för alla huvudnamn eller en separat princip för varje typ av huvudnamn och namnet på principen eller principerna.

   

Hantera silor för autentiseringsprinciper med hjälp av Windows PowerShell

Det här kommandot skapar ett siloobjekt för autentiseringsprinciper och framtvingar det.

PS C:\>New-ADAuthenticationPolicySilo -Name newSilo -Enforce

Det här kommandot hämtar alla silor för autentiseringsprinciper som matchar filtret som anges av parametern Filter . Utdata skickas sedan till cmdleten Format-Table för att visa namnet på principen och värdet för Framtvinga för varje princip.

PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Name -like "*silo*"' | Format-Table Name, Enforce -AutoSize

Name  Enforce
----  -------
silo     True
silos   False

Det här kommandot använder cmdleten Get-ADAuthenticationPolicySilo med parametern Filter för att hämta alla silor för autentiseringsprinciper som inte tillämpas och skicka resultatet av filtret till cmdleten Remove-ADAuthenticationPolicySilo .

PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Enforce -eq $False' | Remove-ADAuthenticationPolicySilo

Det här kommandot ger åtkomst till silon för autentiseringsprinciper med namnet Silo till användarkontot User01.

PS C:\>Grant-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01

Det här kommandot återkallar åtkomsten till silon för autentiseringsprinciper med namnet Silo för användarkontot user01. Eftersom parametern Confirm är inställd på $False visas inget bekräftelsemeddelande.

PS C:\>Revoke-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01 -Confirm:$False

Det här exemplet använder först cmdleten Get-ADComputer för att hämta alla datorkonton som matchar filtret som parametern Filter anger. Utdata från det här kommandot skickas till Set-ADAccountAuthenticationPolicySilo för att tilldela silon för autentiseringsprinciper med namnet Silo och autentiseringsprincipen med namnet AuthenticationPolicy02 till dem.

PS C:\>Get-ADComputer -Filter 'Name -like "newComputer*"' | Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo Silo -AuthenticationPolicy AuthenticationPolicy02