Descrição do uso de AMA em cenários de logon interativo no Windows

Problemas do cenário 1 (logon/logoff)

Considere o seguinte cenário:

• Um administrador deseja impor a autenticação de Logon de cartão inteligente (SC) quando os usuários acessam determinados recursos sensíveis à segurança. Para fazer isso, o administrador implanta AMA de acordo com a Garantia do mecanismo de autenticação para o AD DS no guia passo a passo do Windows Server 2008 R2 para o identificador de objeto de diretiva de emissão é usado em todos os certificados de cartão inteligente.
  
  Observação: Neste artigo, nós nos referimos a esse novo grupo mapeado como "o grupo de segurança universal de cartão inteligente".
  

• O "logon interativo: requer um cartão inteligente" política não estiver habilitada em estações de trabalho. Portanto, os usuários podem fazer logon usando outras credenciais, como nome de usuário e senha.

• Local e o grupo de segurança universal de cartão inteligente requer o acesso aos recursos de rede.

Nesse cenário, você pode esperar que somente o usuário que assina usando cartões inteligentes pode acessar local e recursos de rede. No entanto, porque a estação de trabalho permite logon/em cache otimizado, é usado o verificador em cache durante o logon para criar o token de acesso do NT para o desktop do usuário. Portanto, os grupos de segurança e declarações de logon anterior são usadas em vez do atual.

Cenário 2 problemas (bloqueio e desbloqueio)

Considere o seguinte cenário:

• Um administrador deseja impor a autenticação de Logon de cartão inteligente (SC) quando os usuários acessam determinados recursos sensíveis à segurança. Para fazer isso, o administrador implanta AMA de acordo com a Garantia do mecanismo de autenticação para o AD DS no guia passo a passo do Windows Server 2008 R2 para o identificador de objeto de diretiva de emissão é usado em todos os certificados de cartão inteligente.

• O "logon interativo: requer um cartão inteligente" política não estiver habilitada em estações de trabalho. Portanto, os usuários podem fazer logon usando outras credenciais, como nome de usuário e senha.

• Local e o grupo de segurança universal de cartão inteligente requer o acesso aos recursos de rede.

Nesse cenário, você pode esperar que apenas um usuário que assina usando cartões inteligentes pode acessar local e recursos de rede. No entanto, como o token de acesso de área de trabalho do usuário é criado durante o logon, ele não será alterado.

Logon/logoff

Se Fast Logon optimization está ativo, o subsistema de segurança Local (lsass) usa o cache local para gerar a participação em grupos no token de logon. Fazendo isso, a comunicação com o controlador de domínio (DC) não é necessária. Portanto, o tempo de logon é reduzido. Esse é um recurso altamente desejável.

No entanto, essa situação causa o seguinte problema: após Logon SC e SC Logoff, o grupo AMA armazenadas em cache localmente é, incorretamente, ainda está presente no token de usuário após o logon interativo de nome/senha de usuário.

Observações:

• Essa situação se aplica somente a logons interativos.

• Um grupo AMA é armazenada em cache da mesma maneira e usando a mesma lógica de outros grupos.

Nessa situação, se o usuário tenta acessar recursos de rede, participação em grupo em cache no lado do recurso não é usada e sessão de logon do usuário no lado do recurso não contêm um grupo AMA.

Esse problema pode ser corrigido ao se desativar o Fast Logon Optimization ("configuração do computador > modelos administrativos > sistema > Logon > sempre esperar pela rede ao iniciar o computador e fazer logon").

Importante Esse comportamento é relevante apenas no cenário de logon interativo. Acesso aos recursos de rede irá funcionar como esperado porque não é necessário para a otimização do logon. Portanto, a participação em grupo em cache não é usada. O controlador de domínio é contatado para criar o novo tíquete usando as mais recentes informações de membros de grupo AMA.

Lock/unlock

Considere o seguinte cenário:

• Um usuário faz logon interativamente usando o cartão inteligente e abre os recursos de rede protegida AMA.
  
  Observação: Rede protegida AMA recursos podem ser acessados apenas usuários que possuam um grupo AMA em seu token de acesso.
  

• O usuário bloqueia o computador sem primeiro fechar o recurso de rede protegida AMA abertos anteriormente.

• O usuário desbloqueia o computador usando o nome de usuário e a senha do usuário mesmo que anteriormente logon usando um cartão inteligente).
  

Nesse cenário, o usuário ainda pode acessar os recursos protegidos AMA depois que o computador é desbloqueado. Esse comportamento é pré-definido. Quando o computador é desbloqueado, Windows não recriar todas as sessões abertas que tinham os recursos da rede. Windows também não verificar participação no grupo. Isso ocorre porque essas ações causaria penalidades de desempenho inaceitável.

Não há nenhuma solução out-of-box para esse cenário. Uma solução seria criar um filtro de provedor de credenciais que filtra o provedor de nome/senha de usuário após o logon SC e bloqueio de etapas ocorrerão. Para saber mais sobre o provedor de credenciais, consulte os seguintes recursos:

Interface de ICredentialProviderFilter

Exemplos de provedor de credenciais do Windows VistaObservação: Não podemos confirmar se esta abordagem já foi implementada com êxito.

Para obter mais informações sobre AMA

AMA não pode identificar nem aplicar o tipo de logon interativo (cartão inteligente ou nome de usuário/senha). Esse comportamento é pré-definido.

AMA destina-se a situações em que os recursos de rede exigem um cartão inteligente. Ele não deveria ser usado para acesso local.

Qualquer tentativa de correção do problema com a introdução de novos recursos, como a capacidade de usar os membros do grupo dinâmico ou a alça AMA grupos como um grupo dinâmico pode causar problemas significativos. É por isso símbolos NT não oferecem suporte a participações em grupos dinâmicos. Se o sistema permitidos grupos seja cortada em real, usuários poderá ser impedidos de interagir com sua própria área de trabalho e aplicativos. Portanto, participações em grupo bloqueadas no momento em que a sessão é criada e mantidas durante toda a sessão.

Logons em cache também são problemáticos. Se otimizado de logon estiver habilitada, o lsass tenta primeiro um cache local antes que ele invoca uma rede ida. Se o nome de usuário e a senha são idênticos ao que viu lsass para logon anterior (Isso é verdadeiro para a maioria dos logons), o lsass cria um token que tem os membros do grupo mesmo que o usuário tinha anteriormente.

Se o logon otimizado é desativado, uma resposta da rede seria necessária. Isso seria Certifique-se de que os membros do grupo funcionam no logon conforme o esperado.

Em um logon em cache, o lsass mantém uma entrada por usuário. Essa entrada inclui a associação de grupo do usuário anterior. Isso é protegido pela última senha ou credencial do cartão inteligente que viu lsass. Ambos decodificar a mesma chave de token e credenciais. Se os usuários tentar fazer logon usando uma chave de credencial obsoletos, eles seriam perder dados DPAPI, conteúdo protegido pelo EFS e assim por diante. Portanto, logons em cache sempre produzem os membros do grupo local mais recentes, independentemente do mecanismo usado para efetuar logon.