Re: .NET 2.0 Remoting Bug?

Apparently it does not. It is set to a GenericPrincipal. I found another
post from about a month ago reporting the same problem. There was no real
solution. Thread.CurrentPrincipal.Identity IS set to a WindowsIdentity
(containing the correct user).

I ended up creating a PrincipalSink that does

Thread.CurrentPrincipal = new
WindowsPrincipal(Thread.CurrentPrincipal.Identity);

and now PrincipalPermission works OK. I reset Thread.CurrentPrincipal to
the GenericPrincipal after I finish handling the call.

I am not entirely aware of all the remoting interals and threading issues,
I hope I haven't opened the door to a world of race conditions and pain. For
instance, I'm not 100% sure that it will work with asynchronous calls (I
might reset the CurrentPrincipal of a DIFFERENT thread, because
AsyncProcessResponse and ProcessResponse may be called in two different
threads. Or not).

"Dominick Baier [DevelopMentor]" wrote:

Hi,

i never experienced this - Thread.CurrentPrincipal should be set to a WindowsPrincipal
- for Windows groups you have to use the domain\group syntax for principalpermission

is Thread.CurrentPrincipal.Identity.Name set to the name of the client?

---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

Hi.

I'm trying to apply role-based security to a .NET remoting server.
I'm using a secure TcpServerChannel with security turned on
(identification only, I don't want to impersonate the client), and I
want to limit access to a remoted method, like so:

class RemotedObject
{
[PrincipalPermission(SecurityAction.Demand, Role="Important")]
void MeaningfulStuff() { ... }
}
This fails miserably - no matter who the user running the client is.
Apparently Thread.CurrentPrincipal is set to a GenericEntity type
which never belongs to any roles. When I change the channel setting to
Impersonate, it works well.

Since I don't want to impersonate the client, I have no chance but
to create my own new
WindowsPrincipal(Thread.CurrentPrincipal.Identity) and ask it if it
IsInRole("Important") . Note that I need to to this trick even if the
client and server are running under exactly the same user.

Is there any reasonable fix for this .NET bug?

Itay.




.

Relevant Pages

  • Re: Debugger not working in Vs.net 2003
    ... I check The "Impersonate a client after authentication" user right, aspnet ...
    (microsoft.public.vsnet.debugging)
  • Re: help on caller credentials !! :-(
    ... the back end SQL server maybe. ... In fact I simply try to flow the client user until the database level. ... Hosting my remote object in IIS would be much more simple but thi is not my ... under windows 2000 and prefer mode should be "Impersonate". ...
    (microsoft.public.dotnet.security)
  • Re: fire event & IUnknown
    ... Is your client single-threaded or multi-threaded? ... The client project consists of one ATL ActiveX ... the threading model is causing the event to fail. ... > - I do need to fire events from within worker threads; ...
    (microsoft.public.vc.atl)
  • Re: client impersonation
    ... While you are able to retrieve the login names of all current ... Why not create a simple client autostart ... tool that makes a request to the webservice with the user's login ... impersonate the client user to have the appropriate rights on the ...
    (microsoft.public.win32.programmer.tapi)
  • Re: Remote Registry Problem
    ... I have checked the local policy and the setting for "Impersonate a client ... after authentication" has both Administrators and SERVICE defined. ...
    (microsoft.public.windows.server.sbs)