web-dev-qa-db-ja.com

Apache LDAPのネストされたグループのユーザーを認証する方法は?

次の設定でLDAP認証を使用しています

 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

これは機能しますが、認証したいすべてのユーザーをMySpecificGroupに入れなければなりません。しかし、LDAPサーバーでは、MySpecificGroupに別のユーザーのリストを含むグループMyOtherGroupも含まれるように設定しました。

しかし、MyOtherGroupのユーザーは認証されていません。手動ですべてをMySpecificGroupに追加する必要があり、基本的にネストされたグループを使用できません。 Windows SBS 2003を使用しています。

これを行うようにApache LDAPを構成する方法はありますか?または、無限再帰の可能性があるために許可されない問題がありますか?

21
mark

これを機能させるには、AuthLDAPSubGroupDepthを設定する必要があります。ここで指定する整数は、ユーザー検索が中止される前に評価されるサブグループのネストの最大深度を指定します。

これを設定に追加してください:

AuthLDAPSubGroupDepth 1

詳細: ここ および ここ

19
Bart De Vos

Apache 2.4でのみ利用可能なAuthLDAPSubGroupDepthに加えて、Microsoft AD LDAPを使用している場合、LDAP_MATCHING_RULE_IN_CHAINマッチングルールを使用することで、ネストされたグループを使用して認証を行うことができます。これは、DCサーバー上でネットワーク経由のクエリを減らして実行されるため、クライアントでサブグループを検索するよりもはるかに高速です。

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

文字列_1.2.840.113556.1.4.1941_は、_LDAP_MATCHING_RULE_IN_CHAIN_と呼ばれる [〜#〜] oid [〜#〜] です。これは、OIDは、LDAP実装(Active Directoryの一部)で使用するためにMicrosoftによって割り当てられます。他のLDAPサーバーでは使用できません。人間が再利用できる形式は次のとおりです:iso(1).member_body(2).us(840).Microsoft(113556).ad(1).as_schema(4).LDAP_MATCHING_RULE_IN_CHAIN(1941)

Microsoftのドキュメントから:

このルールは、DNに適用されるフィルターに限定されます。これは、特別な「拡張」一致演算子であり、一致するものが見つかるまで、オブジェクトの祖先のチェーンをルートまでたどります。

以下も参照してください。

34

Apache 2.2での唯一の選択肢は、メインの承認済みグループに含まれるすべてのグループをリストすることです。

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

ネストされたグループがそれほど複雑でない場合、これは妥当なはずです。


ADドメインのクロス(2つのLDAPサーバーを使用)

認証をプロキシするWebサーバーで実行されている slapd_meta オーバーレイを使用してOpenLDAPを設定できます。

/etc/ldap/slapd.confは次のようになります。

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"

次に、mod_authnz_ldapスタンザは次のようになります。

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

これを機能させるにはマッサージが必要ですが、これは一般的な考えです。

7
Jeff Strunk

@Mircea_Vutcoviciによって提供されたソリューションは私にとってはうまくいきましたが、私の唯一の批判は、ビット単位の演算子が使用されているのを見ていると人々がきしむかもしれないということです。

たとえば、Apache HTTPdをフロントエンドとしてADグループ認証を使用するApache Bloodhoundインストールを、仲間の開発者のグループに渡します。彼らはビットごとの演算子とのグリップに来る問題を抱えることになるでしょう。もちろん、管理者はきしむようなことはありません...私は願っています。

そうは言っても、ビットワイズ演算子を使用せず、複数のLDAPグループ定義を使用しないソリューションがあります。

次の設定は私のために働きます:

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

重要な部分は次の構成でした:

AuthLDAPSubGroupClass group

AuthLDAPMaxSubGroupDepthは、それ自体では機能せず、AuthLDAPSubgroupAttributeと組み合わせても機能しません。サブグループに対する認証が機能し始めたのは、AuthLDAPSubGroupClassを使用したときだけでした...少なくとも私と私の状況では。

4
Chris Harris