Problems with IsInRole

[John Rusk]

I'm having problems with WindowsPrincipal.IsInRole. It's returning false
when it should return true.

I've written some test code that uses reflection to call the private
_GetRoles method of WindowsIdentity. That gets the same list of roles that
IsInRole uses. It returns a long list, but most of the strings in the list
are blank (i.e. zero length or null). That explains why IsInRole fails,
since it's doing lookups in a list that consists of (mostly) empty strings.

Does anyone know the cause of this behaviour?

John

[Joe Kaplan \(MVP - ADSI\)]

Is it possible that the SID->name resolution might be failing due to a
security context error? I think the underlying API call requires a domain
security context on the current thread. You might try impersonating the
WindowsIdentity in the WindowsPrincipal before you call IsInRole to see if
that changes your results. You can revert back right after you call
IsInRole for the first time.

Let us know if that fixes the problem.

Joe K.

"John Rusk" <JohnRusk@discussions.microsoft.com> wrote in message
news:2BF3DB46-DBFA-4E9D-9FD7-B59346693801@microsoft.com...

> I'm having problems with WindowsPrincipal.IsInRole. It's returning false
> when it should return true.
>
> I've written some test code that uses reflection to call the private
> _GetRoles method of WindowsIdentity. That gets the same list of roles
> that
> IsInRole uses. It returns a long list, but most of the strings in the
> list
> are blank (i.e. zero length or null). That explains why IsInRole fails,
> since it's doing lookups in a list that consists of (mostly) empty
> strings.
>
> Does anyone know the cause of this behaviour?
>
> John
>
>

[John Rusk]

> security context on the current thread. You might try impersonating the

> WindowsIdentity in the WindowsPrincipal before you call IsInRole to see if

Joe,

I wondered about that. I haven't tried it yet at the client's site. What I
have tried there is the little test application that calls _GetRoles. It's a
Winforms app, so runs under the account of the logged in domain user. It
fails as described in my original post, which leads me to believe that doing
impersonation in ASP probably wouldn't help either.

Can you think of any explaination why the _GetRoles call should fail? It is
run by a user logged in to domain "X", but fails to return groups in domain
"X" to which the user belongs. The only possible complicating factor, at
least the only one I've thought of so far, is that the machine itself is not
a member of domain "X".

John

[John Rusk]

I think I've found the problem. I think its something like this:

[url]http://support.microsoft.com/default.aspx?scid=kb;en-us;262958[/url]

While I'm not 100% sure that I'm suffering from _exactly_ the same problem,
it seems that its possible to configure domain controllers in a way that
breaks .NET's role based security.

I ended up dropping .NET's IsInRole, and using equivalent code from Keith
Brown's security library
([url]http://www.theserverside.net/discussions/thread.tss?thread_id=25074[/url]). That
was when I finally got the error 1789, which means "The trust relationship
between this workstation and the primary domain failed". It's a shame that
..NET's IsInRole doesn't log anything to indicate what's going wrong. The
only sign was blank/missing names for global groups when I called _GetRoles.

In the code I used, from Keith Brown's library, it was the translation from
names to SIDs that was failing.

Thanks for your suggestions Joe.

John

[Joe Kaplan \(MVP - ADSI\)]

That's too bad. I've seen these kinds of problems, but they are pretty
mysterious.

You could also try using some Directory Services code to do this to overcome
the issue with the LSA, but that will require more config and potentially be
more brittle.

Perhaps there is a way to solve the trust issue though. I'm the wrong guy
to ask there, but I'm sure someone understands the options.

Joe K.

"John Rusk" <JohnRusk@discussions.microsoft.com> wrote in message
news:AE2E348F-4FF9-444B-9B6B-B2E0A397C315@microsoft.com...

>I think I've found the problem. I think its something like this:
>
> [url]http://support.microsoft.com/default.aspx?scid=kb;en-us;262958[/url]
>
> While I'm not 100% sure that I'm suffering from _exactly_ the same
> problem,
> it seems that its possible to configure domain controllers in a way that
> breaks .NET's role based security.
>
> I ended up dropping .NET's IsInRole, and using equivalent code from Keith
> Brown's security library
> ([url]http://www.theserverside.net/discussions/thread.tss?thread_id=25074[/url]).
> That
> was when I finally got the error 1789, which means "The trust relationship
> between this workstation and the primary domain failed". It's a shame
> that
> .NET's IsInRole doesn't log anything to indicate what's going wrong. The
> only sign was blank/missing names for global groups when I called
> _GetRoles.
>
> In the code I used, from Keith Brown's library, it was the translation
> from
> names to SIDs that was failing.
>
> Thanks for your suggestions Joe.
>
> John
>
>