Depuración de errores de autenticación de Windows

Cuando se utiliza la autenticación de Windows como un mecanismo de seguridad, la interfaz del proveedor de compatibilidad para seguridad (SSPI) controla los procesos de seguridad. Cuando los errores de seguridad se producen en el nivel de SSPI, Windows Communication Foundation (WCF) los emerge. En este tema se proporciona un marco y conjunto de cuestiones que le ayudarán a diagnosticar los errores.

Para obtener una introducción al protocolo Kerberos, vea Kerberos explicado; para una introducción a SSPI, vea SSPI.

Para la autenticación de Windows, WCF utiliza normalmente el proveedor de compatibilidad para seguridad (SSP) Negotiate, que realiza la autenticación mutua de Kerberos entre el cliente y el servicio. Si el protocolo Kerberos no está disponible, de forma predeterminada WCF se retira a NT LAN Manager (NTLM). Sin embargo, puede configurar WCF para utilizar sólo el protocolo Kerberos (y para que se inicie una excepción si Kerberos no está disponible). También puede configurar WCF para utilizar formularios restringidos del protocolo Kerberos.

Depuración de la metodología

El método básico es el siguiente:

1. Determine si está utilizando la autenticación de Windows. Si está utilizando cualquier otro esquema, no se aplicará este tema.
2. Si está seguro de que está utilizando la autenticación de Windows, determine si su configuración de WCF utiliza Kerberos Direct o Negotiate.
3. Cuando haya determinado si su configuración está utilizando el protocolo Kerberos o NTLM, podrá entender los mensajes de error en el contexto correcto.

Disponibilidad del protocolo Kerberos y NTLM

SSP de Kerberos exige que un controlador de dominio actúe como el Centro de distribución de claves de Kerberos (KDC). El protocolo Kerberos sólo está disponible cuando el cliente y el servicio están utilizando las identidades del dominio. En otras combinaciones de cuentas, se utiliza NTLM, tal y como se resume en la tabla siguiente.

Los encabezados de la tabla muestran posibles tipos de cuenta utilizados por el servidor. La columna izquierda muestra posibles tipos de cuenta utilizados por el cliente.

	Usuario local	Sistema local	Usuario de dominio	Equipo del dominio
Usuario local	NTLM	NTLM	NTLM	NTLM
Sistema local	NTLM anónimo	NTLM anónimo	NTLM anónimo	NTLM anónimo
Usuario de dominio	NTLM	NTLM	Kerberos	Kerberos
Equipo del dominio	NTLM	NTLM	Kerberos	Kerberos

Específicamente, los cuatro tipos de cuenta incluyen:

• Usuario local: perfil de usuario de sólo el equipo. Por ejemplo: MachineName\Administrator o MachineName\ProfileName.
• Sistema local: el SISTEMA de cuentas integrado en un equipo que no está unido a un dominio.
• Usuario del dominio: una cuenta de usuario en un dominio de Windows. Por ejemplo: DomainName\ProfileName.
• Equipo del dominio: un proceso con la identidad del equipo en ejecución en un equipo unido a un dominio de Windows. Por ejemplo: MachineName\Network Service.

Nota

Se captura la credencial de servicio cuando se llama al método Open de la clase ServiceHost. Se lee la credencial del cliente siempre que el cliente envíe un mensaje.

Problemas comunes de autenticación de Windows

En esta sección se tratan algunos problemas comunes de autenticación de Windows y las soluciones posibles.

Protocolo Kerberos

Problemas de SPN/UPN con el protocolo Kerberos

Cuando se utiliza la autenticación de Windows y se usa o se negocia el protocolo Kerberos mediante SSPI, la dirección URL que el extremo de cliente usa debe incluir el nombre de dominio completo del host de servicio dentro de la dirección URL del servicio. Esto supone que la cuenta con la que se ejecuta el servicio tiene acceso a la clave del nombre principal de servicio (SPN) de equipo (valor predeterminado) que se crea cuando el equipo se agrega al dominio de Active Directory, que se hace por lo general ejecutando el servicio en la cuenta Servicio de red. Si el servicio no tiene acceso a la clave SPN del equipo, debe proporcionar el SPN correcto o el nombre principal del usuario (UPN) de la cuenta con la que se está ejecutando el servicio en la identidad del extremo del cliente. Para obtener más información acerca de cómo WCF funciona con SPN y UPN, vea Identidad del servicio y autenticación.

En los escenarios de equilibrio de carga, como las granjas de servidores web o los conjuntos de procesos de aplicación web, una práctica común es definir una cuenta única para cada aplicación, asignar un SPN a esa cuenta y asegurarse de que todos los servicios de la aplicación se ejecutan con esa cuenta.

Para obtener un SPN para la cuenta de servicio, necesita ser un administrador de dominios de Active Directory. Para obtener más información, consulte Kerberos Technical Supplement for Windows.

El protocolo Kerberos Direct requiere que el servicio se ejecute en una cuenta de equipo de dominio

Esto se produce cuando la propiedad ClientCredentialType está establecida como Windows y la propiedad NegotiateServiceCredential está establecida como false, tal y como se muestra en el código siguiente.

Para solucionarlo, ejecute el servicio mediante una cuenta de equipo de dominio, como el servicio de red, en un equipo unido a un dominio.

La delegación requiere la negociación de la credencial

Para utilizar el protocolo de autenticación Kerberos con la delegación, debe implementar el protocolo Kerberos con negociación de la credencial (a veces denominado Kerberos de "autenticación mutua" o "de varios pasos"). Si implementa la autenticación de Kerberos sin la negociación de la credencial (denominada en ocasiones Kerberos de "un disparo" o "fase única"), se producirá una excepción.

Para implementar Kerberos con la negociación de credenciales, lleve a cabo los pasos siguientes:

1. Implemente la delegación estableciendo AllowedImpersonationLevel como Delegation.
2. Es necesaria la negociación de SSPI:
   1. Si está usando enlaces estándar, establezca la propiedad NegotiateServiceCredential como true.
   2. Si está utilizando los enlaces personalizados, establezca el atributo AuthenticationMode del elemento Security como SspiNegotiated.
3. Es necesaria la negociación de SSPI para utilizar Kerberos al no permitir el uso de NTLM:
   1. Realice esta acción en el código, con la siguiente instrucción: ChannelFactory.Credentials.Windows.AllowNtlm = false
   2. O bien puede hacerlo en el archivo de configuración estableciendo el atributo allowNtlm como false. Este atributo se incluye en <windows> of <clientCredentials> element.

Protocolo NTLM

Negociar SSP retrocede hasta NTLM, pero NTLM está deshabilitado

La propiedad AllowNtlm se establece en false, que hace que Windows Communication Foundation (WCF) intente por todos los medios que se inicie una excepción si se utiliza NTLM. Tenga en cuenta que, aunque se establezca esta propiedad en false, es posible que se envíen igualmente las credenciales NTLM a través de la conexión.

A continuación, se muestra cómo deshabilitar el retroceso a NTLM.

Error en el inicio de sesión de NTLM

Las credenciales del cliente no son válidas en el servicio. Compruebe que el nombre de usuario y la contraseña se hayan establecido correctamente y que se corresponde con una cuenta que es conocida en el equipo en el que se está ejecutando el servicio. NTLM utiliza las credenciales especificadas para iniciar sesión en el equipo del servicio. Mientras las credenciales pueden ser válidas en el equipo donde el cliente se está ejecutando, se producirá un error en este inicio de sesión si las credenciales no son válidas en el equipo del servicio.

Se inicia la sesión anónima de NTLM, aunque los inicios de sesión anónimos se deshabilitan de manera predeterminada

Al crear un cliente, la propiedad AllowedImpersonationLevel se establece como Anonymous, tal y como se muestra en el ejemplo siguiente, aunque de forma predeterminada el servidor no permite los inicio de sesión anónimos. Esto sólo se produce cuando el valor predeterminado de la propiedad AllowAnonymousLogons de la clase WindowsServiceCredential sea false.

El código de cliente siguiente intenta habilitar los inicios de sesión anónimos (observe que la propiedad predeterminada es Identification).

El código del servicio siguiente cambia el valor predeterminado para habilitar los inicio de sesión anónimos por el servidor.

Para obtener más información acerca de suplantación, vea Delegación y suplantación con WCF.

Por otra parte, el cliente se está ejecutando como un servicio de Windows, utilizando el SISTEMA de cuentas integrado.

Otros problemas

No se establecen las credenciales del cliente correctamente

La autenticación de Windows utiliza la instancia WindowsClientCredential devuelta por la propiedad ClientCredentials de la clase ClientBase, no UserNamePasswordClientCredential. A continuación se muestra un ejemplo incorrecto.

En el ejemplo siguiente se muestra el ejemplo correcto.

SSPI no está disponible

Los sistemas operativos siguientes no admiten la autenticación de Windows cuando se utilizó como un servidor: Windows XP Home Edition, Windows XP Media Center Edition y Windows Vista Home Editions.

Desarrollo e implementación con distintas identidades

Si desarrolla una aplicación en un equipo y la implementa en otro, y utiliza tipos de cuentas diferentes para autenticarse en cada equipo, el comportamiento puede ser diferente. Supongamos, por ejemplo, que desarrolla una aplicación en un equipo Windows XP Pro con el modo de autenticación SSPI Negotiated. Si utiliza una cuenta de usuario local para autenticarse, se utilizará el protocolo NTLM. Una vez desarrollada la aplicación, implementa el servicio en un equipo Windows Server 2003, donde se ejecuta bajo una cuenta de dominio. En este punto, el cliente no podrá autenticar el servicio, porque estará utilizando Kerberos y un controlador de dominio.

Consulte también

Referencia

WindowsClientCredential
WindowsServiceCredential
WindowsClientCredential
ClientBase

Conceptos

Delegación y suplantación con WCF
Escenarios no admitidos