Re: User.IsInRole is always FALSE
From: Dominick Baier [DevelopMentor] (dbaier_at_pleasepleasenospamdevelop.com)
Date: 06/11/05
- Next message: Nicole Calinoiu: "Re: policy files and .Net Configuration tool?"
- Previous message: Dominick Baier [DevelopMentor]: "Re: session manager vs Form authentication in the Global.asax.cs f"
- In reply to: Joseph Bittman MCAD: "Re: User.IsInRole is always FALSE"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 11 Jun 2005 01:28:47 -0700
Hello Joseph,
Thread.CurrentPrincipal will return whatever
> account the thread is running under. Since this is a web application,
> it would be the thread that the web Application is running under; not
> the client. By default this would be ASPNET on IIS 5.0.
Thread.CurrentPrincipal returns the client identity (if set - e.g. if anonymous
is enabled - it will be empty)
WinowsIdentity.GetCurrent() will give you the process identity (which is
ASPNET und IIS5 and NETWORK SERVICE und IIS6 - by default)
The messy part is : If you are impersonating - WindowsIdentity.GetCurrent()
will give you the impersonated identity (and there is no straightforward
way to figure out if you are impersonating). This is why in .NET 2.0 there
is a new overload of GetCurrent() for exactly that reason.
---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com
> June 9, 2005
>
> :-) That helps a lot. Thread.CurrentPrincipal will return whatever
> account the thread is running under. Since this is a web application,
> it would be the thread that the web Application is running under; not
> the client. By default this would be ASPNET on IIS 5.0. This would
> still be the case unless there are impersonation settings or if you
> specified your web application to run under a different account in
> IIS. It sounds like there is impersonation of an Administrator account
> and therefore doesn't sound like you are checking what the client's
> roles are. Use the User object to check whether the USER is in a role.
> The difference is that the currentprincipal object is what the
> application running under and the User is what the Client web browser
> is running under. This assumes that you only have Windows
> Authentication in IIS. This should work now.... As far as the username
> format, you should step through the code and see what the username
> looks like. It can be LocalMachineName\Username, or Domain\Username,
> or BUILTIN\Username. Therefore to always get it right, use the
> Environment.UserDomainName string. This will return either the machine
> name or the domain name, depending on what it expects. This way, you
> don't have to guess which name to put. So try
>
> User.IsInRole(@Environment.UserDomainName & "\TestGroup");
>
> I'm not a C# programmer, so you might have to adjust my statement
> slightly! :-) You may want to step through the code if it doesn't work
> and find out what name is actually being returned in User. :-) Let me
> know how this works!!!
>
> Web Site: http://71.35.110.42
> Dynamic IP -- Check here for future changes
> "Dominick Baier [DevelopMentor]"
> <dbaier@pleasepleasenospamdevelop.com> wrote in message
> news:469621632539081378571528@news.microsoft.com...
>
>> Hello Oliver,
>>
>> ok -
>> a) have you disabled anonymous access for the asp.net app?
>> b) WindowsIdentity.GetCurrent() gives you the worker process identity
>> - or
>> the client identity (if impersonating)
>> c) better - always use Page/Context.User if you want to make checks
>> against the client identity.
>> string user = Page.User.Identity.Name;
>>
>> bool isInTestgroup2 = Page.User.IsInRole(@"DOMAIN\Testgroup2");
>>
>> does that make a difference??
>>
>> ---------------------------------------
>> Dominick Baier - DevelopMentor
>> http://www.leastprivilege.com
>>> Hi Joseph,
>>>
>>> I executed the following code for testing the stuff --> all booleans
>>> were false except the local admin groups...
>>>
>>> WindowsPrincipal windowsPrincipal =
>>> (WindowsPrincipal)Thread.CurrentPrincipal;
>>> IPrincipal iPrincipal = Thread.CurrentPrincipal;
>>> WindowsIdentity windowsIdentity =
>>> System.Security.Principal.WindowsIdentity.GetCurrent(); string user
>>> = windowsIdentity.Name;
>>>
>>> bool isLocalAdmin =
>>> windowsPrincipal.IsInRole(WindowsBuiltInRole.Administrator); bool
>>> isInTestgroup1 = windowsPrincipal.IsInRole(@"DOMAIN\Testgroup1");
>>>
>>> bool isInTestgroup2 =
>>> windowsPrincipal.IsInRole(@"DOMAIN\Testgroup2");
>>>
>>> bool isLocalAdmin_2 =
>>> iPrincipal.IsInRole(@"BUILTIN\Administrators");
>>>
>>> bool isInTestgroup1_2 = iPrincipal.IsInRole(@"DOMAIN\Testgroup1");
>>>
>>> bool isInTestgroup2_2 = iPrincipal.IsInRole(@"DOMAIN\Testgroup2");
>>>
>>> Thanks for your help...
>>>
>>> Oliver Rainer
>>>
>>> "Joseph Bittman MCAD" <RyanBittman@msn.com> wrote in message
>>> news:OJWiWGEbFHA.3032@TK2MSFTNGP10.phx.gbl...
>>>
>>>> June 9, 2005
>>>>
>>>> :-) Yes, the BUILTIN will only work for local groups. AD groups are
>>>> somewhat more mysterious and have had problems with them myself.
>>>> When you call IsInRole, where is the IPrincipal coming from? Are
>>>> you using the interface directly, or using an object taken from the
>>>> System.Threading.Thread.CurrentPrincipal, or the User object????
>>>> This
>>>>
>>> makes
>>>
>>>> a big difference in the result that you will get, because I believe
>>>> in
>>>>
>>> your
>>>
>>>> case that only a principal taken from User will reflect the user's
>>>>
>>> identity
>>>
>>>> and not ASPNET. If you could post how you got Iprincipal.IsInRole,
>>>> then I believe that I can help you further! :-) Have a great day
>>>> and until
>>>>
>>> later!!!
>>>
>>>> --
>>>> Joseph Bittman Beta ID# 678424
>>>> Microsoft Certified Application Developer
>>>> Web Site: http://71.35.110.42
>>>> Dynamic IP -- Check here for future changes
>>>> "Oliver Rainer" <olrainer@tiscali.ch> wrote in message
>>>> news:O$%23NC1$aFHA.1044@TK2MSFTNGP10.phx.gbl...
>>>>> Thanks for your suggestion... that really works for local groups
>>>>> (BUILTIN),
>>>>> but IIS still has the problem to resolve AD groups
>>>>> (OURDOMAIN\...)...
>>> The
>>>
>>>>> strange thing is that on certain machines (our developer
>>>>> machines),
>>>>> IIS
>>>>> can
>>>>> succesfully determine if a user belongs to an AD group...
>>>>> Do you have other suggestions??
>>>>> Thanks
>>>>> Oliver Rainer
>>>>> "Joseph Bittman MCAD" <RyanBittman@msn.com> wrote in message
>>>>> news:eIRT4F4aFHA.3280@TK2MSFTNGP12.phx.gbl...
>>>>>> June 7, 2005
>>>>>>
>>>>>> hehe I actually have to go to a meeting right now, but a quick
>>>>>> suggestion
>>>>>> before I leave. Try switching the PrincipalPermission
>>>>>> role="domain\groupname" to "BUILTIN\GROUPNAME". There is a little
>>>>>> more
>>> to
>>>
>>>>>> this change, but it should work.... depending on which role it
>>>>>> is, so
>>>>>>
>>> if
>>>
>>>>> you
>>>>>
>>>>>> could post it, that would really help... until later! :-)
>>>>>>
>>>>>> --
>>>>>> Joseph Bittman
>>>>>> Microsoft Certified Application Developer
>>>>>> Web Site: http://71.35.110.42
>>>>>> Dynamic IP -- Check here for future changes
>>>>>> "Oliver Rainer" <olrainer@tiscali.ch> wrote in message
>>>>>> news:ubg7WH3aFHA.2440@TK2MSFTNGP10.phx.gbl...
>>>>>>> Hi, I have the following problem...
>>>>>>>
>>>>>>> Pre-requisites:
>>>>>>> Installation of an Asp.net webservice on a IIS5 server (win2k).
>>>>> Anonymous
>>>>>
>>>>>>> access is not allowed, only using windows authentication
>>>>>>> (intranet
>>>>>>> app),
>>>>>>> webmethoda are using the Principalpermssion attribute
>>>>>>> ([PrincipalPermission(SecurityAction.Demand,
>>>>>>> Role=@"DomainName\WindowsGroup...")]) for identification.
>>>>>>> Result --> does not work
>>>>>>> When I change the to [PrincipalPermission(SecurityAction.Demand,
>>>>>>> name=@"DomainName\Windowsuser...")]) -> it runs fine
>>>>>>>
>>>>>>> --> conclusion: IIS cannot determine if a user belongs to an AD
>>>>>>>
>>>>> group -->
>>>>>
>>>>>>> IPrincipal.IsInRole(@"DomainName\WindowsGroup") is always FALSE!
>>>>>>>
>>>>>>> I already found an article on the web
>>>>>>> (http://www.kbalertz.com/kb_894432.aspx --> web dir is UNC
>>>>>>> share),
>>>>>>> but
>>>>>>> didn't solved the problem...
>>>>>>> Does anyone know more about this issue?
>>>>>>> Thanks
>>>>>>> Oliver Rainer
- Next message: Nicole Calinoiu: "Re: policy files and .Net Configuration tool?"
- Previous message: Dominick Baier [DevelopMentor]: "Re: session manager vs Form authentication in the Global.asax.cs f"
- In reply to: Joseph Bittman MCAD: "Re: User.IsInRole is always FALSE"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
