autenticación LDAP de usuario en dominios de confianza

Question

Mi aplicación define los usuarios autorizados a través de LDAP (por lo general de Active Directory):

1. El cliente define un servidor LDAP (TreeA) y un grupo (GrupoA). Cualquier usuario en GroupA puede usar la aplicación.
2. A la hora de inicio de sesión, un usuario envía su nombre de usuario y contraseña - si un aprieto a la TreeA LDAP con sus credenciales de obras, y su cuenta de usuario se encuentra en una GrupoA, que son buenos para ir

I' hemos encontrado una situación en la que dos Directorios Activos confían entre sí, y el Grupo A especificado en TreeA contiene usuarios de TreeB. Así que el paso # 2 falla porque estoy tratando de autenticar UserB (desde TreeB) contra TreeA.

La aplicación tiene acceso a TreeA, por lo que supongo que podría verse en GroupA y ver UserB allí. Pero, ¿cómo sabría que necesita enviar solicitudes de vinculación a TreeB para autenticar el nombre de usuario y la contraseña?

¿Hay una mejor manera de abordar esto?
¿Deberían esas solicitudes de enlace a TreeA automágicamente reenviarse a TreeB ya que existe una relación de confianza?

Answer 1

Puede ser que tenga un problema de configuración en el servidor LDAP (TreeA). Usted escribió que hay confianza entre TreeA y TreeB, de modo que puede agregar UserB (de TreeB) como el miembro del GroupA en TreeA. Si puede hacer esto, entonces habrá logrado establecer confianza en la dirección correcta entre TreeA y TreeB. Debe comprender que esa confianza significa únicamente que Active Directory B verifique solo la contraseña del usuario, pero UserB por defecto no tendrá acceso a ningún recurso del Active Directory A. El usuario UserB no tiene permiso para hacer que LDAP se enlace al servidor A. En el caso, el problema se resolverá otorgando al usuario B el permiso de inicio de sesión remoto en el servidor A y el acceso de lectura a GroupA y probablemente lea el permiso para la OU donde exista GroupA. Puede probar Insight for Active Directory para monitorear el acceso de AD para localizar los problemas de permisos.

Otra posible razón de su problema podría ser el uso de la API que utiliza para acceder a LDAP. En tu pregunta, no escribiste ninguna información sobre la API. ¿Utiliza Win32 API como ldap_bind_s o usa DirectoryEntry en .NET? En ambos casos, puede ser importante que utilice explícitamente el nombre de dominio junto con el nombre de la cuenta (para el Usuario B) durante el enlace o use null para el nombre y la contraseña de la credencial de usuario actual del usuario.

El uso de la cuenta fija de TreeA para todos los accesos a TreeA (también para pruebas sobre UserB) también podría resolver el problema, pero podría ser posible solo algún tipo de uso de la aplicación.

De cualquier forma, más información en su pregunta podría reducir el problema y las formas de resolver el problema.

Answer 2

Quizás debería usar la replicación de ldap para que los objetos estén siempre presentes en ambos servidores?

Answer 3

La aplicación tiene acceso a TreeA, así que supongo que podría buscar en GrupoA y ver el usuario b allí. Pero, ¿cómo podría saber que debe enviar solicitudes de vinculación a TreeB para autenticar el nombre de usuario y la contraseña?

El atributo member en GrupoA dará el nombre completo (DN) de cada miembro, lo que podría ser algo como:

member: CN=User1,OU=People,DC=TreeA,DC=foobar,DC=com 
member: CN=User2,OU=People,DC=TreeB,DC=foobar,DC=com 

Por lo tanto, cuando los intentos 'Usuario2' autenticarse, podría coincidir el CN ​​y sabe que debe autenticarse contra 'TreeB' en lugar de 'TreeA'. (Es de suponer que tendrías algún tipo de tabla asignando el DN al nombre de host del servidor AD.) O bien, simplemente fuerza bruta e intenta con 'TreeB' si obtienes un 'no such user' desde 'TreeA'.

Debería tomar una decisión sobre cómo manejar el caso de nombres de usuario duplicados en los dos árboles: ¿uno tiene prioridad sobre el otro?

Otro enfoque sería exigir a los usuarios que especifiquen en qué árbol se están autenticando, por ejemplo, iniciando sesión con un nombre de usuario como 'user1@treea.foobar.com'.

Answer 4

Digamos que usted tiene dominio A y el dominio B que confiar entre sí, y si desea autenticar el usuario B del Dominio B contra el dominio A en el servidor A del Dominio A así que lo que tienes que hacer es:

1. Suplantar al usuario B en el dominio A mediante las API de Win32.

2. Autentica el usuario B contra el dominio A usando DirectoryEntry, luego puede acceder al AD del Dominio A para obtener información sobre otros usuarios, como los grupos asignados.

Lo he implementado en una aplicación ASP.NET que utiliza la autenticación de Windows.

Espero que ayude,