0

I have a .NET Remoting server using IPC channel with multiple clients. I need to set up server end so that only Administrators have access to the pipe. I know there is "authorizedGroup" property for server channel.

When I do not set it I can communicate only if the server and client are sun under the same account (ok). If I set it to "Users" (I use English version of Windows) then the server can run under LocalSystem and client running as any other user can connect (ok). When I create a dedicated group then it also works fine. But I would like to configure it so that only members of local Administrators group can connect. I tried setting authorizedGroup to "Administrators" or "BUILTIN\Administrators", but I get an exception on the client end that basically says "Access denied", even though the user running the client is a member of Administrators group.

Server configuration:

var clientProv = new BinaryClientFormatterSinkProvider();
var serverProv = new BinaryServerFormatterSinkProvider() { TypeFilterLevel = TypeFilterLevel.Full };
Hashtable channelProperties = new Hashtable();
channelProperties.Add("portName", "MyService");
channelProperties.Add("authorizedGroup", "Administrators");
channelProperties.Add("secure", "true");
channelProperties.Add("exclusiveAddressUse", false);
channel = new IpcChannel(channelProperties, clientProv, serverProv);
ChannelServices.RegisterChannel(channel, false);
RemotingServices.Marshal(this, "MyService.rem");

Client configuration:

var clientProv = new BinaryClientFormatterSinkProvider();
var serverProv = new BinaryServerFormatterSinkProvider() { TypeFilterLevel = TypeFilterLevel.Full };
Hashtable channelProperties = new Hashtable();
channelProperties.Add("portName", "remotingClient_" + Guid.NewGuid().ToString("N"));
channelProperties.Add("authorizedGroup", GetNameForSid(WellKnownSidType.LocalSystemSid));
channelProperties.Add("exclusiveAddressUse", false);
channelProperties.Add("secure", "true");
channelProperties.Add("tokenImpersonationLevel", "identification");
channel = new IpcChannel(channelProperties, clientProv, serverProv);
ChannelServices.RegisterChannel(channel, false);

var uri = "ipc://" + "MyService/MyService.rem";
RemotingConfiguration.RegisterWellKnownClientType(new WellKnownClientTypeEntry(typeof(IMyService), uri));
remoteServer = (IMyService)Activator.GetObject(typeof(IMyService), uri);

Any idea what may I be doing wrong? Or at least how do I start debugging this issue.

Tomasz Grobelny
  • 2,666
  • 3
  • 33
  • 43
  • Can you post your configuration code for the server and client ends of the channel. Are you sure you are running as LocalSystem and not and not LocalService? – csaam Jan 16 '14 at 02:43
  • The service is running as Local System - task mgr shows it as SYSTEM. – Tomasz Grobelny Jan 16 '14 at 20:43

1 Answers1

0

I know we all hate this answer but it worked for me.

I made an interface IMyService with a single method Ping. Then I implemented it and added your client code to it's constructor since I see you register this as the service in the Marshal call:

public class MyService : MarshalByRefObject, IMyService
{
    private IpcChannel channel;
    public MyService()
    {
        var clientProv = new BinaryClientFormatterSinkProvider();
        var serverProv = new BinaryServerFormatterSinkProvider() { TypeFilterLevel = TypeFilterLevel.Full };
        Hashtable channelProperties = new Hashtable();
        channelProperties.Add("portName", "MyService");
        channelProperties.Add("authorizedGroup", "Administrators");
        channelProperties.Add("secure", "true");
        channelProperties.Add("exclusiveAddressUse", false);
        channel = new IpcChannel(channelProperties, clientProv, serverProv);
        ChannelServices.RegisterChannel(channel, false);
        RemotingServices.Marshal(this, "MyService.rem");
    }
    public string Ping(string value)
    {
        return value;
    }
}

I constructed member variable MyService in the NT service OnStart method.

After installing the service as LocalSystem and starting it I ran the client code:

class Program
{
    static void Main(string[] args)
    {
        var clientProv = new BinaryClientFormatterSinkProvider();
        var serverProv = new BinaryServerFormatterSinkProvider() { TypeFilterLevel = TypeFilterLevel.Full };
        Hashtable channelProperties = new Hashtable();
        channelProperties.Add("portName", "remotingClient_" + Guid.NewGuid().ToString("N"));
        channelProperties.Add("authorizedGroup", GetNameForSid(WellKnownSidType.LocalSystemSid));
        channelProperties.Add("exclusiveAddressUse", false);
        channelProperties.Add("secure", "true");
        channelProperties.Add("tokenImpersonationLevel", "identification");
        IpcChannel channel = new IpcChannel(channelProperties, clientProv, serverProv);
        ChannelServices.RegisterChannel(channel, false);

        var uri = "ipc://" + "MyService/MyService.rem";
        RemotingConfiguration.RegisterWellKnownClientType(new WellKnownClientTypeEntry(typeof(IMyService), uri));
        IMyService remoteServer = (IMyService)Activator.GetObject(typeof(IMyService), uri);
        Console.WriteLine(remoteServer.Ping("Hello World"));
    }
    private static string GetNameForSid(WellKnownSidType wellKnownSidType)
    {
        SecurityIdentifier id = new SecurityIdentifier(wellKnownSidType, null);
        return id.Translate(typeof(NTAccount)).Value;

    }
}

Ping is just an echo really and Console.WriteLine output "Hello World".

Is it possible that the user really isn't in the admin group of the local machine or is it possible that MyService is doing something it itself doesn't have an permission to do and what your seeing is a server side exception? For instance LocalServer doesn't have access to Network Resources.

csaam
  • 1,349
  • 9
  • 9
  • "user really isn't in the admin group of the local machine" - it for sure is (at least when I check in Control Panel-> Admininistrative Tools->Computer Management->Local Users and Groups). However, it seems UAC plays a role here: if I turn it off (EnableLUA to 0 in registry) then it all works as expected (but obviously this is not a solution). – Tomasz Grobelny Jan 19 '14 at 15:22