Configuración de la autenticación Kerberos: Configuración principal (SharePoint Server 2010)

 

Se aplica a: SharePoint Server 2010

Última modificación del tema: 2017-01-18

En el primer escenario se configurarán dos aplicaciones web de SharePoint Server 2010 para usar el protocolo Kerberos para autenticar las solicitudes de cliente entrantes. Con fines de demostración, se configurará una aplicación web para usar puertos estándar (80/443) y la otra usará un valor de puerto no predeterminado (5555). Este escenario será la base de todos los escenarios siguientes, en los que se asume que se han completado todas las actividades que se describen a continuación.

Importante

Se requiere configurar las aplicaciones web con autenticación de Windows clásica mediante la autenticación Kerberos para asegurarse de que los escenarios funcionen correctamente. La autenticación de notificaciones de Windows puede usarse en algunos escenarios, pero podría no producir los resultados detallados en los escenarios siguientes.

Nota

Si va a realizar una instalación en Windows Server 2008, es posible que tenga que instalar la siguiente revisión para la autenticación Kerberos:
Se produce un error en la autenticación Kerberos junto con el código de error 0X80090302 o 0x8009030f en un equipo que ejecuta Windows Server 2008 o Windows Vista cuando se utiliza el algoritmo AES (https://support.microsoft.com/kb/969083/es-es)

En este escenario, realice las siguientes tareas:

• Configurar dos aplicaciones web con zonas predeterminadas que usan el protocolo Kerberos para la autenticación

• Crear dos colecciones de sitios de prueba, una en cada aplicación web

• Comprobar la configuración de IIS de la aplicación web

• Comprobar que los clientes puedan autenticarse con la aplicación web y garantizar que se use el protocolo Kerberos para la autenticación

• Configurar el elemento web Visor de RSS para mostrar fuentes RSS en una aplicación web local y remota

• Rastrear cada aplicación web y probar la búsqueda de contenido en cada colección de sitios de prueba

Lista de comprobación de configuración

Área de configuración	Descripción
DNS	Registrar un registro A de DNS para la dirección IP virtual (VIP) de equilibrio de carga de red (NLB) de las aplicaciones web
Active Directory	Crear cuentas de servicio para el grupo de aplicaciones de IIS de las aplicaciones web Registrar nombres de entidad de seguridad de servicio (SPN) para las aplicaciones web en la cuenta de servicio creada para el grupo de aplicaciones de IIS de la aplicación web Configurar la delegación limitada de Kerberos para las cuentas de servicio
Aplicación web de SharePoint	Crear cuentas administradas de SharePoint Server Crear la aplicación de servicio de búsqueda de SharePoint Crear las aplicaciones web de SharePoint
IIS	Validar que la autenticación Kerberos esté habilitada Comprobar que la autenticación de modo kernel esté deshabilitada Instalar certificados para SSL
Cliente de Windows 7	Asegurarse de que las direcciones URL de las aplicaciones web están en la zona de intranet o en una zona configurada para autenticarse automáticamente con la autenticación integrada de Windows
Configuración del firewall	Abrir los puertos del firewall para permitir el tráfico HTTP de entrada en puertos predeterminados y no predeterminados Asegurarse de que los clientes puedan conectarse a los puertos de Kerberos en Active Directory
Probar la autenticación del explorador	Comprobar que la autenticación funcione correctamente en el explorador Comprobar la información de inicio de sesión en el registro de eventos de seguridad del servidor web Usar herramientas de terceros para confirmar que la autenticación Kerberos esté configurada correctamente
Probar la consulta y el índice de búsqueda de SharePoint Server	Comprobar el acceso al explorador desde los servidores de indexación Cargar el contenido de ejemplo y realizar un rastreo Probar la búsqueda
Probar la delegación de WFE	Configurar orígenes de fuentes RSS en cada colección de sitios Agregar elementos web Visor de RSS a la página principal de cada colección de sitios

Instrucciones de configuración paso a paso

Configurar el DNS

Configure DNS para las aplicaciones web del entorno. En este ejemplo tenemos dos aplicaciones web, http://portal y http://teams:5555, que se resuelven en la misma dirección VIP de NBL (192.168.24.140/24)

Para obtener información general sobre cómo configurar DNS, vea el tema sobre la administración de registros DNS.

Aplicaciones web de SharePoint Server

http://portal: configure un nuevo registro A de DNS para la aplicación web portal. En este ejemplo tenemos un host "portal" configurado para resolver la dirección VIP de carga equilibrada.

http://teams:5555: configure un nuevo registro A de DNS para la aplicación web del grupo

Nota

Es importante asegurarse de que las entradas DNS sean registros A y no alias CNAME para que la autenticación Kerberos funcione correctamente en entornos con más de una aplicación web en ejecución con encabezados host y cuentas de servicio dedicadas independientes. Vea Problemas conocidos de la configuración de Kerberos (SharePoint Server 2010) para obtener una explicación sobre el problema conocido al usar CNAME con aplicaciones web habilitadas para Kerberos.

Configuración de Active Directory

A continuación, debe configurar las cuentas de Active Directory para las aplicaciones web del entorno. Como procedimiento recomendado, debe configurar cada aplicación web para que se ejecute en su propio grupo de aplicaciones de IIS con su propio contexto de seguridad (identidad del grupo de aplicaciones).

Cuentas de servicio de aplicación de servicio de SharePoint

En este ejemplo, tenemos dos aplicaciones web de SharePoint Server que se ejecutan en dos grupos de aplicaciones de IIS independientes en ejecución con sus propias identidades del grupo de aplicaciones.

Aplicación web (zona predeterminada)	Identidad del grupo de aplicaciones de IIS
http://portal	vmlab\svcPortal10App
http://teams:5555	vmlab\ svcTeams10App

Nombres de entidad de seguridad de servicio (SPN)

Para cada cuenta de servicio, configure un conjunto de nombres de entidad de seguridad de servicio que se asignen a los nombres de host DNS asignados a cada aplicación web.

Use SetSPN, una herramienta de línea de comandos en Windows Server 2008, para configurar un nuevo nombre de entidad de seguridad de servicio. Para obtener una explicación completa sobre cómo usar SetSPN, vea el tema sobre Setspn. Para obtener información sobre las mejoras de SetSPN en Windows Server 2008, vea el tema del blog Care, Share and Grow! sobre las nuevas características de SETSPN.EXE en Windows Server 2008.

Todas las aplicaciones web de SharePoint Server, independientemente del número de puerto, usan el siguiente formato de SPN:

• HTTP/<nombreDeHostDNS>

• HTTP/<FQDNdeDNS>

Ejemplo:

• HTTP/portal

• HTTP/portal.vmlab.local

Para las aplicaciones web que se ejecutan en los puertos no predeterminados (puertos que no sean 80/443), registre SPN adicionales con número de puerto:

• HTTP/<nombreDeHostDNS>:<puerto>

• HTTP/<FQDNdeDNS>:<puerto>

Ejemplo:

• HTTP/teams:5555

• HTTP/teams.vmlab.local:5555

Nota

Vea el apéndice para obtener una explicación sobre por qué se recomienda configurar SPN con y sin número de puerto para servicios HTTP que se ejecutan en los puertos no predeterminados (80, 443). Técnicamente, la manera correcta para hacer referencia a un servicio HTTP que se ejecuta en un puerto no predeterminado consiste en incluir el número de puerto en el SPN; sin embargo, debido a problemas conocidos que se describen en el apéndice, también se necesita configurar SPN sin puerto. Tenga en cuenta que los SPN sin puerto para la aplicación web teams no implican que se tenga acceso a los servicios mediante los puertos predeterminados (80, 443) en este ejemplo.

En este ejemplo, se configuran los siguientes nombres de entidad de seguridad de servicio para las dos cuentas que se crearon en el paso anterior:

Host DNS	Identidad del grupo de aplicaciones de IIS	Nombres de entidad de seguridad de servicio
Portal.vmlab.local	vmlab\svcPortal10App	HTTP/portal HTTP/portal.vmlab.local
Teams.vmlab.local	vmlab\ svcTeams10App	HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555

Se han ejecutado los siguientes comandos para crear los nombres de entidad de seguridad de servicio:

SetSPN -S HTTP/Portal vmlab\svcportal10App

SetSPN -S HTTP/Portal.vmlab.local vmlab\svcportal10App

SetSPN -S HTTP/Teams vmlab\svcTeams10App

SetSPN -S HTTP/Teams.vmlab.local vmlab\ svcTeams10App

SetSPN -S HTTP/Teams:5555 vmlab\ svcTeams10App

SetSPN -S HTTP/Teams.vmlab.local:5555 vmlab\ svcTeams10App

Importante

No configure nombres de entidad de seguridad de servicio con HTTPS, aún si la aplicación web usa SSL.

En este ejemplo, se usó un nuevo modificador de la línea de comandos, -S, incluido en Windows Server 2008, que comprueba la existencia del SPN antes de crearlo en la cuenta. Si ya existe el SPN, no se crea el nuevo y se muestra un mensaje de error.

Si se encuentran SPN duplicados, tendrá que resolver el problema mediante un nombre de DNS distinto para la aplicación web (con lo cual se cambia el SPN) o quitando el SPN existente de la cuenta en que se detectó.

Importante

Antes de eliminar un SPN existente, asegúrese de que ya no sea necesario; de lo contrario, se podría romper la autenticación Kerberos para otra aplicación del entorno.

Nombres de entidad de seguridad de servicio y SSL

Es común que se confundan los nombres de entidad de seguridad de servicio de Kerberos con las direcciones URL para aplicaciones web HTTP porque los formatos de SPN y URI tienen sintaxis muy similares, pero es importante comprender que son dos cosas muy distintas e independientes. Los nombres de entidad de seguridad de servicio de Kerberos se usan para identificar un servicio; cuando ese servicio es una aplicación HTTP, el esquema de servicio es "HTTP", independientemente de si el servicio es acceso con SSL o no. Esto significa que incluso si accede a la aplicación web mediante "https://someapp", no se debe configurar un nombre de entidad de seguridad de servicio con HTTPS, por ejemplo "HTTPS/someapp".

Configurar la delegación limitada de Kerberos para los equipos y las cuentas de servicio

En función del escenario, es posible que parte de la funcionalidad de SharePoint Server 2010 requiera delegación restringida para funcionar correctamente. Por ejemplo, si el elemento web Visor de RSS está configurado para mostrar una fuente RSS de un origen autenticado, requerirá la delegación para consumir la fuente de origen. En otras situaciones, es posible que se necesite configurar la delegación restringida para permitir que las aplicaciones de servicio (como Servicios de Excel) deleguen la identidad del cliente a los sistemas back-end.

En este escenario, se configurará la delegación limitada de Kerberos para permitir que el elemento web Visor de RSS lea una fuente RSS segura local y una fuente RSS segura remota desde una aplicación web remota. En escenarios posteriores, se configurará la delegación limitada de Kerberos para otras aplicaciones de servicio de SharePoint Server 2010.

El siguiente diagrama describe conceptualmente lo que se configurará en este escenario:

Contamos con dos aplicaciones web, cada una con su propia colección de sitios con una página de sitio que hospeda dos elementos web Visor de RSS. Las aplicaciones web tienen una zona única predeterminada y configurada para usar la autenticación Kerberos, por lo que todas las fuentes procedentes de estos sitios web requerirán autenticación. En cada sitio se configurará un visor de RSS para leer una fuente RSS local de una lista y otro para leer una fuente de autenticación en el sitio remoto.

Con este fin, la delegación limitada de Kerberos se configurará para permitir la delegación entre las cuentas de servicio del grupo de aplicaciones de IIS. El diagrama siguiente describe conceptualmente las rutas de acceso de delegación restringidas que son necesarias:

Recuerde que la aplicación web se identifica por nombre de servicio mediante el nombre de entidad de seguridad de servicio (SPN) asignado a la identidad del grupo de aplicaciones de IIS. Se deben permitir que las solicitudes de procesamiento de las cuentas de servicio deleguen la identidad del cliente a los servicios designados. En total, se deben configurar las siguientes rutas de acceso de delegación restringida:

Tipo de entidad de seguridad	Nombre de entidad de seguridad	Delega al servicio
Usuario	svcPortal10App	HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555
Usuario	svcTeams10App	HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555

Nota

La configuración de la delegación de un servicio a sí mismo puede parecer redundante, como configurar la cuenta de servicio portal para que delegue a la aplicación de servicio portal. Sin embargo, esto es necesario en escenarios donde hay varios servidores que ejecutan el servicio. Esto sirve para resolver el escenario en que un servidor puede tener que delegar a otro servidor que ejecuta el mismo servicio; por ejemplo, un WFE que procese una solicitud con un visor de RSS que use la aplicación web local como origen de datos. Según la configuración y la topología del conjunto o granja de servidores, es posible que la solicitud de RSS sea atendida por un servidor diferente, lo cual requeriría delegación para funcionar correctamente.

Para configurar la delegación puede usar el complemento Usuarios y equipos de Active Directory. Haga clic con el botón secundario en cada cuenta de servicio y abra el cuadro de diálogo de propiedades. En él, verá una ficha para delegación (tenga en cuenta que esta ficha solo aparece si el objeto tiene un SPN asignado; los equipos tienen un SPN de forma predeterminada). En la ficha Delegación, seleccione Confiar en este usuario para la delegación sólo a los servicios especificados y, a continuación, seleccione Usar cualquier protocolo de autenticación.

Haga clic en el botón Agregar para agregar los servicios a los que el usuario (cuenta de servicio) podrá delegar. Para seleccionar un SPN, debe buscar el objeto al que se aplica el SPN. En esta instancia, intentamos delegar a un servicio HTTP, lo cual significa que buscamos la cuenta de servicio del grupo de aplicaciones de IIS al que se asignó el SPN en el paso anterior.

En el cuadro de diálogo Seleccionar usuarios o equipos, haga clic en Usuarios y equipos, busque las cuentas de servicio del grupo de aplicaciones de IIS (en este ejemplo, vmlab\svcPortal10App y vmlab\svcTeams10App) y, a continuación, haga clic en Aceptar.

A continuación, se le pedirá que seleccione los servicios asignados a los objetos por nombre de entidad de seguridad de servicio.

En el cuadro de diálogo Agregar servicios, haga clic en Seleccionar todo y, a continuación, haga clic en Aceptar. Tenga en cuenta que cuando regrese al cuadro de diálogo Delegación, no verá realmente todos los SPN seleccionados. Para ver todos los SPN, active la casilla de verificación Expandido en la esquina inferior izquierda.

Realice estos pasos para cada cuenta de servicio del entorno que requiera delegación. En este ejemplo, es la lista de cuentas de servicio

Configurar el servidor de SharePoint

Una vez configurados DNS y Active Directory, es el momento de crear la aplicación web en la granja de servidores de SharePoint Server 2010. En este documento se supone que a esta altura ya se completó la instalación de SharePoint Server, y que la topología y la infraestructura de la granja de servidores, como puede ser el equilibrio de carga, están configuradas. Para obtener más información acerca de cómo instalar y configurar la granja de servidores de SharePoint, vea el tema sobre la implementación para SharePoint Server 2010.

Configurar cuentas de servicio administradas

Antes de crear las aplicaciones web, configure las cuentas de servicio creadas en los pasos anteriores como cuentas de servicio administradas en SharePoint Server. Si lo hace con anticipación, podrá omitir este paso cuando cree las propias aplicaciones web.

Para configurar una cuenta administrada

1. En Administración central de SharePoint, haga clic en Seguridad.

2. En Seguridad general, haga clic en Configurar cuentas administradas:

3. Haga clic en Registrar cuenta administrada y cree una cuenta administrada para cada cuenta de servicio. En este ejemplo, se crearon cinco cuentas de servicio administradas:

   Cuenta	Propósito
   VMLAB\svcSP10Search	Cuenta de servicio de búsqueda de SharePoint
   VMLAB\svcSearchAdmin	Cuenta de servicio de administración de búsqueda de SharePoint
   VMLAB\svcSearchQuery	Cuenta de servicio de consulta de búsqueda de SharePoint
   VMLAB\svcPortal10App	Cuenta de grupo de aplicaciones de IIS de la aplicación web Portal
   VMLAB\svcTeams10App	Cuenta de grupo de aplicaciones de IIS de la aplicación web Teams

   Nota

   Las cuentas administradas de SharePoint Server 2010 no son las mismas que las cuentas de servicio administradas de Active Directory de Windows Server 2008 R2.

Crear la aplicación de servicio de búsqueda de SharePoint Server

En este ejemplo se configurará la aplicación de servicio de búsqueda de SharePoint Server para garantizar que se pueda buscar en la aplicación web recién creada y se pueda rastrear correctamente. Cree una nueva aplicación web de búsqueda de SharePoint Server y coloque los servicios de búsqueda, consulta y administración en el servidor de aplicaciones; en este ejemplo, vmSP10App01. Para obtener una explicación detallada sobre cómo configurar la aplicación de servicio de búsqueda, vea el tema sobre las instrucciones paso a paso para aprovisionar la aplicación de servicio de búsqueda.

Nota

La colocación de todos los servicios de búsqueda en un único servidor de aplicaciones es solo con fines de demostración. Este documento no incluye una descripción completa de los procedimientos recomendados y las opciones de topología de búsqueda de SharePoint Server 2010.

Crear la aplicación web

Vaya a Administración central y navegue hasta Administrar aplicaciones web en la sección Administración de aplicaciones. En la barra de herramientas, seleccione Nuevo y cree la aplicación web. Asegúrese de que estén configurados los siguientes elementos:

• Seleccione Autenticación de modo clásico.

• Configure el puerto y el encabezado host de cada aplicación web.

• Seleccione Negociar como el proveedor de autenticación.

• En el grupo de aplicaciones, seleccione Crear nuevo grupo de aplicaciones y elija la cuenta administrada creada en el paso anterior.

En este ejemplo, se crearon dos aplicaciones web con la siguiente configuración:

Configuración	http://Portal Web Application	http://Teams Web Application
Autenticación	Modo clásico	Modo clásico
Sitio web de IIS	Nombre: SharePoint – Portal – 80 Puerto: 80 Encabezado host: Portal	Nombre: SharePoint – Teams – 5555 Puerto: 80 Encabezado host: Teams
Configuración de seguridad	Proveedor de autenticación: Negociar Permitir anónimo: no Usar capa de sockets seguros: no	Proveedor de autenticación: Negociar Permitir anónimo: no Usar capa de sockets seguros: no
Dirección URL pública	http://Portal:80	http://Teams:5555
Grupo de aplicaciones	Nombre: SharePoint – Portal80 Cuenta de seguridad: vmlab\svcPortal10App	Nombre: SharePoint – Teams5555 Cuenta de seguridad: vmlab\svcTeams10App

Al crear la nueva aplicación web, también se crea una nueva zona, la zona predeterminada, configurada para usar el proveedor de autenticación de Windows. Puede ver el proveedor y su configuración para la zona en Administración de aplicaciones web. Para ello, seleccione primero la aplicación web y, a continuación, haga clic en Proveedores de autenticación en la barra de herramientas. En el cuadro de diálogo de proveedores de autenticación se enumeran todas las zonas de la aplicación web seleccionadas junto con el proveedor de autenticación para cada zona. Al seleccionar la zona, verá las opciones de autenticación para esa zona.

Si configura incorrectamente las opciones de Windows y seleccionó NTLM cuando se creó la aplicación web, puede usar el cuadro de diálogo de autenticación de edición para la zona para cambiar la zona de NTLM a Negociar. Si no se seleccionó el Modo clásico como el modo de autenticación, debe crear una nueva zona mediante la extensión de la aplicación web a un nuevo sitio web de IIS; o bien, eliminar y volver a crear la aplicación web.

Crear colecciones de sitios

Para comprobar si la autenticación está funcionando correctamente, deberá crear al menos una colección de sitios en cada aplicación web. La creación y configuración de la colección de sitios no afectará a la funcionalidad de Kerberos; por lo tanto, siga las instrucciones existentes sobre cómo crear una colección de sitios del tema sobre la creación de una colección de sitios (SharePoint Foundation 2010).

Para este ejemplo, se configuraron dos colecciones de sitios:

Aplicación web	Ruta de acceso de colección de sitios	Plantilla de colección de sitios
http://portal	/	Portal de publicación
http://teams:5555	/	Sitio de grupo

Crear asignaciones de acceso alternativas

La aplicación web portal se configurará para usar HTTPS, así como HTTP, para demostrar cómo funciona la delegación con los servicios protegidos con SSL. Para configurar SSL, la aplicación web portal necesitará una segunda asignación de acceso alternativa (AAM) de SharePoint Server para el extremo HTTPS.

Para configurar asignaciones de acceso alternativas

1. En Administración central, haga clic en Administración de aplicaciones.

2. En Aplicaciones web, haga clic en Configurar asignaciones de acceso alternativas.

3. En la lista desplegable Colección de asignaciones de acceso alternativas, seleccione Cambiar colección de asignaciones de acceso alternativas.

4. Seleccione la aplicación web portal.

5. Haga clic en Editar direcciones URL internas en la barra de herramientas superior.

6. En una zona libre, agregue la dirección URL HTTPS para la aplicación web. Esta dirección URL será el nombre en el certificado SSL que se va a crear en los pasos siguientes.

7. Haga clic en Guardar.

   Ahora debería ver la dirección URL HTTPS en la lista de zonas para la aplicación web.

Configuración de IIS

Instalar certificados SSL

Deberá configurar un certificado SSL en cada servidor de SharePoint Server que hospede el servicio de aplicación web para cada aplicación web que use SSL. Nuevamente, en este documento no se trata el tema sobre cómo configurar certificados SSL y certificados de confianza. Vea la sección Configuración de SSL en este documento para obtener referencias a material acerca de cómo configurar certificados SSL en IIS.

Comprobar que la autenticación Kerberos está habilitada

Para comprobar que la autenticación Kerberos está habilitada en el sitio web

1. Abra el Administrador de IIS.

2. Seleccione el sitio web de IIS que va a comprobar.

3. En la vista Características, en IIS, haga doble clic en Autenticación.

4. Seleccione Autenticación de Windows, que debe estar habilitado.

5. En el lado derecho, bajo Acciones, seleccione Proveedores. Compruebe que Negociar esté en la parte superior de la lista.

Comprobar que la autenticación de modo kernel está deshabilitada

En SharePoint Server 2010, no se admite la autenticación de modo kernel. De forma predeterminada, todas las aplicaciones web de SharePoint Server deben tener la autenticación de modo kernel deshabilitada en los sitios web de IIS correspondientes. Incluso en situaciones donde se ha configurado la aplicación web en un sitio web de IIS existente, SharePoint Server deshabilita la autenticación de modo kernel, debido a que aprovisiona una nueva aplicación web en el sitio de IIS existente.

Para comprobar que la autenticación de modo kernel está deshabilitada

1. Abra el Administrador de IIS.

2. Seleccione el sitio web de IIS que va a comprobar.

3. En la vista Características, en IIS, haga doble clic en Autenticación.

4. Seleccione Autenticación de Windows, que debe estar habilitado.

5. Haga clic en Configuración avanzada.

6. Compruebe que la autenticación de modo kernel y EAP estén deshabilitados.

Configurar el firewall

Antes de probar la autenticación, asegúrese de que los clientes tienen acceso a las aplicaciones web de SharePoint Server en los puertos HTTP configurados. Además, asegúrese de que los clientes pueden autenticarse con Active Directory y solicitar vales Kerberos de KDC (Centro de distribución de claves) a través de los puertos de Kerberos estándar.

Abrir los puertos del firewall para permitir el tráfico HTTP de entrada en puertos predeterminados y no predeterminados

Normalmente, tendrá que configurar el firewall en cada front-end web para permitir las solicitudes entrantes a través de puertos TCP 80 y TCP 443. Abra Firewall de Windows con seguridad avanzada y busque las siguientes reglas de entrada:

• Servicios de World Wide Web (Entrada de tráfico HTTP)

• Servicios de World Wide Web (Entrada de tráfico HTTPS)

Asegúrese de que los puertos correctos están abiertos en el entorno. En este ejemplo, se accede a SharePoint Server a través de HTTP (puerto 80), por lo que se ha habilitado esta regla.

Además, tenemos que abrir el puerto no predeterminado que se usa en este ejemplo (TCP 5555). Si tiene sitios web que se ejecuten en puertos no predeterminados, también debe configurar reglas personalizadas para permitir el tráfico HTTP en esos puertos.

Asegurarse de que los clientes pueden conectarse a los puertos de Kerberos en el rol de Active Directory

Para usar la autenticación Kerberos, los clientes deben solicitar vales de concesión de vales (TGT) y vales de servicio (ST) desde KDC a través del puerto UDP o TCP 88. De forma predeterminada, cuando se instala el rol de Active Directory en Windows Server 2008 y posterior, el rol deberá configurar las siguientes reglas de entrada para permitir esta comunicación de forma predeterminada:

• Centro de distribución de claves Kerberos - PCR (TCP de entrada)

• Centro de distribución de claves Kerberos - PCR (UDP de entrada)

• Centro de distribución de claves Kerberos (TCP de entrada)

• Centro de distribución de claves Kerberos (UDP de entrada)

En el entorno, asegúrese de que estas reglas están habilitadas y que los clientes pueden conectarse con KDC (controlador de dominio) a través del puerto 88.

Probar la autenticación del explorador

Después de configurar Active Directory, DNS y SharePoint Server puede probar si la autenticación Kerberos está configurada correctamente al examinar las aplicaciones web. Al probar en el explorador, asegúrese de que se cumplan las condiciones siguientes:

1. El usuario de prueba inició sesión en un equipo con Windows XP, Vista o Windows 7, se unió al dominio en que está instalado SharePoint Server o inició sesión en un dominio de confianza para el dominio de SharePoint Server.

2. El usuario de prueba usa Internet Explorer 7.0 o posterior (Internet Explorer 6.0 ya no se admite en SharePoint Server 2010). Vea el tema sobre la planeación de exploradores admitidos (SharePoint Server 2010)).

3. La autenticación integrada de Windows está habilitada en el explorador. En la ficha Opciones avanzadas de Opciones de Internet, asegúrese de que está habilitada la opción Habilitar autenticación integrada de Windows* en la sección Seguridad:

4. La intranet local está configurada para que los clientes inicien sesión automáticamente. En la opción de Internet Explorer, en la ficha Seguridad, seleccione Intranet local y haga clic en el botón Nivel personalizado. Desplácese hacia abajo y asegúrese de que la opción Inicio de sesión automático solo en la zona de intranet esté seleccionada.

   Nota

   Es posible configurar el inicio de sesión automático en otras zonas, pero el tema sobre los procedimientos recomendados para las zonas de seguridad de IE está fuera del alcance de este documento. En esta demostración, la zona de intranet se usará para todas las pruebas.

5. Asegúrese de que la opción Detectar redes intranet automáticamente está seleccionada en Opciones de Internet -> Seguridad -> Zona de intranet -> Sitios.

6. Si usa nombres de dominio completos para tener acceso a las aplicaciones web de SharePoint Server, asegúrese de que los FQDN se incluyen en la zona de intranet, ya sea tanto de forma explícita como por inclusión de caracteres comodín (por ejemplo, “*.vmlab.local”).

La forma más sencilla para determinar si la autenticación Kerberos está en uso es iniciar sesión en una estación de trabajo de prueba y navegar al sitio web en cuestión. Si no se le piden credenciales al usuario y el sitio se representa correctamente, puede suponer que la autenticación integrada de Windows está funcionando. El siguiente paso es determinar si se usó el protocolo de negociación para negociar la autenticación Kerberos como proveedor de autenticación para la solicitud. Esto puede realizarse de las siguientes maneras:

Registros de seguridad front-end web

Si la autenticación Kerberos está funcionando correctamente, verá eventos de inicio de sesión en los registros de eventos de seguridad en los front-end web con el identificador de evento = 4624. En la información general para estos eventos, debería aparecer el identificador de seguridad en el que se inicia sesión en el equipo y el proceso de inicio de sesión que se usa, que debería ser Kerberos.

KList

KList es una utilidad de línea de comandos que se incluye en la instalación predeterminada de Windows Server 2008 y Windows Server 2008 R2, que sirve para enumerar y purgar los vales Kerberos en un equipo determinado. Para ejecutar KLIST, abra un símbolo del sistema en Windows Server 2008 y escriba Klist.

Si desea purgar la memoria caché de vales, ejecute Klist con el parámetro opcional purge: Klist purge

KerbTray

KerbTray es una utilidad gratuita que se incluye con la herramienta del kit de recursos de Windows Server 2000, que se puede instalar en el equipo cliente para ver la memoria caché de vales Kerberos. Descárguela e instálela desde el tema sobre la herramienta del kit de recursos de Windows 2000 Kerbtray.exe. Una vez instalada, realice las acciones siguientes:

1. Navegue a los sitios web que usan la autenticación Kerberos.

2. Ejecute KerbTray.exe.

3. Para visualizar la memoria caché de vales Kerberos, haga clic con el botón secundario en el icono de KerbTray de la bandeja del sistema y seleccione List Tickets (Enumerar vales).

4. Valide los vales de servicio para las aplicaciones web que autenticó que se encuentren en la lista de vales almacenados en la memoria caché. En este ejemplo, navegamos a los sitios web que tienen los siguientes SPN registrados:

   Dirección URL del sitio web	SPN
   http://portal	HTTP/Portal.vmlab.local
   http://teams:5555	HTTP/Teams.vmlab.local

Fiddler

Fiddler es un analizador de tráfico HTTP gratuito que se puede descargar desde la siguiente ubicación: http://www.fiddler2.com/fiddler2/. En Fiddler, verá cómo el cliente y el servidor negocian la autenticación Kerberos y cómo el cliente envía los vales de servicio Kerberos al servidor en los encabezados HTTP de cada solicitud. Para validar que la autenticación Kerberos esté funcionando correctamente mediante Fiddler, realice las siguientes acciones:

1. Descargue e instale Fiddler (www.fiddlertool.com) en el equipo cliente.

2. Cierre sesión en el escritorio y vuelva a iniciar sesión para vaciar las conexiones almacenadas en la memoria caché en el servidor web y forzar el explorador para que negocie la autenticación Kerberos y realice el protocolo de enlace de la autenticación.

3. Inicie Fiddler.

4. Abra Internet Explorer y vaya a la aplicación web (en este ejemplo, http://portal).

Debería ver las solicitudes y respuestas al front-end web de SharePoint Server en Fiddler.

El primer HTTP 401 es el intento del explorador para realizar la solicitud GET sin autenticación. En respuesta, el servidor devuelve "HTTP 401 No autorizado" e indica, en esta respuesta, qué métodos de autenticación admite. En la siguiente solicitud, el cliente vuelve a enviar la solicitud anterior, pero esta vez, envía el vale de servicio para la aplicación web en los encabezados de la solicitud. Si se autentica correctamente, el servidor devolverá el recurso solicitado.

NetMon 3.4

NetMon 3.4 es un analizador de paquetes de red gratuito de Microsoft que puede descargarse desde el Centro de descarga de Microsoft: Microsoft Network Monitor 3.4.

En NetMon verá todas las solicitudes y respuestas TCP para KDC y los servidores web de SharePoint Server, lo cual ofrece una visión integral del tráfico que conforma una solicitud de autenticación completa. Para validar que la autenticación Kerberos funciona mediante netmon, realice las siguientes acciones:

1. Descargue e instale NetMon 3.4 (Microsoft Network Monitor 3.4).

2. Cierre sesión en el cliente y vuelva a iniciar sesión para vaciar la memoria caché de vales Kerberos. Como alternativa, puede usar KerbTray para purgar la memoria caché de vales. Para ello, haga clic con el botón secundario en KerbTray y seleccione Purge Tickets (Purgar vales).

3. Inicie NetMon en modo de administrador. A continuación, haga clic con el botón secundario en el acceso directo de NetMon y seleccione Ejecutar como administrador.

4. Inicie una nueva captura en las interfaces que se conectan con el controlador de Active Directory en el entorno y los front-end web.

5. Abra Internet Explorer y vaya a la aplicación web.

6. Una vez que se represente el sitio web, detenga la captura y agregue un filtro de presentación para mostrar los marcos para la autenticación Kerberos y el tráfico HTTP.

7. En la ventana de marcos debe ver el tráfico HTTP y Kerberos V5.

Probar la autenticación Kerberos a través de SSL

Para mostrar con claridad los SPN solicitados cuando un cliente accede a un recurso protegido con SSL, puede usar una herramienta como netmon para capturar el tráfico entre cliente y servidor, y examinar las solicitudes de vales de servicio Kerberos.

1. Cierre sesión y, a continuación, vuelva a iniciar sesión en el equipo cliente; o bien, borre todos los vales Kerberos almacenados en la memoria caché mediante KerbTray.

2. Inicie una nueva captura de NetMon en el equipo cliente. Asegúrese de iniciar NetMon con permisos de administrador.

3. Vaya a la aplicación web mediante SSL (en este ejemplo, https://portal.)

4. Detenga la captura de NetMon y examine el tráfico de Kerberos V5. Para obtener instrucciones sobre cómo filtrar la pantalla de capturas, consulte las instrucciones de la sección NetMon 3.4 de este artículo.

5. Busque la solicitud de TGS que envía el cliente. En el parámetro "Sname" de la solicitud, verá el SPN solicitado.

   Tenga en cuenta que "Sname" es HTTP/portal.vmlab.local y no HTTPS/portal.vmlab.local.

Probar la consulta y el índice de búsqueda de SharePoint Server

Comprobar el acceso al explorador desde los servidores de indexación

Antes de ejecutar un rastreo, asegúrese de que el servidor de indexación tiene acceso a las aplicaciones web y se autentica correctamente. Inicie sesión en el servidor de indexación y abra las colecciones de sitios de prueba en el explorador. Si los sitios se representan correctamente y no aparece ningún cuadro de diálogo de autenticación, vaya al paso siguiente. Si se producen problemas al acceder a los sitios en los exploradores, vuelva a los pasos anteriores para asegurarse de que todas las acciones de configuración se hayan realizado correctamente.

Cargar el contenido de ejemplo y realizar un rastreo

En cada colección de sitios, cargue un documento de "valor de inicialización" (que sea fácil de identificar en la búsqueda) a una biblioteca de documentos de la colección de sitios. Por ejemplo, cree un documento de texto que contenga las palabras "alfa, beta, delta" y guárdelo en una biblioteca de documentos de cada colección de sitios.

A continuación, vaya a Administración central de SharePoint e inicie un rastreo completo en el origen de contenido de sitios locales de SharePoint (que debería contener las dos colecciones de sitios de prueba de forma predeterminada).

Probar la búsqueda

Si la indización se completa correctamente, debería ver los elementos que se pueden buscar en el índice y no debería haber errores en el registro de rastreo.

Nota

Si ha configurado la aplicación de perfil de usuario (UPA) y va a realizar un rastreo en el almacén de perfiles, asegúrese de configurar los permisos adecuados en UPA para permitir que la cuenta de acceso al contenido tenga acceso a los datos de perfil. Si no ha configurado los permisos de UPA, recibirá errores en los registros de rastreos, que indicarán que el rastreador (crawler) no pudo acceder al servicio de perfiles porque recibió un HTTP 401 al intentar obtener acceso al servicio. El 401 devuelto no se debe a Kerberos, sino a que la cuenta de acceso al contenido no tiene permisos para leer datos de perfil.

A continuación, vaya a cada colección de sitios y realice una búsqueda para el documento iniciador. Las consultas de búsqueda de cada colección de sitios deberían devolver el documento iniciador cargado.

Probar la delegación front-end web

Como último paso de este escenario, use el elemento web Visor de RSS en cada colección de sitios para asegurarse de que la delegación funciona tanto de forma local como remota.

Configurar orígenes de fuentes RSS en cada colección de sitios

Para la aplicación portal, debe habilitar las fuentes RSS en la colección de sitios. Para activar las fuentes RSS, siga las instrucciones del tema sobre la administración de fuentes RSS en Office.com.

Una vez que se habilitan las fuentes RSS, cree una nueva lista personalizada y agregue un elemento de lista para fines de prueba. Navegue hasta el menú Lista de la barra de herramientas y haga clic en Fuente RSS para ver la fuente RSS. Copie la dirección URL de la fuente para usarla en los pasos siguientes.

Realice este paso para cada colección de sitios.

Agregar elementos web Visor de RSS a la página principal de cada colección de sitios

En la aplicación portal, deberá habilitar la característica de colección de sitios Características Enterprise de SharePoint para usar el elemento web Visor de RSS. Una vez habilitada, agregue dos elementos web Visor de RSS a la página principal. Para el primer elemento web, configure la dirección URL de la fuente para que apunte a la fuente RSS local que creó en el paso anterior. Para el segundo elemento web, configure la dirección URL de la fuente para que apunte a la dirección URL de la fuente remota. Una vez completada la tarea, ambos elementos web deberían representar correctamente el contenido de las fuentes RSS local y remota.