Riepilogo
In questo articolo viene illustrato come utilizzare l'autenticazione meccanismo di garanzia (AMA) negli scenari di accesso interattivo.
Introduzione
AMA aggiunge un'appartenenza a gruppo universale, designata amministratore un token di accesso quando l'autenticazione delle credenziali dell'utente durante l'accesso utilizzando un metodo di accesso basate su certificati. In questo modo gli amministratori di risorse di rete di controllare l'accesso a risorse quali file, cartelle e stampanti. Questo accesso si basa su se l'utente accede utilizzando un metodo di accesso basato sui certificati e il tipo di certificato utilizzato per l'accesso.
In questo articolo
Questo articolo è incentrato su due scenari di problema: accesso/fine sessione e Blocca/Sblocca. Il comportamento di AMA in questi scenari è "by design" e può essere riepilogato come segue:
-
AMA è destinato a proteggere le risorse di rete.
-
AMA può identificare né applicare il tipo di accesso interattivo (smart card o nome utente e password) per computer locale dell'utente. In questo modo le risorse accessibili dopo l'accesso un utente interattivo non possono essere protetti in modo affidabile utilizzando AMA.
Sintomi
Problema Scenario 1 (accesso/fine sessione)
Si consideri lo scenario seguente:
-
Un amministratore desidera applicare l'autenticazione di accesso Smart Card (SC) quando gli utenti accedere a determinate risorse riservate. A tale scopo, l'amministratore distribuisce AMA secondo la Verifica del meccanismo di autenticazione di dominio Active Directory in Windows Server 2008 R2 Step Guide per l'identificatore di oggetto Criteri di rilascio utilizzato in tutti i certificati smart card. Nota: In questo articolo, si fa riferimento al nuovo gruppo mappato come "gruppo di protezione universale smart card."
-
il "accesso interattivo: Richiedi smart card" criterio non è attivato sulle workstation. Pertanto, gli utenti possono accedere tramite altre credenziali, quali nome utente e password.
-
Locale e il gruppo di protezione universale delle smart card richiede l'accesso alle risorse di rete.
In questo scenario, si prevede che soltanto l'utente che accede utilizzando le smart card può accedere locale e risorse di rete. Tuttavia, poiché la workstation consente l'accesso ottimizzato cache, il verificatore memorizzato nella cache viene utilizzato durante l'accesso per creare il token di accesso NT per il desktop dell'utente. Pertanto, anziché quella corrente vengono utilizzati i gruppi di protezione e richieste di accesso precedente.
Esempi di scenario
Nota: In questo articolo, appartenenza al gruppo viene recuperato per le sessioni di accesso interattivo tramite "whoami/gruppi". Questo comando recupera i gruppi e le attestazioni dal token di accesso del desktop.
-
Esempio 1
Se l'accesso precedente è stata eseguita utilizzando una smart card, il gruppo di protezione universale delle smart card fornito da AMA il token di accesso per il desktop. Si verifica uno dei seguenti risultati:-
L'utente accede utilizzando la smart card: l'utente potrà comunque accedere alle risorse sensibili di protezione locale. L'utente tenta di accedere alle risorse di rete che richiedono il gruppo di protezione universale delle smart card. Questi tentativi hanno esito positivo.
-
L'utente accede utilizzando il nome utente e password: l'utente potrà comunque accedere alle risorse sensibili di protezione locale. Questo risultato non è previsto. L'utente tenta di accedere alle risorse di rete che richiedono il gruppo di protezione universale delle smart card. Questi tentativi non riusciti nel modo previsto.
-
-
Esempio 2
Se l'accesso precedente è stata eseguita utilizzando una password, il token di accesso per il desktop è presente il gruppo di protezione universale delle smart card fornito da AMA. Si verifica uno dei seguenti risultati:-
L'utente accede utilizzando un nome utente e password: l'utente non può accedere alle risorse sensibili di protezione locale. L'utente tenta di accedere alle risorse di rete che richiedono il gruppo di protezione universale delle smart card. Questi tentativi non riusciti.
-
L'utente accede utilizzando la smart card: l'utente non può accedere alle risorse sensibili di protezione locale. L'utente tenta di accedere alle risorse di rete. Questi tentativi hanno esito positivo. Questo risultato non è previsto dai clienti. Pertanto, in access i problemi di controllo.
-
Problema Scenario 2 (bloccato/sbloccato)
Si consideri lo scenario seguente:
-
Un amministratore desidera applicare l'autenticazione di accesso Smart Card (SC) quando gli utenti accedere a determinate risorse riservate. A tale scopo, l'amministratore distribuisce AMA in base alla Verifica del meccanismo di autenticazione di dominio Active Directory in Windows Server 2008 R2 Step Guide per l'identificatore di oggetto Criteri di rilascio utilizzato in tutti i certificati smart card.
-
il "accesso interattivo: Richiedi smart card" criterio non è attivato sulle workstation. Pertanto, gli utenti possono accedere tramite altre credenziali, quali nome utente e password.
-
Locale e il gruppo di protezione universale delle smart card richiede l'accesso alle risorse di rete.
In questo scenario, si prevede che solo un utente che accede utilizzando smart card può accedere a locale e risorse di rete. Tuttavia, poiché il token di accesso per il desktop dell'utente viene creato durante l'accesso, esso non viene modificato.
Esempi di scenario
-
Esempio 1
Se il token di accesso per il desktop è il gruppo di protezione universale delle smart card fornito da AMA, si verifica uno dei seguenti risultati:-
Consente di sbloccare l'utente utilizzando la smart card: l'utente potrà comunque accedere alle risorse sensibili di protezione locale. L'utente tenta di accedere alle risorse di rete che richiedono il gruppo di protezione universale delle smart card. Questi tentativi hanno esito positivo.
-
Consente di sbloccare l'utente utilizzando il nome utente e password: l'utente potrà comunque accedere alle risorse sensibili di protezione locale. Questo risultato non è previsto. L'utente tenta di accedere alle risorse di rete che richiedono il gruppo di protezione universale delle smart card. Questi tentativi non riusciti.
-
-
Esempio 2
Se il token di accesso per il desktop non è fornito da AMA il gruppo di protezione universale delle smart card, si verifica uno dei seguenti risultati:-
Consente di sbloccare l'utente utilizzando il nome utente e password: l'utente non può accedere alle risorse sensibili di protezione locale. L'utente tenta di accedere alle risorse di rete che richiedono il gruppo di protezione universale delle smart card. Questi tentativi non riusciti.
-
Consente di sbloccare l'utente utilizzando la smart card: l'utente non può accedere alle risorse sensibili di protezione locale. Questo risultato non è previsto. L'utente tenta di accedere alle risorse di rete. Questi tentativi di successo come previsto.
-
Ulteriori informazioni
A causa della progettazione AMA e sottosistema di protezione è descritto nella sezione "Sintomi", i seguenti scenari in cui AMA non può identificare in modo affidabile il tipo di accesso interattivo è che gli utenti.
Logon/logoff
Se l'ottimizzazione di accesso rapido è attivo, il sottosistema di protezione locale (lsass) utilizza cache locale per generare l'appartenenza ai gruppi nel token di accesso. In questo modo la comunicazione con il controller di dominio (DC) non è necessaria. Di conseguenza, diminuisce il tempo di accesso. Si tratta di funzionalità estremamente utili.
Tuttavia, questa situazione determina il seguente problema: dopo accesso SC e disconnessione SC, il gruppo AMA nella cache locale è, in modo errato, ancora presente nel token utente dopo l'accesso interattivo di nome e password utente. Note-
Questa situazione si applica soltanto agli accessi interattivi.
-
Un gruppo AMA viene memorizzato nella cache nello stesso modo e utilizzando la stessa logica di come altri gruppi.
In questo caso, se si tenta di accedere alle risorse di rete, non viene utilizzata l'appartenenza di gruppo nella cache sul lato risorse e la sessione di accesso dell'utente sul lato risorse non deve contenere un gruppo AMA. Questo problema può risolto disattivando l'ottimizzazione dell'accesso rapido ("Configurazione Computer > modelli amministrativi > sistema > accesso > Attendi sempre disponibilità rete all'avvio del computer e all'accesso"). Importante Questo comportamento è rilevante solo per lo scenario di accesso interattivo. Accesso alle risorse di rete funzioneranno come previsto perché non è necessario per l'ottimizzazione dell'accesso. Pertanto, non viene utilizzata nella cache di appartenenza. Per creare il nuovo ticket utilizzando le informazioni di appartenenza gruppo AMA sempre aggiornate, viene contattato il controller di dominio.
Lock/unlock
Si consideri lo scenario seguente:
-
Un utente accede in modo interattivo utilizzando la smart card, quindi apre risorse di rete protette da AMA.
Nota: Rete protetta da AMA le risorse possono essere accessibile solo agli utenti che dispongono di un gruppo AMA i token di accesso. -
L'utente blocca il computer senza prima chiudere la risorsa di rete protetto AMA precedentemente aperti.
-
L'utente Sblocca il computer utilizzando il nome utente e password dell'utente stesso che ha già eseguito l'accesso utilizzando una smart card).
In questo scenario, l'utente può accedere le risorse protette da AMA dopo che il computer viene sbloccato. Questo è il comportamento previsto. Quando il computer viene sbloccato, Windows non ricreare tutte le sessioni aperte con le risorse di rete. Windows inoltre non ricontrollare appartenenza al gruppo. Questo avviene perché queste azioni provocare effetti negativi sulle prestazioni inaccettabili.
Non vi è alcuna soluzione out-of-box per questo scenario. Una soluzione, è possibile creare un filtro di Provider di credenziali che esclude il provider di nome e password utente dopo l'accesso SC e vengono eseguite operazioni di blocco. Per ulteriori informazioni sui Provider di credenziali, vedere le risorse seguenti:Interfaccia ICredentialProviderFilter Esempi di Provider credenziali di Windows VistaNota: È Impossibile verificare se questo approccio è mai stato implementato con successo.
Ulteriori informazioni su AMA
AMA può identificare né applicare il tipo di accesso interattivo (smart card o nome utente e password). Questo è il comportamento previsto.
AMA è destinato a scenari in cui le risorse di rete richiedono una smart card. Non è destinata a essere utilizzato per l'accesso locale. Qualsiasi tentativo di risolvere il problema mediante l'introduzione di nuove funzionalità, come la possibilità di utilizzare l'appartenenza al gruppo dinamico o ai gruppi AMA handle come gruppo dinamico, potrebbe provocare problemi significativi. Questo è il motivo token NT non supportano le appartenenze di gruppo dinamico. Se il sistema di gruppi da tagliare in reale, gli utenti potrebbero essere impediti che interagiscono con i propri desktop e applicazioni. Pertanto, appartenenze ai gruppi sono bloccate nel momento in cui viene creata una sessione e vengono mantenute per tutta la sessione. Inoltre, gli accessi alla cache sono problematici. Se è attivato l'accesso ottimizzato, lsass tenterà una cache locale prima di richiamare una rete percorso andata/ritorno. Se il nome utente e password sono identici a quello visualizzato lsass per l'accesso precedente (questo è vero per la maggior parte degli accessi), lsass crea un token che ha le stesse appartenenze che l'utente disponeva in precedenza. Se viene disattivato l'accesso ottimizzato, un percorso di andata e rete sarebbero necessaria. Questo sarebbe, assicurarsi che le appartenenze ai gruppi di lavoro all'accesso come previsto. In un accesso alla cache lsass mantiene una voce per ogni utente. Questa voce comprende l'appartenenza al gruppo precedente dell'utente. Questo è protetto da entrambi gli ultima password o credenziali smart card che osservati in lsass. Entrambi unwrap la stessa chiave di token e credenziali. Se gli utenti per tentare di accedere al sistema utilizzando una chiave delle credenziali non aggiornati, vengono perse DPAPI dati contenuto protetto con crittografia file System e così via. Pertanto, gli accessi alla cache produce sempre l'appartenenza ai gruppi locali più recenti, indipendentemente dal sistema utilizzato per l'accesso.