El hecho de utilizar una topología Split Back-to-Back en SharePoint, implica que tenemos servidores SharePoint pertenecientes a múltiples Dominios de Directorio Activo de diferentes Bosques sobre los que existe un relación de confianza unidireccional, aunque realmente la Granja la montemos sobre un dominio en particular, y las cuentas de servicio y de los Application Pools pertenezcan a dicho Dominio de Directorio Activo.
El caso habitual suele estar formado por un Bosque con uno o varios Dominios en una red interna (Intranet) y otro Bosque en una red externa (Extranet), separados por un Firewall, montándose la Granja de SharePoint sobre la red interna, y siendo necesario configurar una relación de confianza (Trust) unidireccional así como abrir los puertos en el Firewall para Directorio Activo y MOSS, de tal modo que la Extranet confíe en los usuarios de la Intranet, pero no al contrario (por motivos evidentes de seguridad). De este modo, podremos instalar SharePoint sobre un servidor de la Extranet (Split Back-to-Back), o sobre varios servidores si fuera necesario.
En este escenario, nos encontraremos que antes o después necesitaremos conceder permisos a usuarios en nuestros Sitios de SharePoint, tanto a usuarios de la red interna (Intranet) como a usuarios de la red externa (Extranet). En este caso, existe una casuística algo peculiar, ya que en función de que intentemos asignar permisos desde un Frontal que pertenezca a un Dominio (ej: Intranet) o que pertenezca a otro (ej: Extranet), el comportamiento puede ser diferente. Me explico:
- Conceder permisos a usuarios de la red interna (Intranet). Aquí no tendremos ningún problema. Los servidores de la Intranet están en casa, y los servidores de la Extranet poseen una relación de confianza unidireccional con la Intranet, así que, OK.
- Conceder permisos a usuarios de la red externa (Extranet). Esta tarea sólo la podremos realizar desde un servidor SharePoint de la Extranet. El problema, es que los servidores SharePoint de la Intranet no pueden acceder al Directorio Activo para poder realizar la concesión de permisos, por la naturaleza propia de la relación de confianza (Trust) unidireccional que está configurada.
Este comportamiento es así por definición.
Otro tema es el Selector de Personas y Grupos (People Picker). Para conceder permisos, podemos especificar directamente la cuenta de usuario o grupo, o bien utilizar el Selector de Personas y Grupos (People Picker) para realizar una búsqueda. En este caso, debemos tener en cuenta que por defecto, el Selector de Personas y Grupos (People Picker) sólo funcionará para las cuentas existentes en el dominio sobre el que está montada la Granja de SharePoint, así como sobre todos los Dominios con los que exista una relación de confianza (Trust) bidireccional, como se describe en la documentación del producto de TechNet (ver Peoplepicker-searchadforests: Stsadm property - Office SharePoint Server). Pero en nuestro caso, existe una relación de confianza (Trust) unidireccional, por lo tanto, por defecto el Selector de Personas y Grupos (People Picker) no funcionará para realizar búsquedas sobre el Dominio de la Extranet.
Veámoslo en detalle.
Descripción del escenario/problema
Si en un servidor de la Extranet especificamos la cuenta del administrador del Dominio de la Extranet (YOLINET\administrator) y le damos a Comprobar Nombres, se resolverá satisfactoriamente.
Sin embargo, si en un servidor de la Intranet intentamos resolver cuentas de usuario del Dominio de la Extranet (yolinet.local), no tendremos éxito (No exact match was found. Click the ítems that did not resolve for more options), algo lógico y razonable, debido a la naturaleza propia de la relación de confianza (Trust) unidireccional existente entre la Extranet y la Intranet. Un comportamiento característico de la topología Split Back-to-Back.
Por otro lado, si buscamos por Administrator utilizando el Selector de Personas y Grupos (People picker), tanto en los servidores de la Intranet como en los servidores de la Extranet, obtenemos el siguiente resultado, es decir, no se reconoce al usuario Administrator del Dominio de la Extranet (yolinet.local). De hecho, busquemos lo que busquemos, no aparecerá ningún resultado del dominio de la Extranet, para nuestro regocijo.
Configurar el Selector de Personas y Grupos (People Picker) sobre una Relación de Confianza (Trust) unidireccional
Para resolver este comportamiento del Selector de Personas y Grupos (People picker), vamos a ejecutar el siguiente comando STSADM SETPROPERTY PEOPLEPICKER-SEARCHADFOREST, incluyendo múltiples dominios/bosques, para permitir la búsqueda tanto en el Dominio de la red interna (Intranet) como sobre la red externa (Extranet): stsadm -o setproperty -url http://sharepoint -pn peoplepicker-searchadforests -pv "forest:guillesql.local;forest:yolinet.local"
Realizado esto, ahora al utilizar el Selector de Personas y Grupos (People picker) en un servidor SharePoint de la Extranet, si es posible resolver usuarios y grupos tanto pertenecientes al Dominio de la red interna (Intranet) como de la red external (Extranet). De hecho, al repetir la búsqueda por el término Administrator sobre un servidor de la Extranet, aparecen como resultados tanto el usuario GUILLESQL\Administrator como YOLINET\Administrador.
Mientras tanto, en la Intranet nada habrá cambiado, por lo que desde los servidores SharePoint de la red interna sólo podremos conceder permisos sobre usuarios de los dominios en los que se confía, lo cual, excluye a la Extranet.
Un caso particular a contemplar cuando se realizan este tipo de configuraciones, es el caso de configurar el People-Picker sólo con algunos de los dominios con los que se tiene una relación de confianza unidireccional. También es interesante tener presente algunos comandos STSADM de ayuda a personalizar el funcionamiento del People-Picker.
Conclusión: Problema solucionado.
Téngase en cuenta, que al ejecutar el anterior comando STSADM SETPROPERTY PEOPLEPICKER-SEARCHADFOREST hemos especificado ambos Dominios/Bosques, tanto el de la Intranet como el de la Extranet. Esto es muy importante. Si pensamos que sólo es necesario especificar el dominio de la Extranet, porque el de la Intranet ya funcionar, lo que conseguiremos es que sólo se resuelvan usuarios y grupos de la Extranet. Es decir, el comando STSADM SETPROPERTY PEOPLEPICKER-SEARCHADFOREST no tiene carácter aditivo, por lo tanto, cuando lo ejecutemos sobrescribiremos su anterior configuración, y en consecuencia, si deseamos en un futuro que sean tres Dominios de Directorio Activo los que podamos utilizar desde el People Picker, tendremos que lanzar de nuevo un comando STSADM SETPROPERTY PEOPLEPICKER-SEARCHADFOREST especificando los tres dominios de marras.
Por último, aprovecho para poner unos enlaces de interés, para quien desee profundizar un poco más:
Poco más por hoy. Como siempre, confío que la lectura resulte de interés.
