Comment authentifier les utilisateurs dans des groupes imbriqués 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 utilisateurs dans lesquels je veux m'authentifier MySpecificGroup. Mais sur le serveur LDAP, j'ai configuré qui MySpecificGroupcontient également le groupe MyOtherGroupavec une autre liste d'utilisateurs.

Mais ces utilisateurs MyOtherGroupne sont pas authentifiés, je dois tous les ajouter manuellement et je MySpecificGroupne peux pas utiliser le regroupement imbriqué. J'utilise Windows SBS 2003.

Existe-t-il un moyen de configurer Apache LDAP pour ce faire? Ou y a-t-il un problème avec une possible récursion infinie et donc non autorisé?

Vous devez configurer AuthLDAPSubGroupDepthpour que cela fonctionne. L'entier que vous fournissez ici spécifie la profondeur d'imbrication maximale des sous-groupes qui sera évaluée avant l'arrêt de la recherche d'utilisateurs.

Ajoutez ceci à votre configuration:

AuthLDAPSubGroupDepth 1

Plus d'infos: ici et ici .

En outre AuthLDAPSubGroupDepth, qui n'est disponible que dans apache 2.4, il est possible, lors de l'utilisation de Microsoft AD LDAP, de faire une autorisation à l'aide de groupes imbriqués à l'aide de la règle de correspondance LDAP_MATCHING_RULE_IN_CHAIN. Ceci est beaucoup plus rapide que la recherche de sous-groupes sur le client, car cela se fait sur le serveur DC avec moins 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 chaîne 1.2.840.113556.1.4.1941est un OID appelé LDAP_MATCHING_RULE_IN_CHAIN. Cet OID est attribué par Microsoft pour être utilisé avec son implémentation LDAP (partie d'Active Directory). Vous ne pouvez pas l'utiliser avec d'autres serveurs LDAP. Le format réductible 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 filtres qui s'appliquent au DN. Il s'agit d'un opérateur de correspondance "étendu" spécial qui parcourt la chaîne d'ascendance des objets jusqu'à la racine jusqu'à ce qu'il trouve une correspondance.

Voir également:

• http://msdn.microsoft.com/en-us/library/windows/desktop/aa746475%28v=vs.85%29.aspx
• http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html#authorphase

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

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 imbriqués ne sont pas trop compliqués.

Traversée des domaines AD (à l'aide de deux serveurs LDAP)

Vous pouvez configurer OpenLDAP avec la superposition slapd_meta exécutée sur votre serveur Web pour proxy votre authentification.

/etc/ldap/slapd.conf devrait ressembler à:

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 à quelque chose comme:

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 un certain massage pour le faire fonctionner, mais je pense que c'est l'idée générale.

Bien que la solution fournie par @Mircea_Vutcovici ait fonctionné pour moi, ma seule critique est que les gens peuvent devenir délicats lorsqu'ils voient des opérateurs au niveau du bit utilisés.

Par exemple, je remettrai une installation Apache Bloodhound, qui utilise Apache HTTPd comme frontal avec l'authentification du groupe AD, à un groupe de collègues développeurs. Ils vont avoir des problèmes à gérer avec les opérateurs au niveau du bit. Les administrateurs ne seront pas aussi délicats bien sûr ... j'espère.

Cela étant dit, j'ai une solution qui n'utilise pas l'opérateur au niveau du 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
    AuthLDAPSubgroupAttribute member
    AuthLDAPSubGroupClass group
    AuthLDAPGroupAttribute member
    AuthLDAPGroupAttributeIsDN on
</Location>

La partie critique était la configuration suivante:

AuthLDAPSubGroupClass group

AuthLDAPMaxSubGroupDepth ne fonctionne pas par lui-même, ni lorsqu'il est couplé avec AuthLDAPSubgroupAttribute. Ce n'est que lorsque j'ai utilisé AuthLDAPSubGroupClass que l'authentification contre les sous-groupes a commencé à fonctionner ... au moins pour moi et ma situation.