Descrizione dell'utilizzo AMA negli scenari di accesso interattivo in Windows

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.

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.

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.