Comment authentifier les users dans les groupes nesteds dans Apache LDAP?

J'ai travaillé l'authentification LDAP avec la configuration suivante

AuthName "whatever" AuthType Basic AuthBasicProvider ldap AuthLDAPUrl "ldap://server/OU=SBSUsers,OU=Users,OU=MyBusiness,DC=company,DC=local?sAMAccountName?sub?(objectClass=*)" Require ldap-group CN=MySpecificGroup,OU=Security Groups,OU=MyBusiness,DC=company,DC=local 

Cela fonctionne, mais je dois mettre tous les users que je veux authentifier dans MySpecificGroup . Mais sur le server LDAP, j'ai configuré que MySpecificGroup contient également le groupe MyOtherGroup avec une autre list d'users.

Mais ces users dans MyOtherGroup ne sont pas authentifiés, je dois les append manuellement à MySpecificGroup et MySpecificGroup ne peux essentiellement pas utiliser le groupement nested. J'utilise Windows SBS 2003.

Existe-t-il un moyen de configurer Apache LDAP pour le faire? Ou y a-t-il un problème avec une possible recursion infinie et donc pas autorisé?

Vous devez définir AuthLDAPSubGroupDepth pour que cela fonctionne. L'entier que vous fournissez ici spécifie la profondeur d'imbrication maximale du sous-groupe qui sera évaluée avant que la search de l'user ne soit interrompue.

Ajoutez ceci à votre configuration:

 AuthLDAPSubGroupDepth 1 

Plus d'infos: ici et ici .

Outre AuthLDAPSubGroupDepth , disponible uniquement dans apache 2.4, il est possible, lors de l'utilisation de Microsoft AD LDAP, de faire une autorisation en utilisant des groupes nesteds en utilisant LDAP_MATCHING_RULE_IN_CHAIN ​​correspondant à la règle. Ceci est beaucoup plus rapide que la search de sous-groupes sur le client, car il se fait sur le server DC avec less de requêtes sur le réseau.

 Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=Access to Apache,OU=My Organization Unit,DC=company,DC=com 

La string 1.2.840.113556.1.4.1941 est un OID appelé LDAP_MATCHING_RULE_IN_CHAIN . Cet OID est atsortingbué par Microsoft pour être utilisé avec sa mise en œuvre LDAP (partie d'Active Directory). Vous ne pouvez pas l'utiliser avec d'autres servers LDAP. Le format redéfinible humain est: iso(1).member_body(2).us(840).microsoft(113556).ad(1).as_schema(4).LDAP_MATCHING_RULE_IN_CHAIN(1941)

De la documentation Microsoft:

Cette règle est limitée aux filters qui s'appliquent au DN. Il s'agit d'un opérateur de correspondance "étendu" spécial qui parcourt la string d'ascendance dans les objects jusqu'à la racine jusqu'à ce qu'il trouve une correspondance.

Voir également:

Il semble que votre seule option dans Apache 2.2 consiste à énumérer tous les groupes inclus dans votre groupe principal autorisé.

 Require ldap-group CN=MySpecificGroup,OU=Security Groups,OU=MyBusiness,DC=company,DC=local Require ldap-group CN=MyOtherGroup,OU=Security Groups,OU=MyBusiness,DC=company,DC=local 

Cela devrait être raisonnable si vos groupes nesteds ne sont pas trop compliqués.


Traversant des domaines AD (utilisant deux servers LDAP)

Vous pouvez configurer OpenLDAP avec la superposition slapd_meta exécutée sur votre server Web pour transférer votre authentification.

/etc/ldap/slapd.conf devrait ressembler à quelque chose comme:

 database meta suffix "DC=company,DC=local" uri "ldap://a.foo.com/OU=MyBusiness,DC=company,DC=local" uri "ldap://b.foo.com/OU=otherdomainsuffix,DC=company,DC=local" 

Ensuite, votre strophe mod_authnz_ldap ressemblerait à:

 AuthName "whatever" AuthType Basic AuthBasicProvider ldap AuthLDAPUrl "ldapi:///DC=company,DC=local?sAMAccountName?sub?(objectClass=*)" Require ldap-group CN=MySpecificGroup,OU=Security Groups,OU=MyBusiness,DC=company,DC=local Require ldap-group CN=MyOtherGroup,OU=Security Groups,OU=otherdomainsuffix,DC=company,DC=local 

Cela nécessitera des massages pour le faire fonctionner, mais je pense que c'est l'idée générale.

Alors que la solution fournie par @Mircea_Vutcovici a fonctionné pour moi, ma seule critique est que les gens peuvent se sentir plus clairs lorsqu'ils voient des opérateurs bit à bit en cours d'utilisation.

Par exemple, je vais remettre une installation Apache Bloodhound, qui utilise Apache HTTPd comme front end avec AD de groupe AD, à un groupe de développeurs. Ils auront des problèmes pour s'attaquer aux opérateurs bit à bit. Les administrateurs ne seront pas aussi clairs, bien sûr … J'espère.

Cela dit, j'ai une solution qui n'utilise pas l'opérateur bit à bit et qui n'utilise pas plusieurs définitions de groupe ldap.

La configuration suivante fonctionne pour moi:

 <Location /protected> # Using this to bind AuthLDAPURL "ldap://<MY_SERVER>:3268/<MY_SEARCH_BASE>?sAMAccountName?sub?(objectClass=user)" AuthLDAPBindDN "<MY_BIND_DN>" AuthLDAPBindPassword "<MY_PASSWORD>" LDAPReferrals Off AuthType Basic AuthName "USE YOUR AD ACCOUNT" AuthBasicProvider ldap Require ldap-group <MY_PARENT_GROUP> AuthLDAPMaxSubGroupDepth 1 AuthLDAPSubgroupAtsortingbute member AuthLDAPSubGroupClass group AuthLDAPGroupAtsortingbute member AuthLDAPGroupAtsortingbuteIsDN on </Location> 

La partie critique était la configuration suivante:

 AuthLDAPSubGroupClass group 

AuthLDAPMaxSubGroupDepth ne fonctionne pas seul, ni lorsqu'il est associé à AuthLDAPSubgroupAtsortingbute. Ce n'est que lorsque j'ai utilisé AuthLDAPSubGroupClass que les authirus sous-groupes ont commencé à fonctionner … au less pour moi et pour ma situation.