Re: User.IsInRole

From: Frank Racis (frank.racis@smed.com)
Date: 08/11/02 

From: "Frank Racis" <frank.racis@smed.com>
Date: Sat, 10 Aug 2002 20:07:56 -0400

I did some more testing today, and we're both right.
WindowsPrincipal.IsInRole is case insensitive, unless you're a member of 23
or more groups, then it becomes case sensitive.

Looking in the debugger, the WindowsPrincipal class has two places to store
roles, string[] m_roles and HashTable m_rolesTable. When the user is a
member of a 22 or fewer groups, m_roles is populated, m_rolesTable is null,
and the match is insensitive. When the number of groups is 23 or more,
m_roles is null, m_rolesTable is populated, and the matching becomes case
sensitive. My guess is that is has a different algorithm for caching small
and large sets of roles, and the large set algorithm (with hashing) is doing
a case-sensitive lookup when it shouldn't.

This seems a bit like Q321562, but SP2 didn't fix it. Also, the length of
the group name didn't affect the outcome. The 23rd group was only 2
characters long. I went back to 22 but made the group names a lot longer,
and it still worked.

-Frank

"Willy Denoyette [MVP]" <willy.denoyette@pandora.be> wrote in message
news:#7BTztAMCHA.1312@tkmsftngp04...
> Are you sure?
> All tests I've done so far indicate that it is case insensitive.
>
> Willy.
>
> "Frank Racis" <frank.racis@smed.com> wrote in message
news:e1V4oKyICHA.1636@tkmsftngp10...
> > That didn't work for me. I needed to use "BUILTIN\\Administrators"
(with a
> > capital A). The IsInRole check is case sensitive on the entire string,
> > both the machine/domain name and the user name. From some quick
testing,
> > the machine/domain is always uppercase, and the group is however it's
> > entered in user manager.
> >
> > I'm wondering whether this should be reported as a bug. Everywhere else
in
> > Windows, the names of users, groups, and domains are case-insensitive.
> > Having them case-sensitive for this call just seems wrong.
> >
> > -Frank