Не уверен, что правильно выбрал форум для этом проблеммы, но всё-таки.

Исходные данные:
Windows Server 2003

Есть .NET Windows service, к которому можно подключится через IpcChannel:

IDictionary prop = new Hashtable();
prop["portName"] = "IpcServicePort";
prop["authorizedGroup"] = ConfigurationManager.AppSettings["ClientAuthorizedGroup"];
prop["name"] = "ipcService";
prop["impersonationLevel"] = "None";

IpcServerChannel chan = new IpcServerChannel(prop, null);
ChannelServices.RegisterChannel(chan, false);

RemotingConfiguration.RegisterWellKnownServiceType(
    typeof (SubmitAlertServiceProxy),                            
    "SubmitAlertService",
    WellKnownObjectMode.Singleton);

authorizedGroup задаётся обычно "Everyone", но я перепробовал разные — без успеха.

Есть .NET dll, которая позволяет связываться с этим сервисом, одновременно предоставляя COM интерфейс для не .NET клиентов.
Код соединения:

submitAlertService = (ISubmitAlertService)Activator.GetObject(typeof (ISubmitAlertService), "ipc://IpcServicePort/SubmitAlertService");

Проблемма в том, что все возможные .NET клиенты (включая ASP.NET процессы), а также обычное VB6 приложение (через COM interop) замечательно работают под любыми аккаунтами.
Единственно, ASP (old ASP) приложение при попытке соединия всегда выдаёт ошибку: Failed to connect to an IPC Port: Access is denied. — т.е. ошибка доступа к данной Named Pipe.
Никакое изменение прав приложения (включая запуск под админским аккаунтом не помагают). Возможно IIS как-то дополнительно ограничевает права процесса вне зависимости от использованного аккаунта? Облазил наверно все возможные источники в сети по данному вопросу, но везде как правило рассматривается проблемма с ASP.NET приложением

Буду благодарен любой помощи.

Здравствуйте, Curufinwe, Вы писали:

Я долго мучался со всякими Ipc и в результате у меня получился подобный smippet

private static bool InitIpcChannel()
        {
            SecurityIdentifier Sid = new SecurityIdentifier(WellKnownSidType.WorldSid, null);
            NTAccount Account = (NTAccount)Sid.Translate(typeof(NTAccount));

            BinaryServerFormatterSinkProvider serverProv = new BinaryServerFormatterSinkProvider();
            serverProv.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;
            BinaryClientFormatterSinkProvider clientProv = new BinaryClientFormatterSinkProvider();
            //clientProv.
            IDictionary properties = new Hashtable();
            properties["name"] = "ipc";
            properties["priority"] = "20";
            properties["portName"] = "Lalalalala");
            properties["authorizedGroup"] = Account.Value;            


            try
            {                
                iChannel = new IpcChannel(properties, clientProv, serverProv);
                ChannelServices.RegisterChannel(iChannel, false);                
            }
            catch
            {
                Log.Write("Cannot register IPC chanel");
                return false;
            }            

            return true;
        }

Здравствуйте, arkhivania, Вы писали:

A>Здравствуйте, Curufinwe, Вы писали:

A>Я долго мучался со всякими Ipc и в результате у меня получился подобный smippet

Спасибо, но мне увы не помогло. Боюсь тут проблемма скорее на уровне named pipes/windows security/IIS.

Попробовал TcpChannel, вроде работает. Конечно немного криво для локального общения

Здравствуйте, Curufinwe,

у меня совершенно идентичная ситуация, вот уже который день бьюсь в поисках решения...
Удалось ли вам решить эту проблему?
Буду крайне признателен за любую помощь,

Влад

Здравствуйте, Bolzen, Вы писали:

B>у меня совершенно идентичная ситуация, вот уже который день бьюсь в поисках решения...
B>Удалось ли вам решить эту проблему?
B>Буду крайне признателен за любую помощь,

Увы, времени было мало, поэтому не найдя нормального решения пришлось использовать TcpChannel

А если попробовать вот такой код?

На сервере:

..
SecurityIdentifier si = new SecurityIdentifier(WellKnownSidType.WorldSid, null);
IdentityReference ir = si.Translate(typeof(NTAccount));

IDictionary props = new Hashtable();
props["name"] = channelName;
props["portName"] = channelName;
props["tokenImpersonationLevel"] = TokenImpersonationLevel.Identification;
props["includeVersions"] = false;
props["strictBinding"] = false;
props["secure"] = true;
props["authorizedGroup"] = ir.Value;

IpcServerChannel channel = new IpcServerChannel(props, null);
ChannelServices.RegisterChannel(channel, true);
RemotingConfiguration.RegisterWellKnownServiceType(objectType, SERVER_CHANNEL_NAME, WellKnownObjectMode.Singleton);
..

На клиенте:
..
string channelName = CLIENT_CHANNEL_NAME + "_" + Guid.NewGuid().GetHashCode();
IDictionary props = new Hashtable
{
{"name", channelName},
{"impersonationLevel", TokenImpersonationLevel.Identification}
};
IpcClientChannel clientChannel = new IpcClientChannel(props, null);

ChannelServices.RegisterChannel(clientChannel, true);
..

Здравствуйте, Аноним,

к сожалению нет. Очень похоже, что дело не в том, как регистрировать канал, потому что IPC прекрасно работает из консольного приложения, но при этом ни в какую и ни при каких конфигурациях из-под IIS, если создавать объект в PHP или ASP.
Путём нехитрых тестов выяснил, что виной всему logon type. Всё отлично, если юзер использовал INTERACTIVE logon и IPC просто перестает работать (Failed to connect to an IPC Port: Access is denied.), если был использован NETWORK logon type, что и происходит в IIS. При всём при этом TCP канал работает нормально при любом logon type, а IPC не хочет работать ни с Impersonation ни с Identification ни даже с non-secure каналом в случае с network logon. Интересно, это баг или фича?..

Влад

Здравствуйте, Curufinwe, Вы писали:

C>Не уверен, что правильно выбрал форум для этом проблеммы, но всё-таки.

C>Исходные данные:
C>Windows Server 2003

C>Есть .NET Windows service, к которому можно подключится через IpcChannel:

Я коннектился к pipe, открытому в сервисе и да, была такая проблема. Суть ее в том, что Named Pipe — этот тот же файл и поэтому при создании Named Pipe надо указать пермишены. Вот вырезка из рабочего кода на паскале. Думаю, суть будет понятна.

        if not InitializeSecurityDescriptor (@sd, SECURITY_DESCRIPTOR_REVISION) or
        not SetSecurityDescriptorDacl (@sd, true, pAcl (nil), false) then
                ErrMsg ('Security');
        sa.nLength := sizeof(sa);
        sa.lpSecurityDescriptor := @sd;
        sa.bInheritHandle := true;

        C.HPipe := Windows.CreateNamedPipe (
                '\\.\pipe\uchet',
                PIPE_ACCESS_DUPLEX or FILE_FLAG_OVERLAPPED,
                PIPE_TYPE_MESSAGE or PIPE_READMODE_MESSAGE or PIPE_WAIT,
                PIPE_UNLIMITED_INSTANCES,
                PKT_SIZE+HDR_SIZE,
                PKT_SIZE+HDR_SIZE,
                PIPE_TIMEOUT, //timeout
                @sa);

Обратите внимание на последний параметр в функции CreateNamedPipe — это он, больной зуб.

Здравствуйте, Bolzen, Вы писали:

B>к сожалению нет. Очень похоже, что дело не в том, как регистрировать канал, потому что IPC прекрасно работает из консольного приложения, но при этом ни в какую и ни при каких конфигурациях из-под IIS, если создавать объект в PHP или ASP.
B>Путём нехитрых тестов выяснил, что виной всему logon type.

долго не читал rsdn, а то подсказал бы раньше

Наоборот, дело именно в том, КАК РЕГИСТРИРОВАТЬ канал Как решить вашу проблему смотрите в примере msdn "Remoting IpcChannel with Custom ACL Sample"

Здравствуйте, _Morpheus_, Вы писали:

_M_>долго не читал rsdn, а то подсказал бы раньше

_M_>Наоборот, дело именно в том, КАК РЕГИСТРИРОВАТЬ канал Как решить вашу проблему смотрите в примере msdn "Remoting IpcChannel with Custom ACL Sample"

Спасибо за ссылку, но проблема не исчезла. В примере используется unsecure channel, что не позволяет определить какой пользователь вызвал функцию по IPC, потому что props["tokenImpersonationLevel"] = TokenImpersonationLevel.Identification; имеет смысл только для secure канала.
При использовании IPC remoting из-под IIS получаем неизменный "access denied" при том, что консольное приложение, запущенное под тем же пользователем, работает отлично.