Sammanfattning
I den här artikeln beskrivs hur du använder AMA (Authentication Mechanism Assurance) i interaktiva inloggningsscenarier.
Inledning
AMA lägger till ett administratörsangivet, universellt gruppmedlemskap i en användares åtkomsttoken när användarens autentiseringsuppgifter autentiseras under inloggningen med hjälp av en certifikatbaserad inloggningsmetod. Det gör det möjligt för nätverksresursadministratörer att styra åtkomsten till resurser, till exempel filer, mappar och skrivare. Den här åtkomsten baseras på om användaren loggar in med en certifikatbaserad inloggningsmetod och vilken typ av certifikat som används för att logga in.
I den här artikeln
Den här artikeln fokuserar på två problemscenarier: inloggning/utloggning och lås/lås upp. Beteendet för AMA i dessa scenarier är "avsiktligt" och kan sammanfattas på följande sätt:
-
AMA är avsett att skydda nätverksresurser.
-
AMA kan varken identifiera eller tillämpa den interaktiva inloggningstypen (smartkort eller användarnamn/lösenord) för användarens lokala dator. Det beror på att resurser som används efter en interaktiv användarinloggning inte kan skyddas med hjälp av AMA.
Symptom
Problemscenario 1 (inloggning/utloggning)
Tänk dig följande situation:
-
En administratör vill tillämpa smartkortsautentisering (SC) inloggning när användare får åtkomst till vissa säkerhetskänsliga resurser. Det gör du genom att administratören distribuerar AMA enligt Authentication Mechanism Assurance för AD DS i Windows Server 2008 R2 – steg-för-steg-guide för den utfärdarprincipobjektidentifierare som används i alla smartkortscertifikat. Obs! I den här artikeln kallar vi den här nya mappade gruppen för "den universella säkerhetsgruppen för smartkort".
-
Principen Interaktiv inloggning: Kräv smartkort är inte aktiverad på arbetsstationer. Därför kan användare logga in med andra autentiseringsuppgifter, till exempel användarnamn och lösenord.
-
Åtkomst till lokala resurser och nätverksresurser kräver den universella säkerhetsgruppen för smartkort.
I det här scenariot förväntar du dig att endast användare som loggar in med smartkort kan komma åt lokala resurser och nätverksresurser. Men eftersom arbetsstationen tillåter optimerad/cachelagrad inloggning används den cachelagrade verifieraren under inloggningen för att skapa NT-åtkomsttoken för användarens skrivbord. Därför används säkerhetsgrupperna och anspråken från den tidigare inloggningen i stället för den aktuella.
Scenarioexempel
Obs! I den här artikeln hämtas gruppmedlemskap för interaktiva inloggningssessioner med hjälp av "whoami/groups". Det här kommandot hämtar grupperna och anspråken från skrivbordets åtkomsttoken.
-
Exempel 1Om den tidigare inloggningen utfördes med ett smartkort har åtkomsttoken för skrivbordet den universella säkerhetsgruppen för smartkort som tillhandahålls av AMA. Ett av följande resultat uppstår:
-
Användaren loggar in med smartkortet: Användaren kan fortfarande komma åt lokala säkerhetskänsliga resurser. Användaren försöker komma åt nätverksresurser som kräver den universella säkerhetsgruppen för smartkort. Försöken lyckas.
-
Användaren loggar in med användarnamn och lösenord: Användaren kan fortfarande komma åt lokala säkerhetskänsliga resurser. Det här resultatet förväntas inte. Användaren försöker komma åt nätverksresurser som kräver den universella säkerhetsgruppen för smartkort. Dessa försök misslyckas som förväntat.
-
-
Exempel 2Om den tidigare inloggningen utfördes med ett lösenord har inte åtkomsttoken för skrivbordet den universella säkerhetsgruppen för smartkort som tillhandahålls av AMA. Ett av följande resultat uppstår:
-
Användaren loggar in med ett användarnamn och lösenord: Användaren kan inte komma åt lokala säkerhetskänsliga resurser. Användaren försöker komma åt nätverksresurser som kräver den universella säkerhetsgruppen för smartkort. Försöken misslyckas.
-
Användaren loggar in med smartkortet: Användaren kan inte komma åt lokala säkerhetskänsliga resurser. Användaren försöker komma åt nätverksresurser. Försöken lyckas. Det här resultatet förväntas inte av kunderna. Därför orsakar det problem med åtkomstkontroll.
-
Problemscenario 2 (lås/lås upp)
Tänk på följande scenario:
-
En administratör vill tillämpa smartkortsautentisering (SC) inloggning när användare får åtkomst till vissa säkerhetskänsliga resurser. Det gör du genom att administratören distribuerar AMA enligt Authentication Mechanism Assurance för AD DS i Windows Server 2008 R2 Step-by-Step Guide för den utfärdarprincipobjektidentifierare som används i alla smartkortscertifikat.
-
Principen Interaktiv inloggning: Kräv smartkort är inte aktiverad på arbetsstationer. Därför kan användare logga in med andra autentiseringsuppgifter, till exempel användarnamn och lösenord.
-
Åtkomst till lokala resurser och nätverksresurser kräver den universella säkerhetsgruppen för smartkort.
I det här scenariot förväntar du dig att endast en användare som loggar in med smartkort kan komma åt lokala resurser och nätverksresurser. Men eftersom åtkomsttoken för användarens skrivbord skapas under inloggningen ändras den inte.
Scenarioexempel
-
Exempel 1Om åtkomsttoken för skrivbordet har den universella säkerhetsgruppen för smartkort som tillhandahålls av AMA, uppstår något av följande resultat:
-
Användaren låser upp med hjälp av smartkortet: Användaren kan fortfarande komma åt lokala säkerhetskänsliga resurser. Användaren försöker komma åt nätverksresurser som kräver den universella säkerhetsgruppen för smartkort. Försöken lyckas.
-
Användaren låser upp genom att använda användarnamn och lösenord: Användaren kan fortfarande komma åt lokala säkerhetskänsliga resurser. Det här resultatet förväntas inte. Användaren försöker komma åt nätverksresurser som kräver den universella säkerhetsgruppen för smartkort. Försöken misslyckas.
-
-
Exempel 2Om åtkomsttoken för skrivbordet inte har den universella säkerhetsgruppen för smartkort som tillhandahålls av AMA, uppstår något av följande resultat:
-
Användaren låser upp med användarnamn och lösenord: Användaren kan inte komma åt lokala säkerhetskänsliga resurser. Användaren försöker komma åt nätverksresurser som kräver den universella säkerhetsgruppen för smartkort. Försöken misslyckas.
-
Användaren låser upp med hjälp av smartkortet: Användaren kan inte komma åt lokala säkerhetskänsliga resurser. Det här resultatet förväntas inte. Användaren försöker komma åt nätverksresurser. Dessa försök lyckas som förväntat.
-
Mer information
På grund av designen för AMA och säkerhetsundersystem som beskrivs i avsnittet Symptom upplever användarna följande scenarier där AMA inte kan identifiera typen av interaktiv inloggning på ett tillförlitligt sätt.
Inloggning/utloggning
Om Snabb inloggningsoptimering är aktivt använder det lokala säkerhetsundersystemet (lsass) lokal cache för att generera gruppmedlemskap i inloggningstoken. Genom att göra detta krävs inte kommunikation med domänkontrollanten (DC). Därför minskas inloggningstiden. Detta är mycket önskvärt funktion.Den här situationen orsakar dock följande problem: Efter SC-inloggning och SC-utloggning finns den lokalt cachelagrade AMA-gruppen felaktigt kvar i användartoken efter den interaktiva inloggningen med användarnamn/lösenord.Anteckningar
-
Den här situationen gäller endast interaktiva inloggningar.
-
En AMA-grupp cachelagrats på samma sätt och med samma logik som andra grupper.
Om användaren sedan försöker komma åt nätverksresurser används inte cachelagrat gruppmedlemskap på resurssidan och användarens inloggningssession på resurssidan innehåller ingen AMA-grupp.Det här problemet kan åtgärdas genom att inaktivera Snabb inloggningsoptimering ("Datorkonfiguration > administrativa mallar > system > inloggning > vänta alltid på nätverket vid datorns start och inloggning"). Viktigt Det här beteendet är bara relevant i det interaktiva inloggningsscenariot. Åtkomst till nätverksresurser fungerar som förväntat eftersom det inte finns något behov av inloggningsoptimering. Därför används inte cachelagrat gruppmedlemskap. DC kontaktas för att skapa den nya biljetten med hjälp av den senaste informationen om AMA-gruppmedlemskap.
Låsa/låsa upp
Tänk på följande scenario:
-
En användare loggar in interaktivt med smartkortet och öppnar sedan AMA-skyddade nätverksresurser.Obs! AMA-skyddade nätverksresurser kan endast nås av användare som har en AMA-grupp i sin åtkomsttoken.
-
Användaren låser datorn utan att först stänga den tidigare öppnade AMA-skyddade nätverksresursen.
-
Användaren låser upp datorn med användarnamn och lösenord för samma användare som tidigare loggat in med ett smartkort.
I det här scenariot kan användaren fortfarande komma åt de AMA-skyddade resurserna efter att datorn har låsts upp. Detta är avsiktligt. När datorn är upplåst återskapas inte alla öppna sessioner med nätverksresurser. Windows kontrollerar inte heller gruppmedlemskap igen. Detta beror på att dessa åtgärder skulle orsaka oacceptabla prestationsstraff.Det finns ingen out-of-box-lösning för det här scenariot. En lösning skulle vara att skapa ett filter för provider för autentiseringsuppgifter som filtrerar bort användarnamn/lösenordsprovidern efter att SC-inloggnings- och låsstegen har utförts. Mer information om provider för autentiseringsuppgifter finns i följande resurser:
Gränssnittet ICredentialProviderFilter Exempel på autentiseringsprovider för Windows VistaObs! Vi kan inte bekräfta om den här metoden någonsin har implementerats.
Mer information om AMA
AMA kan varken identifiera eller tillämpa den interaktiva inloggningstypen (smartkort eller användarnamn/lösenord). Detta är avsiktligt.AMA är avsett för scenarier där nätverksresurser kräver ett smartkort. Den är inte avsedd att användas för lokal åtkomst.Alla försök att åtgärda problemet genom att införa nya funktioner, till exempel möjligheten att använda dynamiskt gruppmedlemskap eller hantera AMA-grupper som en dynamisk grupp, kan orsaka betydande problem. Det är därför NT-token inte har stöd för dynamiska gruppmedlemskap. Om systemet tillät att grupper trimmades på riktigt kan användare hindras från att interagera med sina egna skrivbord och program. Därför är gruppmedlemskap låsta när sessionen skapas och underhålls under hela sessionen.Cachelagrade inloggningar är också problematiska. Om optimerad inloggning är aktiverad försöker lsass först en lokal cache innan en nätverksrunda aktiveras. Om användarnamnet och lösenordet är identiska med det som lsass såg för den tidigare inloggningen (detta gäller de flesta inloggningar) skapar lsass en token som har samma gruppmedlemskap som användaren tidigare hade. Om optimerad inloggning är inaktiverat krävs ett nätverksrunda. På så sätt ser du till att gruppmedlemskapen fungerar som förväntat vid inloggning.I en cachelagrade inloggning behåller lsass en post per användare. Den här posten omfattar användarens tidigare gruppmedlemskap. Detta skyddas av både det senaste lösenordet eller smartkortsautentiseringsuppgifterna som lsass såg. Båda skriver upp samma token- och autentiseringsnyckel. Om användarna skulle försöka logga in med en inaktuell autentiseringsnyckel förlorar de DPAPI-data, EFS-skyddat innehåll och så vidare. Cachelagrade inloggningar ger därför alltid de senaste lokala gruppmedlemskapen, oavsett vilken mekanism som används för att logga in.
