Qual e o nome dado a um programa ou código de programa que contorna a autenticação normal?

• Portal do Governo
• Cidadão SP

• Fale Conosco

• Portal do Governo
• Cidadão SP

• /governosp

• Fale Conosco

Secretaria da Fazenda e Planejamento

Em atendimento à legislação eleitoral, os demais conteúdos deste site ficarão
indisponíveis de 2 de julho de 2022 até o final da eleição estadual em São Paulo.

hidden

• Portal do Governo
• Cidadão SP

• /governosp

• Fale Conosco

Pesquisa de Opinião

Hidden

• Início

• Institucional

• Cidadão

• Empresa

• Acesso à Informação

• Notícias

• Atendimento

Governo do Estado de São Paulo Secretaria da Fazenda e Planejamento

hidden

Avançar para o conteúdo principal

Não há mais suporte para esse navegador.

Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.

Processos de credenciais na autenticação do Windows

• Artigo
• 05/04/2022
• 29 minutos para o fim da leitura

Neste artigo

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 autenticação do Windows processa credenciais.

Windows gerenciamento de credenciais é o processo pelo qual o sistema operacional recebe as credenciais do serviço ou do usuário e protege essas informações para futura apresentação 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, Windows credenciais 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 do 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 esteja protegida por 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

Este tópico contém as seguintes seções:

• Entrada de credencial para logon do usuário

• Entrada de credencial para logon de aplicativo e serviço

• Autoridade de Segurança Local

• Credenciais e validação armazenadas em cache

• Armazenamento e validação de credenciais

• Banco de dados do Gerenciador de Contas de Segurança

• Domínios locais e domínios confiáveis

• Certificados em autenticação do Windows

Entrada de credencial para logon do usuário

Em Windows Server 2008 e Windows Vista, a arquitetura GINA (Identificação Gráfica e Autenticação) 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 são descritos abaixo.

Arquitetura de autenticação e identificação gráfica

A arquitetura GINA (Identificação Gráfica e Autenticação) 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 interativa 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 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 LSA (Autoridade de Segurança Local).

O diagrama a seguir mostra o processo de credencial 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 ao 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 diferentes métodos de autenticação, como senha, cartão inteligente e biometria.

Com a arquitetura do provedor de credenciais, o Winlogon sempre inicia a interface do usuário do 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 para o número de diferentes tipos 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 que todos os provedores enumeraram seus blocos, a interface do usuário do Logon os exibe para o usuário. O usuário interage com um bloco para fornecer suas credenciais. A interface do usuário do logon envia essas credenciais para autenticação.

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.

As credenciais de empacotamento 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 do logon. Portanto, sua organização pode controlar a exibição de logon, como usuários, sistemas de destino para logon, acesso pré-logon às políticas de bloqueio/desbloqueio de rede e estação de trabalho por meio do uso de provedores de credenciais personalizados. Vários provedores de credenciais podem coexistir no mesmo computador.

Provedores de SSO (logon único) podem ser desenvolvidos como um provedor de credenciais padrão ou como um provedor de pré-logon-access.

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 destina-se a 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 para este 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 PROVEDOR de serviços de Internet (ISP), autentica-se 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 de Serviços do Access Remota 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 de Serviços do Access remota 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 no Applies para listar no início deste tópico.

• O provedor de credencial 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 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 atualmente é 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 atualmente é 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 do usuário de credencial não usa a mesma instância do provedor que a interface do usuário do 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 possam afetar potencialmente 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 credencial para os sistemas operacionais designados na lista Aplica-se ao início deste tópico.

Entrada de credencial para logon de aplicativo e serviço

autenticação do Windows foi projetado 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 Provedor de Suporte de Segurança (SSP) por meio da SSPI (Interface do Provedor de Suporte de Segurança) em 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)SSPI.

• O aplicativo no lado do servidor da conexão responde com a função AcceptSecurityContext (General)SSPI.

• As funções de SSPI e AcceptSecurityContext (General) são repetidas InitializeSecurityContext (General) 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 for autenticada, o 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 ImpersonateSecurityContext SSPI 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 gravados 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 (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 de 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, inclusive 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).

A 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 gerenciadas e contas virtuais foram introduzidas no Windows Server 2008 R2 e Windows 7 para fornecer aplicativos cruciais, como Microsoft SQL Server e Serviços de Informações da Internet (IIS), com o isolamento de suas próprias contas de domínio, eliminando 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 a 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 Windows sejam executados no contexto de segurança do usuário que os inicia, isso não é verdade para os serviços. Muitos serviços 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 após o último usuário humano fazer logon.

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. Windows Server 2008 R2 introduziu serviços executados em uma conta de serviço gerenciada, 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 Windows implementa uma interface programática que o gerenciador do controlador de serviço pode usar para controlar o serviço. Um serviço de 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 messenger 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, assim 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 o 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 total aos recursos de hardware e sistema do computador. O modo kernel impede que os 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 informações sobre todos os aspectos da segurança local em um computador (esses aspectos são coletivamente conhecidos como política de segurança local) e fornece vários serviços para 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. O 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 locais 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 se originou 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 que os usuários acessem diretamente os recursos de rede, como compartilhamentos de arquivos, caixas de correio Exchange Server e sites SharePoint, sem inserir novamente 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 (tíquetes de concessão de tíquetes (TGTs), tíquetes de serviço)

• Hash de 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 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 em Windows com uma senha compatível com hashes LM (LAN Manager), esse autenticador estará 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 LSASS (Serviço de Subsistema da Autoridade de Segurança Local) que foram 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 no 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 em Windows 8.1, o sistema operacional cliente fornece proteção adicional para a 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 a LSA armazena e gerencia.

Para obter mais informações sobre essas proteções adicionais, consulte Configurar proteção LSA adicional.

Credenciais em cache e validação

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, 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, Windows armazena em cache as credenciais fornecidas e as armazena no hive de segurança no registro do sistema de operações.

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 dentro desse 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 de sistemas operacionais Windows e os sistemas operacionais Windows Vista e Windows XP.

Processos de credencial de logon remoto

O RDP (Protocolo de Área de Trabalho Remota) gerencia as credenciais do usuário que se conecta a um computador remoto usando o Cliente de Área de Trabalho Remota, que foi introduzido em Windows 8. As credenciais no formulário 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 em Windows Server 2012 R2 e Windows 8.1, o modo administrador restrito fornece segurança adicional para cenários de logon remoto. Esse modo de Área de Trabalho Remota faz com que o aplicativo cliente execute uma resposta de desafio de logon de rede com a função NT unidirecional (NTOWF) ou use um tíquete de serviço Kerberos ao autenticar para o 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 do 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, o LSA salva as credenciais do usuário na memória criptografada que são acessíveis 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 Autologon para o usuário.

Na reinicialização, o usuário é conectado automaticamente por meio do mecanismo de Autologon e, em seguida, o computador também está bloqueado 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 disponíveis.

Para obter mais informações sobre ARSO, consulte o ARSO (Winlogon Automatic Restart Sign-On).

Nomes de usuário e senhas armazenados em Windows Vista e Windows XP

No Windows Server 2008, Windows Server 2003, Windows Vista e Windows XP, nomes de usuário armazenados e senhas em Painel de Controle simplifica o gerenciamento e o uso de vários conjuntos de credenciais de logon, incluindo certificados X.509 usados com cartões inteligentes e Windows Credenciais dinâmicas (agora chamadas de conta da 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 comprometerá 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, nomes de usuário armazenados e senhas serão consultados . Se as credenciais alternativas com as informações de logon corretas tiverem sido salvas em Nomes de Usuário Armazenados e Senhas, 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 armazenados e senhas 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 somente para autenticação NTLM, protocolo Kerberos, conta microsoft (anteriormente Windows ID dinâmica) e autenticação 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 Configurações\Username\Application Data\Microsoft\Credentials. Como resultado, essas credenciais poderão ser usadas 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 de Nomes de Usuário Armazenados e Senhas 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 Armazenados e Senhas no segundo computador.

Windows Vault e o Gerenciador de Credenciais

O Gerenciador de Credenciais foi introduzido no Windows Server 2008 R2 e Windows 7 como um recurso de 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 de Windows seguro. 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 no perfil do usuário. Aplicativos que dão suporte a esse recurso (por meio do uso das APIs do Credential Manager), como navegadores e aplicativos da Web, podem apresentar as credenciais corretas para outros computadores e sites durante o processo de logon.

Quando um site, um aplicativo ou outro computador solicita autenticação por meio do NTLM ou do protocolo Kerberos, uma caixa de diálogo é exibida na qual você seleciona 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 Credential Manager. Se o usuário selecionar a caixa de seleção Salvar Senha , o Gerenciador de Credenciais acompanhará o nome de usuário, a senha e as informações relacionadas do 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 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á a nova credencial no Cofre 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 Windows sistema operacional; 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 humano está conectado. Para iniciar as 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, em seguida, constrói o contexto de segurança do computador da mesma forma que faz 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 Leitura, Gravação ou Modificação) que podem ser executadas por essa entidade - 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 em uma estação de trabalho diferente da estação de trabalho principal do próprio usuário. Ele 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 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 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. Os trusts 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, os trusts atuam como pontes que permitem que somente as solicitações de autenticação validadas viajem entre domínios.

A forma como uma confiança específica passa solicitações de autenticação depende de como ela é 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 bidirecional, fornecendo acesso de cada domínio a recursos no outro domínio. As relações de confiança também não são transitivas, caso em que existe uma confiança somente entre os dois domínios de parceiros de confiança ou transitiva, nesse caso, uma confiança se estende automaticamente para quaisquer outros domínios que um dos parceiros confia.

Para obter informações sobre relações de confiança de domínio e floresta sobre autenticação, consulte Autenticação Delegada e Relações de Confiança.

Certificados no autenticação do Windows

Uma PKI (infraestrutura de chave pública) é 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 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 alguma outra identificação exclusiva, datas de emissão e expiração 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 autoridade de certificação (AC). 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 o computador local devem 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 o Algoritmo de Hash Seguro 1 (SHA1), para produzir um resumo de 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 em Windows 7 e Windows Vista, mas foi alterado para SHA2 em 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 ele usa a identificação baseada em criptografia e a prova de posse ao autenticar um usuário em um domínio. O AD CS (Active Directory Certificate Services) 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 o Windows Referência Técnica de Cartão Inteligente.

A tecnologia de cartão inteligente virtual foi introduzida em Windows 8. Ele 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 a Autenticação Extensível Protocol-Transport Nível de Segurança (EAP-TLS), PEAP (Protocolo de Autenticação Extensível Protegida) ou Segurança de Protocolo de 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 certificado na rede, consulte autenticação e certificados de acesso à rede.

Confira também

Conceitos de autenticação do Windows

Qual é o nome dado a um programa ou código de programa que contorna a autenticação normal Select One?

Qual é o nome dado a um programa ou código de programa que ignora a autenticação norma?

Qual o nome é dado ao tipo de software que gera receita através da geração de Pop

Quais são três exemplos de controles de acesso administrativo escolha três?