En muchas instalaciones de MOSS, es habitual encontrarnos con una Granja MOSS para el acceso por los usuarios internos, así como una Granja MOSS externa en una DMZ para su publicación a través de Internet. Incluso, puede ser habitual, que cada Granja pertenezca a un dominio de Directorio Activo (ej: un dominio para la Granja Externa con las correspondientes relaciones de confianza con otros dominios, y al margen, todos los dominios internos de nuestra empresa o grupo de empresas).
En este escenario, una Granja interna y otra externa, junto con diferentes dominios de Directorio Activo (un dominio y bosque para la Granja externa con sus Controladores de Dominio también en la DMZ, y sus correspondientes relaciones de confianza unidireccionales con los dominios internos), ¿qué puertos deben abrirse en el Firewall?
Son varios los puertos que tendremos que abrir entre los Controladores de Dominio de la DMZ y los Controladores de Dominio de la red interna. Especialmente, me ha dado guerra descubrir la necesidad de abrir el puerto 1025. Al abrir el resto de puertos, pero sin abrir el puerto 1025, si teníamos un Grupo Local en el dominio externo cuyos miembros incluía usuarios de los dominios internos (es decir, los que están al otro lado del Firewall en el que no hemos abierto el puerto 1025), al mostrar los miembros de dicho grupo utilizando la herramienta administrativa Active Directory Users and Computers (ADUC), sólo se muestra el churrito del SID y además se muestra el siguiente mensaje de error: Some of the object names cannot be shown in ther user-friendly form. This can happen if the object is from an external domain and that domain is not available to translate the object's name.
Del mismo modo, al intentar conceder permisos en la Granja externa de MOSS a un usuario perteneciente a uno de los dominios internos, no se reconocía a dicho usuario (como si no existiese el usuario o dominio).
En ambos casos, ejecutando sobre los Controladores de Dominio de la DMZ el comando netstat -ano | findstr SYN, se podía apreciar la existencia de alguna conexión en estado SYN_SENT al puerto 1025 de algún Controlador de Dominio de los dominios internos, esto es, conexiones TCP que están siendo denegadas por el Firewall (esto es lo que se dice, la prueba del algodón ;-).
Es interesante comentar, que estamos hablando de MOSS 2007 SP2, y de Controladores de Dominio con Sistemas Operativos Windows 2000 Server y Windows Server 2003.
Con todo esto, he llegado a la siguiente definición de puertos para la comunicación con Directorio Activo. Quizás esté abriendo algún puertico de más (ej: creo que es suficiente con abrir el puerto TCP-1025, pero ante la duda y las pocas ganas de meterme en líos, he abierto tanto TCP-1025 como UDP-1025), pero al menos, con esta configuración, doy fé de que funciona (hay clientes en los que es fácil hacer este tipo de pruebas y cambios, y otros, en los que es arduo complicado y escandaloso, cada uno que evalúe por sí mismo ;-).
- TCP-53 (DNS)
- UDP-53 (DNS)
- TCP-88 (Kerberos)
- UDP-88 (Kerberos)
- TCP-389 (LDAP)
- UPP-389 (LDAP)
- TCP-636 (LDAP SSL)
- TCP-3268 (LDAP GC)
- TCP-3269 (LDAP GC SSL)
- TCP-445 (SMB)
- TCP-135 (RPC)
- TCP-137 (NBT)
- UDP-137 (NBT)
- TCP-138 (NBT)
- UDP-138 (NBT)
- TCP-139 (NBT)
- UDP-139 (NBT)
- TCP-1025 (RPC)
- UDP-1025 (RPC)
En mi caso, he creado dos reglas en el Firewall, en ambas permitiendo los puertos indicados:
- Una regla con Origen = DCs internos y Destino = DCs DMZ+ Servidores MOSS DMZ.
- Otra regla con Origen = DCs DMZ + Servidores MOSS DMZ y Destino = DCs internos.
Adicionalmente a la propia apertura de puertos, puede ser necesario realizar alguna configuración adicional en MOSS, para que todo esto funcione. Y digo puede, porque depende de cada escenario. Por ejemplo, con relaciones de confianza unidireccionales, es necesario realizar esta configuración (esto lo he sufrido en mis carnes, que son abundantes) mientras que con relaciones de confianza bidireccionales no sería necesario realizar más configuraciones (esto lo he leído, pero no lo he probado).
Los pasos adicionales que podemos necesitar realizar, son los siguientes:
- Ejecutar el comando STSADM SETAPPPASSWORD, en cada Frontal Web de MOSS, especificando en todos, la misma clave, la cual se utilizará para cifrar la credenciales de acceso a los diferentes dominios de Directorio Activo que se indicarán en el paso siguiente. La sintaxis es: STSADM.exe -o setapppassword -password key
- En un único Frontal Web de MOSS, ejecutar un comando STSADM PEOPLEPICKER-SEARCHADFORESTS, teniendo en cuenta que en el mismo comando, es posible especificar las credenciales para distintos Dominios, separándolas por punto y coma. La sintaxis es: STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv domain:DnsName,user,password -url http:// webapp
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.
Adjunto un par de enlaces de TechNet, en los que se puede obtener mayor información y detalle de estos comandos, y de la problemática en cuestión:
Poco más por hoy. Como siempre, espero que os sirva.
