Processos de credenciais na autenticação do Windows
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este tópico de referência para o profissional de TI descreve como a autenticação do Windows processa credenciais.
O gerenciamento de credenciais do Windows é o processo pelo qual o sistema operacional recebe as credenciais do serviço ou do usuário e protege essas informações para apresentação futura para o destino de autenticação. No caso de um computador ingressado no domínio, o destino de autenticação é o controlador de domínio. As credenciais usadas na autenticação são documentos digitais que associam a identidade do usuário a alguma forma de prova de autenticidade, como um certificado, uma senha ou um PIN.
Por padrão, as credenciais do Windows são validadas no banco de dados SAM (Gerenciador de Contas de Segurança) no computador local ou no Active Directory em um computador ingressado no domínio, por meio do serviço Winlogon. As credenciais são coletadas por meio da entrada do usuário na interface do usuário de logon ou programaticamente por meio da API (interface de programação do aplicativo) a ser apresentada ao destino de autenticação.
As informações de segurança local são armazenadas no registro em HKEY_LOCAL_MACHINE\SECURITY. As informações armazenadas incluem configurações de política, valores de segurança padrão e informações de conta, como credenciais de logon armazenadas em cache. Uma cópia do banco de dados SAM também é armazenada aqui, embora seja protegida contra gravação.
O diagrama a seguir mostra os componentes necessários e os caminhos que as credenciais percorrem pelo sistema para autenticar o usuário ou processar um logon bem-sucedido.
A tabela a seguir descreve cada componente que gerencia credenciais no processo de autenticação no ponto de logon.
Componentes de autenticação para todos os sistemas
| Componente | Descrição |
|---|---|
| Logon do usuário | Winlogon.exe é o arquivo executável responsável por gerenciar interações seguras do usuário. O serviço Winlogon inicia o processo de logon para sistemas operacionais Windows passando as credenciais coletadas pela ação do usuário na área de trabalho protegida (interface do usuário de logon) para a LSA (autoridade de segurança local) por meio de Secur32.dll. |
| Logon do aplicativo | Logons de aplicativo ou serviço que não exigem logon interativo. A maioria dos processos iniciados pelo usuário é executada no modo de usuário usando Secur32.dll enquanto os processos iniciados na inicialização, como serviços, são executados no modo kernel usando Ksecdd.sys. Para obter mais informações sobre o modo de usuário e o modo kernel, consulte Aplicativos e Modo de Usuário ou Serviços e Modo Kernel neste tópico. |
| Secur32.dll | Os diversos provedores de autenticação que formam a base do processo de autenticação. |
| Lsasrv.dll | O serviço de servidor LSA impõe políticas de segurança e atua como o gerenciador de pacotes de segurança de LSA. A LSA contém a função Negotiate, que seleciona o protocolo NTLM ou Kerberos depois de determinar qual protocolo deve ser bem-sucedido. |
| Provedores de suporte de segurança | Um conjunto de provedores que podem invocar individualmente um ou mais protocolos de autenticação. O conjunto padrão de provedores pode ser alterado com cada versão do sistema operacional Windows e os provedores personalizados podem ser gravados. |
| Netlogon.dll | Os serviços que o serviço de Logon de Rede executa são os seguintes: – Mantém o canal seguro do computador (para não ser confundido com Schannel) com um controlador de domínio. |
| Samsrv.dll | O SAM (Gerenciador de Contas de Segurança), que armazena contas de segurança locais, impõe políticas armazenadas localmente e dá suporte a APIs. |
| Registro | O Registro contém uma cópia do banco de dados SAM, configurações de política de segurança local, valores de segurança padrão e informações de conta que só podem ser acessadas pelo sistema. |
Este tópico contém as seguintes seções:
Entrada de credencial para logon de usuário
No Windows Server 2008 e no Windows Vista, a arquitetura GINA (Autenticação e Identificação Gráfica) foi substituída por um modelo de provedor de credenciais, o que possibilitou enumerar diferentes tipos de logon por meio do uso de blocos de logon. Ambos os modelos estão descritos abaixo.
Arquitetura de Autenticação e Identificação Gráfica
A arquitetura GINA (Autenticação e Identificação Gráfica) se aplica aos sistemas operacionais Windows Server 2003, Microsoft Windows 2000 Server, Windows XP e Windows 2000 Professional. Nesses sistemas, cada sessão interativa de logon cria uma instância separada do serviço Winlogon. A arquitetura GINA é carregada no espaço de processo usado pelo Winlogon, recebe e processa as credenciais e faz as chamadas para as interfaces de autenticação por meio de LSALogonUser.
As instâncias do Winlogon para uma execução interativa de logon na Sessão 0. A Sessão 0 hospeda serviços do sistema e outros processos críticos, incluindo o processo de LSA (Autoridade de Segurança Local).
O diagrama a seguir mostra o processo de credenciais para Windows Server 2003, Microsoft Windows 2000 Server, Windows XP e Microsoft Windows 2000 Professional.
Arquitetura de provedor de credenciais
A arquitetura do provedor de credenciais se aplica às versões designadas na lista Aplica-se a no início deste tópico. Nesses sistemas, a arquitetura de entrada de credenciais foi alterada para um design extensível usando provedores de credenciais. Esses provedores são representados pelos diferentes blocos de logon na área de trabalho segura que permitem qualquer número de cenários de logon – contas diferentes para o mesmo usuário e métodos de autenticação diferentes, como senha, cartão inteligente e biometria.
Com a arquitetura do provedor de credenciais, o Winlogon sempre inicia a interface do usuário de logon depois de receber um evento de sequência segura. A interface do usuário de logon consulta cada provedor de credenciais para o número de tipos de credenciais diferentes que o provedor está configurado para enumerar. Os provedores de credenciais têm a opção de especificar um desses blocos como o padrão. Depois que todos os provedores enumeraram seus blocos, a interface do usuário de logon os exibe para o usuário. O usuário interage com um bloco para fornecer suas credenciais. A interface do usuário de logon envia essas credenciais para autenticação.
Os provedores de credenciais não são mecanismos de imposição. Eles são usados para coletar e serializar credenciais. A Autoridade de Segurança Local e os pacotes de autenticação impõem segurança.
Os provedores de credenciais são registrados no computador e são responsáveis pelo seguinte:
Descrevendo as informações de credencial necessárias para autenticação.
Manipulando a comunicação e a lógica com autoridades de autenticação externas.
Empacotando credenciais para logon interativo e de rede.
O empacotamento de credenciais para logon interativo e de rede incluem o processo de serialização. Ao serializar credenciais, vários blocos de logon podem ser exibidos na interface do usuário de logon. Portanto, sua organização pode controlar a exibição de logon, como usuários, sistemas de destino para logon, acesso de pré-logon às políticas de bloqueio/desbloqueio de rede e estação de trabalho por meio do uso de provedores de credenciais personalizadas. Vários provedores de credenciais podem coexistir no mesmo computador.
Os provedores de SSO (logon único) podem ser desenvolvidos como um provedor de credenciais padrão ou como um provedor de acesso pré-logon.
Cada versão do Windows contém um provedor de credenciais padrão e um PLAP (provedor de acesso pré-logon) padrão, também conhecido como provedor de SSO. O provedor de SSO permite que os usuários façam uma conexão com uma rede antes de fazer logon no computador local. Quando esse provedor é implementado, o provedor não enumera blocos na interface do usuário do Logon.
Um provedor de SSO deve ser usado nos seguintes cenários:
A autenticação de rede e o logon do computador são tratados por diferentes provedores de credenciais. As variações nesse cenário incluem:
Um usuário tem a opção de se conectar a uma rede, como conectar-se a uma VPN (rede virtual privada), antes de fazer logon no computador, mas não é necessário fazer essa conexão.
A autenticação de rede é necessária para recuperar informações usadas durante a autenticação interativa no computador local.
Várias autenticações de rede são seguidas por um dos outros cenários. Por exemplo, um usuário se autentica em um ISP (provedor de serviços de Internet), em uma VPN e, em seguida, usa suas credenciais de conta de usuário para fazer logon localmente.
As credenciais armazenadas em cache são desabilitadas e uma conexão dos Serviços de Acesso Remoto por meio de VPN é necessária antes do logon local para autenticar o usuário.
Um usuário de domínio não tem uma conta local configurada em um computador ingressado no domínio e deve estabelecer uma conexão dos Serviços de Acesso Remoto por meio da conexão VPN antes de concluir o logon interativo.
A autenticação de rede e o logon do computador são tratados pelo mesmo provedor de credenciais. Nesse cenário, é necessário que o usuário se conecte à rede antes de fazer logon no computador.
Enumeração de bloco de logon
O provedor de credenciais enumera blocos de logon nas seguintes instâncias:
Para os sistemas operacionais designados na lista Aplica-se a no início deste tópico.
O provedor de credenciais enumera os blocos para o logon da estação de trabalho. O provedor de credenciais normalmente serializa credenciais para autenticação para a autoridade de segurança local. Esse processo exibe blocos específicos para cada usuário e para os sistemas de destino de cada usuário.
A arquitetura de logon e autenticação permite que um usuário use blocos enumerados pelo provedor de credenciais para desbloquear uma estação de trabalho. Normalmente, o usuário conectado no momento é o bloco padrão, mas se mais de um usuário estiver conectado, vários blocos serão exibidos.
O provedor de credenciais enumera blocos em resposta a uma solicitação do usuário para alterar sua senha ou outras informações privadas, como um PIN. Normalmente, o usuário conectado no momento é o bloco padrão, mas se mais de um usuário estiver conectado, vários blocos serão exibidos.
O provedor de credenciais enumera blocos com base nas credenciais serializadas a serem usadas para autenticação em computadores remotos. A interface do usuário de credencial não usa a mesma instância do provedor que a interface do usuário de logon, a estação de trabalho de desbloqueio ou a alteração de senha. Portanto, as informações de estado não podem ser mantidas no provedor entre instâncias da interface do usuário da credencial. Essa estrutura resulta em um bloco para cada logon de computador remoto, supondo que as credenciais tenham sido serializadas corretamente. Esse cenário também é usado no UAC (Controle de Conta de Usuário), que pode ajudar a evitar alterações não autorizadas em um computador solicitando ao usuário permissão ou uma senha de administrador antes de permitir ações que poderiam afetar potencialmente a operação do computador ou que poderiam alterar as configurações que afetam outros usuários do computador.
O diagrama a seguir mostra o processo de credencial para os sistemas operacionais designados na lista Aplica-se a no início deste tópico.
Entrada de credencial para logon de aplicativo e serviço
A autenticação do Windows foi projetada para gerenciar credenciais para aplicativos ou serviços que não exigem interação do usuário. Os aplicativos no modo de usuário são limitados em termos de quais recursos do sistema eles têm acesso, enquanto os serviços podem ter acesso irrestrito à memória do sistema e dispositivos externos.
Os serviços do sistema e os aplicativos no nível de transporte acessam um SSP (Provedor de Suporte de Segurança) por meio da SSPI (Interface do Provedor de Suporte de Segurança) no Windows, que fornece funções para enumerar os pacotes de segurança disponíveis em um sistema, selecionar um pacote e usar esse pacote para obter uma conexão autenticada.
Quando uma conexão cliente/servidor é autenticada:
O aplicativo no lado do cliente da conexão envia credenciais para o servidor usando a função
InitializeSecurityContext (General)do SSPI.O aplicativo no lado do servidor da conexão responde com a função
AcceptSecurityContext (General)do SSPI.As funções
InitializeSecurityContext (General)eAcceptSecurityContext (General)do SSPI são repetidas até que todas as mensagens de autenticação necessárias tenham sido trocadas para autenticação bem-sucedida ou com falha.Depois que a conexão tiver sido autenticada, a LSA no servidor usará informações do cliente para criar o contexto de segurança, que contém um token de acesso.
Em seguida, o servidor pode chamar a função
ImpersonateSecurityContextSSPI para anexar o token de acesso a um thread de representação para o serviço.
Aplicativos e modo de usuário
O modo de usuário no Windows é composto por dois sistemas capazes de passar solicitações de E/S para os drivers de modo kernel apropriados: o sistema de ambiente, que executa aplicativos escritos para muitos tipos diferentes de sistemas operacionais, e o sistema integral, que opera funções específicas do sistema em nome do sistema de ambiente.
O sistema integral gerencia as funções específicas do sistema operacional em nome do sistema de ambiente e consiste em um processo do sistema de segurança (o LSA), um serviço de estação de trabalho e um serviço de servidor. O processo do sistema de segurança lida com tokens de segurança, concede ou nega permissões para acessar contas de usuário com base em permissões de recurso, lida com solicitações de logon e inicia a autenticação de logon e determina quais recursos do sistema o sistema operacional precisa auditar.
Os aplicativos podem ser executados no modo de usuário, em que o aplicativo pode ser executado como qualquer entidade de segurança, incluindo no contexto de segurança do Sistema Local (SYSTEM). Os aplicativos também podem ser executados no modo kernel em que o aplicativo pode ser executado no contexto de segurança do Sistema Local (SYSTEM).
O SSPI está disponível por meio do módulo Secur32.dll, que é uma API usada para obter serviços de segurança integrados para autenticação, integridade de mensagens e privacidade de mensagens. Ele fornece uma camada de abstração entre protocolos no nível do aplicativo e protocolos de segurança. Como diferentes aplicativos exigem diferentes maneiras de identificar ou autenticar usuários e diferentes maneiras de criptografar dados à medida que eles viajam por uma rede, o SSPI fornece uma maneira de acessar DLLs (bibliotecas de vínculo dinâmico) que contêm diferentes funções de autenticação e criptografia. Essas DLLs são chamadas de SSPs (Provedores de Suporte de Segurança).
Contas de serviço gerenciado e contas virtuais foram introduzidas no Windows Server 2008 R2 e no Windows 7 para fornecer aplicativos fundamentais, como Microsoft SQL Server e IIS (Serviços de Informações da Internet), com o isolamento de suas próprias contas de domínio, eliminando assim a necessidade de um administrador gerenciar manualmente o SPN (nome da entidade de serviço) e as credenciais dessas contas. Para obter mais informações sobre esses recursos e sua função na autenticação, consulte Documentação de Contas de Serviço Gerenciado para Windows 7 e Windows Server 2008 R2 e Visão geral das Contas de Serviço Gerenciado de grupo.
Serviços e modo kernel
Embora a maioria dos aplicativos do Windows seja executada no contexto de segurança do usuário que os inicia, isso não ocorre nos serviços. Muitos serviços do Windows, como serviços de rede e impressão, são iniciados pelo controlador de serviço quando o usuário inicia o computador. Esses serviços podem ser executados como Serviço Local ou Sistema Local e podem continuar sendo executados após o último logoff do usuário.
Observação
Os serviços normalmente são executados em contextos de segurança conhecidos como Sistema Local (SYSTEM), Serviço de Rede ou Serviço Local. O Windows Server 2008 R2 introduziu serviços executados em uma conta de serviço gerenciado, que são entidades de domínio.
Antes de iniciar um serviço, o controlador de serviço faz logon usando a conta designada para o serviço e, em seguida, apresenta as credenciais do serviço para autenticação pela LSA. O serviço do Windows implementa uma interface programática que o gerenciador do controlador de serviço pode usar para controlar o serviço. Um serviço do Windows pode ser iniciado automaticamente quando o sistema é iniciado ou manualmente com um programa de controle de serviço. Por exemplo, quando um computador cliente do Windows ingressa em um domínio, o serviço de mensagens no computador se conecta a um controlador de domínio e abre um canal seguro para ele. Para obter uma conexão autenticada, o serviço deve ter credenciais que a LSA (Autoridade de Segurança Local) do computador remoto confia. Ao se comunicar com outros computadores na rede, a LSA usa as credenciais para a conta de domínio do computador local, bem como todos os outros serviços em execução no contexto de segurança do Sistema Local e do Serviço de Rede. Os serviços no computador local são executados como SYSTEM para que as credenciais não precisem ser apresentadas à LSA.
O arquivo Ksecdd.sys gerencia e criptografa essas credenciais e usa uma chamada de procedimento local para a LSA. O tipo de arquivo é DRV (driver) e é conhecido como SSP (Provedor de Suporte de Segurança) no modo kernel e, nessas versões designadas na lista Aplica-se a no início deste tópico, é compatível com FIPS 140-2 Nível 1.
O modo kernel tem acesso completo aos recursos de hardware e sistema do computador. O modo kernel impede que serviços e aplicativos no modo de usuário acessem áreas críticas do sistema operacional às quais eles não devem ter acesso.
Autoridade de Segurança Local
A LSA (Autoridade de Segurança Local) é um processo de sistema protegido que autentica e registra os usuários no computador local. Além disso, a LSA mantém as informações sobre todos os aspectos da segurança local em um computador (esses aspectos são coletivamente conhecidos como a política de segurança local) e fornece vários serviços de tradução entre nomes e SIDs (identificadores de segurança). O processo do sistema de segurança, LSASS (Serviço de Servidor da Autoridade de Segurança Local), controla as políticas de segurança e as contas que estão em vigor em um sistema de computador.
A LSA valida a identidade de um usuário com base em qual das duas entidades a seguir emitiu a conta do usuário:
Autoridade de Segurança Local. A LSA pode validar as informações do usuário verificando o banco de dados SAM (Gerenciador de Contas de Segurança) localizado no mesmo computador. Qualquer estação de trabalho ou servidor membro pode armazenar contas de usuário local e informações sobre grupos locais. No entanto, essas contas podem ser usadas para acessar somente essa estação de trabalho ou computador.
Autoridade de segurança para o domínio local ou para um domínio confiável. A LSA entra em contato com a entidade que emitiu a conta e solicita a verificação de que a conta é válida e que a solicitação foi originada do titular da conta.
O serviço LSASS armazena credenciais na memória em nome de usuários com sessões ativas do Windows. As credenciais armazenadas permitem aos usuários acessar facilmente os recursos de rede, como compartilhamento de arquivos, caixas de correio do Exchange Server e sites do SharePoint, sem reinserir suas credenciais para cada serviço remoto.
O LSASS pode armazenar credenciais de várias formas, incluindo:
Texto não criptografado de criptografia reversível
Tíquetes Kerberos (TGTs (tíquetes de concessão de tíquetes), tíquetes de serviço)
Hash de NT
Hash do LM (LAN Manager)
Se o usuário fizer logon no Windows usando um cartão inteligente, o LSASS não armazena uma senha de texto não criptografado, mas sim o valor do hash de NT correspondente da conta e o PIN de texto não criptografado do cartão inteligente. Se o atributo da conta estiver habilitado para um cartão inteligente exigido no logon interativo, um valor de hash de NT aleatório será gerado automaticamente para a conta, e não o hash da senha original. O hash de senha gerado automaticamente quando o atributo é definido não muda.
Se um usuário fizer logon em um computador baseado no Windows com uma senha compatível com hashes do LM (LAN Manager), esse autenticador está presente na memória.
O armazenamento de credenciais em texto não criptografado na memória não pode ser desabilitado, mesmo que os provedores de credenciais que necessitam delas estejam desabilitados.
As credenciais armazenadas estão diretamente associadas às sessões de logon de LSASS iniciadas após a última reinicialização e não foram fechadas. Por exemplo, as sessões de LSA com credenciais LSA armazenadas são criadas quando um usuário:
Faz logon em uma sessão local ou sessão RDP no computador
Executa uma tarefa usando a opção RunAs
Executa um serviço Windows ativo no computador
Executa uma tarefa ou trabalho em lotes programado
Executa uma tarefa no computador local usando uma ferramenta de administração remota
Em algumas circunstâncias, os segredos LSA, que são partes secretas de dados acessíveis apenas para processos de conta SYSTEM, são armazenados na unidade de disco rígido. Alguns desses segredos são credenciais que devem persistir após a reinicialização, e são armazenadas de forma criptografada no disco rígido. Credenciais armazenadas como segredos de LSA podem incluir:
Senha da conta do AD DS (Active Directory Domain Services) do computador
Senhas da conta de serviços Windows que estão configurados no computador
Senhas da conta para tarefas agendadas configuradas
Senhas da conta de pools de aplicativos IIS e sites da Web
Senhas para contas da Microsoft
Introduzido no Windows 8.1, o sistema operacional do cliente fornece proteção adicional para a LSA, a fim de impedir a leitura da memória e a injeção de código por processos não protegidos. Essa proteção aumenta a segurança para as credenciais que a LSA armazena e gerencia.
Para obter mais informações sobre essas proteções adicionais, consulte Configurando a proteção LSA adicional.
Credenciais e validação armazenadas em cache
Os mecanismos de validação dependem da apresentação de credenciais no momento do logon. No entanto, quando o computador é desconectado de um controlador de domínio e o usuário está apresentando credenciais de domínio, o Windows usa o processo de credenciais armazenadas em cache no mecanismo de validação.
Sempre que um usuário faz logon em um domínio, o Windows armazena em cache as credenciais fornecidas e as armazena no hive de segurança no registro do sistema operacional.
Com credenciais armazenadas em cache, o usuário pode fazer logon em um membro do domínio sem estar conectado a um controlador de domínio nesse domínio.
Armazenamento e validação de credenciais
Nem sempre é desejável usar um conjunto de credenciais para acesso a recursos diferentes. Por exemplo, um administrador pode querer usar credenciais administrativas, e não de usuário ao acessar um servidor remoto. Da mesma forma, se um usuário acessar recursos externos, como uma conta bancária, ele só poderá usar credenciais diferentes das credenciais de domínio. As seções a seguir descrevem as diferenças no gerenciamento de credenciais entre as versões atuais dos sistemas operacionais Windows e os sistemas operacionais Windows Vista e Windows XP.
Processos de credencial de logon remoto
O Protocolo RDP gerencia as credenciais do usuário que se conecta a um computador remoto usando o Cliente de Área de Trabalho Remota, que foi introduzido no Windows 8. As credenciais em formato de texto não criptografado são enviadas para o host de destino em que o host tenta executar o processo de autenticação e, se bem-sucedido, conecta o usuário aos recursos permitidos. O RDP não armazena as credenciais no cliente, mas as credenciais de domínio do usuário são armazenadas no LSASS.
Introduzido no Windows Server 2012 R2 e Windows 8.1, o modo de Administração Restrita fornece segurança adicional para cenários de logon remoto. Esse modo de Área de Trabalho Remota faz com que o aplicativo cliente execute um logon de rede desafio/resposta com a NTOWF (função de uma via do NT) ou use um tíquete de serviço Kerberos ao autenticar no host remoto. Depois que o administrador é autenticado, o administrador não tem as respectivas credenciais de conta no LSASS porque elas não foram fornecidas ao host remoto. Em vez disso, o administrador tem as credenciais da conta de computador para a sessão. As credenciais de administrador não são fornecidas ao host remoto, portanto, as ações são executadas como a conta do computador. Os recursos também são limitados à conta de computador e o administrador não pode acessar recursos com sua própria conta.
Processo de credencial de logon de reinicialização automática
Quando um usuário entra em um dispositivo Windows 8.1, a LSA salva as credenciais do usuário na memória criptografada acessível somente por LSASS.exe. Quando Windows Update inicia uma reinicialização automática sem a presença do usuário, essas credenciais são usadas para configurar o logon automático para o usuário.
Na reinicialização, o usuário é conectado automaticamente por meio do mecanismo de logon automático e, em seguida, o computador é bloqueado adicionalmente para proteger a sessão do usuário. O bloqueio é iniciado por meio do Winlogon, enquanto o gerenciamento de credenciais é feito pela LSA. Ao entrar e bloquear automaticamente a sessão do usuário no console, os aplicativos de tela de bloqueio do usuário são reiniciados e disponibilizados.
Para obter mais informações sobre ARSO, confira ARSO (Logon de Reinicialização Automática) do Winlogon.
Nomes de usuário e senhas armazenados no Windows Vista e no Windows XP
No Windows Server 2008, Windows Server 2003, Windows Vista e Windows XP, os Nomes de usuário e senhas armazenados no Painel de Controle simplificam o gerenciamento e o uso de vários conjuntos de credenciais de logon, incluindo certificados X.509 usados com cartões inteligentes e credenciais do Windows Live (agora chamado de conta Microsoft). As credenciais - parte do perfil do usuário - são armazenadas até quando for necessário. Essa ação pode aumentar a segurança por recurso, garantindo que, se uma senha for comprometida, ela não comprometa toda a segurança.
Depois que um usuário faz logon e tenta acessar recursos adicionais protegidos por senha, como um compartilhamento em um servidor, e se as credenciais de logon padrão do usuário não forem suficientes para obter acesso, os Nomes de usuário e senhas armazenados serão consultados. Se credenciais alternativas com as informações de logon corretas tiverem sido salvas em Nomes de usuário e senhas armazenados, essas credenciais serão usadas para obter acesso. Caso contrário, o usuário será solicitado a fornecer novas credenciais, que podem ser salvas para reutilização, posteriormente na sessão de logon ou durante uma sessão subsequente.
As restrições a seguir se aplicam:
Se Nomes de usuário e senhas armazenados contiver credenciais inválidas ou incorretas para um recurso específico, o acesso ao recurso será negado e a caixa de diálogo Nomes de usuário e senhas armazenados não será exibida.
Nomes de usuário e senhas armazenados armazenam credenciais apenas para autenticação NTLM, protocolo Kerberos, conta Microsoft (anteriormente Windows Live ID) e protocolo SSL. Algumas versões do Internet Explorer mantêm seu próprio cache para autenticação básica.
Essas credenciais se tornam uma parte criptografada do perfil local de um usuário no diretório \Documents and Settings\Username\Application Data\Microsoft\Credentials. Como resultado, essas credenciais poderão usar perfil móvel com o usuário se a política de rede do usuário der suporte a Perfis de Usuário Móvel. No entanto, se o usuário tiver cópias dos Nomes de usuário e senhas armazenados em dois computadores diferentes e alterar as credenciais associadas ao recurso em um desses computadores, a alteração não será propagada para Nomes de usuário e senhas armazenados no segundo computador.
Windows Vault e Gerenciador de Credenciais
O Gerenciador de Credenciais foi introduzido no Windows Server 2008 R2 e no Windows 7 como um recurso do Painel de Controle para armazenar e gerenciar nomes de usuário e senhas. O Gerenciador de Credenciais permite que os usuários armazenem credenciais relevantes para outros sistemas e sites no Cofre seguro do Windows. Algumas versões do Internet Explorer usam esse recurso para autenticação em sites.
O gerenciamento de credenciais executado pelo Gerenciador de Credenciais é controlado pelo usuário no computador local. Os usuários podem salvar e armazenar credenciais de navegadores e aplicativos do Windows com suporte para ter conveniência ao entrar nesses recursos. As credenciais são salvas em pastas criptografadas especiais no computador sob o perfil do usuário. Os aplicativos que dão suporte a esse recurso (com o uso das APIs do Gerenciador de Credenciais), como os navegadores e os aplicativos, podem apresentar as credenciais corretas a outros computadores e sites durante o processo de logon.
Quando um site, aplicativo ou outro computador solicita autenticação por meio do NTLM ou do protocolo Kerberos, uma caixa de diálogo é exibida na qual você marca a caixa de seleção Atualizar Credenciais Padrão ou Salvar Senha. Essa caixa de diálogo que permite que um usuário salve credenciais localmente é gerada por um aplicativo que dá suporte às APIs do Gerenciador de Credenciais. Se o usuário marcar a caixa de seleção Salvar Senha, o Gerenciador de Credenciais controlará o nome de usuário, a senha e as informações do usuário relacionadas para o serviço de autenticação que está sendo usado.
Na próxima vez em que o serviço for usado, o Gerenciador de Credenciais fornecerá automaticamente a credencial que está armazenada no Cofre do Windows. Se a credencial não for aceita, o usuário será solicitado a fornecer as informações de acesso corretas. Se o acesso for concedido com as novas credenciais, o Gerenciador de Credenciais substituirá a credencial anterior pela nova e armazenará esta no Cofre do Windows.
Banco de dados do Gerenciador de Contas de Segurança
O SAM (Gerenciador de Contas de Segurança) é um banco de dados que armazena contas e grupos de usuários locais. Ele está presente em todos os sistemas operacionais Windows. No entanto, quando um computador é ingressado em um domínio, o Active Directory gerencia contas de domínio em domínios do Active Directory.
Por exemplo, os computadores cliente que executam um sistema operacional Windows participam de um domínio de rede, comunicando-se com um controlador de domínio, mesmo quando nenhum usuário está conectado. Para iniciar as comunicações, o computador deve ter uma conta ativa no domínio. Antes de aceitar as comunicações do computador, a LSA no controlador de domínio autentica a identidade do computador e constrói o contexto de segurança do computador, assim como faz para a entidade de segurança humana. Esse contexto de segurança define a identidade e as capacidades de um usuário ou serviço em um computador específico ou de um usuário, serviço ou computador em uma rede. Por exemplo, o token de acesso contido no contexto de segurança define os recursos (como um compartilhamento de arquivos ou impressora) que podem ser acessados e as ações (como Leitura, Gravação ou Modificação) que podem ser executadas por essa entidade de segurança - um usuário, computador ou serviço nesse recurso.
O contexto de segurança de um usuário ou computador pode variar de um computador para outro, como quando um usuário faz logon em um servidor ou uma estação de trabalho diferente da estação de trabalho primária do usuário. Ele também pode variar de uma sessão para outra, como quando um administrador modifica os direitos e as permissões do usuário. Além disso, o contexto de segurança geralmente é diferente quando um usuário ou computador está operando em uma base autônoma, em uma rede ou como parte de um domínio do Active Directory.
Domínios locais e domínios confiáveis
Quando existe uma relação de confiança entre dois domínios, os mecanismos de autenticação para cada domínio confiam na validade das autenticações provenientes do outro domínio. As relações de confiança ajudam a fornecer acesso controlado a recursos compartilhados em um domínio de recursos (o domínio confiante), verificando se as solicitações de autenticação recebidas são provenientes de uma autoridade confiável (o domínio confiável). Dessa forma, as relações de confiança atuam como pontes que permitem que apenas as solicitações de autenticação validadas viajem entre domínios.
A maneira como uma relação de confiança específica passa solicitações de autenticação depende de como ela está configurada. As relações de confiança podem ser unidirecionais, fornecendo acesso do domínio confiável aos recursos no domínio confiável ou bidirecionais, fornecendo acesso de cada domínio aos recursos no outro domínio. As relações de confiança também são não transitivas, caso em que uma confiança existe apenas entre os dois domínios de parceiros confiáveis; ou transitivas, nesse caso, a confiança se estende automaticamente a quaisquer outros domínios que qualquer um dos parceiros confia.
Para obter informações sobre relações de confiança de domínio e de floresta em relação à autenticação, confira Autenticação delegada e Relações de confiança.
Certificados na autenticação do Windows
A PKI (infraestrutura de chave pública) é a combinação de software, tecnologias de criptografia, processos e serviços, a qual permite que uma organização proteja comunicações e transações de negócios. A capacidade de uma PKI de proteger comunicações e transações comerciais baseia-se na troca de certificados digitais entre usuários autenticados e recursos confiáveis.
Um certificado digital é um documento eletrônico que contém informações sobre a entidade à qual pertence, a entidade pela qual foi emitido, um número de série exclusivo ou outra identificação exclusiva, datas de emissão e validade e uma impressão digital.
A autenticação é o processo de determinar se um host remoto pode ser confiável. Para estabelecer sua confiabilidade, o host remoto deve fornecer um certificado de autenticação aceitável.
Os hosts remotos estabelecem sua confiabilidade obtendo um certificado de uma AC (autoridade de certificação). A AC pode, por sua vez, ter certificação de uma autoridade superior, o que cria uma cadeia de confiança. Para determinar se um certificado é confiável, um aplicativo deve determinar a identidade da AC raiz e determinar se ele é confiável.
Da mesma forma, o host remoto ou computador local deve determinar se o certificado apresentado pelo usuário ou aplicativo é autêntico. O certificado apresentado pelo usuário por meio do LSA e do SSPI é avaliado quanto à autenticidade no computador local para logon local, na rede ou no domínio por meio dos repositórios de certificados no Active Directory.
Para produzir um certificado, os dados de autenticação passam por algoritmos de hash, como SHA1 (Secure Hash Algorithm 1), para produzir um resumo da mensagem. O resumo da mensagem é assinado digitalmente usando a chave privada do remetente para provar que o resumo da mensagem foi produzido pelo remetente.
Observação
SHA1 é o padrão no Windows 7 e no Windows Vista, mas foi alterado para SHA2 no Windows 8.
Autenticação com cartão inteligente
A tecnologia de cartão inteligente é um exemplo de autenticação baseada em certificado. Fazer logon em uma rede com um cartão inteligente fornece uma forma forte de autenticação porque usa a identificação baseada em criptografia e a verificação de posse ao autenticar um usuário em um domínio. O AD CS (Serviços de Certificados do Active Directory) fornece a identificação baseada em criptografia por meio da emissão de um certificado de logon para cada cartão inteligente.
Para obter informações sobre a autenticação de cartão inteligente, consulte a Referência técnica do Cartão Inteligente do Windows.
A tecnologia de cartão inteligente virtual foi introduzida no Windows 8. Ela armazena o certificado do cartão inteligente no computador e o protege usando o chip de segurança TPM (Trusted Platform Module) à prova de adulteração do dispositivo. Dessa forma, o computador realmente se torna o cartão inteligente que deve receber o PIN do usuário para ser autenticado.
Autenticação remota e sem fio
A autenticação de rede remota e sem fio é outra tecnologia que usa certificados para autenticação. O IAS (Serviço de autenticação da Internet) e os servidores de rede virtual privada usam EAP-TLS (Protocolo de Autenticação Extensível–Segurança de Nível de Transporte), PEAP (EAP Protegido) ou IPsec para executar a autenticação baseada em certificado para vários tipos de acesso à rede, incluindo VPN (rede virtual privada) e conexões sem fio.
Para obter informações sobre a autenticação baseada em certificado na rede, confira Autenticação e certificados de acesso à rede.