IsInRole performance issue

[Joseph E Shook]

I have found an issue with IsInRole().

The following is a piece of test code:

using System;
using System.Security.Principal;
using System.Threading;

class Class1
{
[STAThread]
static void Main(string[] args)
{

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
;
DateTime startTime = DateTime.Now;

Console.WriteLine(Thread.CurrentPrincipal.IsInRole("Everyone").ToString());
DateTime endTime = DateTime.Now;
Console.WriteLine("Elapsed time: " + ((TimeSpan)(endTime.TimeOfDay -
startTime.TimeOfDay)).ToString());
Console.ReadLine();
}
}

Usage:

-Create a domain account.
-Add that domain account to a large number of groups. I tested with 300
groups the first time.
-Install NetMon and monitor network traffic between your client machine and
your domain controller. In my test I setup netmon on the domain controller.
-Make sure that you log in with new account and that your token now contains
the 300 groups. Use WhoAmI from one of the OS resource kits if you want to
be sure that your token contains all of the groups.
-Run the sample code and watch the number of frames that are sent to the
domain controller.

More Info:

I found that when the sample account was a member of 125 groups in my test
only 6 frames would be sent out. But when I increased the group membership
to 126 then I observed 2030 frames being sent from the client to the domain
controller.

This is almost unoticable when the client and domain controller are in the
same subnet. But when you put some distance between the two entities the
performance is magnified. I have a web server that experienced this issue
when the Web server was in another building than the domain machines.

You might say who would ever have 125 groups in their token? Well with the
increase use of Active Directory and the abilit to be placed in Universal
Groups, Global Groups, and Domain Local Groups, and more and more
applications relying on integrated security, ones group memebership could
grow. Atually I have an application that we were contemplating a membership
of close to 100 groups depending on the user.

What worries me more than whether I implement an application with a large
number of group membership is that fact that some other application could
put a user account in multiple groups. That will effect all of the inocent
applications that only relied on 2 or three roles.

Anyways with the help of Keith Brown I implemented a IsInRole() substitute
for the frameworks IsInRole(). My implementation uses LsaLookUpNames and
CheckTokenMembership APIs. I think that the framework is just implmented
with an older API.

I also checked that the 300 group membershp was not a problem by placing a
text.htm file on my web server and securing it with an ACE allowing only the
test account access to it. Of course it has no additional network traffic
to determine access because it isn't useing the same API as the frameworks
IsInRole().

I also implemented this test in asp.net and deployed it on Win2003 RC2 which
is using the 1.1 framework. I have not compiled the console app above under
the 1.1 framework but I believe the deployment to RC2 would suffice.

[Joe Kaplan]

We have a domain with users in many hundreds of groups (I've seen up 880 in
a few rare cases), so I am very interested in this. Would you care to share
how your IsInRole implementation works? Also, who do you use it? Do you
create a new class that implements IPrincipal with your IsInRole
implementation and the user's token inside and stick that on the current
thread? Also, what are the OS limitations with using your implementation?

Thanks!

Joe K. (also a Joseph E....)

"Joseph E Shook" <JoeS...@DeploymentCentric.com> wrote in message
news:O1wmwtE7...@TK2MSFTNGP12.phx.gbl...

[Joseph E Shook]

I didn't implement my own WindowsIdentity but if I had to implement from
scratch then yes, I would extend the existing WindowsIdentity and override
the IsInRole(). We created an object called permchecker. If helps us move
from development to stage and then to production, changing the domain
throughout the deployments. I discovered this about two weeks back and I
presented the issue to the DevelopMentor DOTNET-WEB list serv. Keith Brown,
a very smart Windows Security guy added an additional library to his
DM.SecUtil project. Basically he wrote a managed c++ wrapper to wrap
LsaLookupAccountNames and CheckTokenMembership. LsaLookupAccountName was a
little on the complicated side to just to c# p/invoke against. So I was
very thankfull that Keith was so willing to share this code. I don't know
If he has updated the library but her is the link:
http://www.develop.com/devresources/default.aspx#security

You will be looking for the DevelopMentor Security Utilities link. If it
isn't up to date Keith offered to email it to anyone in need.

Also you will notice that he took it an extra step and wrapped the C++
component with a c# component called SidCache. This allows you to cache
name to sid relationships for quick checking without having to travel the
network.

I have to imagine that future versions of the framwork will not suffer from
this but I have yet to get a response from a real MS person.

"Joe Kaplan" <ilearnedthi...@noway.com> wrote in message
news:#ZR3gQN7...@TK2MSFTNGP10.phx.gbl...

[Joe Kaplan]

Thanks for following up.

Joe K.

"Joseph E Shook" <JoeS...@DeploymentCentric.com> wrote in message

news:O7vkRJO7...@TK2MSFTNGP11.phx.gbl...