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 smart card.
  
  Nota Neste artigo, referimo-nos a este novo grupo mapeado como "o grupo de segurança universal de smart card".
  

• A política "Início de sessão interativo: Exigir smart card" 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 de smart card.

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 smart card.

• A política "Início de sessão interativo: Exigir smart card" 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 de smart card.

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 o smart card 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 utilizando o nome de utilizador e a palavra-passe do mesmo utilizador que iniciou sessão anteriormente através de um smart card).
  

Neste cenário, o utilizador ainda pode aceder aos recursos protegidos pelo AMA depois de o computador ser desbloqueado. Este comportamento é por predefiniçã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 existe nenhuma solução inicial para este cenário. Uma solução seria criar um filtro do Fornecedor de Credenciais que filtra o fornecedor de nome de utilizador/palavra-passe após a ocorrência dos passos de início de sessão e bloqueio do SC. Para saber mais sobre o Fornecedor de Credenciais, veja os seguintes recursos:

Interface ICredentialProviderFilter

Exemplos do Fornecedor de Credenciais do Windows VistaNota Não podemos confirmar se esta abordagem foi implementada com êxito.

Mais informações sobre o AMA

O AMA não consegue identificar nem impor o tipo de início de sessão interativo (smart card ou nome de utilizador/palavra-passe). Este comportamento é por predefinição.

A AMA destina-se a cenários em que os recursos de rede exigem um smart card. Não se destina a ser utilizado para acesso local.

Qualquer tentativa de corrigir este problema ao introduzir novas funcionalidades, como a capacidade de utilizar a associação a grupos dinâmicos ou processar grupos AMA como um grupo dinâmico, pode causar problemas significativos. É por isso que os tokens NT não suportam associações a grupos dinâmicos. Se o sistema permitiu que os grupos fossem cortados de forma real, os utilizadores poderiam ser impedidos de interagir com o seu próprio ambiente de trabalho e aplicações. Por conseguinte, as associações a grupos são bloqueadas no momento em que a sessão é criada e são mantidas ao longo da sessão.

Os inícios de sessão em cache também são problemáticos. Se o início de sessão otimizado estiver ativado, o lsass tenta primeiro uma cache local antes de invocar um percurso de ida e volta de rede. Se o nome de utilizador e a palavra-passe forem idênticos ao que o lsass viu para o início de sessão anterior (isto é verdade para a maioria dos inícios de sessão), o lsass cria um token que tem as mesmas associações de grupo que o utilizador tinha anteriormente. 

Se o início de sessão otimizado estiver desativado, será necessária uma ida e volta de rede. Isto garantiria que as associações a grupos funcionam no início de sessão conforme esperado.

Num início de sessão em cache, o lsass mantém uma entrada por utilizador. Esta entrada inclui a associação de grupo anterior do utilizador. Esta opção está protegida pela última palavra-passe ou credencial de smart card que o LSASS viu. Desembrulham o mesmo token e a mesma chave de credencial. Se os utilizadores tentassem iniciar sessão com uma chave de credencial obsoleta, perderiam dados DPAPI, conteúdo protegido por EFS, etc. Por conseguinte, os inícios de sessão em cache produzem sempre as associações de grupos locais mais recentes, independentemente do mecanismo utilizado para iniciar sessão.