Autenticación Kerberos para la conexión de cliente MAPI a una matriz de servidores de acceso de cliente

Resumen

Para las implementaciones de Microsoft Exchange Server 2010 que tienen más de un servidor de acceso de cliente en un sitio de Active Directory, la topología requiere con frecuencia una matriz de servidores de acceso de cliente y una solución de equilibrio de carga para distribuir el tráfico entre todos los servidores de acceso de cliente del sitio. Debido a los cambios en Exchange Server 2010, los clientes de correo electrónico MAPI no pueden usar la autenticación Kerberos para conectarse a un buzón cuando se usa una matriz de servidores de acceso de cliente. Para solucionar este comportamiento, Microsoft Exchange Server Service Pack 1 (SP1) incluye una nueva funcionalidad que le permite configurar la autenticación Kerberos para los clientes de correo electrónico MAPI en una matriz de servidores de acceso de cliente.

Para obtener más información sobre cómo funcionaba la autenticación Kerberos en versiones anteriores de Exchange Server y sobre los cambios en Exchange Server 2010 que impiden que la autenticación Kerberos funcione con clientes de correo electrónico MAPI, vea la siguiente entrada de blog en el blog del equipo de Exchange:

Recomendación: Habilitación de la autenticación Kerberos para clientes MAPI

Más información

El servicio Host de servicio de Microsoft Exchange que se ejecuta en el rol de servidor de acceso de cliente (CAS) se extiende en Exchange Server 2010 SP1 para usar una credencial de cuenta de servicio alternativa compartida (ASA) para la autenticación Kerberos. Esta extensión de host de servicio supervisa el equipo local. Cuando se agregan o quitan credenciales, se actualiza el paquete de autenticación Kerberos en el sistema local y el contexto del servicio de red. En cuanto se agrega una credencial al paquete de autenticación, todos los servicios de acceso de cliente pueden usarla para la autenticación Kerberos. El servidor de acceso de cliente también podrá autenticar las solicitudes de servicio dirigidas directamente, además de poder usar la credencial ASA. Esta extensión, conocida como servicelet, se ejecuta de forma predeterminada y no requiere ninguna configuración ni acción para ejecutarse.

Es posible que tenga que usar la autenticación Kerberos para la organización de Exchange Server 2010 por los siguientes motivos:

• La autenticación Kerberos es necesaria para la directiva de seguridad local.

• Está experimentando o esperando problemas de escalabilidad NTLM, como la conectividad MAPI directa al servicio de acceso de cliente RPC que provoca errores NTLM intermitentes.

  En las implementaciones de clientes a gran escala, NTLM puede provocar cuellos de botella en los servidores de acceso de cliente. Esto puede provocar errores de autenticación intermitentes. Los servicios que usan la autenticación NTLM son más sensibles a los problemas de latencia de Active Directory. Esto provoca errores de autenticación cuando aumenta la tasa de solicitudes del servidor de acceso de cliente.

Para configurar la autenticación Kerberos, debe estar familiarizado con Active Directory y cómo configurar matrices de servidores de acceso de cliente. También debe tener conocimientos prácticos de la autenticación Kerberos.

Para implementar la credencial asa para la autenticación Kerberos, siga estos pasos.

Creación de una cuenta que se usará como credencial asa

Todos los equipos de la matriz del servidor de acceso de cliente deben compartir la misma cuenta de servicio. Esto incluye todos los servidores de acceso de cliente que pueden iniciarse como parte de un cambio de centro de datos. Por lo general, una cuenta de servicio por bosque es suficiente.

Cree una cuenta de equipo en lugar de una cuenta de usuario para la cuenta de servicio alternativa (ASA), porque una cuenta de equipo no permite el inicio de sesión interactivo. Por lo tanto, una cuenta de equipo puede tener directivas de seguridad más sencillas que una cuenta de usuario y es la solución preferida para la credencial ASA.

Para obtener más información sobre cómo crear una cuenta de equipo, consulte Creación de una nueva cuenta de equipo.

No hay requisitos particulares para el nombre de la credencial ASA. Puede usar cualquier nombre que siga el esquema de nomenclatura. La credencial ASA no necesita privilegios de seguridad especiales. Si va a implementar una cuenta de equipo para la credencial ASA, esto significa que la cuenta solo necesita ser miembro del grupo de seguridad Equipos de dominio. Si va a implementar una cuenta de usuario para la credencial ASA, esto significa que la cuenta solo necesita ser miembro del grupo de seguridad Usuarios del dominio.

Determinación de los SPN que se van a asociar a la credencial de cuenta de servicio alternativa

Después de crear la cuenta de servicio alternativa, debe determinar los nombres de entidad de servicio (SPN) de Exchange que se asociarán con las credenciales de ASA. Los valores de SPN deben configurarse para que coincidan con el nombre del servicio que se usa en el equilibrador de carga de red en lugar de en servidores individuales. La lista de SPN de Exchange puede variar en función de la configuración, pero la lista debe incluir al menos lo siguiente:

• http Use este SPN para servicios web de Exchange, descargas de libreta de direcciones sin conexión y el servicio de detección automática.
• exchangeMDB Use este SPN para el acceso de cliente RPC.
• exchangeRFR Use este SPN para el servicio de libreta de direcciones.
• exchangeAB Use este SPN para el servicio de libreta de direcciones.

Para una pequeña empresa, probablemente no tendrá nada más grande que un solo sitio de Active Directory. Por ejemplo, el único sitio de Active Directory puede ser similar al diagrama siguiente.

Para determinar los SPN que usaría en este ejemplo, debemos examinar los nombres de dominio completos (FQDN) que usan los clientes internos de Outlook en la ilustración anterior. En este ejemplo, implementaría los siguientes SPN 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

Si el sitio es mayor que un único sitio de Active Directory, puede ver más ejemplos en el tema Configuración de la autenticación Kerberos para Load-Balanced servidores de acceso de cliente .

Convertir el directorio virtual de OAB en una aplicación

El directorio virtual de la libreta de direcciones sin conexión (OAB) no es una aplicación web. Por lo tanto, el servicio Host del servicio Microsoft Exchange no lo controla. Como resultado, la credencial ASA no puede descifrar las solicitudes de autenticación Kerberos en el directorio virtual de OAB.

Para convertir el directorio virtual de OAB en una aplicación web de IIS, ejecute el script ConvertOABVDir.ps1 en cada miembro de CAS. El script también creará un nuevo grupo de aplicaciones denominado MSExchangeOabAppPool para el directorio virtual de OAB. Para descargar el script, vaya a la página ConvertOABDir.ps1 del Centro de scripts de Microsoft.

Implementación de la credencial ASA en los miembros de CAS

Exchange Server 2010 SP1 incluye un script para habilitar la implementación de la credencial ASA. El script se denomina RollAlternateServiceAccountPassword.ps1 y se encuentra en el directorio Scripts.

Para usar el script para insertar la credencial en todos los servidores de acceso de cliente del bosque para la configuración por primera vez, siga estos pasos:

1. En el Shell de administración de Exchange, ejecute el siguiente comando:

   .\RollAlternateserviceAccountPassword.ps1 -ToEntireForest -GenerateNewPasswordFor "Your_Domain_Name\Computer_Account_Name$" -Verbose
   

2. Ejecute el siguiente comando para programar una tarea programada de roll de contraseñas automatizada una vez al mes denominada "Exchange-RollAsa". Esta tarea programada por comandos actualizará la credencial ASA para todos los servidores de acceso de cliente en el bosque con una nueva contraseña generada por script. Se crea la tarea programada, pero no se ejecuta la secuencia de comandos. Cuando se ejecuta la tarea programada, la secuencia de comandos se ejecuta en modo desatendido.

   .\RollAlternateServiceAccountPassword.ps1 -CreateScheduledTask "Exchange-RollAsa" -ToEntireForest -GenerateNewPasswordFor "Your_Domain_Name\Computer_Account_Name$"
   

Para obtener más información sobre cómo usar el script RollAlternateserviceAccountPassword.ps1, vea Using the RollAlternateserviceAccountPassword.ps1 Script in the Shell .

Comprobar la implementación de la credencial ASA

En el Shell de administración de Exchange, ejecute el siguiente comando para comprobar la configuración en los servidores de acceso de cliente: Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*

El resultado de este comando será similar al siguiente:

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>

Asociación de SPN con la credencial ASA

Antes de configurar los SPN, asegúrese de que los SPN de destino aún no estén configurados en una cuenta diferente del bosque. La credencial ASA debe ser la única cuenta en el bosque con el que se asocian estos SPN. Para comprobar que ninguna otra cuenta del bosque tiene asociados los SPN, abra un símbolo del sistema y ejecute el comando setspn con los parámetros –q y –f . En el ejemplo siguiente se muestra cómo ejecutar este comando. El comando no debe devolver nada. Si devuelve un valor, otra cuenta ya está asociada al SPN que desea usar.

Setspn -q -f exchangeMDB/outlook.**domain.domain.domain_root**

En este comando, exchangeMDB/outlook.domain.domain.domain_root es el SPN del SPN para el acceso de cliente RPC, como exchangeMDB/outlook.corp.contoso.com.

El siguiente comando muestra cómo establecer los SPN en la credencial ASA compartida. Debe ejecutar el comando setspn con esta sintaxis una vez por cada SPN de destino que identifique.

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

Después de establecer los SPN, compruebe que se agregaron mediante la ejecución del siguiente comando.

Setspn -L contoso\newSharedServiceAccountName

Después de configurar correctamente Kerberos e implementar el script de RollAlternateServiceAccountPasswordl.ps1, compruebe que los equipos cliente pueden autenticarse correctamente.

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

Asegúrese de que ha instalado Exchange Server paquete acumulativo 3 de 2010 SP1 o una versión posterior en todos los servidores de acceso de cliente del entorno. El servicio Host del servicio Microsoft Exchange en los servidores de acceso de cliente es responsable de administrar la credencial ASA. Si este servicio no se está ejecutando, la autenticación Kerberos no funcionará. De forma predeterminada, el servicio está configurado para iniciarse automáticamente cuando se inicia el equipo. Para comprobar que el servicio se está ejecutando, siga estos pasos:

1. Abra Servicios en el CAS. Para abrir Servicios, haga clic en Inicio, Panel de control, haga doble clic en Herramientas administrativas y, a continuación, haga doble clic en Servicios.
2. En la lista de servicios, busque Servicio host de servicio de Microsoft Exchange.
3. En la columna Estado , compruebe que el estado es Iniciado. Si el servicio no se ha iniciado, haga clic con el botón derecho en Servicio host de Microsoft Exchange y, a continuación, haga clic en Iniciar. Para configurar el servicio para que se inicie automáticamente, haga clic con el botón derecho en Servicio host de Microsoft Exchange, haga clic en Propiedades, en Automáticoen la lista Tipo de inicio y, a continuación, haga clic en Aceptar.
   Validación de la autenticación desde Outlook

Para confirmar que Outlook puede usar la autenticación Kerberos para conectarse a los servidores de acceso de cliente, siga estos pasos:

1. Confirme que Outlook está configurado para que apunte a la matriz correcta del servidor de acceso de cliente con equilibrio de carga.
2. Configure las opciones de seguridad del servidor de la cuenta de correo electrónico para usar la seguridad de red de inicio de sesión Negotiate Authentication. NotaPuede configurar el cliente para que use la autenticación con contraseña kerberos, pero si los SPN se quitan alguna vez, los equipos cliente no podrán autenticarse hasta que cambie el mecanismo de autenticación a Negociar autenticación.
3. Asegúrese de que Outlook Anywhere no está habilitado para el equipo cliente. Si Outlook no puede autenticarse mediante la autenticación con contraseña kerberos, intentará volver a Outlook en cualquier lugar, por lo que Outlook anywhere debe deshabilitarse para esta prueba.
4. Reinicie Outlook.
5. Si el equipo de escritorio ejecuta Windows 7, puede ejecutar klist.exe para ver qué vales kerberos se conceden y se usan. Si no ejecuta Windows 7, puede obtener klist.exe del Kit de recursos de Windows Server 2003.

Recursos adicionales

Para obtener información detallada sobre este problema y su trabajo, consulte el siguiente artículo de TechNet:

Use Kerberos con una matriz de servidores de Acceso de cliente o una solución de equilibrio de carga

Para obtener más información sobre cómo usar la autenticación Kerberos en servidores de acceso de cliente con equilibrio de carga, consulte el siguiente artículo de TechNet:

Configuración de la autenticación Kerberos para Load-Balanced servidores de acceso de cliente