Descrição da utilização do AMA em cenários de início de sessão interativos no Windows

Cenário do Problema 1 (início de sessão/fim de sessão)

Considere o seguinte cenário:

• Um administrador quer impor a autenticação de Início de Sessão do Smart Card (SC) quando os utilizadores acedem a determinados recursos confidenciais de segurança. Para tal, o administrador implementa o 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 política de emissão utilizado em todos os certificados de card inteligentes.
  
  Nota Neste artigo, referimo-nos a este novo grupo mapeado como "o grupo de segurança universal card inteligente".
  

• A política "Início de sessão interativo: Exigir card inteligente" não está ativada nas estações de trabalho. Por conseguinte, os utilizadores podem iniciar sessão com outras credenciais, como o nome de utilizador e a palavra-passe.

• O acesso a recursos locais e de rede requer o grupo de segurança universal card inteligente.

Neste cenário, espera que apenas o utilizador que inicia sessão através de smart cards possa aceder aos recursos locais e de rede. No entanto, como a estação de trabalho permite o início de sessão otimizado/em cache, o verificador em cache é utilizado durante o início de sessão para criar o token de acesso NT para o ambiente de trabalho do utilizador. Por conseguinte, os grupos de segurança e as afirmações do início de sessão anterior são utilizados em vez do atual.

Cenário de Problema 2 (bloqueio/desbloqueio)

Considere o seguinte cenário:

• Um administrador quer impor a autenticação de Início de Sessão do Smart Card (SC) quando os utilizadores acedem a determinados recursos confidenciais de segurança. Para tal, o administrador implementa o 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 política de emissão utilizado em todos os certificados de card inteligentes.

• A política "Início de sessão interativo: Exigir card inteligente" não está ativada nas estações de trabalho. Por conseguinte, os utilizadores podem iniciar sessão com outras credenciais, como o nome de utilizador e a palavra-passe.

• O acesso a recursos locais e de rede requer o grupo de segurança universal card inteligente.

Neste cenário, espera que apenas um utilizador que inicie sessão através de smart cards possa aceder aos recursos locais e de rede. No entanto, como o token de acesso para o ambiente de trabalho do utilizador é criado durante o início de sessão, não é alterado.

Início de sessão/fim de sessão

Se a otimização do Início de Sessão Rápido estiver ativa, o Subsistema de Segurança Local (lsass) utiliza a cache local para gerar associação a grupos no token de início de sessão. Ao fazê-lo, a comunicação com o controlador de domínio (DC) não é necessária. Por conseguinte, o tempo de início de sessão é reduzido. Esta funcionalidade é altamente desejável.

No entanto, esta situação causa o seguinte problema: após o início de sessão sc e o início de sessão SC, o grupo AMA em cache localmente ainda está, incorretamente, presente no token de utilizador após o início de sessão interativo do nome de utilizador/palavra-passe.

Notas

• Esta situação aplica-se apenas a inícios de sessão interativos.

• Um grupo AMA é colocado em cache da mesma forma e através da mesma lógica que outros grupos.

Nesta situação, se o utilizador tentar aceder aos recursos de rede, a associação a grupos em cache no lado do recurso não é utilizada e a sessão de início de sessão do utilizador no lado do recurso não conterá um grupo AMA.

Este problema pode ser corrigido ao desativar a Otimização rápida de Início de Sessão ("Configuração do Computador > Modelos Administrativos > Sistema > Início de Sessão > Aguarde sempre pela rede no arranque e início de sessão do computador").

Importante Este comportamento é relevante apenas no cenário de início de sessão interativo. O acesso aos recursos de rede funcionará conforme esperado porque não é necessário otimizar o início de sessão. Por conseguinte, a associação a grupos em cache não é utilizada. O DC é contactado para criar o novo pedido de suporte com as informações de associação do grupo AMA mais recentes.

Bloquear/desbloquear

Considere o seguinte cenário:

• Um utilizador inicia sessão interativamente com a card inteligente e, em seguida, abre os recursos de rede protegidos pelo AMA.
  
  Tenha em atenção que os recursos de rede protegidos pelo AMA só podem ser acedidos a utilizadores que tenham um grupo AMA no respetivo token de acesso.
  

• O utilizador bloqueia o computador sem primeiro fechar o recurso de rede protegido por AMA anteriormente aberto.

• O utilizador desbloqueia o computador com o nome de utilizador e a palavra-passe do mesmo utilizador que iniciou sessão anteriormente através de uma card inteligente).
  

Neste cenário, o utilizador ainda pode aceder aos recursos protegidos pelo AMA depois de o computador ser desbloqueado. Este é o comportamento padrão. Quando o computador é desbloqueado, o Windows não recria todas as sessões abertas que tinham recursos de rede. O Windows também não verifica novamente a associação a grupos. Isto deve-se ao facto de estas acções provocarem penalizações de desempenho inaceitáveis.

Não há nenhuma solução fora de caixa para este cenário. Uma solução seria criar um filtro provedor de credenciais que filtra o provedor de nome de usuário/senha após a ocorrência das etapas de logon e bloqueio de SC. Para saber mais sobre o Provedor de Credenciais, confira os seguintes recursos:

Interface

ICredentialProviderFilterExemplos de provedor de credenciais do Windows VistaObservação Não podemos confirmar se essa abordagem foi implementada com êxito.

Mais informações sobre a AMA

A AMA não pode identificar nem impor o tipo de logon interativo (smart card ou nome de usuário/senha). Este é o comportamento padrão.

A AMA destina-se a cenários nos quais os recursos de rede exigem uma card inteligente. Não se destina a ser usado para acesso local.

Qualquer tentativa de corrigir esse problema introduzindo novos recursos, como a capacidade de usar a associação dinâmica de grupo ou lidar com grupos AMA como um grupo dinâmico, pode causar problemas significativos. É por isso que os tokens NT não dão suporte a associações dinâmicas de grupo. Se o sistema permitisse que grupos fossem cortados em real, os usuários poderão ser impedidos de interagir com sua própria área de trabalho e aplicativos. Portanto, as associações de grupo são bloqueadas no momento em que a sessão é criada e são mantidas durante toda a sessão.

Logons armazenados em cache também são problemáticos. Se o logon otimizado estiver habilitado, o lsass primeiro tentará um cache local antes de invocar uma viagem de ida e volta de rede. Se o nome de usuário e a senha forem idênticos ao que o lsass viu para o logon anterior (isso é verdadeiro para a maioria dos logons), o lsass cria um token que tem as mesmas associações de grupo que o usuário tinha anteriormente. 

Se o logon otimizado for desativado, será necessária uma ida e volta de rede. Isso garantirá que as associações de grupo funcionem no logon conforme o esperado.

Em um logon armazenado em cache, o lsass mantém uma entrada por usuário. Essa entrada inclui a associação de grupo anterior do usuário. Isso é protegido pela última senha ou pela credencial de card inteligente que o lsass viu. Ambos desembrulhar o mesmo token e a chave de credencial. Se os usuários tentassem fazer logon usando uma chave de credencial obsoleta, eles perderiam dados DPAPI, conteúdo protegido por EFS e assim por diante. Portanto, logons armazenados em cache sempre produzem as associações de grupo local mais recentes, independentemente do mecanismo usado para fazer logon.