Configurar la autenticación de Kerberos para servidores de acceso de cliente con equilibrio de carga

 

Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Última modificación del tema: 2016-11-28

Para usar la autenticación Kerberos con una matriz de carga equilibrada de servidores Acceso de cliente, se deben completar varios pasos de configuración. Para obtener más información sobre cómo usar Kerberos con una matriz de servidores de acceso de clientes o soluciones de equilibrio de carga, consulte Uso de Kerberos con una matriz de servidor de acceso de cliente o una solución de equilibrio de carga.

Cree la credencial de cuenta de servicio alternativa en Active Directory

Todos los equipos de la matriz de servidor de acceso de cliente deben compartir la misma cuenta de servicio. Además, todos los servidores de acceso de cliente que pueden ser solicitados en un escenario de activación de centro de datos también deben compartir la misma cuenta de servicio. En general, es suficiente tener una única cuenta de servicio por bosque. Esta cuenta se denomina credencial de cuenta de servicio alternativa (credencial ASA).

Nota

Si su implementación es compleja y se extiende más allá de los escenarios descritos a continuación, si tiene problemas de delegación de administrador o si tiene segmentos de varios bosques en programaciones de implementación de Exchange diferentes, es posible que deba crear cuentas adicionales. El script RollAlternateServiceAccountPasswordl.ps1 debe ejecutarse por separado para cada cuenta creada.

Tipo de credencial

Puede crear una cuenta de equipo o una cuenta de usuario para la cuenta de servicio alternativa. Debido a que una cuenta de equipo no permite el inicio de sesión interactivo, es posible que cuente con directivas de seguridad más sencillas que una cuenta de usuario y, por lo tanto, sea una mejor opción para una credencial ASA. Si crea una cuenta de equipo, al contraseña no expira realmente, pero se recomienda actualizar la contraseña de manera periódica. La directiva de grupo local puede especificar una edad de cuenta máxima para las cuentas del equipo y puede haber secuencias programadas para eliminar periódicamente las cuentas del equipo que no cumplen con las directivas actuales. Actualizar periódicamente la contraseña para las cuentas del equipo asegurará que sus cuentas del equipo no se eliminen por no cumplir con la directiva local. Su directiva de seguridad local determinará cuándo se debe cambiar la contraseña.

Nombre de credencial

No hay ningún requisito concreto para el nombre de la credencial ASA. Puede usar cualquier nombre que cumpla con su esquema de nombre.

Grupos y roles

La credencial ASA no necesita privilegios de seguridad especiales. Si va a implementar una cuenta de equipo para la credencial ASA, esto significa que solo es necesario que la cuenta sea miembro del grupo de seguridad Equipos del dominio. Si va a implementar una cuenta de usuario para la credencial ASA, esto significa que solo es necesario que la cuenta sea miembro del grupo de seguridad Usuarios del dominio.

Contraseña

La contraseña que usted proporciona al crear la cuenta no se usará nunca. En su lugar, el script restablecerá la contraseña. Por lo tanto, al crear la cuenta, puede usar cualquier contraseña que cumpla con los requisitos de contraseña de su organización.

Escenarios entre bosques

Si cuenta con una implementación entre bosques o de recurso de bosque y los usuarios se encuentran fuera del bosque de Active Directory que contiene Exchange, debe configurar confianzas entre bosques y sufijos de nombres de enrutamiento en los bosques. Para obtener más información, consulte Obtener acceso a recursos en bosques (en inglés) y Sufijos de nombres de enrutamiento en bosques (en inglés).

Identificación de los nombres de entidad de seguridad de servicio que se deben asociar con la credencial de cuenta de servicio alternativa

Una vez creada la cuenta de servicio alternativa, tiene que determinar los nombres de entidad de seguridad de servicio de Exchange (SPN) que se asociarán con las credenciales ASA. La lista de SPN de Exchange puede variar en función de la configuración, pero al menos debería incluir lo siguiente:

  • http Use este SPN para servicios Web Exchange, descargas de la libreta de direcciones sin conexión y el servicio Detección automática.

  • exchangeMDB Use este SPN para el acceso de cliente de RPC.

  • exchangeRFR Use este SPN para el Servicio de libreta de direcciones.

  • exchangeAB Use este SPN para el Servicio de libreta de direcciones.

Los valores de SPN se deben configurar para que coincidan con el nombre de servicio usado en el equilibrador de carga de red en lugar de en servidores individuales.

Para ayudarle a pensar los valores de SPN que debe implementar, tenga en cuenta los escenarios conceptuales siguientes:

  1. Un solo sitio de Active Directory

  2. Varios sitios de Active Directory

  3. Varios sitios de Active Directory con resistencia de sitios de DAG

En cada uno de estos escenarios, se da por supuesto que se han implementado nombres de dominio completos con equilibrio de carga para las direcciones URL internas, las direcciones URL externas y el URI interno de la Detección automática usado por los miembros del servidor de acceso de cliente. Para obtener más información, vea Descripción del uso de proxy y redirección.

Un solo sitio de Active Directory

Si solo dispone de un sitio de Active Directory, su entorno puede ser parecido al de la ilustración a continuación.

Según los nombres de dominio completos usados por los clientes de Outlook internos en la ilustración anterior, no es necesario implementar los SPN siguientes en la credencial ASA:

  • http/mail.corp.contoso.com

  • http/autod.corp.contoso.com

  • exchangeMDB/outlook.corp.contoso.com

  • exchangeRFR/outlook.corp.contoso.com

  • exchangeAB/outlook.corp.contoso.com

Los clientes externos o basados en Internet que usan Outlook Anywhere no usarán la autenticación Kerberos. Por lo tanto, no es necesario agregar como SPN a la credencial ASA los nombres de dominio completos que usen dichos clientes.

Importante

Si implementa una estructura de DNS dividida, los clientes externos e internos usarán los mismos nombres de dominio completo y dichos nombres deben representarse como SPN en la credencial ASA.

Varios sitios de Active Directory

Si dispone de varios sitios de Active Directory, su entorno puede ser parecido al de la ilustración a continuación.

Según los nombres de dominio completos usados por los clientes de Outlook internos de la ilustración anterior, los SPN siguientes deberían implementare en la credencial ASA usada para la matriz de servidores de acceso de cliente en el sitio de Active Directory ADSite1:

  • http/mail.corp.contoso.com

  • http/autod.corp.contoso.com

  • exchangeMDB/outlook.corp.contoso.com

  • exchangeRFR/outlook.corp.contoso.com

  • exchangeAB/outlook.corp.contoso.com

Según los nombres de dominio completos usados por los clientes de Outlook internos de la ilustración anterior, los SPN siguientes deberían implementarse en la credencial ASA usada para la matriz de servidores de acceso de cliente en el sitio de Active Directory ADSite2:

  • http/mailsdc.corp.contoso.com

  • http/autodsdc.corp.contoso.com

  • exchangeMDB/outlooksdc.corp.contoso.com

  • exchangeRFR/outlooksdc.corp.contoso.com

  • exchangeAB/outlooksdc.corp.contoso.com

Nota

En este ejemplo se muestra que puede usar varias credenciales ASA para este escenario concreto. No obstante, puede usar una única credencial ASA para todos los sitios de Active Directory que hospeden matrices de servidores de acceso de cliente donde desee implementar la autenticación Kerberos.

Varios sitios de Active Directory con resistencia de sitios de DAG

Si dispone de varios sitios de Active Directory con resistencia de sitios de DAG, su entorno puede ser parecido al de la ilustración a continuación.

Dado que esta arquitectura incluye un grupo de disponibilidad de base de datos (DAG) que se extiende por ambos sitios de Active Directory, solo es necesario implementar una credencial ASA para su uso por parte de los miembros de las matrices de servidores de acceso de cliente de ADSite1 y ADSite2. Si no usa una única credencial ASA, los clientes tendrán problemas con la autenticación Kerberos cuando usted realice un cambio de centro de datos, puesto que los miembros de la matriz de servidores de acceso de cliente del centro de datos secundario no podrán descifrar el vale de la sesión de Kerberos. Para obtener más información acerca de las activación del centros de datos secundario, consulte Cambios en el centro de datos.

Según los nombres de dominio completos usados por los clientes de Outlook internos de la ilustración anterior, los SPN siguientes deberían implementarse en la credencial ASA usada para la matriz de servidores de acceso de cliente en ADSite1 y ADSite2:

  • http/mail.corp.contoso.com

  • http/autod.corp.contoso.com

  • exchangeMDB/outlook.corp.contoso.com

  • exchangeRFR/outlook.corp.contoso.com

  • exchangeAB/outlook.corp.contoso.com

  • http/mailsdc.corp.contoso.com

  • http/autodsdc.corp.contoso.com

  • exchangeMDB/outlooksdc.corp.contoso.com

  • exchangeRFR/outlooksdc.corp.contoso.com

  • exchangeAB/outlooksdc.corp.contoso.com

Convertir el directorio virtual de la libreta de direcciones sin conexión en una aplicación

El directorio virtual de la libreta de direcciones sin conexión no es una aplicación web, por lo que no está controlado por el host de servicios de Microsoft Exchange. Por lo tanto, las solicitudes de autenticación Kerberos del directorio virtual de la libreta de direcciones sin conexión no puede ser descifrado por una credencial ASA.

Para convertir un directorio virtual de la libreta de direcciones sin conexión en una aplicación web, ejecute el script ConvertOABDir.ps1 en cada miembro del servidor de acceso de cliente. El script también creará un nuevo grupo de aplicaciones para el directorio virtual de la libreta de direcciones sin conexión. El script se ubica en el directorio de scripts de Exchange 2010 SP2 o puede descargar el script aquí.

Implementación de la credencial de cuenta de servicio alternativa

Una vez creada la credencial ASA, compruebe que la cuenta se haya replicado en todos los controladores de dominio en todos los sitios de Active Directory que contengan servidores de acceso de cliente que usarán la credencial ASA.

A continuación, puede ejecutar el script de la credencial AlternateServiceAccount en el Shell de administración de Exchange. Para obtener más información, consulte Uso del script RollAlternateserviceAccountCredential.ps1 en el Shell. Una vez ejecutado el script, recomendamos que compruebe que todos los servidores de destino se hayan actualizado correctamente.

Nota

La secuencia se proporciona en inglés solamente.

Para ayudar a resolver los errores de la secuencia, consulte Solución de problemas del script RollAlternateServiceAccountCredential.ps1.

En el resultado del ejemplo siguiente del script RollAlternateServiceAccountPassword.ps1 se usa una cuenta de equipo que se ha creado como credencial ASA. El nombre de la cuenta es contoso/newSharedServiceAccountName. En el ejemplo siguiente, el script aplica la configuración de la credencial a cada uno de los miembros de una matriz de servidores de acceso de cliente denominada outlook.corp.contoso.com.

Para ejecutar el script, use el comando siguiente.

RollAlternateServiceAccountPassword.ps1 -ToArrayMembers outlook.corp.contoso.com -GenerateNewPasswordFor contoso\newSharedServiceAccountName$

Después de ejecutar el script, recibirá el resultado siguiente. Se le solicitará que apruebe el cambio de contraseña.

========== Started at 08/02/2010 15:48:09 ==========Destination servers that will be updated:Name----CASACASBCredentials that will be pushed to every server in the specified scope (recent first):UserName                               Password--------                               --------contoso\newSharedServiceAccountName$                System.Security.SecureStringPrior to pushing new credentials, all existing credentials that are invalid or no longer work will be removed from the destination servers.Pushing credentials to server CASAPushing credentials to server CASBSetting a new password on Alternate Service Account in Active DirectoryPassword changeDo you want to change password for contoso\newSharedServiceAccountName$ in Active Directory at this time?[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): yPreparing to update Active Directory with a new password for contoso\newSharedServiceAccountName$ ...Resetting a password in the Active Directory for contoso\newSharedServiceAccountName$ ...New password was successfully set to Active Directory.Retrieving the current Alternate Service Account configuration from servers in scopeAlternate Service Account properties:StructuralObjectClass QualifiedUserName       Last Pwd Update     --------------------- -----------------       ---------------     computer              contoso\newSharedServiceAccountName$ 8/2/2010 3:49:05 PM SPNs-----Per-server Alternate Service Account configuration as of the time of script completion:   Array: outlook.corp.contoso.comIdentity  AlternateServiceAccountConfiguration--------  ------------------------------------NAE14CAS  Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>NAE14CAS2 Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>

También podrá ver dos identificadores de evento en los registros de eventos. Uno de los eventos marca el inicio del script y el otro la finalización correcta de este. Esta es una cita de la finalización correcta del evento.

Log Name:      ApplicationSource:        MSExchange Management ApplicationEvent ID:      14002Task Category: KerberosLevel:         InformationDescription:Maintenance of the Alternate Service Accounts succeeded.

Comprobación de la implementación de la credencial ASA

En el Shell de administración de Exchange, ejecute el comando siguiente para comprobar la configuración de los servidores de acceso de cliente.

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*

El resultado de este comando debe ser parecido a este:

Name                                 : CASAAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$                                       Previous: <Not set>Name                                 : CASBAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$                                       Previous: <Not set>

Si ha ejecutado el script varias veces y ha realizado cambios, la entrada Previous indicará cuando se realizó el último cambio.

Name                                 : NAE14CASAlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$Name                                 : NAE14CAS2AlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$

Asociación de los nombres de entidad de seguridad de servicio con la credencial de la cuenta de servicio alternativa

Antes de configurar los SPN, compruebe que los SPN de destino no estén configurados en una cuenta diferente en el bosque. La credencial ASA debe ser la única cuenta en el bosque que tenga estos SPN asociados. Puede comprobar que ninguna otra cuenta en el bosque tenga asociados los SPN mediante la ejecución del comando setspn con el parámetro –q y –f desde la línea de comandos. En el ejemplo siguiente se muestra cómo ejecutar este comando. El comando no debe devolver nada. Si devuelve un valor, significa que otra cuenta ya está asociada con el SPN que quiere usar.

Nota

Solamente Windows Server 2008 es compatible con el parámetro de todo el bosque (-f) para la comprobación de duplicados en el comando setspn.

Setspn -q -f exchangeMDB/outlook.corp.contoso.com

El comando siguiente proporciona un ejemplo sobre cómo definir los SPN en la credencial ASA compartida. El comando setspn con esta sintaxis debe ejecutarse una vez para cada SPN de destino que identifique.

Setspn -S exchangeMDB/outlook.corp.contoso.com contoso\newSharedServiceAccountName$

Cuando haya establecido los SPN, compruebe que se hayan agregado mediante el uso del siguiente comando.

Setspn -L contoso\newSharedServiceAccountName$

Validación de la autenticación Kerberos del cliente de Exchange

Después de haber configurado Kerberos e implementado el script RollAlternateServiceAccountPasswordl.ps1 correctamente, compruebe que los clientes se puedan autenticar de manera correcta.

Comprobar si se está ejecutando el servicio de Microsoft Exchange Service Host

El servicio de Microsoft Exchange Service Host en los servidores de acceso de cliente es responsable de la administración de la credencial ASA. Si dicho servicio no está en ejecución, no será posible llevar a cabo la autenticación Kerberos. De forma predeterminada, el servicio está configurado para iniciarse de forma automática al iniciar el equipo. Compruebe si ha instalado el Exchange Server 2010paquete acumulativo 3 de SP1 o una versión posterior en todos los servidores de acceso de cliente de su entorno.

Validación de la autenticación desde Outlook

Para garantizar que Outlook pueda conectarse a los servidores de acceso de cliente con la autenticación Kerberos, siga estos pasos:

  1. Confirme que Outlook esté configurado para apuntar a la matriz del servidor de acceso de cliente con la carga equilibrada correcta.

  2. Defina la configuración de seguridad del servidor de cuenta de correo electrónico para usar Autenticación Negotiate para la seguridad de inicio de sesión en red. O bien, puede configurar el cliente para usar Autenticación de contraseña Kerberos. No obstante, si se quitaran los SPN, los clientes no podrían autenticarse mientras usted no volviera a definir el mecanismo de autenticación en Autenticación Negotiate.

  3. Confirme que Outlook Anywhere no está habilitado para el cliente. Si Outlook no se puede autenticar mediante el uso de Kerberos, tratará de volver a Outlook Anywhere; por lo tanto, debe deshabilitar Outlook Anywhere para esta prueba.

  4. Reinicie Outlook.

  5. Si su equipo de escritorio usa Windows 7, puede ejecutar klist.exe para ver qué vales de Kerberos se han concedido y están en uso. Si no usa Windows 7, puede obtener klist.exe en el kit de recursos de Windows Server 2003.

Validación mediante el uso del cmdlet Test-OutlookConnectivity

Para comprobar si Kerberos funciona, use el cmdlet Test-OutlookConnectivity. Esta es la mejor manera de ver si se puede establecer la conectividad TCP. De forma predeterminada, el cmdlet usará la autenticación Negotiate para una conexión TCP. Por lo tanto, Kerberos se usará en caso de haber sido configurado. El archivo klist.exe se puede usar para ver los vales de Kerberos en el equipo. Esto se puede ejecutar desde el servidor de acceso de cliente y desde una herramienta de supervisión automática como SCOM. Si usa el cmdlet Test-OutlookConnectivity, compruebe que la base de datos del buzón tenga la propiedad RPCClientAccessServer establecida en el nombre de la matriz de servidores de acceso de cliente. De lo contrario, el cmdlet no probará la funcionalidad de credencial ASA compartida.

Test-OutlookConnectivity -Identity administrator -MailboxCredential $c -Protocol tcp

Para garantizar que la conexión se produzca mediante el uso de Kerberos, vea klist.exe para comprobar si hay vales de Kerberos asociados con los SPN recién agregados.

Validación de Kerberos desde el servidor Acceso de cliente

Para confirmar que Kerberos esté funcionando correctamente desde el servidor Acceso de cliente, puede examinar los registros de protocolo para comprobar satisfactoriamente las conexiones Kerberos. Puede usar estos registros, además de las otras validaciones, para confirmar que se está usando Kerberos.

  • En el servidor Acceso de cliente, examine los registros de protocolo de la Libreta de direcciones. Generalmente, estos registros se encuentran en la ruta de acceso siguiente: C:\Program Files\Microsoft\Exchange server\v14\Logging\AddressBook Service.

  • Examine el último archivo de registro y busque la palabra Kerberos después de que se haya ejecutado el script. Si observa tráfico de Kerberos, una conexión se ha producido correctamente. La línea del archivo de registro debe ser similar a lo siguiente.

    2010-06-11T22:58:49.799Z,9,0,/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Administrator,,2001:4898:f0:3031:99f:ce35:750a:8b09,EXCH-A-363,ncacn_ip_tcp,Bind,,6,,,Kerberos,
    

Si ve la palabra Kerberos, entonces el servidor está creando correctamente las conexiones autenticadas de Kerberos. Para obtener más información acerca del registro de servicio Libretas de direcciones, consulte Descripción del servicio de libreta de direcciones.

Solución de problemas de errores de autenticación

Existen diversos problemas comunes que pueden ocurrir al configurar la autenticación Kerberos.

Los clientes de Outlook configurados para usar solo la autenticación Kerberos no se pueden conectar

Si su cliente de Outlook que está configurado para usar solamente la autenticación Kerberos no se puede conectar, siga estos pasos para solucionar el problema:

  1. Configure Outlook para usar solo la autenticación NTLM y, a continuación, compruebe la conectividad. Si no se puede llevar a cabo la conexión, compruebe que la matriz de servidores de Acceso de cliente se encuentre disponible o que la conectividad de red se encuentre estable.

    Si la conectividad NTLM es satisfactoria, pero Kerberos no, compruebe que los SPN no estén registrados en otra cuenta además de la cuenta de servicio alternativa. Asegúrese de que los SPN de Exchange estén registrados en la cuenta usada por la cuenta de servicio alternativa de uso compartido mediante el uso del comando de consulta setSPN tal como se describió anteriormente en este tema.

  2. Asegúrese de que la contraseña esté coordinada entre todos los servidores Acceso de cliente y Active Directory. Para realizar esto, ejecute el script en modo asistido y haga que este genere una contraseña nueva.

  3. Compruebe que el servicio de Libreta de direcciones de Microsoft Exchange se esté ejecutando en los servidores de acceso de cliente.

  4. Si la autenticación todavía no es satisfactoria, compruebe que los directorios virtuales para los servicios a los que desea obtener acceso con Kerberos tengan habilitada la autenticación integrada de Windows. Puede usar los cmdlets Get-VirtualDirectory para comprobar los métodos de autenticación. Para obtener más información acerca de los directorios virtuales, consulte Descripción de los directorios virtuales de Outlook Web App y Descripción de los directorios virtuales de servicios web de Exchange.

Errores del servicio Detección automática

Si observa el siguiente error del servicio Detección automática, es posible que sea porque el encabezado de solicitud del servicio Detección automática contiene un vale de autenticación Kerberos grande que provocó que el tamaño del encabezado supere el límite configurado por el servidor Servicios de Internet Information Server (IIS). El error será similar al siguiente.

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 09 Mar 2010 18:06:18 GMT
Connection: close
Content-Length: 346

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""https://www.w3.org/TR/html4/strict.dtd">

<HTML><HEAD><TITLE>Bad Request</TITLE>

<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>

<BODY><h2>Bad Request - Request Too Long</h2>

<hr><p>HTTP Error 400. The size of the request headers is too long.</p>

</BODY></HTML>

Para corregir este error, aumente el límite del tamaño del encabezado de IIS. Para obtener más información, consulte Documentación de IIS.

Mantenimiento en curso de la credencial ASA

Si su contraseña local en la credencial ASA de uso compartido debe actualizarse periódicamente, consulte Uso del script RollAlternateserviceAccountCredential.ps1 en el Shell para obtener instrucciones para configurar una tarea programada para realizar el mantenimiento regular de contraseñas. Asegúrese de supervisar las tareas programadas para garantizar la sustitución oportuna de contraseñas y evitar los posibles cortes de autenticación.

Cómo apagar la autenticación Kerberos

Para invertir su matriz de servidores de acceso de cliente para que no use Kerberos, quite los SPN de la cuenta de servicio compartido. Si se quitan los SPN, la autenticación Kerberos no será intentada por sus clientes, y los clientes configurados para la autenticación Negociar usarán NTLM. Los clientes configurados para usar solamente Kerberos no podrán conectarse. Cuando se eliminan los SPN también debe quitar la cuenta de servicio compartido. Puede usar la secuencia de mantenimiento para borrar las credenciales de todos los miembros de la matriz de servidores de acceso de cliente usando el parámetro toEntireForest y usando la copia desde el parámetro del servidor para especificar un servidor que no tiene credenciales de Kerberos. Además, por último tendrá que reiniciar todos los equipos cliente para borrar los vales de Kerberos de la memoria caché.

 © 2010 Microsoft Corporation. Reservados todos los derechos.