HTTP-запрос неавторизован с помощью схемы аутентификации клиента "Ntlm"
При вызове веб-службы я получаю следующую ошибку:
HTTP-запрос неавторизован с помощью схемы аутентификации клиента "NTLM". Заголовок аутентификации, полученный с сервера, был "NTLM". HTTP-запрос неавторизован с помощью схемы аутентификации клиента "NTLM". Заголовок аутентификации, полученный с сервера, был "NTLM".
У меня есть приложение Silverlight 4, которое вызывает веб-службу WCF, как на моем IIS (7).
мой веб-сервис WCF вызывает другую веб-службу ASMX, установленную на другом веб-сервере, используя NTLM (аутентификация Windows).
Оба сервера, мой и один, обслуживающий веб-службу ASMX, находятся в одном домене.
Когда клиент Silverlight открывает приложение с сервера с помощью http://localhost/MySiteName
, все работает отлично. Но когда клиент Silverlight открывает приложение с другого клиента, который не является сервером, но все еще находится в том же домене, используя http://MyServerName/MySiteName
, я получаю сообщение об ошибке.
Аутентификация Windows включена в моем IIS.
Анонимная аутентификация отключена в моем IIS.
Конфигурация привязки для вызова моей веб-службы WCF:
<binding name="winAuthBasicHttpBinding">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</binding>
Конфигурация привязки для вызова веб-службы ASMX:
<binding name="ClNtlmBinding">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" />
</security>
</binding>
Ответы
Ответ 1
ОК, вот что приходит в голову:
- Ваша служба WCF, предположительно работающая на IIS, должна работать в контексте безопасности, который имеет привилегию, вызывающую веб-службу. Вы должны убедиться в том, что в пуле приложений есть пользователь, который является пользователем домена - в идеале выделенный пользователь.
- Вы не можете использовать олицетворение, чтобы использовать токен безопасности пользователя, чтобы вернуться к ASMX, используя олицетворение, поскольку
my WCF web service calls another ASMX web service, installed on a **different** web server
- Попробуйте изменить
Ntlm
на Windows
и снова проверьте.
ОК, несколько слов о олицетворении. В основном это известная проблема: вы не можете использовать токены олицетворения, которые вы получили на одном сервере, чтобы перейти на другой сервер. Причина в том, что токен является своего рода хешем, использующим пароль пользователя и действительным для машины, сгенерированной из-за того, что он не может использоваться с среднего сервера.
UPDATE
Делегирование возможно под WCF (т.е. пересылка олицетворения с сервера на другой сервер). Посмотрите на эту тему здесь.
Ответ 2
Это долгое время, когда вопрос был опубликован, но я столкнулся с той же проблемой в аналогичном сценарии. У меня есть консольное приложение, и я потребляю веб-службу, а наш сервер IIS, на котором размещен веб-сервис, имеет проверку подлинности Windows (NTLM).
Я следил за этой ссылкой и это исправило мою проблему. Здесь пример кода для App.config
:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="Service1Soap">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" proxyCredentialType="None"
realm=""/>
<message clientCredentialType="UserName" algorithmSuite="Default"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost/servicename/service1.asmx"
binding="basicHttpBinding" bindingConfiguration="ListsSoap"/>
</client>
</system.serviceModel>
Ответ 3
Для меня решение было, кроме того, использовать "Ntlm" в качестве типа учетных данных, аналогично решению Jeroen K. Если бы у меня был уровень разрешений, я бы плюнул на его пост, но позвольте мне разместить здесь весь мой код, который будет поддерживать как Windows, так и другие типы учетных данных, такие как basic auth:
XxxSoapClient xxxClient = new XxxSoapClient();
ApplyCredentials(userName, password, xxxClient.ClientCredentials);
private static void ApplyCredentials(string userName, string password, ClientCredentials clientCredentials)
{
clientCredentials.UserName.UserName = userName;
clientCredentials.UserName.Password = password;
clientCredentials.Windows.ClientCredential.UserName = userName;
clientCredentials.Windows.ClientCredential.Password = password;
clientCredentials.Windows.AllowNtlm = true;
clientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
}
Ответ 4
Мне пришлось переместить домен, имя пользователя, пароль из
client.ClientCredentials.UserName.UserName = домен + "\\" + имя пользователя; client.ClientCredentials.UserName.Password = пароль
к
client.ClientCredentials.Windows.ClientCredential.UserName = имя пользователя; client.ClientCredentials.Windows.ClientCredential.Password = пароль; client.ClientCredentials.Windows.ClientCredential.Domain = domain;
Ответ 5
1) Мне пришлось сделать следующее с моей конфигурацией: (Добавить BackConnectionHostNames или Отключить проверку Loopback)
http://support.microsoft.com/kb/896861
2) Я работал над системой dev в изолированной сети dev. Я работал с использованием имени компьютера системы dev в URL-адресе веб-службы, но когда я изменил URL-адрес URL-адреса, который будет использоваться в процессе производства (а не имени компьютера), я начал получать ошибку NTLM.
3) Я заметил, что журнал безопасности показал, что учетная запись службы не может войти с ошибкой, аналогичной ошибке в статье MSDN.
4) Добавление BackConnectionHostNames сделало его таким, чтобы я мог войти на сервер через браузер, работающий на сервере, но учетная запись службы по-прежнему имела ошибки NTLM при попытке аутентификации для веб-служб. Я отключил проверку цикла и установил ее для меня.
Ответ 6
Возможно, вы можете обратиться к: http://msdn.microsoft.com/en-us/library/ms731364.aspx
Мое решение состоит в том, чтобы изменить 2 свойства
authenticationScheme и proxyAuthenticationScheme в "Ntlm", а затем он работает.
PS: Моя среда следующая.
- Серверная сторона:.net 2.0 ASMX
- Клиентская сторона:.net 4