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.
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 usuário e protege essas informações para apresentação futura ao destino de autenticação. No caso de um computador associado a um 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 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.
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 segura (interface do usuário de logon) para a Autoridade de Segurança Local (LSA) através 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 neste tópico. |
| 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: - Mantém o canal seguro do computador para um controlador de domínio (não confundir com Schannel). |
| 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. |
Este tópico contém as seguintes seções:
Entrada de credenciais para de logon do usuário
Entrada de credenciais para logon do usuário
No Windows Server 2008 e no Windows Vista, a arquitetura de Identificação e Autenticação Gráfica (GINA) foi substituída por um modelo de provedor de credenciais, que tornou possível enumerar diferentes tipos de logon por meio do uso de blocos de logon. Ambos os modelos são descritos abaixo.
Arquitetura de identificação gráfica e autenticaçã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 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 mudou 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 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 fornecedores terem enumerado os seus blocos, o ecrã de início de sessão exibirá-os ao 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 fornecedores 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 pelo seguinte:
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 azulejos de logon podem ser exibidos na interface do usuário de logon. Portanto, a sua organização pode controlar a exibição de logon, como os utilizadores, os sistemas de destino para logon, o acesso à rede antes do logon e as políticas de bloqueio/desbloqueio da estação de trabalho - através do uso de 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 Pré-Logon-Access.
Cada versão do Windows contém um provedor de credenciais padrão e um provedor de pré-Logon-Access padrão (PLAP), também conhecido como fornecedor 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 este provedor é implementado, o provedor não enumera blocos na interface de início de sessão.
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. As variações para este cenário incluem:
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. Nesse cenário, o usuário é obrigado a se conectar à rede antes de fazer logon no computador.
Enumeração do bloco de início de sessão
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 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 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; no entanto, 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 de credenciais não utiliza a mesma instância do provedor que a interface de logon, desbloquear estação de trabalho ou alterar senha. Portanto, as informações de estado não podem ser mantidas no provedor entre instâncias da Interface de Utilizador de Credenciais. Essa estrutura resulta em um bloco para cada logon do computador remoto, supondo que as credenciais tenham sido 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.
O diagrama a seguir mostra o processo de credenciais para os sistemas operacionais designados na lista Aplica-se a no início deste tópico.
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 no 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 tenham sido trocadas para autenticação bem-sucedida ou falhada.Depois que a conexão for 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 as funções específicas do sistema operacional em nome do sistema ambiental 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 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 através 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 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 de 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. 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 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 ficheiro Ksecdd.sys gere e codifica estas credenciais e utiliza uma chamada de função local no LSA. O tipo de arquivo é DRV (driver) e é conhecido como SSP (Security Support Provider) de modo kernel e, nas 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 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. O LSA pode validar as informações do usuário verificando o banco de dados do 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 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 contacta a entidade que emitiu a conta e solicita a verificação de que a conta é válida e de que o pedido teve origem no 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 encriptado de forma reversível
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 sem formatação na memória não pode ser desabilitado, mesmo se os provedores de credenciais que as exigem estiverem desabilitados.
As credenciais armazenadas estão diretamente associadas às sessões de logon do LSASS (Local Security Authority Subsystem Service) que foram iniciadas após a última reinicialização e não foram fechadas. Por exemplo, sessões LSA com credenciais LSA armazenadas são criadas quando um usuário faz qualquer um dos seguintes:
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 lote
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 para a conta dos Serviços de Domínio do Active Directory (AD DS) do computador
Palavras-passe de conta para serviços do Windows configurados no computador
Palavras-passe de conta para tarefas agendadas configuradas
Senhas de conta para pools de aplicativos e sites do IIS
Palavras-passe para contas Microsoft
Introduzido no Windows 8.1, o sistema operacional cliente fornece proteção adicional para o LSA para evitar a leitura de memória e injeção de código por processos não protegidos. Essa proteção aumenta a segurança das credenciais que o LSA armazena e gerencia.
Para obter mais informações sobre essas proteções adicionais, consulte Configuração de 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 utilizar um conjunto de credenciais para aceder a diferentes recursos. 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. 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 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.
Introduzido no Windows Server 2012 R2 e no Windows 8.1, o modo Administrador Restrito fornece segurança adicional para cenários de logon remoto. 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 os 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 num dispositivo Windows 8.1, o LSA guarda as credenciais do utilizador na memória encriptada que só são acessíveis por LSASS.exe. 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).
Nomes de usuário e senhas armazenados no Windows Vista e Windows XP
No Windows Server 2008, Windows Server 2003, Windows Vista e Windows XP, Nomes de Utilizador e Senhas Guardadas no Painel de Controlo simplifica 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 chamadas de conta Microsoft). As credenciais - parte do perfil do usuário - são armazenadas até que seja 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 de o utilizador fazer logon e tentar aceder a recursos adicionais protegidos por palavra-passe, como uma partilha num servidor, e se as credenciais de logon padrão do utilizador não forem suficientes para obter acesso, são consultados os Nomes de Utilizador e Senhas Armazenadas. 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.
Aplicam-se as seguintes restrições:
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 armazena credenciais apenas para autenticação NTLM, protocolo Kerberos, conta da Microsoft (anteriormente Windows Live ID) e SSL (Secure Sockets Layer). 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 podem fazer roaming com o usuário se a política de rede do usuário oferecer suporte a perfis de usuário móvel. No entanto, se o usuário tiver cópias de 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.
Cofre do Windows 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 do Windows seguro. Algumas versões do Internet Explorer usam esse recurso para autenticação em sites.
O gerenciamento de credenciais usando o Gerenciador de Credenciais é controlado pelo usuário no computador local. Os usuários podem salvar e armazenar credenciais de navegadores e aplicativos do Windows compatíveis 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 (por meio do uso das 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. Essa caixa de diálogo que permite que um usuário salve credenciais localmente é gerada por um aplicativo que oferece 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 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 uma partilha de ficheiros ou impressora) que podem ser acedidos e as ações (como Ler, Gravar ou Modificar) que podem ser executadas por essa entidade - um utilizador, computador ou serviço no 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 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 existe uma relação de confiança 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 pela qual foi emitido, 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 ela é 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 Secure Hash Algorithm 1 (SHA1), para produzir um resumo de mensagem. O resumo da mensagem é então 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 Windows Vista, mas foi alterado para SHA2 no Windows 8.
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.
Para obter informações sobre autenticação de smart card, consulte a Referência Técnica do Windows Smart Card .
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, a fim de ser autenticado.
Autenticação remota e sem fios
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.