2009-08-24 9 views
1

C#でADオブジェクトにアクセスする際に問題があります。コードの目的は、ユーザーのグループを取得することです。アプリケーションと多数のユーザーが常駐するドメインとユーザーを含む信頼できるドメインの2つのドメインがあり、コードは両方のドメインからグループを取得できる必要があります。コードでADを検索できません

私はDirectorySearcherオブジェクトを使用しており、ユーザーSIDに基づいてフィルタリングしています。アプリケーションによって使用されるDLLにパッケージ化されています。アプリケーションは現在、同じコードを使用して動作しますが、DLLを呼び出すとDLLはADから何も返しません。 FindOne()呼び出しからユーザーを取得することはできません。

ドメインを1つしか持っていないときにユーザーの検索を使用すると、同じ問題が発生しましたが、回避策が見つかりました。ユーザーオブジェクトを直接開くことができ、オブジェクトを検索できませんでした。 2番目のドメインが関与したので、ユーザーのSIDを使用する必要があり、オブジェクトを開くだけではなりません。

DLLは1つのテスト環境で動作しますが、他の2つのテスト環境では動作しません。このタイプの行動を引き起こす原因は何ですか?これはDLLの問題ですか? ADセキュリティ?アプリケーションのセキュリティ?ユーザーが検索にアクセスできるかどうかはどのように判断するのですか?

(この問題の解決策が見つからない場合)検索を使用せずにSIDに基づいてユーザーのグループを取得するにはどうすればよいですか?

+0

これは.net 2.0とサーバー2003 –

答えて

2

.NET 3.5をお使いですか?グループ管理とユーザー管理(「プリンシパル管理」)の広告は、3.5で大幅に改善されました。

非常に参考になる新しいSystem.DirectoryServices.AccountManagement名前空間があります。Ethan WilanskyとJoe Kaplanの記事でhere on MSDN Magazineの記事をすべて読んでください。

最終的に.NET 3.5のものは、ユーザーのグループを簡単にプログラムで取得し、ユーザーのプライマリグループとネストされたグループメンバーシップを含めることができます。

は、.NET 3.5上にある場合、あなたはこのようなコードを使用することができます:

using(PrincipalContext ctx = new PrincipalContext(ContextType.Domain)) 
{ 
    using(p = Principal.FindByIdentity(ctx, "yourUserName")) 
    { 
     var groups = p.GetGroups(); 

     using (groups) 
     { 
      foreach (Principal group in groups) 
      { 
       Console.WriteLine(group.SamAccountName + "-" + group.DisplayName); 
      } 
     } 
    } 
} 

S.AD.AMもプリンシパル(ユーザー、グループ、コンピュータを検索するために「校長」クラスに新しいメソッドが含まれてい)を様々な検索基準、例えば名前で、SID、GUID:

FindByIdentityは見つけることPrincipalContext と値を取り、どちらも2つのオーバーロード、 が含まれています。値の場合、 は、サポートされている のIDタイプ(SamAccountName、Name、 、UserPrincipalName、DistinguishedName、 Sid、またはGuid)のいずれかを指定できます。

かなりきれいですか? :-)

マルク・

+0

すごくいいですね。これはユーザー/グループの情報を取得する古い方法よりも良い方法です – Alan

+0

それは確かにです! .NET 3.5にアップグレードする時間? :-) –

+0

それは偉大なように聞こえる...一度我々は3.5にアップグレード!アプリケーションはまだ2.0です...私たちもそうです。 –

0

総称的には、System.DirectoryServicesがどのように動作するか変更されませんDLLを使用して、話します。私はADを検索するプラグインアセンブリのアプローチを使用して、それは実際のアセンブリ自体を実行するのと同じように動作します。

いくつかの光を当てるかもしれません(あなたがあなた自身に尋ねる必要があります)いくつかの質問があります。

  1. は、テストが同じ環境ですか? 同じ機能ドメインレベル (Win2000、Win2003など)、同じ信頼 の設定? ( DirectoryEntryオブジェクトを作成するとき、すなわち、あなた は、資格情報を供給している)
  2. は コードドメインを実行しているマシンが参加しましたか? 1.ドメインを検索するために使用するアカウントは、ドメイン間の信頼関係を持つ ですか。
  3. ドメインは親/子の の関係に設定されていますか?
  4. ドメインをsAMAccountNameまたは UPNで検索するとどうなりますか?
  5. DirectorySearchのパラメータを に設定して、他のドメインを自動的に検索していますか?

これをデバッグするにはいくつかの方法があります。

FindOneが何も返さない(例外がスローされない)場合、FindOneは条件に一致する結果を見つけられないことを伝えます。

FindOneは例外(通常はComException)をスローしています。comexceptionエラーコードを使用して何が起きているかを調べることができます。

WireSharkを起動し、無効にし、封印して保護し、アプリケーションからパケットを傍受することができます。検索結果に対するLDAPの応答が表示されます。

+0

例外はスローされません。0グループのみを返します。 失敗した2つは同じように設定されている可能性があります。 3つのenvはすべて2003年の機能レベルです。 sAMAccountNameを検索することはできません。これは、コードを変更してもはや検索しないうちに元々持っていた問題です。 –

+0

同じWindowsIdentityアプリケーションとDLL間の現在の名前 –

関連する問題