Authorization problem

[Nikolay Petrov]

The following code doesn't produse the expected effect to only allow the
members of Administrators group to access the web method, it stops everyone.
=========
<WebMethod(), _
PrincipalPermission(SecurityAction.Demand, Role:="Administrators")> _
Public Function HelloWorld() As String
Return "Hello World"
End Function
=========

The web service folder is set to require only Windows Authentication, which
goes fine. I can get the user credentials whitout any problem.

What is wrong?
TIA

 

[Joe Kaplan \(MVP - ADSI\)]

Did you try MACHINE\Administrators or the proper domain suffix? Windows
roles always have a prefix in .NET.

Joe K.

 

[Nikolay Petrov]

I have tried this. Doesn't help.

 

[Joe Kaplan \(MVP - ADSI\)]

Are you certain that the client is being authenticated with Windows
authentication? It would probably be a good idea to dump out the value of
Context.User.Identity.Name and make sure it is the user that you think it
is.

Joe K.

 

[Nikolay Petrov]

I have done that. It is fine.
Something else is broken. The auditing don't show nothing also.

 

[Joe Kaplan \(MVP - ADSI\)]

One other thing to check:

Can you do a programmatic check instead of a declarative one? Try
Context.User.IsInRole("machine\administrators") or
Thread.CurrentPrincipal.IsInRole("machine\administrators")?

Those should do the same thing as the declarative demand, but it is worth a
shot.

Another thing to try is to use reflection on _GetRoles private method on
WindowsIdentity to see what the actual values are. This can be helpful for
troubleshooting Windows group resolution. Don't use this in production
though!

Google will dig up a bunch of code samples showing how to do that if you
need it.

Joe K.

 

[Nikolay Petrov]

Never heard of reflection ;-)
how to do?

One other thing to check:

Can you do a programmatic check instead of a declarative one? Try
Context.User.IsInRole("machine\administrators") or
Thread.CurrentPrincipal.IsInRole("machine\administrators")?

Those should do the same thing as the declarative demand, but it is worth
a shot.

Another thing to try is to use reflection on _GetRoles private method on
WindowsIdentity to see what the actual values are. This can be helpful
for troubleshooting Windows group resolution. Don't use this in
production though!

Google will dig up a bunch of code samples showing how to do that if you
need it.

Joe K.

 

[Joe Kaplan \(MVP - ADSI\)]

'imports System.Security.Principal
'imports System.Reflection

Function GetRoles(byval identity as WindowsIdentity) as String()

Dim idType As Type
idType = GetType(WindowsIdentity)
Dim result As Object =
idType.InvokeMember("_GetRoles",BindingFlags.Static Or
BindingFlags.InvokeMethod Or BindingFlags.NonPublic,Nothing, identity, New
Object() {identity.Token}, Nothing)
Dim roles() As String = DirectCast(result, String())
Return roles

End Function

Like I said, this is for troubleshooting only, not for production code.
This may not work in future versions of the framework, but does on 1.1.

Joe K.

 

[Nikolay Petrov]

Ok, I'll try it tommorow and let you know.
Thanks for help.

 

[Guest]

Hi,
I'm using form authentication with Active Directory not a Database.
Can you give me a hint how i can GetRoles from the Active Directory and
later perform Authorisation?
Thx

 

[Joe Kaplan \(MVP - ADSI\)]

I think the standard Forms Authentication with ASP.NET article is an okay
starting point. I'd suggest you rip out their group lookup code and replace
it with some code that uses tokenGroups instead of memberOf. There are many
advantages to this approach.

http://support.microsoft.com/default.aspx?scid=kb;en-us;326340
http://groups.google.com/groups?hl=en&lr=&[email protected]

If you are having trouble with ASP.NET and security contexts in S.DS, please
read this too:
http://support.microsoft.com/default.aspx?scid=kb;en-us;329986

The alternatives to this are to use the LogonUser API or SSPI to
authenticate the user and create a Windows token that can be turned into a
WindowsPrincipal for role-based authorization. This approach is actually
better in many ways to the LDAP approach, but might not work in all
situations. These have also been discussed endlessly on the public
newsgroups.

Joe K.