Case Sensitivity Issue with WindowsPrincipal.IsInRole (.net 1.1)

[Guest]

Hi,

I have a problem with WindowsPrincipal.IsInRole. I have heard that in version 1.0 of the framework it was case sensitive, but now its not.

However, I'm having a problem that seems to be related to case sensitivity in version 1.1 of the framework. It's like this:

- I create a local group on my development machine
- I add myself (i.e. my domain account) to that group. My account is of the form MYDOMAIN\RuskJ
- If I then re-open that group (in the Computer Management console) I see that the member of that group is now listed as "MYDOMAIN\Ruskj". Notice that the last letter is now lower case, even though it was upper case beforehand. I think this is the cause of the problem.
- If I call IsInRole for my new group, it always returns false.
- If I use reflection to invoke _GetRoles, I can see that the role I created is not listed.
- However, another local role IS listed. If I open that role I see that my account is listed there with the "correct" captialisation - i.e. MYDOMAIN\RuskJ".

In summary, it appears that in .NET 1.1, IsInRole is case insensitive on group names, but still case SENSITIVE with regard to the users who are in those groups.

E.g. IsInRole("machine\TestGroup") and IsInRole("machine\TESTGROUP") do, correctly, return the same value.

However, it returns true if MYDOMAIN\RuskJ is a member of that group, but false if MYDOMAIN\Ruskj (different capitalisation but same user) is a member of that group.

I may be missing something trivial here, and if I am please let me know. For instance, why am I displayed with different capitalisation in different groups? On the other hand, it could be a real bug. Can anyone confirm ....?

I'm using Visual Studio 2003 on Windows XP Pro.

Thanks!

 

[Rob Teixeira [MVP]]

If you look at eh WindowsPrincipal class in IL (or use some reflection
code), you'll see that has an internal list of roles. The issue is that
there are two internal private containers for role names. One is an array of
strings, and the other is a hashtable. If there are fewer than some magic
number of groups the user belongs to (somewhere in the mid-20's), the array
is used. If the user belongs to more groups, the hashtable is used instead.
In the hashtable, the group name is used as the lookup hash, and because of
that, it is case sensitive. If the array is used, the behaviour is case
insensitive.

As for the different capitalization, i'm pretty certain that's an artifact
of the underlying win32 api. You can always try to use them through p/invoke
to see if you get the same results.

-Rob Teixeira [MVP]

Hi,

I have a problem with WindowsPrincipal.IsInRole. I have heard that in

version 1.0 of the framework it was case sensitive, but now its not.

However, I'm having a problem that seems to be related to case sensitivity

in version 1.1 of the framework. It's like this:

- I create a local group on my development machine
- I add myself (i.e. my domain account) to that group. My account is of the form MYDOMAIN\RuskJ
- If I then re-open that group (in the Computer Management console) I see

that the member of that group is now listed as "MYDOMAIN\Ruskj". Notice
that the last letter is now lower case, even though it was upper case
beforehand. I think this is the cause of the problem.

- If I call IsInRole for my new group, it always returns false.
- If I use reflection to invoke _GetRoles, I can see that the role I created is not listed.
- However, another local role IS listed. If I open that role I see that my

account is listed there with the "correct" captialisation - i.e.
MYDOMAIN\RuskJ".

In summary, it appears that in .NET 1.1, IsInRole is case insensitive on

group names, but still case SENSITIVE with regard to the users who are in
those groups.

E.g. IsInRole("machine\TestGroup") and IsInRole("machine\TESTGROUP") do,

correctly, return the same value.

However, it returns true if MYDOMAIN\RuskJ is a member of that group, but

false if MYDOMAIN\Ruskj (different capitalisation but same user) is a member
of that group.

I may be missing something trivial here, and if I am please let me know.

For instance, why am I displayed with different capitalisation in different
groups? On the other hand, it could be a real bug. Can anyone confirm
.....?

 

[Guest]

Rob,

Thanks for your reply.

However my problem does not seem to be related to the number of groups, nor does it seem to be related to the captialization of the group name.

It appears ( and I might be wrong) to be related to how the user is recorded "in" the group. I.e. I have two different groups. I am a member of both of them. But, according to IsInRole (and _GetRoles) I am only a member of one of them.

I can change the captialization of the group in the call to IsInRole and it makes no difference. It still gives the right answer for one group and the wrong answer for the other.

The only difference I can see is that when I look at one group, my name appears in it as "RuskJ", and it appears as "Ruskj" in the other.

John