Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
A autenticação do Windows é a pedra angular do acesso seguro em ambientes corporativos, permitindo que usuários e serviços interajam com sistemas enquanto protegem informações confidenciais. Este artigo fornece aos profissionais de TI uma visão geral abrangente de como o Windows processa credenciais durante a autenticação. Ele abrange os principais componentes, mecanismos e arquiteturas envolvidos no gerenciamento, validação e armazenamento de credenciais, garantindo uma compreensão clara do processo de autenticação em vários sistemas operacionais Windows.
Especificamente, estes componentes são abrangidos:
Entrada de credenciais para de logon do usuário
Visão geral da autenticação de credenciais do Windows
O gerenciamento de credenciais do Windows é o processo pelo qual o sistema operacional recebe as credenciais do serviço ou usuário e protege essas informações para apresentação futura ao destino de autenticação. Se um computador estiver associado ao domínio, o destino de autenticação será 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 em relação ao banco de dados SAM (Gerenciador de Contas de Segurança) no computador local ou em relação ao Ative Directory em um computador associado a um domínio, por meio do serviço Winlogon. As credenciais são recolhidas através da entrada do utilizador na interface do utilizador de início de sessão ou programaticamente através da interface de programação de aplicações (API), que será apresentada ao alvo de autenticação.
As informações de segurança local são armazenadas no registo 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 esteja 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 o processo para um logon bem-sucedido.
A tabela a seguir descreve cada componente que gerencia credenciais no processo de autenticação no ponto de logon 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 operativos Windows, passando as credenciais coletadas pela ação do utilizador no ambiente de trabalho seguro (Logon UI) para a Autoridade de Segurança Local (LSA) através de secur32.dll. |
| Logon do aplicativo | Logons de aplicativos ou serviços que não exigem logon interativo. A maioria dos processos iniciados pelo usuário são executados 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. |
secur32.dll |
Os vários provedores de autenticação que formam a base do processo de autenticação. |
lsasrv.dll |
O serviço LSA Server, que impõe políticas de segurança e atua como o gerenciador de pacotes de segurança para o LSA. O LSA contém a função Negotiate, que seleciona o protocolo NTLM ou Kerberos depois de determinar qual protocolo deve ser bem-sucedido. |
| Fornecedores 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:
|
samsrv.dll |
O Gerenciador de Contas de Segurança (SAM), que armazena contas de segurança locais, impõe políticas armazenadas localmente e oferece suporte a APIs. |
| Registo | O Registro contém uma cópia do banco de dados SAM, configurações de diretiva de segurança local, valores de segurança padrão e informações de conta que só podem ser acessadas pelo sistema. |
Entrada de credenciais para logon do usuário
A arquitetura do provedor de credenciais, que foi introduzida no Windows Server 2008, é o principal mecanismo para coletar credenciais de usuário durante o logon. Ele permite uma maneira flexível e extensível de coletar credenciais dos usuários, como senhas, cartões inteligentes ou biometria. A arquitetura do provedor de credenciais substitui a arquitetura mais antiga de Identificação e Autenticação Gráfica (GINA) usada em versões anteriores do Windows.
Para saber mais sobre a arquitetura de Identificação e Autenticação Gráfica (GINA) em versões mais antigas do Windows, expanda esta seção.
A arquitetura de identificação gráfica e autenticação (GINA) aplica-se aos sistemas operacionais Windows Server 2003, Microsoft Windows 2000 Server, Windows XP e Windows 2000 Professional. Nesses sistemas, cada sessão de logon interativo 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 através do LSALogonUser.
As instâncias de Winlogon para um logon interativo são executadas na Sessão 0. A sessão 0 hospeda serviços do sistema e outros processos críticos, incluindo o processo da Autoridade de Segurança Local (LSA).
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 do provedor de credenciais
A arquitetura do provedor de credenciais usa um design extensível usando provedores de credenciais. Blocos de logon diferentes representam esses provedores na área de trabalho segura que permitem qualquer número de cenários de logon, incluindo contas diferentes para o mesmo usuário e diferentes métodos de autenticação, como senha, cartão inteligente e biometria.
O diagrama a seguir mostra o processo de credencial para a arquitetura do provedor de credenciais:
Winlogon sempre inicia o processo Logon UI depois que ele recebe um evento de seqüência de atenção segura. A Interface do Usuário de Logon consulta cada provedor de credenciais quanto ao número de tipos diferentes de credenciais que o provedor está configurado para enumerar. Os provedores de credenciais têm a opção de especificar um desses blocos como padrão. Depois de todos os provedores enumerarem os seus blocos, a Interface de Logon os exibe para o utilizador. 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 aplicação; eles são usados para reunir e serializar credenciais. A Autoridade de Segurança Local e os pacotes de autenticação impõem a segurança.
Os fornecedores de credenciais estão registados no computador e são responsáveis pelas seguintes tarefas:
Descrevendo as informações de credencial necessárias para autenticação.
Gestão da comunicação e lógica com autoridades de autenticação externas.
Empacotamento de credenciais para logon interativo e de rede.
A embalagem de credenciais para logon interativo e em rede inclui o processo de serialização. Ao serializar credenciais, vários blocos de logon podem ser exibidos para um usuário. Portanto, a sua organização pode controlar a exibição de logon, como usuários, sistemas-alvo para logon, acesso pré-logon à rede e políticas de bloqueio/desbloqueio da estação de trabalho, usando provedores de credenciais personalizados. Vários provedores de credenciais podem coexistir no mesmo computador. Os provedores de logon único (SSO) podem ser desenvolvidos como um provedor de credenciais padrão ou como um provedor de acesso pré-logon (PLAP).
Cada versão do Windows contém um provedor de credenciais padrão e um provedor de acesso pré-logon padrão, também conhecido como provedor 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 este provedor é implementado, o provedor não enumera tiles na interface do usuário de logon.
Um provedor de SSO deve ser usado nos seguintes cenários:
A autenticação de rede e o logon do computador são manipulados por diferentes provedores de credenciais, incluindo as seguintes variações para esse cenário:
Um usuário tem a opção de se conectar a uma rede, como conectar-se a uma rede virtual privada (VPN), 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 provedor de serviços de Internet (ISP), autentica em uma VPN e 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 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 associado a um domínio e deve estabelecer uma conexão de Serviços de Acesso Remoto por meio de conexão VPN antes de concluir o logon interativo.
A autenticação de rede e o logon do computador são manipulados pelo mesmo provedor de credenciais, onde o usuário precisa se conectar à 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 iniciar sessão numa 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 específicos 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 utilizador de credenciais não usa a mesma instância do provedor que a interface do utilizador de logon, ao desbloquear a estação de trabalho ou ao alterar uma senha. Portanto, as informações de estado não podem ser mantidas no provedor entre instâncias da interface do usuário de credenciais. Essa estrutura resulta em um bloco para cada logon do computador remoto, supondo que as credenciais sejam serializadas corretamente. Esse cenário também é usado no Controle de Conta de Usuário (UAC), que pode ajudar a impedir alterações não autorizadas em um computador, solicitando permissão ou uma senha de administrador ao usuário antes de permitir ações que possam afetar a operação do computador ou que possam alterar as configurações que afetam outros usuários do computador.
Entrada de credenciais 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 de nível de transporte acessam um SSP (Provedor de Suporte de Segurança) por meio da Interface do Provedor de Suporte de Segurança (SSPI) 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 SSPI
InitializeSecurityContext (General).O aplicativo no lado do servidor da conexão responde com a função SSPI
AcceptSecurityContext (General).As funções SSPI
InitializeSecurityContext (General)eAcceptSecurityContext (General)são repetidas até que todas as mensagens de autenticação necessárias sejam trocadas para resultar na autenticação bem-sucedida ou falhar.Depois que a conexão é autenticada, o LSA no servidor usa informações do cliente para criar o contexto de segurança, que contém um token de acesso.
O servidor pode então chamar a função SSPI
ImpersonateSecurityContextpara anexar o token de acesso a um thread de impersonação para o serviço.
Aplicações e modo de utilizador
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 funções específicas do sistema operacional em nome do sistema de ambiente e consiste em um processo de 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 processa tokens de segurança, concede ou nega permissões para acessar contas de usuário com base nas permissões dos recursos, lida com solicitações de logon, inicia a autenticação de logon e determina quais recursos o sistema operacional precisa auditar.
Os aplicativos podem ser executados no modo de usuário, onde o aplicativo pode ser executado como qualquer principal, inclusive no contexto de segurança do Sistema Local (SYSTEM). Os aplicativos também podem ser executados no modo kernel, onde o aplicativo pode ser executado no contexto de segurança do Sistema Local (SYSTEM).
O SSPI está disponível pelo módulo secur32.dll, que é uma API usada para obter serviços de segurança integrados para autenticação, integridade das mensagens e privacidade das mensagens. Ele fornece uma camada de abstração entre protocolos de nível de aplicativo e protocolos de segurança. Como aplicativos diferentes exigem maneiras diferentes de identificar ou autenticar usuários e maneiras diferentes de criptografar dados à medida que eles viajam por uma rede, o SSPI fornece uma maneira de acessar bibliotecas de vínculo dinâmico (DLLs) que contêm diferentes funções de autenticação e criptografia. Essas DLLs são chamadas de SSPs (provedores de suporte de segurança).
As contas de serviço gerenciadas e as contas virtuais foram introduzidas no Windows Server 2008 R2 e no Windows 7 para fornecer aplicativos cruciais, como o Microsoft SQL Server e o IIS (Serviços de Informações da Internet), com o isolamento de suas próprias contas de domínio, ao mesmo tempo em que eliminam a necessidade de um administrador administrar 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 é verdade para os serviços. O controlador de serviço controla muitos serviços do Windows, como serviços de rede e impressão, quando o utilizador inicia o computador. Esses serviços podem ser executados como Serviço Local ou Sistema Local e podem continuar a ser executados depois que o último usuário humano fizer logoff.
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 que são executados sob 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 pelo 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 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 nas quais a Autoridade de Segurança Local (LSA) do computador remoto confia. Ao se comunicar com outros computadores na rede, o LSA usa as credenciais para a conta de domínio do computador local, assim como todos os outros serviços em execução no contexto de segurança do Sistema Local e Serviço de Rede. Os serviços no computador local são executados como SYSTEM, portanto, as credenciais não precisam ser apresentadas ao LSA.
O arquivo ksecdd.sys gerencia e criptografa essas credenciais e usa uma chamada de procedimento local no LSA. O tipo de ficheiro é DRV (driver) e é conhecido como o Provedor de Suporte de Segurança em modo kernel (SSP) e é compatível com FIPS 140-2 Nível 1, começando a partir do Windows Server 2008.
O modo kernel tem acesso total ao hardware e aos recursos do sistema do computador. O modo kernel impede que serviços e aplicativos de modo de usuário acessem áreas críticas do sistema operacional às quais eles não deveriam ter acesso.
Autoridade de Segurança Local
A Autoridade de Segurança Local (LSA) é um processo de sistema protegido que autentica e faz logon dos usuários no computador local. Além disso, a LSA mantém informações sobre todos os aspetos da segurança local em um computador (esses aspetos são coletivamente conhecidos como a política de segurança local) e fornece vários serviços para tradução entre nomes e identificadores de segurança (SIDs). O processo do sistema de segurança, Local Security Authority Server Service (LSASS), controla as políticas de segurança e as contas que estão em vigor num sistema informático.
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 utilizador verificando a base de dados do Gestor de Contas de Segurança (SAM) localizada no mesmo computador. Qualquer estação de trabalho ou servidor membro pode armazenar contas de usuário locais e informações sobre grupos locais. No entanto, essas contas podem ser usadas para acessar apenas 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 se a solicitação foi originada do titular da conta.
O LSASS (Local Security Authority Subsystem Service) armazena credenciais na memória em nome de usuários com sessões ativas do Windows. As credenciais armazenadas permitem que os usuários acessem perfeitamente recursos de rede, como compartilhamentos 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 em vários formulários, incluindo:
Texto simples reversivelmente encriptado.
Bilhetes Kerberos (bilhetes de concessão de bilhetes (TGTs), bilhetes de serviço).
Hash NT.
Hash do LAN Manager (LM).
Se o usuário fizer logon no Windows usando um cartão inteligente, o LSASS não armazenará uma senha de texto sem formatação, mas armazenará o valor de hash NT correspondente para a conta e o PIN de texto sem formatação para o cartão inteligente. Se o atributo de conta estiver ativado para um cartão inteligente necessário para início de sessão interativo, um valor de hash NT aleatório será gerado automaticamente para a conta em vez do hash da palavra-passe original. O hash de senha que é gerado automaticamente quando o atributo é definido não é alterado.
Se um usuário fizer logon em um computador baseado no Windows com uma senha compatível com hashes do LAN Manager (LM), esse autenticador estará presente na memória. O armazenamento de credenciais de texto simples na memória não pode ser desativado, mesmo que os provedores de credenciais que as exigem estejam desabilitados.
As credenciais armazenadas estão diretamente associadas às sessões de logon do LSASS (Local Security Authority Subsystem Service) que são iniciadas após a última reinicialização e não são fechadas. Por exemplo, sessões LSA com credenciais LSA armazenadas são criadas quando um usuário executa qualquer uma das seguintes ações:
Faz logon em uma sessão local ou sessão RDP (Remote Desktop Protocol) no computador.
Executa uma tarefa usando a opção RunAs .
Executa um serviço ativo do Windows no computador.
Executa uma tarefa agendada ou um trabalho em lotes.
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 aos processos da 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 na unidade de disco rígido. As credenciais armazenadas como segredos LSA podem incluir:
Palavra-passe da conta dos Serviços de Domínio Active Directory (AD DS) do computador.
Palavras-passe de conta para serviços do Windows configurados no computador.
Senhas de conta para tarefas agendadas configuradas.
Senhas de conta para pools de aplicativos e sites do IIS.
Palavras-passe para contas Microsoft.
O sistema operacional cliente Windows fornece proteção extra para o LSA para impedir a leitura de memória e injeção de código por processos não protegidos, que foi introduzido no Windows 8.1. Essa proteção aumenta a segurança das credenciais que o LSA armazena e gerencia.
Para obter mais informações sobre essas proteções extras, 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.
Cada vez 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 as 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 dentro desse domínio.
Armazenamento e validação de credenciais
Nem sempre é desejável usar um conjunto de credenciais para acessar recursos diferentes. Por exemplo, um administrador pode querer usar credenciais administrativas em vez de credenciais 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 de suas credenciais de domínio.
Processos de credenciais de logon remoto
O protocolo RDP (Remote Desktop Protocol) 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 forma de texto sem formatação são enviadas para o host de destino onde 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.
O modo Administrador restrito fornece segurança extra para cenários de logon remoto, que foi introduzido no Windows Server 2012 R2 e no Windows 8.1. Este modo de Ambiente de Trabalho Remoto faz com que a aplicação cliente execute um desafio-resposta de logon de rede com a função unidirecional NT (NTOWF) ou utilize um tíquete de serviço Kerberos quando se autentica no anfitrião remoto. Depois que o administrador é autenticado, o administrador não tem as respetivas 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 do computador e o administrador não pode acessar recursos com sua própria conta.
Processo de credenciais de início de sessão de reinício automático
Quando um utilizador inicia sessão, o LSA guarda as credenciais do utilizador na memória encriptada que só é acessível pelo LSASS.exe, que foi introduzido no Windows 8.1. Quando o 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 é automaticamente conectado através do mecanismo de logon automático e, em seguida, o computador é adicionalmente bloqueado para proteger a sessão do usuário. O bloqueio é iniciado através do Winlogon, enquanto o gerenciamento de credenciais é feito pelo LSA. Ao iniciar sessão automaticamente e bloquear a sessão do utilizador na consola, as aplicações do ecrã de bloqueio do utilizador são reiniciadas e ficam disponíveis.
Para obter mais informações sobre ARSO, consulte Winlogon Automatic Restart Sign-On (ARSO).
Cofre do Windows e Gerenciador de Credenciais
O Gerenciador de Credenciais é um recurso do Painel de Controle para armazenar e gerenciar nomes de usuário e senhas, que foi introduzido no Windows Server 2008 R2 e no Windows 7. O Gerenciador de Credenciais permite que os usuários armazenem credenciais relevantes para outros sistemas e sites no Cofre do Windows seguro.
Os usuários podem salvar e armazenar credenciais de navegadores e aplicativos do Windows suportados no computador local para torná-lo conveniente quando precisarem entrar nesses recursos. As credenciais são salvas em pastas criptografadas especiais no computador sob o perfil do usuário. Os aplicativos que oferecem suporte a esse recurso (usando as APIs do Gerenciador de Credenciais), como navegadores da Web e aplicativos, podem apresentar as credenciais corretas a outros computadores e sites durante o processo de logon.
Quando um site, um aplicativo ou outro computador solicita autenticação por meio de NTLM ou do protocolo Kerberos, aparece uma caixa de diálogo na qual você marca a caixa de seleção Atualizar credenciais padrão ou Salvar senha. Um aplicativo que suporta as APIs do Gerenciador de Credenciais gera essa caixa de diálogo que permite que um usuário salve credenciais localmente. 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 relacionadas do usuário para o serviço de autenticação que está em uso.
Na próxima vez que o serviço for usado, o Gerenciador de Credenciais fornecerá automaticamente a credencial armazenada no Cofre do Windows. Se não for aceite, ser-lhe-á solicitada a informação de acesso correta. Se o acesso for concedido com as novas credenciais, o Gerenciador de Credenciais substituirá a credencial anterior pela nova e, em seguida, armazenará a nova credencial no Cofre do Windows.
Base de dados do Gestor 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. Está presente em todos os sistemas operativos Windows; no entanto, quando um computador ingressa em um domínio, o Ative Directory gerencia contas de domínio em domínios do Ative Directory.
Por exemplo, os computadores clientes 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 humano está conectado. Para iniciar comunicações, o computador deve ter uma conta ativa no domínio. Antes de aceitar comunicações do computador, o LSA no controlador de domínio autentica a identidade do computador e constrói o seu contexto de segurança tal como é feito para uma entidade de segurança humana. Esse contexto de segurança define a identidade e os recursos de um usuário ou serviço em um determinado computador ou 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 Ler, Gravar ou Modificar) que uma entidade de segurança (um usuário, computador ou serviço) pode executar 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 estação de trabalho diferente da estação de trabalho principal do usuário. Também pode variar de uma sessão para outra, como quando um administrador modifica os direitos e permissões do usuário. Além disso, o contexto de segurança geralmente é diferente quando um usuário ou computador está operando de forma autônoma, em uma rede ou como parte de um domínio do Ative Directory.
Domínios locais e domínios fidedignos
Quando existe uma relação de confiança entre dois domínios, os mecanismos de autenticação para cada domínio dependem da 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 recurso (o domínio confiável) verificando se as solicitações de autenticação de entrada vêm 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 solicitações de autenticação validadas viajem entre domínios.
A forma como uma relação de confiança específica lida com as solicitações de autenticação depende de como está configurada. As relações de confiança podem ser unidirecionais, fornecendo acesso do domínio confiável a recursos no domínio confiável, ou bidirecionais, fornecendo acesso de cada domínio a recursos no outro domínio. As relações de confiança também são não transitivas, caso em que uma relação de confiança existe apenas entre os dois domínios de parceiros de confiança, ou transitivas, caso em que uma relação de confiança se estende automaticamente a quaisquer outros domínios em que qualquer um dos parceiros confia.
Para obter informações sobre relações de confiança de domínio e floresta em relação à autenticação, consulte Autenticação Delegada e Relações de Confiança.
Certificados na autenticação do Windows
Uma infraestrutura de chave pública (PKI) é a combinação de software, tecnologias de criptografia, processos e serviços que permitem que uma organização proteja suas comunicações e transações comerciais. A capacidade de uma PKI para 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 a que pertence, a entidade que o emitiu, um número de série único ou alguma outra identificação única, 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 anfitriões remotos estabelecem a sua fiabilidade obtendo um certificado de uma autoridade de certificação (AC). A AC pode, por sua vez, ter a 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 autoridade de certificação raiz e, em seguida, determinar se é confiável.
Da mesma forma, o host remoto ou o 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 Ative Directory.
Para produzir um certificado, os dados de autenticação passam por algoritmos de hash, como o Secure Hash Algorithm (SHA), para produzir um resumo de mensagens. O resumo da mensagem é então assinado digitalmente usando a chave privada do remetente para provar que o remetente produziu o resumo da mensagem.
Autenticação de 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 identificação baseada em criptografia e prova de posse ao autenticar um usuário em um domínio. Os Serviços de Certificados do Ative Directory (AD CS) fornecem a identificação baseada em criptografia através da emissão de um certificado de início de sessão para cada cartão inteligente.
A tecnologia de cartão inteligente virtual foi introduzida no Windows 8. Armazena o certificado do cartão inteligente no PC e, em seguida, protege-o utilizando o chip de segurança TPM (Trusted Platform Module) inviolável do dispositivo. Desta forma, o PC realmente se torna o cartão inteligente que deve receber o PIN do usuário para ser autenticado.
Para obter informações sobre autenticação de smart card, consulte a Referência Técnica do Windows Smart Card .
Autenticação remota e sem fio
A autenticação de rede remota e sem fio é outra tecnologia que usa certificados para autenticação. O Serviço de Autenticação da Internet (IAS) e os servidores de rede virtual privada usam a Segurança de Nível de Protocol-Transport de Autenticação Extensível (EAP-TLS), o Protocolo de Autenticação Extensível Protegida (PEAP) ou a Segurança do Protocolo Internet (IPsec) para executar a autenticação baseada em certificado para muitos tipos de acesso à rede, incluindo VPN (rede virtual privada) e conexões sem fio.
Para obter informações sobre a autenticação baseada em certificados na rede, consulte Autenticação de acesso à rede e certificados.