Wie authentifiziere ich Benutzer in verschachtelten Gruppen in Apache LDAP?

Ich arbeite mit LDAP-Authentifizierung mit dem folgenden Setup

 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

Das funktioniert, aber ich muss alle Benutzer angeben, bei denen ich mich authentifizieren möchte MySpecificGroup. Aber auf LDAP-Server habe ich konfiguriert, dass MySpecificGroupauch die Gruppe MyOtherGroupmit einer anderen Liste von Benutzern enthält.

Diese Benutzer MyOtherGroupsind jedoch nicht authentifiziert. Ich muss sie manuell hinzufügen MySpecificGroupund kann die verschachtelte Gruppierung im Grunde nicht verwenden. Ich verwende Windows SBS 2003.

Gibt es eine Möglichkeit, Apache LDAP dafür zu konfigurieren? Oder gibt es ein Problem mit einer möglichen unendlichen Rekursion und somit nicht erlaubt?

Sie müssen festlegen AuthLDAPSubGroupDepth, damit dies funktioniert. Die hier angegebene Ganzzahl gibt die maximale Schachtelungstiefe für Untergruppen an, die ausgewertet wird, bevor die Benutzersuche abgebrochen wird.

Fügen Sie dies zu Ihrer Konfiguration hinzu:

AuthLDAPSubGroupDepth 1

Mehr Infos: hier und hier .

Außerdem AuthLDAPSubGroupDepthist dies nur in Apache 2.4 verfügbar. Wenn Sie Microsoft AD LDAP verwenden, können Sie die Autorisierung mithilfe verschachtelter Gruppen mithilfe der Übereinstimmungsregel LDAP_MATCHING_RULE_IN_CHAIN ​​durchführen. Dies ist viel schneller als das Durchsuchen von Untergruppen auf dem Client, da dies auf dem DC-Server mit weniger Abfragen über das Netzwerk erfolgt.

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

Die Zeichenfolge 1.2.840.113556.1.4.1941ist eine OID, die aufgerufen wird LDAP_MATCHING_RULE_IN_CHAIN. Diese OID wird von Microsoft zur Verwendung mit der LDAP-Implementierung (Teil von Active Directory) zugewiesen. Sie können es nicht mit anderen LDAP-Servern verwenden. Das vom Menschen redeable Format ist:iso(1).member_body(2).us(840).microsoft(113556).ad(1).as_schema(4).LDAP_MATCHING_RULE_IN_CHAIN(1941)

Aus der Microsoft-Dokumentation:

Diese Regel ist auf Filter beschränkt, die für den DN gelten. Dies ist ein spezieller "erweiterter" Übereinstimmungsoperator, der die Kette von Vorfahren in Objekten bis zum Stamm durchläuft, bis eine Übereinstimmung gefunden wird.

Siehe auch:

• 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

Es sieht so aus, als ob Ihre einzige Option in Apache 2.2 darin besteht, jede Gruppe aufzulisten, die von Ihrer autorisierten Hauptgruppe aufgenommen wurde.

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

Dies sollte sinnvoll sein, wenn Ihre verschachtelten Gruppen nicht zu kompliziert sind.

Crossing AD Domains (mit zwei LDAP-Servern)

Sie können OpenLDAP mit dem Overlay slapd_meta einrichten, das auf Ihrem Webserver ausgeführt wird, um Ihre Authentifizierung als Proxy zu verwenden.

/etc/ldap/slapd.conf sollte ungefähr so ​​aussehen:

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"

Dann würde Ihre Zeilengruppe mod_authnz_ldap ungefähr so ​​aussehen:

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

Dies erfordert einige Massagen, um es zum Laufen zu bringen, aber ich denke, das ist die allgemeine Idee.

Während die von @Mircea_Vutcovici bereitgestellte Lösung für mich funktioniert hat, ist mein einziger Kritikpunkt, dass die Leute möglicherweise zimperlich werden, wenn sie bitweise Operatoren im Einsatz sehen.

Zum Beispiel übergebe ich eine Apache Bloodhound-Installation, die Apache HTTPd als Front-End mit AD-Gruppenauthentifizierung verwendet, an eine Gruppe von Mitentwicklern. Sie werden Probleme mit bitweisen Operatoren haben. Admins werden natürlich nicht so zimperlich sein ... Ich hoffe.

Davon abgesehen habe ich eine Lösung, die nicht den bitweisen Operator verwendet und die nicht mehrere LDAP-Gruppendefinitionen verwendet.

Die folgende Konfiguration funktioniert für mich:

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

Der kritische Teil war die folgende Konfiguration:

AuthLDAPSubGroupClass group

AuthLDAPMaxSubGroupDepth funktioniert weder für sich noch in Verbindung mit AuthLDAPSubgroupAttribute. Erst als ich AuthLDAPSubGroupClass verwendete, funktionierte die Authentifizierung für Untergruppen ... zumindest für mich und meine Situation.