4

私が使用しているADセットアップには、（複数の）セキュリティグループのメンバーとして保存されているユーザーがいます。

ユーザーのmemberofプロパティを読み取って、アクセス許可を取得するソフトウェアを使用しています。

AD Explorerで、ユーザーのmemberofプロパティが、「コース-英語」と言って所属する直接のセキュリティグループを示していることがわかります。「すべての生徒」と表示されるようにネストされた親グループは表示されません。

これには理由がありますか、それともすべてのネストされたグループがmemberofプロパティに表示されるようにする方法がありますか？

4

2 に答える 2

5

.NET 3.5以降を使用している場合は、System.DirectoryServices.AccountManagement（S.DS.AM）名前空間を確認する必要があります。ここでそれについてすべて読んでください：

基本的に、ドメインコンテキストを定義して、AD内のユーザーやグループを簡単に見つけることができます。

// set up domain context
PrincipalContext ctx = new PrincipalContext(ContextType.Domain);

// find a user
UserPrincipal user = UserPrincipal.FindByIdentity(ctx, "SomeUserName");

if(user != null)
{
   var groups = user.GetAuthorizationGroups();

   // enumerate over groups
   foreach(GroupPrincipal gp in groups)
   {
      // do something here....
   }
}

新しいS.DS.AMを使用すると、ADのユーザーやグループを簡単に操作できます。

この.GetAuthorizationGroups()方法は、再帰検索を実行することを私が知っている唯一の方法です。たとえば、別のグループによってユーザーがメンバーになっているグループを検索します。.NET 3.5より前のDirectoryServicesものはこれを行いません-それが必要な場合は、完全に自分でロールする必要があります。

于 2012-08-20T17:05:28.057 に答える
5

属性にネストされたグループ情報がすべて含まれていない可能性のある理由は、次のリンクmemberOfに示されているように、属性がロードされたときに値が計算されるためです。

この属性には、メンバー属性にユーザーが含まれているグループがリストされていることに注意してください。ネストされた先行オブジェクトの再帰的なリストは含まれていません。たとえば、ユーザーOがグループCのメンバーであり、グループBとグループBがグループAにネストされている場合、ユーザーOのmemberOf属性はグループCとグループBをリストしますが、グループAはリストしません。

この属性は保存されません—計算された被リンク属性です。

したがって、これをサポートするために、LDAPクエリが属性を返すたびに、DCはすべてのネストされたグループをロードするように強制されますmemberOf。これは、多くの余分な作業になる可能性があります。

使用しているテクノロジーによっては、すべてのグループをロードしてすべてを一覧表示するよりも、グループのメンバーシップを確認するためのより良い方法がほぼ確実にあります。たとえば、 ADSIには、ユーザーがグループのメンバーであるかどうかを確認するための事前に作成された関数があります。

ただし、純粋なLDAPソリューションの場合は、この回答LDAP_MATCHING_RULE_IN_CHAINに示されているように（ユーザーのDNがあると仮定して）、たとえば、を使用できます。

(member:1.2.840.113556.1.4.1941:=CN=Administrator,OU=Users,DC=fabrikam,DC=com)

これにより、Administratorがメンバーになっているすべてのグループが取得されます。ただし、このクエリは非常に遅くなる可能性があることに注意してください。パフォーマンスを高速化するには、結果をページングするか、検索ベースをチェックしたいグループのみに制限することを検討してください。

于 2012-08-20T17:05:57.993 に答える