miércoles, 12 de noviembre de 2014

Reconociendo otros dominios del directorio activo en SharePoint 2013, 2010 y 2007

El Problema

Cuando deseamos asignar permisos o tareas a usuarios de otros dominios no es posible encontrarlos en las ventanas de búsqueda de usuarios de SharePoint denominada PeoplePicker.  Qué debemos de configurar en SharePoint para que pueda realizar búsquedas en otros dominios a los predeterminados?.  Eso es lo que resolveremos en este artículo.

image

NOTA: Este artículo aplica a las versiones de 2007 a la 2013 de SharePoint tanto Services, Foundation y Server debido a que todavía se puede utilizar el comando stsadm.exe aunque en powershell esta disponible el equivalente es mucho mas sencillo utilizar el stsadm.exe.

Escenario

La granja de SharePoint esta en una Zona Desmilitarizada o DMZ y los usuarios de la intranet pertenecen a diferentes bosques o forest.  En total son 3 bosques del directorio Activo, el bosque predeterminado donde esta instalado la granja de SharePoint que denominaremos xyz.local y los otros bosques denominaremos como abc.com y fgh.local.  Como esta en una DMZ la mayoría de puertos están bloqueados entonces es necesario desbloquear los puertos que utiliza la implementación del directorio activo para su descubrimiento, el cual si es la implementación del AD predeterminado sería el puerto 389.  

Requisitos

Antes de realizar las pruebas  a través de la aplicación telnet deberemos asegurarnos que el dominios puedan resolverse desde el front-end de SharePoint ya sea por DNS o archivos host.  Para ello vamos a levantar una ventana de línea de comando y ejecutar el comando ping de la siguiente manera:

c:\>ping abc.com

c:\>ping fhg.local

Esto nos debería de responder con la ip de algún controlador de dominio que nos responda de estos dominios.

Para comprobar la comunicación en el servidor de front-end hacia estos bosques y puerto podemos realizar las siguientes pruebas por medio de la aplicación telnet.  Si la aplicación no esta disponible en el servidor puede habilitarse por medio de las características de Windows Server en la opción del Panel de control, Programas y Características.

Si ya tenemos la aplicación telnet habilitada podemos ejecutar las siguientes líneas de comando como administradores locales del servidor de front-end de SharePoint:

c:\>telnet xyz.local 389

c:\>telnet abc.com 389

c:\>telnet fgh.local 389

El resultado debería ser que la pantalla se borra y el prompt esta disponible para escribir, sino marcará un error indicando que el puerto no esta disponible o que esta cerrado.  Entonces deberá solicitarse que se abran estos para la comunicación entre dominios.

Si la implementación de los otros bosques incluyen SSL o kerberos consultar el siguiente artículo:

http://blogs.technet.com/b/wbaer/archive/2009/01/21/people-picker-port-protocol-requirements.aspx

Validaciones

Se deberá validar que estos bosques y/o dominios del directorio activo tenga relación de confianza ya sea full trust o completa o en una sola vía.   Si es una sola vía deberemos incluir las credenciales de una cuenta del dominio al que deseamos realizar la búsqueda del usuarios desde SharePoint. Si por el contrario es una relación de confianza completa o full trust entonces no es y no debemos de pasar las credenciales de usuario para que funcione.  Esto lo podemos hacer por medio de la consola administrativa Active Directory Domains and Trust.

http://technet.microsoft.com/en-us/library/cc753821.aspx

El proceso de habilitación de los otros dominios

Bueno ahora vamos a ejecutar la línea de comando stsadm.exe para ello debemos de abrir la consola de administración de SharePoint o bien dirigirnos a la siguiente ruta según la versión de SharePoint:

c:\program files\common files\microsoft shared\web server extensions\12\bin

c:\program files\common files\microsoft shared\web server extensions\14\bin

c:\program files\common files\microsoft shared\web server extensions\15\bin

12 para 2007, 14 para 2010 y 15 para 2013.

primero vamos asegurarnos que no hay ninguna ruta definida.  Para consultarla podemos ejecutar la siguiente línea de comando:

stsadm.exe –o getproperty -pn peoplepicker-searchadforests –url http://sharepoint-web-application:80

Para limpiar los valores que tenga y no sean los correctos podemos ejecutar la siguiente línea de comando

stsadm.exe –o setproperty -pn peoplepicker-searchadforests –url http://sharepoint-web-application:80 –pv “”

Ahora para registrar los bosques y dominios tanto el predeterminado como los otros deberemos ejecutar la siguiente línea de comando

stsadm.exe –o setproperty -pn peoplepicker-searchadforests –url http://sharepoint-web-application:80 –pv “forest:xyz.local;doamin:xyz.local;forest:abc.com;domain:abc.com;forest:fgh.local;domain:fgh.local”

Para relaciones de confianza de una sola vía deberemos incluir la cuenta domain admin o enterprise admin para que pueda realizar las búsquedas dentro de esos bosques.  Entonces el comando se transformaría en lo siguiente:

stsadm.exe –o setproperty -pn peoplepicker-searchadforests –url http://sharepoint-web-application:80 –pv “forest:xyz.local;doamin:xyz.local;forest:abc.com,xyz\domainadmin,password;domain:abc.com;forest:fgh.local,xyz\domainadmin,password;domain:fgh.local”

Va seperado por comas luego de definir el nombre del forest.

Y eso es todo.  En la red hay artículos que hacen referencia a una propiedad de SPSite llamada UserAccountDirectoryPath, esta bloquea más que corregir el problema asegurese que esta en blanco.  Esta es por colección de sitios y una aplicación Web puede tener “n” colecciones de sitios así que deberá ejectar el comando por cada colección de sitios de la siguiente forma, desde PowerShell de SharePoint:

Set-SPSite -Identity http://sharepoint-web-application -UserAccountDirectoryPath "”

Set-SPSite -Identity http://sharepoint-web-application\sites\rrhh -UserAccountDirectoryPath "”

Set-SPSite -Identity http://sharepoint-web-application\sites\IT -UserAccountDirectoryPath "”

Para validar si tiene algún valor puede ejecutar la siguientes líneas de comando vía powershell:

$site = Get-SPSite –Identity http://sharepoint-web-application

$site.UserAccountDirectoryPath

Este deberá devoler algún valor si lo tienen ingresado.

Los interesados en ejecutar este procedimiento en PowerShell ver el siguiente enlace:

http://xblogs.kompas-xnet.si/post/The-People-picker-and-domain-trusts.aspx

Bueno amigo con ello debería poder desde el peoplepiker o las opciones de Compartir o asignar permisos los usuarios de los otros dominios.  Esto no esta ligado con los perfiles de usuario que para ello deberá crearse una conexión para cada dominio, pero esto es otra historia para otro artículo.

SharePoint4Fun,

Juan Manuel Herrera Ocheita