Проверка подлинности вызова службы WCF

Я пытаюсь вызвать веб-службу Sharepoint через WCF изнутри .ASHX на другом сервере. Мой код работает, если я запускаю внутри веб-сервера отладки Visual Studio, но не из IIS. Рабочий сервер работает в различных режимах аутентификации (Kerberos, NTLM), а нерабочий не работает ни в одном. Я выдаю себя за одного и того же пользователя в обоих случаях.

Используя NTLM, я записал рабочую сессию и нерабочую сессию в Wireshark. В рабочем Wireshark анализирует данные NTLM и сообщает ДОМЕН и ИМЯ ПОЛЬЗОВАТЕЛЯ, которые я ожидаю. В нерабочем показывает

  DOMAIN: NULL
  USER NAME: NULL

Я провел отладку в IIS, и олицетворение определенно работает в момент вызова службы. Если я отмечу WindowsIdentity.GetCurrent(), это пользователь, которого я ожидаю.

Если я проверю прокси службы WCF на рабочем и нерабочем серверах, они выглядят одинаково — часть, которая имеет дело с ClientCredentials, имеет значение "" для имени пользователя и пароля для обеих версий.

Есть идеи, что еще проверить? Почему в данных NTLM для ДОМЕНА и ИМЯ ПОЛЬЗОВАТЕЛЯ установлено значение NULL - откуда он это берет?


iis wcf ntlm
person Lou Franco    schedule 22.05.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Согласно этому:

http://support.microsoft.com/kb/207671

Когда IIS обслуживает HTTP-запрос, IIS выполняет олицетворение, чтобы доступ к ресурсам для обработки запроса был соответствующим образом ограничен. Олицетворенный контекст безопасности основан на типе проверки подлинности, выполненной для запроса. Пять различных типов проверки подлинности, доступных в IIS 4.0:

Authentication Type                          Impersonation Type
------------------------------------         ---------------------
Anonymous Access (no authentication)         Network
Auto Password Synchronization is
ON (ON=default)

Anonymous Access (no authentication)         IIS Clear Text
Auto Password Synchronization is OFF         

Basic Authentication                         IIS Clear Text 

NT Challenge/Response Authentication         Network 

Client SSL Certificate Mapping               Interactive

В моем случае у меня есть сетевой токен, но

Сетевым токенам НЕ разрешен доступ к сетевым ресурсам. (Сетевые токены названы так, потому что этот тип токена традиционно создается сервером, когда пользователь аутентифицируется в сети. Чтобы позволить серверу использовать сетевой токен в качестве сетевого клиента и получать доступ к другому серверу, это называется «делегирование» и считается возможной дырой в безопасности.)

В базе знаний есть много возможных способов избежать проблемы

person Lou Franco    schedule 23.05.2012