Carrera de relevos o Configuración de Kerberos en SharePoint 2010

 

El presente artículo es un resumen de la Guía para configurar Kerberos provista por Microsoft para SharePoint 2010, no pretende reemplazarlo sino dar un panorama general y una comprensión de lo que se va hacer. El detalle de cada paso esta en la guía en la siguiente dirección:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=1a794fb5-77d0-475c-8738-ea04d3de1147&displaylang=en

Antes de configurar Kerberos hay que comprender como funciona y se integra con los diferentes servicios.

Kerberos es un protocolo de seguridad que soporta autenticación por etiquetado.

Este protocolo de seguridad es necesario en SharePoint 2010 cuando deseamos conectarnos a una fuente de datos externa y se requiere pasar las credenciales del usuario que se conecto al portal.  Para que comprendamos mejor veamos el siguiente diagrama:

Como vemos en la figura de arriba la credenciales son almacenadas en SharePoint como un Claim, es entonces necesario convertirlas de nuevo en un Tiquete de Kerberos, para autenticarse con un sistema externo.

Kerberos se asocia a una o varias cuentas de dominio y a un servicio para su utilización.  Esto se hace a través de crear un SPN o Service Principal Name, en línea de comando en un servidor con Windows Server 2008 que no sea el Controlador de dominio, como se muestra a continuación:

SetSPN –S HTTP/Portal [cuenta de dominio]

También es necesario la delegación de una cuenta o otra para transferir el Tiquete que lleva las credenciales del usuario.  Como lo muestra la imagen de abajo.

La delegación la hacemos a través del Directorio Activo.  Para las cuentas que se le asociaron el SPN, en el Directorio Activo sobre las propiedades de la cuenta aparecerá una pestaña llamada Delegation, en ella nos permitirá seleccionar que servicios estarán asociados a la cuenta.

En SharePoint como primer paso es habilitar el protocolo de Kerberos para al autenticarse al portal genere dicho Tiquete.

Luego deberá registrarse las cuentas que tienen generado el SPN como una cuenta administrada (un concepto viejo en SharePoint pero que toma relevancia en 2010) y luego asociar esta cuenta a un servicio de SharePoint que utilizará el tiquete generado para autenticar o pasar las credenciales del usuario.

Hay ciertos servicios asociados a SharePoint que utilizan Basic Kerberos Delegation otros Kerberos constrained delegation. La regla es que si se puede pasar de una basic delegation a una constrarined pero no a la inversa.  Los servicios que requieren Kerberos son constrained delegation son:

· Excel Services

· PerformancePoint Services

· InfoPath Forms Services

· Visio Services

Los que requieren Basic Kerberos delegation son:

· Business Data Connectivity service and Microsoft Business Connectivity Services

· Access Services

· Microsoft SQL Server Reporting Services (SSRS)

· Microsoft Project Server 2010

La diferencia importante entre estos dos sistemas de delegación en la intervención de un Servicio llamada C2WTS o Claims to Windows Token Service. La imagen de abajo muestra claramente lo que debería de suceder.

En resumen debemos de configurar Kerberos para:

1. Autenticarnos al portal.

2. Para pasar el Tiquete al Servicio C2WTS.

3. Para el servicio de SharePoint que requiere y pasará las credenciales por ejemplo Performance Point o Excel Services.

4. A la cuenta que inicia el servicio de la fuente de datos externa, por ejemplo SQL Server 2008 R2 Analysis Services o bien Database Engine o ambos.

Para ello debe crearse estas cuentas de Windows asociar el SPN a las mismas, delegarlo a través de Active Directory, configurar SharePoint y configurar las cuentas y asociarlas a los servicios requeridos.

Sugerencia vaya probando como lo sugiere la guía cada paso para asegurarse que ha hecho el procedimiento correcto.  Hay ocasiones que Kerberos no autentica luego de recién configurar un servicio, a veces registrando de nuevo la cuenta asociada al servicio y reiniciándolo hace que funciona o bien como ultimo recurso reiniciar el servidor de SharePoint o del servidor donde se esta configurando la cuenta que deseamos que utilice Kerberos.

Otros aspectos a tomar en cuenta: http://technet.microsoft.com/en-us/library/gg502599.aspx

Y otro buen artículo sobre Kerberos y SharePoint es: http://technet.microsoft.com/en-us/magazine/ee914605.aspx

SharePoint4Fun,

Manolo Herrera

Comentarios sobre la integración de Reporting Services y SharePoint 2010

Las opciones para integrar SharePoint 2010 y Reporting Services dependen de la configuración de los servidores, la mas sencilla que no requiere mayor intervención en la de un solo servidor, pero cuando hablamos de más de uno hay variadas configuraciones.

Me llamó la atención la configuración de 2 servidores que es una de las instalaciones mas comunes en nuestros clientes.  Que hay 2 variantes les muestro la imagen de abajo:

Imagen obtenida de technet

Con esta configuración debes de instalar SharePoint en ambos servidores.  Configurar primero la granja y luego instalar SharePoint en el servidor de bases de datos ya que Report Server necesita el modelo de objetos de SharePoint a la mano. 

Al ejecutar el asistente de SharePoint 2010 debes de indicar que te vas a conectar a una granja existente y no necesitas el Central Administration.  Si ya lo instalaste aunque no te afecta te recomiendo que lo desinstales porque no lo vas a utilizar, para ello debes de ejecutar de nuevo el asistente de SharePoint e indicarle que quieres seguir conectado a la granja pero que no quieres hospedar el Central Administration en esta computadora.

La segunda configuración fue la que me llamo la atención, se las muestro a continuación:

Imagen obtenida de technet

En esta no instalas Reporting Services en el servidor de bases de datos, sino en el Front End o Servidor de Cara y entonces no necesitas instalar SharePoint 2010 en el servidor de bases de datos ya que el que necesita el MO de SharePoint es el Report Server.

En cuanto a licenciamiento dependiendo de la versión de Sql server utilizada en el servidor de bases de datos y de SharePoint en el servidor de Front End que estés utilizando te convendrá una o la otra.  Ya que SharePoint 2010 bajo sus precios en el core pero aumento el valor en Calls y el valor del Core de Sql Server 2008 R2 Enterprise es bastante mas caro que el de SharePoint 2010 Core Enterprise, así que debes de jugar con tus versiones y números y ver que te conviene mas.  Debes de solicitar a un proveedor autorizado de Microsoft los precios porque no son públicos y puedes obtener información incorrecta en la red.

SharePoint4Fun!,

Manolo Herrera

Dos aspectos importantes a tomar en cuenta en los Timer Job Personalizados de SharePoint 2010

Al parecer Visual Studio 2010 ha hecho un buen trabajo para automatizar el proceso de instalación o deployment cuando desarrollamos componentes para SharePoint 2010, como elementos Web, “Timer Jobs”, etc.  Tan buen trabajo han hecho que los desarrolladores que no desarrollaron para SP 2007 no sabe que al instalar el Timer Job manualmente en el servidor productivo es necesario activar la “feature” en la Colección de Sitio (Asumiendo que el alcance definido de la “feature” es Site que equivale a una Colección de Sitios). De otra forma aunque este instalada, e implementada el “Timer Job” no aparecerá en el “Central Administration” de SharePoint 2010, en la sección de Supervisión o “Monitoring”.

Pero cuando la intentemos activar sucederá que nos indicará un error que al revisar los USLogs de SharePoint leeremos la descripción Acceso Denegado Event ID : 6615.  Pero no te preocupes nuestro amigo Paul Kotlayr a resuelto el problema ejecutando un script a nivel del Power Shell de SharePoint 2010.

Aquí el link: http://unclepaul84.blogspot.com/2010/06/sppersistedobject-xxxxxxxxxxx-could-not.html

Así que no olvide activar la “feature” en la colección de sitios que deseas que se ejecute y ejecutar el script de Paul para eliminar el error de acceso denegado que aunque lo hagas con el Farm Administrator no te va permitir ejecutarlo sino cambias el valor RemoteAdministratorAccessDenied a falso.

Hasta la próxima, SharePoint20104Fun!,

Manolo Herrera

A pesar de tener control total sobre el sitio no puede ver todos los elementos Web disponibles a nivel de colección de sitios

El problema se debe a que dicho usuario no tiene acceso al Sitio de nivel mas alto solo al sitio o sub-sitio en cuestión que esta a nivel menor y debido a que la galería de elementos Web esta a nivel de colección de sitios y el usuario no tiene acceso a esta no le muestra los elementos Web.

Solución:

Debe de darle permisos al usuario dentro de la galería de sitios ya sea agregando al usuario a un grupo que tenga acceso de lectura a esa librería o bien que rompa la herencia de permisos de la librería y agregue un grupo o al usuario a dicha librería.

Pasos:

1. Con un usuario que pueda acceder a la galería de elementos web (administrador de la colección de sitios) ingrese al portal.
2. Si esta en el sitio principal, raíz o de  nivel superior.  Haga clic sobre Acciones del Sitios.
3. Clic sobre configuración del Sitio.
4. En Galerías haga clic sobre Elementos Web
5. Haga clic sobre Biblioteca
6. Haga clic sobre Configuración de biblioteca.
7. Permisos sobre esta galería
8. Haga clic sobre Visitantes
9. Haga clic en Nuevo
10. Agregue el usuario deseado y eso es todo.

Vaya a la página deseada , ingrese con el usuario al que le dio permisos, edite la página y le debería de mostrar todos los elementos Web disponibles en la versión de SharePoint que instaló.

SharePoint4Fun!,

Manolo Herrera