Getting a list of roles

[ECUnited]

This may have been answered in a previous post, and if so, please excuse my redundancy. I am using Windows authentication and I know about the IsInRole check, but I need to obtain a list of roles that each user is in. How is the most simple way to do that? What I need to do is to evaluate each user's role(s) against a role assigned to a record in SQL Server, in order to display or not display an item in a web page. Any help would be greatly appreciated

[Joe Kaplan \(MVP - ADSI\)]

There is a hack you can do using reflection on the priate _GetRoles() method
on WindowsIdentity to get the array of strings containing the actual Windows
groups name that IsInRole uses under the hood. However, that would be a bad
idea to use in production as reflecting on private members is not a good
idea and may leave you stranded on a future version of the framework.

You could also try to look up the groups using System.DirectoryServices and
expanding a user's tokenGroups AD attribute to get their group membership,
but this tricky and will miss some of the other SIDs that Windows adds to
the token such as Authenticated Users and such.

Another idea would be to just loop through your roles in SQL and call
IsInRole on each one so get a mapping. That is probably the easiest way to
go. Also, you could potentially do that only once and cache the results if
that is an expensive operation.

HTH,

Joe K.

"ECUnited" <anonymous@discussions.microsoft.com> wrote in message
news:3DBE3084-7631-49B0-B84B-B6B6C2D73140@microsoft.com...

> This may have been answered in a previous post, and if so, please excuse

my redundancy. I am using Windows authentication and I know about the
IsInRole check, but I need to obtain a list of roles that each user is in.
How is the most simple way to do that? What I need to do is to evaluate
each user's role(s) against a role assigned to a record in SQL Server, in
order to display or not display an item in a web page. Any help would be
greatly appreciated.

>
>

[jzhu]

This can be obtained from the token already built by Windows for the current user, by using a Win32 API (i.e., GetTokenInformation). I posted an answer to a similar question earlier
One option is to use DataMarvel's wrapper for Win32 APIs
[url]http://www.DataMarvel.co[/url]
Using its NAccessToken wrapper with your current "WindowsIdentity.Token", you can call "Groups" property that returns an array of all the groups and its attributes, or simply call "UserGroups" that returns an array of the "regular" groups in the form of "domain\group" format ("regular" means it ignores the "Logon SID" and all the restrictive groups). Its try version has a sample solution that shows how to call them

[jzhu]

Because the group information is already built for the user in the token, so the API call should have almost no cost.

Making DirectoryService call is much more expensive (going across the wire to a domain controller), and you can only get groups that the user is a direct member (so if a user is a member of A and A is a subgroup of B, then B will not show up in the groups). The situation is made easier in Win2003 though.

[Joe Kaplan \(MVP - ADSI\)]

It seems to me that this is a little misleading since the token contains the
SIDs, but unless LSASS.exe has cached the names of the groups for those
SIDs, a network call will be involved to do the resolution.

There are some other advantages to using the DirectoryServices call in that
LookupAccountName requires the current security context to be a domain
account that can resolve the SID, whereas S.DS allows you to supply
credentials for the operation. However, that might not be applicable in
this situation.

In any event, that's the main reason why I presented options as options are
good :)

Joe K.

"jzhu" <anonymous@discussions.microsoft.com> wrote in message
news:58A535FA-B7D9-468B-99BE-E62B8F049369@microsoft.com...

> Because the group information is already built for the user in the token,

so the API call should have almost no cost.

>
> Making DirectoryService call is much more expensive (going across the wire

to a domain controller), and you can only get groups that the user is a
direct member (so if a user is a member of A and A is a subgroup of B, then
B will not show up in the groups). The situation is made easier in Win2003
though.

[jzhu]

Thanks for pointing out the cost of translating SIDs to their names. I never thought of that before

----- Joe Kaplan (MVP - ADSI) wrote: ----

It seems to me that this is a little misleading since the token contains th
SIDs, but unless LSASS.exe has cached the names of the groups for thos
SIDs, a network call will be involved to do the resolution