active-directory - permisos - sacar un reporte de usuarios de active directory
¿Cómo usar un filtro para evitar una OU secundaria en Active Directory? (5)
AFAICT, esto no se puede hacer con un filtro LDAP en el directorio activo. Muchas otras implementaciones de LDAP admiten la concordancia extensible, pero AD no lo hace.
Los usuarios que recomiendan filtros que contienen ( ou:dn:=Evil ) o comodines en distinguishedName no han probado con Active Directory.
Tengo una aplicación que extrae información de usuario de una OU en Active Directory. Los parámetros que toma son una base para la búsqueda y una cadena de filtro.
Tengo una OU de la que quiero extraer información, pero hay una sub OU que quiero evitar:
Querido
usuarios de OU=People,DC=mydomain,DC=com
No deseado
usuarios de OU=Evil,OU=People,DC=mydomain,DC=com
Sé que esto podría hacerse reescribiendo la aplicación que realiza la importación para detener la búsqueda de sub-OUs, pero ¿hay alguna forma de hacerlo con un filtro LDAP en la búsqueda? Algo como ( DistinguishedName !contains "Evil" ) o similar que me permitirá excluir a los usuarios según la ruta de acceso al usuario, en lugar de filtrar una propiedad del usuario.
De acuerdo con http://www.zytrax.com/books/ldap/apa/component.html , es posible obtener lo que desea mediante los filtros de componentes LDAP. Aquí hay un ejemplo que podría coincidir con lo que usted describe:
(&(objectClass=organizationalUnit)(!(ou:dn:=Evil)))
Esto coincide con todos los objetos que tienen un objectClass de organizationUnit, pero rechaza cualquier elemento cuyo DN contenga un componente que coincida con ou = Evil.
La unidad organizationalUnit objectClasses y su descendiente inetOrgPerson permiten que el atributo ou esté presente en una entrada. Agregue un atributo ou con valor evil a los objetos subordinados a la rama ou=evil e incluya la aserción (!(ou=evil)) al filtro de búsqueda para limitar las respuestas de la lista de candidatos a aquellas que no contienen un atributo ou con El valor del evil . Alternativamente, el control de aserción de LDAP podría usarse en las solicitudes de la misma manera para garantizar que las solicitudes que contienen una ou con el valor evil no se procesen. Los servidores de directorio de calidad profesional que son compatibles con LDAP admitirán ambos métodos.
Lo siguiente hará el truco:
(&(objectClass=user)(!(distinguishedName:=%Evil%)))
Me encontré con un problema similar al crear una libreta de direcciones para escanear a correo electrónico. Probé (&(objectClass=user)(!(distinguishedName:=*Evil*))) pero parece que algunos dispositivos multifunción no aceptan * como comodín, pero aceptan %
Si está utilizando System.DirectoryServices ( .Protocols ) en .NET, puede configurar SearchScope en OneLevel para que solo busque en la OU de personas (y no en las unidades organizativas secundarias). Pero eso no funcionará si tienes alguna OU=Good,OU=People,DC=mydomain,DC=com ...
La segunda opción sería consultar a la OU de personas para todas las OU sub: s ( objectClass=organizationalUnit ) y luego emitir varias solicitudes de búsqueda; uno para cada uno de ellos (excepto el "malvado").
Edit: @geoffc - eso será muy difícil de implementar. De forma predeterminada, todos los usuarios autenticados tienen acceso de lectura a todos los objetos en Active Directory. El solo hecho de establecer una "Denegación de lectura" en la OU Evil no funcionará porque la lectura correcta para usuarios autenticados se establece en el objeto de usuario individual (en este caso) y, por lo tanto, tiene prioridad sobre la ACL de denegación establecida en la OU. Básicamente, deberá configurar la ACL de lectura denegada en cada uno de los objetos en Evil-OU y siempre asegurarse de que los nuevos objetos agregados al directorio obtengan el mismo conjunto de derechos de denegación. Puede editar el esquema de Active Directory y eliminar los derechos de los usuarios autenticados, pero eso romperá muchas otras cosas (incluido Exchange) y no es compatible con Microsoft.