Web AppのActive DirectoryユーザーロールとUser.IsInRole

私は少しのアドバイスが必要です。 私はADメンバーの役割と統合するためにWebアプリケーションを拡張しているし、User.IsInRoleに依存してメンバーの役割に関する情報を得ることができるかどうかはあまり確かではありません。最初のテストでは私にはわかりましたが、これを使用して、DirectorySearcher/AccountManagementでユーザーロールを返すクラスを作成することとの違いは何ですか?

1つのソリューションは他のソリューションよりも優れていますか?

この場合、同じことが達成されたように見えます。私は正しい?

ありがとう。

2

2 答え

アクティブディレクトリ許可を使用する場合、 Users.IsInRole は、ユーザーが指定されたグループのメンバーであるかどうかを確認します。 直接メンバーシップしか与えられないので、ユーザーが所属するグループをチェックするのとまったく同じではありません。 Users.IsInRole はネストされたグループメンバシップもチェックします。例:

  • UserA is a member of GroupA
  • GroupA is a member of GroupB

UserA の直接メンバーシップを確認すると、 GroupA のみが表示されます。しかし、 User.IsInRole は、ネストすることによって UserA GroupB のメンバーであることを示します。

4
追加された
実際には、新しい System.DirectoryServices.AccountManagement 名前空間(優れた記事を読んで UserPrincipal.GetGroups()を呼び出すと、ユーザーのネストされたメンバーシップをも返す
追加された 著者 marc_s,
PrinciplePermission または PrincipalPermissionAttribute を使用すると、アクセスを制御する最も簡単な方法です。また、基盤となるアイデンティティプロバイダとは完全に独立しているため、コードはWindowsアカウントでも動作します。 ASP.Netメンバシッププロバイダ。
追加された 著者 Anders Abel,
私はあなたが言っていることを見ています...私の思うところによると、意味があり、有効なポイントです。ユーザー.IsInRole
追加された 著者 TheITGuy,
もう少し調べてみたら、PrinciplePermissionとDemandを使ってメソッドの機能を保護しています。素晴らしい情報をありがとう。
追加された 著者 TheITGuy,

Users.IsInRoleを使用してください。物事を自分で難しくしないでください。これがそのためのものです。

0
追加された
IsInRoleは役割名のスペースを処理しません。すなわち「試験グループ」
追加された 著者 John S,