WCF netTcpBinding завершается ошибкой, когда IIS работает под именем пользователя домена (проверка подлинности SSPI не выполнена) - PullRequest
Новая
       48

WCF netTcpBinding завершается ошибкой, когда IIS работает под именем пользователя домена (проверка подлинности SSPI не выполнена)

0 голосов
/ 06 июня 2018

У нас есть приложение WPF, которое подключается к службам WCF, используя netTcpBinding, используя TransportWithMessageCredential безопасность с clientCredentialType, установленным на Windows для безопасности сообщений и транспорта.Пул приложений IIS выполняется под учетной записью пользователя домена.

Приведенная выше настройка работает локально просто отлично (это означает, что службы WCF и приложение WPF выполняются из одного блока).Когда приложение WPF находится в другом окне, связь не устанавливается со следующей ошибкой:

System.ServiceModel.Security.SecurityNegotiationException: согласование безопасности SOAP с net.tcp: //serv01.domain.local: 30128 / UsersService.svc 'для цели' net.tcp: //serv01.domain.local: 30128 / UsersService.svc 'не удалось.Смотрите внутреннее исключение для более подробной информации.---> System.ComponentModel.Win32Exception: ошибка аутентификации интерфейса поставщика поддержки безопасности (SSPI).Сервер может не работать в учетной записи с идентификатором «host / serv01.domain.local».Если сервер работает в учетной записи службы (например, «Сетевая служба»), укажите ServicePrincipalName учетной записи в качестве идентификатора в EndpointAddress для сервера.Если сервер работает под учетной записью пользователя, укажите UserPrincipalName учетной записи в качестве идентификатора в EndpointAddress для сервера.на System.ServiceModel.Security.WindowsSspiNegotiation.GetOutgoingBlob (байт [] incomingBlob, ChannelBinding channelbinding, ExtendedProtectionPolicy protectionPolicy) на System.ServiceModel.Security.SspiNegotiationTokenProvider.GetNextOutgoingMessageBody (сообщение incomingMessage, SspiNegotiationTokenProviderState sspiState) на System.ServiceModel.Security.IssuanceTokenProviderBase 1.GetNextOutgoingMessage(Message incomingMessage, T negotiationState) at System.ServiceModel.Security.IssuanceTokenProviderBase1. DoNegotiation (TimeSpan timeout) --- Конец трассировки стека внутренних исключений ---

Между блоками нет брандмауэра.Кроме того, когда IIS на веб-сервере использует идентификацию LocalService, связь между приложениями работает нормально.

Что может быть причиной проблем и как я могу определить основную причину?Я не вижу никаких дополнительных сообщений об ошибках в журналах событий, которые могли бы пролить некоторый свет.

1 Ответ

0 голосов
/ 06 июня 2018

Было очень трудно найти ответ, но в моем случае мне нужно было зарегистрировать мою учетную запись службы идентификации IIS с именем узла ServicePrincipalName.Ответ доступен на этой странице: http://www.getshifting.com/wiki/setupn

Что вам нужно сделать:

1) выполнить команду setspn -l domain\identity_user, где "domain\identity_user" - это учетная запись пользователя, под которой IISбежит.Когда все настроено правильно, эта команда должна вернуть вам SPN из сообщения об ошибке.В моем случае - после исправления - возвращается: 

HOST/SERV01
HOST/SERV01.DOMAIN.LOCAL

2), если список пуст, вам нужно добавить эти имена участников-служб.Прогон: 

setspn -A HOST/SERV01 domain\identity_user
setspn -A HOST/SERV01.DOMAIN.LOCAL domain\identity_user

Вот и все.

...