Comment authentifier les utilisateurs dans des groupes imbriqués dans Apache LDAP?

21

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é?

apache-2.2 ldap groups

— marque
source

19

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 .

— Bart De Vos
source

J'utilise apache 2.2, c'est mod_authnz_ldap n'a pas de directive AuthLDAPSubGroupDepth: httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html

— Selivanov Pavel

Alors, pourquoi ne pas mettre à jour?

— Bart De Vos

2

J'utilise Debian Squeeze et je préfère utiliser des paquets de distribution stable: mises à jour de sécurité régulières et bien testées. Apache 2.3 est toujours en version bêta, il apparaîtra bientôt dans stable ou stable-backports. J'ai résolu ce problème en utilisant AuthnProviderAliaspour l'instant. Si personne ne propose de solution pour Apache 2.2, la prime vous appartient :)

— Selivanov Pavel

étant donné les nouvelles informations des groupes étant sur des serveurs différents, je ne pense pas que cette méthode fonctionnera toujours.

— Jeff Strunk

3

AuthLDAPSubGroupDepth n'existe pas dans Apache HTTPd 2.4. AuthLDAPMaxSubGroupDepth est la bonne directive à utiliser.

— Chris Harris

33

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:

— Mircea Vutcovici
source

Je voterais pour ce 10x si je le pouvais. Pour les personnes exécutant RHEL 5, c'est une excellente solution. Compiler la source du fournisseur pour obtenir les dernières fonctionnalités n'est pas toujours une solution souhaitable!

— Aaron Copley

Je suis content que cela ait aidé. Je pense que c'était la première utilisation documentée de LDAP_MATCHING_RULE_IN_CHAIN dans apache.

— Mircea Vutcovici

Existe-t-il un moyen d'utiliser LDAP_MATCHING_RULE_IN_CHAINpour récupérer l'appartenance à un groupe récursif et le passer en tant qu'en-tête à un serveur principal (en utilisant Apache comme proxy inverse) ??

— Gershon Papi

mod_authnz_ldapne fournit pas cela. Cependant, vous pouvez utiliser le LDAP_MATCHING_RULE_IN_CHAINfiltre LDAP dans votre application. Voir: stackoverflow.com/a/34075052/290087

— Mircea Vutcovici

6

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.

— Jeff Strunk
source

1

Malheureusement, cela ne fonctionne pas lorsque les groupes se trouvent dans différents domaines AD (Domain1_DomainLocal_Group inclut Domain2_Global_Group). C'était la première chose que j'essayais :)

— Selivanov Pavel

Est-ce à dire que l'un des groupes se trouve sur un serveur différent? Si c'est vrai, je soupçonne que AuthLDAPSubGroupDepth ne fonctionnera pas pour vous non plus.

— Jeff Strunk

Oui, deux serveurs, deux domaines. J'ai envisagé d'intégrer Linux box dans AD et d'utiliser l'authentification PAM, mais mod-auth-pam n'est pas pris en charge car apache 2.0, mod-authnz-external + pwauth ne prend pas en charge les groupes. Tout cela est malheureusement :(

— Selivanov Pavel

1

Oh, je n'ai pas remarqué que vous avez mis à jour la réponse. L'utilisation d'OpenLDAP slapd_meta peut être une solution, mais elle tue le point principal de cette configuration: obtenir des droits d'utilisateur gérés en un seul point (Active Directory) en ajoutant / supprimant des utilisateurs de groupes et en incluant des groupes les uns dans les autres. Voici ma solution analogique avec AuthnProviderAlias sans service OpenLDAP supplémentaire: <AuthnProviderAlias ldap first-ldap> AuthLDAPURL ... </AuthnProviderAlias> <AuthnProviderAlias ldap second-ldap> AuthLDAPURL ... </AuthnProviderAlias> ... AuthBasic en premier -ldap

— Selivanov Pavel

1

J'ai décidé de faire plaisir à Bart De Vos: ce n'est pas ma question; pour une question originale (sans les miennes) sa solution est simple et fonctionnera

— Selivanov Pavel

4

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.

— Chris Harris
source