Quiere que algunas de sus aplicaciones estén disponibles mediante federación, pero tiene varios bosques. ¿Qué puede hacer? Bueno, si tiene confianzas bidireccionales entre sus bosques, está de suerte, porque AD FS funciona muy bien si tiene confianzas bidireccionales entre los bosques. Pero, ¿y si sólo tiene una confianza unidireccional entre los bosques? ¿Qué ocurre entonces?
Para este escenario, supondremos que desea proporcionar SSO a múltiples aplicaciones para usuarios de dos bosques diferentes. Las aplicaciones pueden residir en uno u otro de los bosques o pueden estar basadas en la nube (y, por tanto, en ninguno de los bosques).
Con una confianza bidireccional entre sus bosques AD y su servidor AD FS en el bosque "A", AD FS es capaz de proporcionar autenticación para todos los usuarios de ambos bosques y consultar a AD sus atributos utilizando la confianza bidireccional. Véase la figura 1. Todos los usuarios podrán utilizar la federación para iniciar sesión en las aplicaciones federadas.
Pero espere, ¿y si los usuarios de uno de los bosques son en realidad cuentas de socios o clientes y el bosque no es de plena confianza, por lo que sólo tenemos una confianza unidireccional? Si el servidor AD FS está unido al bosque de socios, los usuarios de socios pueden autenticarse en AD FS y AD FS puede consultar el AD de socios para obtener sus atributos. Además, los usuarios internos del bosque de empleados pueden autenticarse en AD FS a través de la confianza unidireccional. Oh, pero espera, tenemos un problema. En este escenario, AD FS no puede consultar el bosque de empleados para los atributos de usuario porque la cuenta de servicio bajo la cual se ejecuta AD FS en el bosque asociado no tiene permisos para consultar AD en el bosque de empleados. La autenticación funciona, pero AD FS no puede proporcionar información adicional para rellenar las reclamaciones, por lo que el inicio de sesión federado fallará para la mayoría de las aplicaciones. Véase la figura 2.
Usted puede estar pensando que la respuesta a este dilema es colocar el servidor AD FS en el bosque de empleados, pero eso presenta su propio conjunto de problemas. Colocar el servidor AD FS en el bosque de empleados permitiría a los usuarios internos del bosque de empleados autenticarse en AD FS y permitiría a AD FS consultar el bosque de empleados para los atributos de usuario, pero los usuarios del bosque asociado se quedarían al margen. No podrían autenticarse en AD FS porque la dirección de la confianza significa que las aplicaciones del bosque de empleados no confían en los usuarios del bosque asociado. Los intentos de inicio de sesión en aplicaciones federadas por parte de los usuarios asociados fallarían antes de que apenas hubieran comenzado.
Hay al menos tres opciones para resolver este dilema:
- Restríngete a utilizar sólo determinados atributos.
- Configure un servidor AD FS para cada bosque.
- Coloque el servidor AD FS en el bosque asociado pero ejecútelo con una cuenta en el bosque de empleados.
Opción 1 Limitarse a utilizar sólo determinados atributos
Resulta que con una confianza unidireccional puedes obtener algunos atributos para el usuario. Así que mientras sólo intentes utilizar los atributos que se proporcionan en un escenario de confianza unidireccional, puedes utilizar una confianza unidireccional para autenticar al usuario y crear las reclamaciones de federación.
Entre los atributos disponibles se incluyen:
- Nombre - en la forma DOMAIN\sAMAccountName
- Windowsaccountname - en la forma DOMAIN\sAMAccountName
- Primarygroupsid - en forma de un identificador de seguridad (SID) como S-1-5-19
- Groupsid - una lista de SIDs de grupos a los que pertenece el usuario, por ejemplo S-1-1-0, S-1-5-11
Opción 2 Configurar un servidor AD FS para cada bosque
Desde una perspectiva de funcionalidad básica, la opción 2 funciona bien. Con este diseño, los usuarios asociados pueden autenticarse en el AD asociado y el AD FS asociado puede consultar sus atributos en AD; lo mismo ocurre con los empleados y el bosque de empleados. Sin embargo, en este caso, además de la necesidad de contar con el doble de servidores AD FS, el problema del descubrimiento del dominio de origen asoma la cabeza. Véase la figura 3.
El escollo básico con esta opción es que si un usuario intenta acceder a la aplicación web interna 1 (véase la figura 3), dicha aplicación no sabe si debe enviar al usuario para que se autentique en el servidor AD FS del bosque de socios o de empleados. Hay varios enfoques para abordar este problema, pero puede ser muy difícil de resolver. AD FS pedirá al usuario que elija a qué organización o dominio debe ser enviado (por ejemplo, empleado o socio). Véase la figura 4.
Opción 3 Coloque el servidor AD FS en el bosque de socios pero ejecútelo con una cuenta en el bosque de empleados.
Veamos ahora la opción 3: el servidor AD FS reside en el bosque asociado y opera bajo una cuenta de servicio del bosque de empleados. Este diseño cubre los aspectos básicos. Los usuarios del bosque asociado pueden autenticarse en el AD asociado y AD FS puede consultar el AD asociado para obtener los atributos del usuario porque la confianza unidireccional de AD permite a los usuarios del bosque de empleados realizar búsquedas de AD en el bosque asociado. Los usuarios del bosque de empleados pueden autenticarse en el AD de empleados y AD FS puede consultar el AD de empleados para obtener los atributos del usuario porque la cuenta de servicio para AD FS es miembro del bosque de empleados.
Dado que sólo hay un servidor AD FS en este escenario, no hay problema de descubrimiento del dominio de origen. Las aplicaciones internas no tendrán que pedir a los usuarios que identifiquen qué servidor AD FS se debe utilizar para su autenticación, lo que simplifica la experiencia del usuario. Y, como ventaja añadida, sólo necesitará la mitad de servidores que en la opción 2. Véase la figura 5.
Para que no piense que esta opción es la mejor para todos los escenarios de AD FS de confianza unidireccional multi-bosque, tenga en cuenta que no funciona si hay más de dos bosques que no confían el uno en el otro. AD FS sólo puede ejecutarse como una cuenta de servicio, por lo que sólo puede haber una conexión que no sea de confianza para que esta solución funcione.
Resumen:
Como puede verse en la siguiente tabla, cada opción tiene ventajas e inconvenientes, por lo que debe elegir la que mejor se adapte a su situación.
| Opción | Fondos forestales | Atributos | Problema de descubrimiento del reino de origen |
| 1 | Admite múltiples fideicomisos unidireccionales | Limitado | No |
| 2 | No se requiere confianza | Todos | Sí |
| 3 | Una única confianza unidireccional admitida | Todos | No |
Referencias:
- Proporcione a sus usuarios de Active Directory acceso a sus aplicaciones y servicios de gestión de reclamaciones
https://technet.microsoft.com/en-us/library/dd807071%28WS.10%29.aspx
"Empleados con cuentas de usuario en cualquier lugar de los bosques en los que confía este bosque (a través de una confianza bidireccional de Windows)" - Servicios de federación de Active Directory (AD FS) 2.0
https://technet.microsoft.com/en-us/library/adfs2%28WS.10%29.aspx - InicioRealmDiscoveryPage Descripción general de la clase
https://msdn.microsoft.com/en-us/library/ee895364.aspx
