Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Ao usar a autenticação do Windows como um mecanismo de segurança, o SSPI (Security Support Provider Interface) lida com processos de segurança. Quando ocorrem erros de segurança na camada SSPI, eles são exibidos pelo WCF (Windows Communication Foundation). Este tópico fornece uma estrutura e um conjunto de perguntas para ajudar a diagnosticar os erros.
Para obter uma visão geral do protocolo Kerberos, consulte Kerberos Explained; para obter uma visão geral do SSPI, consulte SSPI.
Para autenticação do Windows, o WCF normalmente usa o Negotiate Security Support Provider (SSP), que executa a autenticação mútua Kerberos entre o cliente e o serviço. Se o protocolo Kerberos não estiver disponível, por padrão, o WCF retornará ao NTLM (NT LAN Manager). No entanto, você pode configurar o WCF para usar apenas o protocolo Kerberos (e gerar uma exceção se Kerberos não estiver disponível). Você também pode configurar o WCF para usar formulários restritos do protocolo Kerberos.
Metodologia de depuração
O método básico é o seguinte:
Determine se você está usando a autenticação do Windows. Se você estiver usando qualquer outro esquema, este tópico não se aplicará.
Se você tiver certeza de que está usando a autenticação do Windows, determine se a configuração do WCF usa Kerberos direto ou Negotiate.
Depois de determinar se a configuração está usando o protocolo Kerberos ou o NTLM, você pode entender as mensagens de erro no contexto correto.
Disponibilidade do Protocolo Kerberos e do NTLM
O SSP kerberos requer que um controlador de domínio atue como o KDC (Centro de Distribuição de Chaves Kerberos). O protocolo Kerberos só está disponível quando o cliente e o serviço estão usando identidades de domínio. Em outras combinações de conta, o NTLM é usado, conforme resumido na tabela a seguir.
Os cabeçalhos da tabela mostram possíveis tipos de conta usados pelo servidor. A coluna à esquerda mostra possíveis tipos de conta usados pelo cliente.
| Usuário Local | Sistema local | Usuário de Domínio | Computador do Domínio | |
|---|---|---|---|---|
| Usuário Local | NTLM | NTLM | NTLM | NTLM |
| Sistema Local | NTLM anônimo | NTLM anônimo | NTLM anônimo | NTLM anônimo |
| Usuário de Domínio | NTLM | NTLM | Kerberos | Kerberos |
| Computador de Domínio | NTLM | NTLM | Kerberos | Kerberos |
Especificamente, os quatro tipos de conta incluem:
Usuário Local: perfil de usuário somente de computador. Por exemplo:
MachineName\AdministratorouMachineName\ProfileName.Sistema Local: o SISTEMA de conta interno em um computador que não está ingressado em um domínio.
Usuário do Domínio: uma conta de usuário em um domínio do Windows. Por exemplo:
DomainName\ProfileName.Máquina de Domínio: um processo com a identidade da máquina em execução em um computador conectado a um domínio do Windows. Por exemplo:
MachineName\Network Service.
Observação
A credencial de serviço é capturada quando o Open método da ServiceHost classe é chamado. A credencial do cliente é lida sempre que o cliente envia uma mensagem.
Problemas comuns de autenticação do Windows
Esta seção discute alguns problemas comuns de autenticação do Windows e possíveis soluções.
Protocolo Kerberos
Problemas de SPN/UPN com o protocolo Kerberos
Quando a autenticação do Windows é usada e o protocolo Kerberos é usado ou negociado pelo SSPI, a URL usada pelo ponto de extremidade do cliente precisa incluir o nome de domínio totalmente qualificado do host do serviço na URL de serviço. Isso pressupõe que a conta sob a qual o serviço está sendo executado tenha acesso à chave SPN (nome da entidade de serviço) do computador (padrão) que é criada quando o computador é adicionado ao domínio do Active Directory, o que geralmente é feito executando o serviço na conta do Serviço de Rede. Se o serviço não tiver acesso à chave SPN do computador, você precisará fornecer o SPN correto ou o UPN (nome de entidade de usuário) da conta na qual o serviço está sendo executado na identidade do ponto de extremidade do cliente. Para obter mais informações sobre como o WCF funciona com SPN e UPN, consulte Identidade e Autenticação de Serviço.
Em cenários de balanceamento de carga, como Web farms ou Web gardens, uma prática comum é criar uma conta exclusiva para cada aplicativo, atribuir um SPN a essa conta e garantir que todos os serviços do aplicativo sejam executados nessa conta.
Para obter um SPN para a conta do serviço, você precisa ser um administrador de domínio do Active Directory. Para obter mais informações, consulte o Suplemento Técnico Kerberos para Windows.
O protocolo Kerberos Direct requer que o serviço seja executado em uma conta de computador de domínio
Isso ocorre quando a propriedade ClientCredentialType é definida como Windows e a propriedade NegotiateServiceCredential é definida como false, conforme mostrado no código a seguir.
WSHttpBinding b = new WSHttpBinding();
// By default, the WSHttpBinding uses Windows authentication
// and Message mode.
b.Security.Message.NegotiateServiceCredential = false;
Dim b As New WSHttpBinding()
' By default, the WSHttpBinding uses Windows authentication
' and Message mode.
b.Security.Message.NegotiateServiceCredential = False
Para corrigir, execute o serviço usando uma conta de máquina de domínio, como uma conta de Serviço de Rede, em um computador conectado ao domínio.
A delegação exige a negociação de credenciais
Para usar o protocolo de autenticação Kerberos com a delegação, você precisa implementar o protocolo Kerberos com a negociação de credenciais (às vezes chamado de Kerberos "de vários segmentos" ou "de várias etapas"). Se você implementar a autenticação Kerberos sem a negociação de credenciais (às vezes chamada de Kerberos "de processo único" ou "de segmento único"), uma exceção será gerada.
Para implementar Kerberos com negociação de credencial, execute as seguintes etapas:
Implemente a delegação definindo AllowedImpersonationLevel como Delegation.
Exija a negociação do SSPI:
Se você estiver usando associações padrão, defina a
NegotiateServiceCredentialpropriedade comotrue.Se você estiver usando associações personalizadas, defina o
AuthenticationModeatributo doSecurityelemento comoSspiNegotiated.
Exija que a negociação do SSPI use o Kerberos, não permitindo o uso do NTLM:
Faça isso no código, com a seguinte instrução:
ChannelFactory.Credentials.Windows.AllowNtlm = falseOu você pode fazer isso no arquivo de configuração definindo o
allowNtlmatributo comofalse. Esse atributo está contido nas <janelas>.
Protocolo NTLM
O SSP Negotiate retorna para o NTLM, mas o NTLM está desabilitado
A propriedade AllowNtlm está definida como false, o que faz com que o WCF (Windows Communication Foundation) faça um melhor esforço para gerar uma exceção se o NTLM for usado. A definição dessa propriedade como false pode não impedir que as credenciais do NTLM sejam enviadas pela rede.
Veja a seguir como desabilitar o fallback para o NTLM.
CalculatorClient cc = new
CalculatorClient("WSHttpBinding_ICalculator");
cc.ClientCredentials.Windows.AllowNtlm = false;
Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
cc.ClientCredentials.Windows.AllowNtlm = False
Falha no logon do NTLM
As credenciais do cliente não são válidas no serviço. Verifique se o nome de usuário e a senha estão definidos corretamente e correspondem a uma conta conhecida pelo computador em que o serviço está sendo executado. O NTLM usa as credenciais especificadas para fazer logon no computador do serviço. Embora as credenciais possam ser válidas no computador em que o cliente está sendo executado, esse logon falhará se as credenciais não forem válidas no computador do serviço.
Ocorre um login NTLM anônimo, mas logins anônimos são desativados por padrão
Ao criar um cliente, a propriedade AllowedImpersonationLevel é definida como Anonymous, conforme o exemplo a seguir, mas, por padrão, o servidor não permite logons anônimos. Isso ocorre porque o valor padrão da AllowAnonymousLogons propriedade da WindowsServiceCredential classe é false.
O código do cliente a seguir tenta habilitar logons anônimos (observe que a propriedade padrão é Identification).
CalculatorClient cc =
new CalculatorClient("WSHttpBinding_ICalculator");
cc.ClientCredentials.Windows.AllowedImpersonationLevel =
System.Security.Principal.TokenImpersonationLevel.Anonymous;
Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
cc.ClientCredentials.Windows.AllowedImpersonationLevel = _
System.Security.Principal.TokenImpersonationLevel.Anonymous
O código de serviço a seguir altera o padrão para habilitar logons anônimos pelo servidor.
Uri httpUri = new Uri("http://localhost:8000/");
ServiceHost sh = new ServiceHost(typeof(Calculator), httpUri);
sh.Credentials.WindowsAuthentication.AllowAnonymousLogons = true;
Dim httpUri As New Uri("http://localhost:8000/")
Dim sh As New ServiceHost(GetType(Calculator), httpUri)
sh.Credentials.WindowsAuthentication.AllowAnonymousLogons = True
Para obter mais informações sobre suplantação, consulte Delegação e Suplantação.
Como alternativa, o cliente está em execução como um serviço Windows, usando a conta interna SISTEMA.
Outros problemas
As credenciais do cliente não estão definidas corretamente
A autenticação do Windows usa a WindowsClientCredential instância retornada pela ClientCredentials propriedade da ClientBase<TChannel> classe, não pela UserNamePasswordClientCredential. O exemplo a seguir mostra um exemplo incorreto.
CalculatorClient cc = new
CalculatorClient("WSHttpBinding_ICalculator");
cc.ClientCredentials.UserName.UserName = GetUserName(); // wrong!
cc.ClientCredentials.UserName.Password = GetPassword(); // wrong!
Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
cc.ClientCredentials.UserName.UserName = GetUserName() ' wrong!
cc.ClientCredentials.UserName.Password = GetPassword() ' wrong!
O exemplo a seguir mostra o exemplo correto.
CalculatorClient cc = new
CalculatorClient("WSHttpBinding_ICalculator");
// This code returns the WindowsClientCredential type.
cc.ClientCredentials.Windows.ClientCredential.UserName = GetUserName();
cc.ClientCredentials.Windows.ClientCredential.Password = GetPassword();
Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
' This code returns the WindowsClientCredential type.
cc.ClientCredentials.Windows.ClientCredential.UserName = GetUserName()
cc.ClientCredentials.Windows.ClientCredential.Password = GetPassword()
O SSPI não está disponível
Os sistemas operacionais a seguir não dão suporte à autenticação do Windows quando usados como servidor: Windows XP Home Edition, Windows XP Media Center Edition e Windows Vista Home Edition.
Desenvolvimento e implantação com identidades diferentes
Se você desenvolver seu aplicativo em um computador e implantar em outro e usar diferentes tipos de conta para autenticar em cada computador, poderá ter um comportamento diferente. Por exemplo, suponha que você desenvolva seu aplicativo em um computador Windows XP Pro usando o SSPI Negotiated modo de autenticação. Se você usar uma conta de usuário local para autenticar, o protocolo NTLM será usado. Depois que o aplicativo é desenvolvido, você implanta o serviço em um computador do Windows Server 2003 em que ele é executado em uma conta de domínio. Neste ponto, o cliente não poderá autenticar o serviço porque ele usará Kerberos e um controlador de domínio.