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 profissionais de TI descreve os protocolos de autenticação do Windows usados na arquitetura SSPI (Security Support Provider Interface).
O Microsoft Security Support Provider Interface (SSPI) é a base para a autenticação do Windows. Aplicativos e serviços de infraestrutura que exigem autenticação usam SSPI para fornecê-la.
SSPI é a implementação da GSSAPI (Generic Security Service API) em sistemas operacionais Windows Server. Para obter mais informações sobre GSSAPI, consulte RFC 2743 e RFC 2744 no banco de dados RFC IETF.
Os SSPs (Provedores de Suporte de Segurança) padrão que invocam protocolos de autenticação específicos no Windows são incorporados ao SSPI como DLLs. Esses SSPs padrão são descritos nas seções a seguir. SSPs adicionais podem ser incorporados se conseguirem operar com o SSPI.
Como mostrado na imagem a seguir, o SSPI no Windows fornece um mecanismo que carrega tokens de autenticação pelo canal de comunicação existente entre o computador cliente e o servidor. Quando dois computadores ou dispositivos precisam ser autenticados para que possam se comunicar com segurança, as solicitações de autenticação são roteadas para o SSPI, que conclui o processo de autenticação, independentemente do protocolo de rede atualmente em uso. O SSPI retorna objetos binários grandes transparentes. Eles são passados entre os aplicativos, momento em que podem ser passados para a camada SSPI. Assim, o SSPI permite que uma aplicação utilize vários modelos de segurança disponíveis num computador ou rede sem alterar a interface para o sistema de segurança.
As seções a seguir descrevem os SSPs padrão que interagem com o SSPI. Os SSPs são usados de maneiras diferentes nos sistemas operacionais Windows para promover uma comunicação segura em um ambiente de rede não seguro.
Também incluído neste tópico:
Seleção do Provedor de Suporte de Segurança
Provedor de suporte de segurança Kerberos
Este SSP usa apenas o protocolo Kerberos versão 5 conforme implementado pela Microsoft. Este protocolo baseia-se no RFC 4120 e nas revisões preliminares do Grupo de Trabalho da Rede. É um protocolo padrão da indústria que é usado com uma senha ou um cartão inteligente para um logon interativo. É também o método de autenticação preferido para serviços no Windows.
Como o protocolo Kerberos é o protocolo de autenticação padrão desde o Windows 2000, todos os serviços de domínio oferecem suporte ao SSP Kerberos. Estes serviços incluem:
Consultas do Ative Directory que usam o protocolo LDAP
Gerenciamento remoto de servidor ou estação de trabalho que usa o serviço de Chamada de Procedimento Remoto
Serviços de impressão
Autenticação cliente-servidor
Acesso remoto a ficheiros que utiliza o protocolo SMB (Server Message Block) (também conhecido como Common Internet File System ou CIFS)
Gerenciamento e referência de sistemas de arquivos distribuídos
Autenticação da intranet para os Serviços de Informações da Internet (IIS)
Autenticação da autoridade de segurança para segurança do protocolo Internet (IPsec)
Solicitações de certificado aos Serviços de Certificados do Ative Directory para usuários e computadores do domínio
Localização: %Windir%\System32\kerberos.dll
Esse provedor está incluído por padrão nas versões designadas na lista Aplica-se a no início deste tópico, além do Windows Server 2003 e do Windows XP.
Recursos adicionais para o protocolo Kerberos e o SSP Kerberos
Aprimoramentos do Kerberos para o Windows Vista
Alterações na autenticação Kerberos para Windows 7
Provedor de suporte de segurança NTLM
O NTLM Security Support Provider (NTLM SSP) é um protocolo binário de mensagens usado pela Security Support Provider Interface (SSPI) para permitir a autenticação de desafio-resposta NTLM e para negociar opções de integridade e confidencialidade. O NTLM é usado sempre que a autenticação SSPI é usada, inclusive para autenticação de Bloco de Mensagens de Servidor ou CIFS, autenticação HTTP Negotiate (por exemplo, Autenticação da Web da Internet) e o serviço de Chamada de Procedimento Remoto. O SSP NTLM inclui os protocolos de autenticação NTLM e NTLM versão 2 (NTLMv2).
Os sistemas operacionais Windows suportados podem usar o SSP NTLM para o seguinte:
Autenticação cliente/servidor
Serviços de impressão
Acesso a arquivos usando CIFS (SMB)
Serviço de Chamada de Procedimento Remoto Seguro ou serviço DCOM
Localização: %Windir%\System32\msv1_0.dll
Esse provedor está incluído por padrão nas versões designadas na lista Aplica-se a no início deste tópico, além do Windows Server 2003 e do Windows XP.
Recursos adicionais para o protocolo NTLM e o SSP NTLM
Alterações na autenticação NTLM no Windows 7
Provedor de suporte de segurança Digest
A autenticação Digest é um padrão do setor usado para LDAP (Lightweight Directory Access Protocol) e autenticação da Web. A autenticação Digest transmite credenciais pela rede como um hash MD5 ou resumo de mensagens.
Digest SSP (Wdigest.dll) é usado para o seguinte:
Acesso ao Internet Explorer e aos Serviços de Informações da Internet (IIS)
Consultas LDAP
Localização: %Windir%\System32\Wdigest.dll
Esse provedor está incluído por padrão nas versões designadas na lista Aplica-se a no início deste tópico, além do Windows Server 2003 e do Windows XP.
Recursos adicionais para o protocolo Digest e o SSP Digest
Provedor de suporte de segurança Schannel
O Canal Seguro (Schannel) é usado para autenticação de servidor baseada na Web, como quando um usuário tenta acessar um servidor Web seguro.
O protocolo TLS, o protocolo SSL, o protocolo PCT (Private Communications Technology) e o protocolo DTLS (Datagram Transport Layer) baseiam-se na criptografia de chave pública. Schannel fornece todos esses protocolos. Todos os protocolos Schannel usam um modelo cliente/servidor. O SSP Schannel usa certificados de chave pública para autenticar partes. Ao autenticar partes, o SSP Schannel seleciona um protocolo na seguinte ordem de preferência:
Transport Layer Security (TLS) versão 1.0
Transport Layer Security (TLS) versão 1.1
Transport Layer Security (TLS) versão 1.2
Secure Socket Layer (SSL) versão 2.0
Secure Socket Layer (SSL) versão 3.0
Tecnologia das Comunicações Privadas (PCT)
Observação O PCT está desativado por padrão.
O protocolo selecionado é o protocolo de autenticação preferencial que o cliente e o servidor podem suportar. Por exemplo, se um servidor suporta todos os protocolos Schannel e o cliente suporta apenas SSL 3.0 e SSL 2.0, o processo de autenticação usa SSL 3.0.
DTLS é usado quando explicitamente chamado pelo aplicativo. Para obter mais informações sobre DTLS e outros protocolos usados pelo provedor Schannel, consulte Referência técnica do provedor de suporte de segurança Schannel.
Localização: %Windir%\System32\Schannel.dll
Esse provedor está incluído por padrão nas versões designadas na lista Aplica-se a no início deste tópico, além do Windows Server 2003 e do Windows XP.
Note
O TLS 1.2 foi introduzido neste provedor no Windows Server 2008 R2 e no Windows 7. O DTLS foi introduzido neste provedor no Windows Server 2012 e no Windows 8.
Recursos adicionais para os protocolos TLS e SSL e o SSP Schannel
Negociar provedor de suporte de segurança
O Mecanismo de Negociação de GSS-API Simples e Protegido (SPNEGO) serve de base para o Negociar SSP, que pode ser usado para negociar um protocolo de autenticação específico. Quando um aplicativo chama o SSPI para fazer logon em uma rede, ele pode especificar um SSP para processar a solicitação. Se o aplicativo especificar o SSP de negociação, ele analisará a solicitação e selecionará o provedor apropriado para lidar com a solicitação, com base nas políticas de segurança configuradas pelo cliente.
SPNEGO é especificado no RFC 2478.
Nas versões suportadas dos sistemas operativos Windows, o fornecedor de suporte de segurança Negociar seleciona entre o protocolo Kerberos e o NTLM. Negociar seleciona o protocolo Kerberos por padrão, a menos que esse protocolo não possa ser usado por um dos sistemas envolvidos na autenticação ou que o aplicativo chamador não forneça informações suficientes para usar o protocolo Kerberos.
Localização: %Windir%\System32\lsasrv.dll
Esse provedor está incluído por padrão nas versões designadas na lista Aplica-se a no início deste tópico, além do Windows Server 2003 e do Windows XP.
Recursos adicionais para a Negociação SSP
[MS-SPNG]: Mecanismo de Negociação Simples e Protegido GSS-API (SPNEGO) Extensões
[MS-N2HT]: Especificação do Protocolo de Autenticação HTTP Negotiate e Nego2
Provedor de suporte de segurança de credenciais
O CredSSP (Credential Security Service Provider) fornece uma experiência de usuário de logon único (SSO) ao iniciar novas sessões dos Serviços de Terminal e dos Serviços de Área de Trabalho Remota. O CredSSP permite que os aplicativos deleguem as credenciais dos usuários do computador cliente (usando o SSP do lado do cliente) para o servidor de destino (por meio do SSP do lado do servidor), com base nas políticas do cliente. As políticas CredSSP são configuradas usando a Diretiva de Grupo e a delegação de credenciais é desativada por padrão.
Localização: %Windir%\System32\credssp.dll
Esse provedor é incluído por padrão nas versões designadas na lista Aplica-se a no início deste tópico.
Recursos adicionais para o SSP de Credenciais
[MS-CSSP]: Especificação do protocolo CredSSP (Credential Security Support Provider)
Provedor de Serviços de Segurança de Credenciais e SSO para Logon dos Serviços de Terminal
Negociar extensões do Provedor de Suporte de Segurança
Negotiate Extensions (NegoExts) é um pacote de autenticação que negocia o uso de SSPs, além do NTLM ou do protocolo Kerberos, para aplicativos e cenários implementados pela Microsoft e outras empresas de software.
Esta extensão para o pacote Negotiate permite os seguintes cenários:
Disponibilidade avançada do cliente dentro de um sistema federado. Os documentos podem ser acessados em sites do SharePoint e podem ser editados usando um aplicativo completo do Microsoft Office.
Suporte de cliente avançado para serviços do Microsoft Office. Os usuários podem entrar nos serviços do Microsoft Office e usar um aplicativo completo do Microsoft Office.
Servidor Microsoft Exchange e Outlook hospedados. Não há confiança de domínio estabelecida porque o Exchange Server está hospedado na Web. O Outlook usa o serviço Windows Live para autenticar usuários.
Disponibilidade de cliente avançado entre computadores cliente e servidores. Os componentes de rede e autenticação do sistema operacional são usados.
O pacote Windows Negotiate trata o SSP NegoExts da mesma maneira que para Kerberos e NTLM. NegoExts.dll é carregado na Autoridade de Sistema Local (LSA) durante a inicialização. Quando uma solicitação de autenticação é recebida, com base na origem da solicitação, o NegoExts negocia entre os SSPs suportados. Ele reúne as credenciais e políticas, criptografa-as e envia essas informações para o SSP apropriado, onde o token de segurança é criado.
Os SSPs suportados pelo NegoExts não são SSPs autônomos, como Kerberos e NTLM. Portanto, dentro do SSP NegoExts, quando o método de autenticação falhar por qualquer motivo, uma mensagem de falha de autenticação será exibida ou registrada. Nenhum método de renegociação ou autenticação de fallback é possível.
Localização: %Windir%\System32\negoexts.dll
Esse provedor está incluído por padrão nas versões designadas na lista Aplica-se a no início deste tópico, excluindo o Windows Server 2008 e o Windows Vista.
Provedor de suporte de segurança PKU2U
O protocolo PKU2U foi introduzido e implementado como um SSP no Windows 7 e Windows Server 2008 R2. Esse SSP permite a autenticação ponto a ponto, particularmente por meio do recurso de compartilhamento de mídia e arquivos chamado Grupo Doméstico, que foi introduzido no Windows 7. O recurso permite o compartilhamento entre computadores que não são membros de um domínio.
Localização: %Windir%\System32\pku2u.dll
Esse provedor está incluído por padrão nas versões designadas na lista Aplica-se a no início deste tópico, excluindo o Windows Server 2008 e o Windows Vista.
Recursos adicionais para o protocolo PKU2U e o SSP PKU2U
Seleção do Provedor de Suporte de Segurança
O SSPI do Windows pode utilizar qualquer um dos protocolos suportados através dos Fornecedores de Suporte de Segurança instalados. No entanto, como nem todos os sistemas operacionais oferecem suporte aos mesmos pacotes SSP que qualquer computador que executa o Windows Server, os clientes e servidores devem negociar para usar um protocolo que ambos suportam. O Windows Server prefere que computadores clientes e aplicativos usem o protocolo Kerberos, um protocolo forte baseado em padrões, quando possível, mas o sistema operacional continua a permitir que computadores cliente e aplicativos cliente que não oferecem suporte ao protocolo Kerberos se autentiquem.
Antes que a autenticação possa ocorrer, os dois computadores que se comunicam devem concordar com um protocolo que ambos possam suportar. Para que qualquer protocolo possa ser utilizado através do SSPI, cada computador deve ter o SSP apropriado. Por exemplo, para que um computador cliente e um servidor usem o protocolo de autenticação Kerberos, ambos devem oferecer suporte ao Kerberos v5. O Windows Server usa a função EnumerateSecurityPackages para identificar quais SSPs são suportados em um computador e quais são os recursos desses SSPs.
A seleção de um protocolo de autenticação pode ser tratada de uma das seguintes maneiras:
Protocolo de autenticação única
Quando um único protocolo aceitável é especificado no servidor, o computador cliente deve suportar o protocolo especificado ou a comunicação falha. Quando um único protocolo aceitável é especificado, a troca de autenticação ocorre da seguinte maneira:
O computador cliente solicita acesso a um serviço.
O servidor responde à solicitação e especifica o protocolo que será usado.
O computador cliente examina o conteúdo da resposta e verifica se ele suporta o protocolo especificado. Se o computador cliente suportar o protocolo especificado, a autenticação continuará. Se o computador cliente não suportar o protocolo, a autenticação falhará, independentemente de o computador cliente estar autorizado a aceder ao recurso.
Opção de negociação
A opção de negociação pode ser usada para permitir que o cliente e o servidor tentem encontrar um protocolo aceitável. Baseia-se no Mecanismo de Negociação Simples e Protegido GSS-API (SPNEGO). Quando a autenticação começa com a opção de negociar um protocolo de autenticação, a troca SPNEGO ocorre da seguinte forma:
O computador cliente solicita acesso a um serviço.
O servidor responde com uma lista de protocolos de autenticação que pode suportar e um desafio ou resposta de autenticação, com base no protocolo que é a sua primeira escolha. Por exemplo, o servidor pode listar o protocolo Kerberos e NTLM e enviar uma resposta de autenticação Kerberos.
O computador cliente examina o conteúdo da resposta e verifica se ele suporta algum dos protocolos especificados.
Se o computador cliente suportar o protocolo preferencial, a autenticação prossegue.
Se o computador cliente não suportar o protocolo preferencial, mas suportar um dos outros protocolos listados pelo servidor, o computador cliente informará ao servidor qual o protocolo de autenticação suportado e a autenticação prossegue.
Se o computador cliente não suportar nenhum dos protocolos listados, a troca de autenticação falhará.