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

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

Joe K.

"Nikolay Petrov" <johntup2_nospam_@mail.bg> wrote in message
news:%(E-Mail Removed)...
> 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
>

I have tried this. Doesn't help.


"Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
in message news:%(E-Mail Removed)...
> Did you try MACHINE\Administrators or the proper domain suffix? Windows
> roles always have a prefix in .NET.
>
> Joe K.

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" <johntup2_nospam_@mail.bg> wrote in message
news:%(E-Mail Removed)...
>I have tried this. Doesn't help.
>
>
> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
> in message news:%(E-Mail Removed)...
>> Did you try MACHINE\Administrators or the proper domain suffix? Windows
>> roles always have a prefix in .NET.
>>
>> Joe K.
>
>

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

"Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
in message news:(E-Mail Removed)...
> 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" <johntup2_nospam_@mail.bg> wrote in message
> news:%(E-Mail Removed)...
>>I have tried this. Doesn't help.
>>
>>
>> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)>
>> wrote in message news:%(E-Mail Removed)...
>>> Did you try MACHINE\Administrators or the proper domain suffix? Windows
>>> roles always have a prefix in .NET.
>>>
>>> Joe K.
>>
>>
>
>

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" <johntup2_nospam_@mail.bg> wrote in message
news:(E-Mail Removed)...
>I have done that. It is fine.
> Something else is broken. The auditing don't show nothing also.
>
> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
> in message news:(E-Mail Removed)...
>> 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.

Never heard of reflection ;-)
how to do?


"Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
in message news:(E-Mail Removed)...
> 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" <johntup2_nospam_@mail.bg> wrote in message
> news:(E-Mail Removed)...
>>I have done that. It is fine.
>> Something else is broken. The auditing don't show nothing also.
>>
>> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)>
>> wrote in message news:(E-Mail Removed)...
>>> 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.
>
>

'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" <johntup2_nospam_@mail.bg> wrote in message
news:(E-Mail Removed)...
> Never heard of reflection ;-)
> how to do?
>
>
> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
> in message news:(E-Mail Removed)...
>> 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" <johntup2_nospam_@mail.bg> wrote in message
>> news:(E-Mail Removed)...
>>>I have done that. It is fine.
>>> Something else is broken. The auditing don't show nothing also.
>>>
>>> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)>
>>> wrote in message news:(E-Mail Removed)...
>>>> 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.
>>
>>
>
>

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


"Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
in message news:%(E-Mail Removed)...
> '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" <johntup2_nospam_@mail.bg> wrote in message
> news:(E-Mail Removed)...
>> Never heard of reflection ;-)
>> how to do?
>>
>>
>> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)>
>> wrote in message news:(E-Mail Removed)...
>>> 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" <johntup2_nospam_@mail.bg> wrote in message
>>> news:(E-Mail Removed)...
>>>>I have done that. It is fine.
>>>> Something else is broken. The auditing don't show nothing also.
>>>>
>>>> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)>
>>>> wrote in message news:(E-Mail Removed)...
>>>>> 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.
>>>
>>>
>>
>>
>
>

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)" wrote:

> '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" <johntup2_nospam_@mail.bg> wrote in message
> news:(E-Mail Removed)...
> > Never heard of reflection ;-)
> > how to do?
> >
> >
> > "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
> > in message news:(E-Mail Removed)...
> >> 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" <johntup2_nospam_@mail.bg> wrote in message
> >> news:(E-Mail Removed)...
> >>>I have done that. It is fine.
> >>> Something else is broken. The auditing don't show nothing also.
> >>>
> >>> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)>
> >>> wrote in message news:(E-Mail Removed)...
> >>>> 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.
> >>
> >>
> >
> >
>
>
>