Arquitetura de Interface SSPI
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este tópico de referência para profissionais de TI descreve os protocolos de autenticação do Windows que são usados na arquitetura SSPI (Interface do Provedor de Suporte de Segurança).
A SSPI da Microsoft é a base da autenticação do Windows. Os aplicativos e serviços de infraestrutura que exigem autenticação usam SSPI.
A SSPI é a implementação da GSSAPI (API de Serviço de Segurança Genérica) em sistemas operacionais do Windows Server. Para obter mais informações sobre GSSAPI, confira a RFC 2743 e a RFC 2744 no banco de dados de RFC da IETF.
Os SSPs (Provedores de Suporte de Segurança) padrão que invocam protocolos de autenticação específicos no Windows estão incorporados na SSPI como DLLs. As próximas seções descrevem esses SSPs padrão. SSPs adicionais podem ser incorporados se eles puderem operar com a SSPI.
Conforme mostrado na imagem, a SSPI no Windows fornece um mecanismo que transporta os tokens de autenticação pelo canal de comunicação 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 à SSPI, que conclui o processo de autenticação, independentemente do protocolo de rede que estão usando. A SSPI retorna objetos binários grandes e claros. Os objetos são passados para os aplicativos somente no momento em que puderem ser recebidos pela camada da SSPI. Desse modo, a SSPI permite que um aplicativo use os vários modelos de segurança disponíveis em um computador ou na rede, sem alterar a interface do sistema de segurança.
As próximas seções descrevem os SSPs padrão que interagem com a SSPI. Os SSPs são usados de diferentes formas nos sistemas operacionais Windows para propiciar uma comunicação segura em um ambiente de rede não seguro.
Este tópico também inclui:
Escolha do Provedor de suporte de segurança
Provedor de suporte de segurança Kerberos
Esse SSP usa apenas o protocolo Kerberos versão 5, conforme implementado pela Microsoft. Esse protocolo baseia-se na RFC 4120 do Grupo de Trabalho de Rede e nas revisões de rascunhos. É um protocolo padrão do setor, usado com uma senha ou um cartão inteligente para oferecer logon interativo. Também é o método de autenticação preferencial dos 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 suportam o SSP Kerberos. Esses serviços incluem:
Consultas do Active Directory que usam LDAP (Lightweight Directory Access Protocol)
Gerenciamento remoto de servidor ou estação de trabalho que usa o serviço Chamada de Procedimento Remoto
Serviços de impressão
Autenticação de cliente-servidor
Acesso remoto a arquivos que usa o protocolo SMB (Server Message Block), também conhecido como Common Internet File System ou CIFS
Gerenciamento e referência do sistema de arquivos distribuídos
Autenticação da intranet para o IIS (Serviços de Informações da Internet)
Autenticação de autoridade de segurança para IPsec (Internet Protocol Security)
Solicitações de certificado de Serviços de Certificados do Active Directory para usuários e computadores de domínio
Local: %Windir%\System32\kerberos.dll
Esse provedor é incluído por padrão em versões definidas 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 Windows Vista
Alterações na Autenticação Kerberos para Windows 7
Provedor de suporte de segurança NTLM
O SSP NTLM (Provedor de suporte de segurança NTLM) é um protocolo de mensagens binária usado pela SSPI para fazer a autenticação em resposta à solicitação do NTLM e negociar opções de integridade e confidencialidade. O NTLM é usado sempre que a autenticação SSPI é usada, inclusive para autenticação SMB ou CIFS, autenticação HTTP do Negotiate (por exemplo, autenticação na Web da Internet) e para o serviço Chamada de Procedimento Remoto. O SSP NTLM inclui os protocolos de autenticação NTLM e NTLM versão 2 (NTLMv2).
Os sistemas operacionais Windows compatíveis podem usar o SSP NTLM para:
Autenticação de cliente-servidor
Serviços de impressão
Acesso a arquivos usando CIFS (SMB)
Serviço Chamada de Procedimento Remoto seguro ou serviço DCOM
Local: %Windir%\System32\msv1_0.dll
Esse provedor é incluído por padrão em versões definidas 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
Auditing and restricting NTLM usage guide (Guia de uso do NTLM para auditoria e restrição)
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 na Web. Essa autenticação transmite as credenciais pela rede como um hash MD5 ou um resumo de mensagens.
O SSP Digest (Wdigest.dll) é usado para:
Acesso ao Internet Explorer e ao IIS (Serviços de Informações da Internet)
Consultas LDAP
Local: %Windir%\System32\Wdigest.dll
Esse provedor é incluído por padrão em versões definidas 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 Schannel (Canal Seguro) é usado para autenticação de servidor baseada na Web, como por exemplo, quando um usuário tenta acessar um servidor Web seguro.
Os protocolos TLS, SSL, DTLS e PCT são baseados em criptografia por chave pública. O Schannel oferece todos esses protocolos. Todos os protocolos Schannel usam um modelo de cliente/servidor. O SSP Schannel usa certificados de chave pública para autenticar as partes. Ao autenticar os envolvidos, o SSP Schannel escolhe um protocolo na seguinte ordem de preferência:
TLS versão1.0
TLS versão1.1
TLS versão1.2
SSL versão 2.0
SSL versão 3.0
PCT
Observe que o PCT fica desabilitada por padrão.
O protocolo escolhido é o protocolo de autenticação preferencial que o cliente e o servidor suportam. Por exemplo, se um servidor suporta todos os protocolos Schannel e o cliente suporta apenas o SSL 3.0 e o SSL 2.0, o processo de autenticação usa o SSL 3.0.
O DTLS é usado quando é chamado explicitamente pelo aplicativo. Para obter mais informações sobre DTLS e os outros protocolos usados pelo provedor Schannel, confira Referência técnica do provedor de suporte de segurança Schannel.
Local: %Windir%\System32\Schannel.dll
Esse provedor é incluído por padrão em versões definidas na lista Aplica-se a (no início deste tópico), além do Windows Server 2003 e do Windows XP.
Observação
O TLS 1.2 começou a ser usado por esse provedor no Windows Server 2008 R2 e no Windows 7. O DTLS começou a ser usado por esse provedor no Windows Server 2012 e no Windows 8.
Recursos adicionais para os protocolos TLS e SSL e o SSP Schannel
Provedor de suporte de segurança Negotiate
O SPNEGO (Mecanismo de Negociação de GSS-API simples e protegido) é a base do SSP Negotiate, 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 escolher o SSP Negotiate, ele analisará a solicitação e escolherá o melhor provedor para gerenciar a solicitação com base na política de segurança configurada pelo cliente.
O SPNEGO está especificado na RFC 2478.
Em versões compatíveis com os sistemas operacionais Windows, o provedor de suporte de segurança Negotiate seleciona o protocolo Kerberos ou o protocolo NTLM. O Negotiate seleciona o protocolo Kerberos por padrão, a menos que ele não possa ser usado por um dos sistemas envolvidos na autenticação ou o aplicativo que está chamando não forneça informações suficientes para usar o protocolo Kerberos.
Local: %Windir%\System32\lsasrv.dll
Esse provedor é incluído por padrão em versões definidas 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 SSP Negotiate
Provedor de Suporte de Segurança de Credencial
O CredSSP (Provedor de serviços de segurança Credential) oferece SSO (logon único) de usuário ao iniciar novas sessões de Serviços de Terminal e de 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 do CredSSP são configuradas usando a Política de Grupo. A delegação de credenciais fica desativada por padrão.
Local: %Windir%\System32\credssp.dll
Esse provedor é incluído por padrão em versões definidas na lista Aplica-se a (no início deste tópico).
Recursos adicionais para o SSP Credential
Provedor de suporte de segurança de extensões Negotiate
O NegoExts (Extensões do Negotiate) é um pacote de autenticação que negocia o uso de SSPs, além dos protocolos NTLM ou Kerberos, para aplicativos e cenários implementados pela Microsoft e outras empresas de software.
Essas extensões viabilizam os seguintes cenários:
Disponibilidade avançada do cliente em um sistema federado. Os documentos podem ser acessados em sites SharePoint e editados usando qualquer aplicativo do Microsoft Office.
Suporte avançado ao cliente para serviços do Microsoft Office. Os usuários podem entrar nos serviços do Microsoft Office e usar qualquer aplicativo do Microsoft Office.
Microsoft Exchange Server e Outlook hospedados. Não há verificação de domínio de confiança porque o Exchange Server está hospedado na Web. O Outlook usa o serviço Windows Live para autenticar usuários.
Disponibilidade avançada do cliente entre computadores cliente e servidores. São usados os componentes de rede e de autenticação do sistema operacional.
O pacote do Windows Negotiate trata o SSP NegoExts da mesma maneira que trata o Kerberos e o NTLM. O NegoExts.dll é carregado na LSA (Autoridade do Sistema Local) durante a inicialização. Quando uma solicitação de autenticação é recebida, com base na origem da solicitação, o NegoExts negocia com os SSPs suportados. Ele coleta as credenciais e as políticas, criptografa esses dados e envia para o SSP apropriado que criará o token de segurança.
Os SSPs compatíveis com o NegoExts não são SSPs autônomos, como o Kerberos e o NTLM. Portanto, no SSP NegoExts, se o método de autenticação falhar, uma mensagem de falha de autenticação será exibida ou registrada. Não é possível usar métodos de renegociação ou autenticação de fallback.
Local: %Windir%\System32\negoexts.dll
Esse provedor é incluído por padrão em versões definidas na lista Aplica-se a (no início deste tópico), exceto no Windows Server 2008 e no Windows Vista.
Provedor de suporte de segurança PKU2U
O protocolo PKU2U começou a ser usado e implementado como um SSP no Windows 7 e no Windows Server 2008 R2. Esse SSP faz autenticação ponto a ponto, especialmente por meio do recurso de compartilhamento de arquivos e mídia chamado HomeGroup, que foi introduzido no Windows 7 . O recurso permite o compartilhamento entre computadores que não são membros de um domínio.
Local: %Windir%\System32\pku2u.dll
Esse provedor é incluído por padrão em versões definidas na lista Aplica-se a (no início deste tópico), exceto no Windows Server 2008 e no Windows Vista.
Recursos adicionais para o protocolo PKU2U e o SSP PKU2U
Escolha do Provedor de suporte de segurança
A SSPI do Windows pode usar qualquer um dos protocolos de Provedores de suporte de segurança que estão instalados. No entanto, como nem todos os sistemas operacionais suportam os mesmos pacotes SSP de computadores que executam o Windows Server, os clientes e os servidores devem negociar o uso de um protocolo suportado por ambos. O Windows Server prefere que, quando possível, computadores cliente e aplicativos usem o protocolo Kerberos, um protocolo forte baseado em padrões. Porém, o sistema operacional permite que computadores cliente e aplicativos cliente que não suportam o protocolo Kerberos se autentiquem.
Antes que a autenticação ocorra, os dois computadores que estão se comunicando devem definir o protocolo que ambos usarão. Esse protocolo deve estar instalado nos dois computadores. Por exemplo, para que um computador cliente e um servidor usem o protocolo de autenticação Kerberos, ambos devem suportar o Kerberos v5. O Windows Server usa a função EnumerateSecurityPackages para identificar quais SSPs são suportados pelo computador e quais são os recursos desses SSPs.
Para escolher o protocolo de autenticação, use uma dessas fomas:
Protocolo de autenticação única
Quando o servidor aceita um único protocolo, o computador cliente deve suportar o protocolo especificado ou a comunicação falhará. Nesse caso, o processo 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 ter autorização para acessar o recurso.
Opção de negociação
A opção para negociar é usada para que o cliente e o servidor tentem encontrar um protocolo aceitável. A negociação se baseia no SPNEGO (Mecanismo de Negociação de GSS-API Simples e Protegido). Quando a autenticação começa com a opção de negociar um protocolo de autenticação, o processo do SPNEGO ocorre da seguinte maneira:
O computador cliente solicita acesso a um serviço.
O servidor responde enviando uma lista de protocolos de autenticação que podem ser usados e uma solicitação ou resposta de autenticação com base no protocolo preferencial dele. Por exemplo, o servidor pode listar os protocolos 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 o protocolo especificado.
Se o computador cliente suportar o protocolo preferencial, a autenticação continuará.
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 protocolo de autenticação ele suporta e a autenticação continuará.
Se o computador cliente não suportar nenhum dos protocolos listados, a troca de autenticação falhará.