Настройка имени участника-службы в адресе конечной точки для конечной точки службы NetNamedPipe

Я получаю сообщение об ошибке «Не было прослушивания конечной точки на net.pipe://localhost», как описано в других местах, но я не могу найти реальный ответ.

Это отличный идентификатор проблемы: http://kennyw.com/indigo/102.

При использовании WCF проверка подлинности Windows выполняется с помощью SSPI-Negotiate, который в большинстве случаев выбирает Kerberos в качестве фактического механизма проверки подлинности. Однако, если целевое имя участника-службы, переданное в SSPI, является правильно сформированным именем участника-службы для учетной записи локального компьютера (например, хост/[имя машины DNS]), то согласование будет использовать NTLM (оптимизация замыкания на себя), а маркер доступа не будет иметь сетевой идентификатор безопасности (и поэтому его можно будет использовать с NetNamedPipes).

Но он не говорит мне, как решить проблему. Я создаю свою конечную точку программно.

var binding = new NetNamedPipeBinding();
binding.Security.Mode = NetNamedPipeSecurityMode.Transport;
binding.Security.Transport.ProtectionLevel = ProtectionLevel.EncryptAndSign;

var id = EndpointIdentity.CreateSpnIdentity("host/" + Environment.MachineName);
var endpointAddress = new EndpointAddress(new Uri(serviceClientUrl), id);

var client = new ServiceClient(binding, endpointAddress);

Я предполагаю, что моя проблема связана с CreateSpnIdentity, но я не уверен, какое значение использовать.

Дополнительная информация. Чтобы уточнить это для большего контекста. Служба Wcf размещается как служба Windows, работающая под учетной записью NetworkService (я пробовал локальную систему). Служба создается с помощью конструктора NetNamedPipeBinding по умолчанию:

host.AddServiceEndpoint(typeof(IService), new NetNamedPipeBinding(), "ServiceName");

Я создал веб-часть SharePoint, которая использует эту службу. Суть в том, что если на сайте SharePoint настроена проверка подлинности на основе форм или в URL-адресе при проверке подлинности Windows используется только имя компьютера, то проблем не возникает. ТОЛЬКО если полное имя компьютера используется для URL-адреса при проверке подлинности Windows, я получаю указанную выше ошибку.

Я почти уверен, что это связано с проблемами NTLM Kerberos, описанными в статье, но я не знаю, как это обойти.


wcf spn netnamedpipebinding
person webwires    schedule 16.09.2010    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Установка идентификатора конечной точки на стороне клиента вам не поможет, так как проблема заключается в контексте безопасности, в котором выполняется ваш клиентский код, а не в конфигурации конечной точки. Как объясняет KennyW, если вы получаете доступ к приложению SharePoint, используя полное доменное имя компьютера, токен олицетворения в процессе веб-сервера (который обеспечивает ваше удостоверение пользователя SharePoint при проверке подлинности Windows) будет получен через Kerberos и иметь членство в группе NETWORK USERS. Если вы используете только имя компьютера, оптимизация, на которую ссылается Кенни, дает вам токен входа в систему через NTLM, который не находится в группе NETWORK USERS, и поэтому ему не отказано в доступе со стороны ACL, которые WCF помещает как в канал, так и в объект общей памяти. где сервер публикует фактическое имя канала.

Ошибка There was no endpoint listening at net.pipe://localhost... не обязательно означает, что служба WCF не прослушивает такую ​​конечную точку именованного канала: она также может (и в данном случае действительно) означать, что хотя она и есть, у вас недостаточно прав доступа, чтобы знать об этом , потому что у вас есть удаленный вход в систему.

person Chris Dickson    schedule 11.01.2011
comment
Да, я в значительной степени пришел к выводу, что Net Tcp был действительно моим единственным решением (и это нормально, потому что в конечном итоге мы переместим этот сервис на другую машину). Спасибо за понимание и ссылку. - person webwires; 14.01.2011

arrow_upward
2
arrow_downward

NamedPipe стал головной болью после усиления защиты: http://msdn.microsoft.com/en-us/library/bb757001.aspx Это фактически заставило меня перейти с NamedPipe на TCP, когда мне нужно было общаться на той же машине.

Теперь это не означает, что это ваша проблема. Если вы работаете под одной учетной записью и пытаетесь подключиться под другой учетной записью, обычно это не удается, поскольку именованные каналы больше не создаются как глобальные (если только это не LocalSys).

Мое предложение:

1) Удалите всю безопасность из вашего сервиса. В конце концов, NamedPipe работает на той же машине, и я считаю, что обычно безопасность не требуется. 2) Попробуйте подключиться. если это не удается, используйте SysInternals ProcExplorer, чтобы увидеть, какой процесс объектов запущен. Если у него есть именованная труба, то это закалка.

Если вы дадите больше информации, я смогу помочь вам больше.

person Aliostad    schedule 16.09.2010
comment
Служба размещена в службе Windows, работающей в разделе NT AUTHORITY\NetworkService. Клиент — это веб-часть SharePoint, в которой SharePoint работает с учетной записью сетевой службы. Если я обращаюсь к машине локально и использую только имя машины в качестве URL-адреса, все работает нормально. Если я добавлю полное доменное имя к URL-адресу, это не сработает. Я знаю, что это связано с тем, что сайт настроен на безопасность Windows, потому что этот код работает без проблем для других сайтов SharePoint, для которых установлен FBA. - person webwires; 17.09.2010
comment
В итоге я получил откат, используя работу Net Tcp, но мне бы очень хотелось решить эту загадку. - person webwires; 20.09.2010
comment
В этом ответе содержится немало дезинформации: (1) усиление защиты именованных каналов ОС полезно и необходимо для устранения уязвимостей безопасности; (2) WCF по-прежнему создает именованные каналы в глобальном пространстве имен: это общая память, которая публикует имя канала для клиентов, которые переходят в локальное (т. е. в пределах сеанса входа в систему), а не в глобальное пространство имен, если сервер недостаточно привилегирован (в Vista и W7). Проблема здесь не связана ни с одним из них - это связано с тем, что WCF запрещает доступ к конечным точкам именованных каналов для удаленного входа в систему. - person Chris Dickson; 11.01.2011