> When having the AppDomain.Current.SetPrincipalPolicy(WindowsPrincipal)
> static method set, the current process's Principal is propagated to
> the current thread to be used for Role-based access check.
>
> This happens the FIRDT time one asks for this property of the thread.
> Now - when doing an impersonation, the thread's principal is
> propagated to reflect this new principal (i.e. the impersonated user).
>
> Question:  How come this property (CurrentPrincipal) on the thread is
> NOT updated when e.g. reverting the impersonation? The threads
> Principal STILL reflects the impersonated user as this was the very
> first time a request was made for the principal (by the RBS system of
> .NET)
>
> /Claus
>

"Dominick Baier" wrote:

> Impersonation and Thread.CurrentPrincipal have nothing to do with each other.
>
> T.CP is a .NET concept to set up a security context you wanna do access checks
> against, e.g. IsInRole - impersonation is a Windows feature to change the
> token against which the Windows kernel does access checks against.
>
> I would not use SetPrincipalPolicy.
>
> Just set T.CP to whatever you want - e.g. Thread.CurrentPrincipal = new WindowsPrincipal(WindowsIdentity.GetCurrent());
>
> ---
> Dominick Baier, DevelopMentor
> http://www.leastprivilege.com
>
> > When having the AppDomain.Current.SetPrincipalPolicy(WindowsPrincipal)
> > static method set, the current process's Principal is propagated to
> > the current thread to be used for Role-based access check.
> >
> > This happens the FIRDT time one asks for this property of the thread.
> > Now - when doing an impersonation, the thread's principal is
> > propagated to reflect this new principal (i.e. the impersonated user).
> >
> > Question:  How come this property (CurrentPrincipal) on the thread is
> > NOT updated when e.g. reverting the impersonation? The threads
> > Principal STILL reflects the impersonated user as this was the very
> > first time a request was made for the principal (by the RBS system of
> > .NET)
> >
> > /Claus
> >
>
>
>

> Thanks.
>
> That was actually what I ended up doing (setting the T.CP = what ever)
> manually.
> But - then, what is the actual purpose of the SetPrincipalPolicy if it
> can
> not be used more than once (or so it appears)?
> /Claus
>
> "Dominick Baier" wrote:
>
>> Impersonation and Thread.CurrentPrincipal have nothing to do with
>> each other.
>>
>> T.CP is a .NET concept to set up a security context you wanna do
>> access checks against, e.g. IsInRole - impersonation is a Windows
>> feature to change the token against which the Windows kernel does
>> access checks against.
>>
>> I would not use SetPrincipalPolicy.
>>
>> Just set T.CP to whatever you want - e.g. Thread.CurrentPrincipal =
>> new WindowsPrincipal(WindowsIdentity.GetCurrent());
>>
>> ---
>> Dominick Baier, DevelopMentor
>> http://www.leastprivilege.com
>>> When having the
>>> AppDomain.Current.SetPrincipalPolicy(WindowsPrincipal) static method
>>> set, the current process's Principal is propagated to the current
>>> thread to be used for Role-based access check.
>>>
>>> This happens the FIRDT time one asks for this property of the
>>> thread. Now - when doing an impersonation, the thread's principal is
>>> propagated to reflect this new principal (i.e. the impersonated
>>> user).
>>>
>>> Question:  How come this property (CurrentPrincipal) on the thread
>>> is NOT updated when e.g. reverting the impersonation? The threads
>>> Principal STILL reflects the impersonated user as this was the very
>>> first time a request was made for the principal (by the RBS system
>>> of .NET)
>>>
>>> /Claus
>>>