ネストされたグループメンバーシップを抽出するためのLDAP検索フィルターに関する情報が必要です。基本的に、私の考えは、たとえば、ユーザーが5つのグループ[A、B、C、D、E]に属しているということです。単一のLDAP検索クエリを記述して、グループ[A、B、C、 D、E]の一部である可能性がありますか？そして、このlogcを再帰的に使用して、ADの完全なルートまですべてのグループ情報を取得できますか？
また、このソリューションは汎用AD用である必要があるため、MSADでのみ機能するLDAP_RULE_IN_CHAINフィルターを使用できません。
グループは、LDAP標準で定義されているものではありません。LDAPに関する限り、グループエントリは単なるLDAPエントリであり、それ以上のものではありません。ネストされたグループや動的グループなどのデータ構造の処理、クエリ、検証などの方法を含むグループサポートの実装は、ディレクトリソフトウェアベンダーに完全に委ねられています。たとえば、IBMのSecurity Directory Server（SDS）ソフトウェアは、ソフトウェアによって特別に認識される独自のオブジェクトクラスと属性、およびメンバーシップを確認するためのトラバース（ネストされたグループの場合）と拡張（動的グループの場合）を通じて、ネストされた動的グループをサポートします。グループ構造を取得することは、LDAPクライアントに対して自動的に行われます。たとえば、SDSは次のような運用属性を提供しibm-allgroupsますibm-allmembersLDAPクライアントが単一の検索でネストされた動的グループのグループおよびメンバーシップ情報をプルするのを支援します。他のディレクトリベンダーは、同じ問題を異なる方法で解決します。したがって、使用するLDAPソフトウェアによってソリューションは異なります。複数のディレクトリサーバーソフトウェアをサポートするようにアプリケーションを設計できますが、それは、アプリケーションでグループサポートをどの程度高度にするかによって異なります。
ユーザーがネストされたグループを含むメンバーであるすべてのグループ
例として、「CN = John Smith、DC = MyDomain、DC = NET」がメンバーであるすべてのグループを検索するには、ベースをグループコンテナDNに設定します。たとえば、（OU = groupsOU、DC = MyDomain、DC = NET）とサブツリーのスコープを指定し、次のフィルターを使用します。
（メンバー：1.2.840.113556.1.4.1941：=（CN = John Smith、DC = MyDomain、DC = NET））
ここで、CN = John Smith、DC = MyDomain、DC = NETは、ユーザーのFDNおよびExtensible MatchRule1.2.840.113556.1.4.1941です。
-ジム