2014-10-16 3 views
0

У меня есть программа, написанная на VB.net, которая взаимодействует с службами передачи данных, размещенными в IIS. Аутентификация выполняется через учетные данные пользователей Active Directory. На одном из моих клиентских сайтов ровно один (из примерно 100) рабочих станций клиента запросы к службе данных терпят неудачу со статусом 401.httpwebrequest 401 ответ

Дополнительная информация: производственная установка IIS разделена на два узла , Балансировщик нагрузки направляет трафик на узлы. Точно такой же запрос, сделанный с помощью Internet Explorer с рабочей станции, не подлежит.

Я подозреваю, что что-то лишает учетные данные пользователя из запросов, когда я делаю запрос через код VB, но я в тупике относительно того, что это может быть.

Вот код VB, который я использую, чтобы сделать запрос:

Dim httpRequest As HttpWebRequest = Nothing 
    Dim httpResponse As HttpWebResponse = Nothing 

    httpRequest = WebRequest.Create("http://server/xyzportal/portal.php") 
    httpRequest.KeepAlive = False 
    httpRequest.UseDefaultCredentials = True 
    httpRequest.Method = "GET" 
    httpRequest.ContentLength = 0 
    httpRequest.Accept = "text/xml" 
    httpRequest.Timeout = 3000000 

    httpResponse = httpRequest.GetResponse 

Любые мысли будут оценены.

Дополнительная информация: здесь представлены записи журнала IIS для запроса, который терпит неудачу. Обратите внимание, что вторая запись не включает в себя имя пользователя Windows:

2014-11-11 22:20:42 199.99.51.58 GET /xyzportal/portal.php - 80 - 199.99.50.128 - 401 2 5 0 
2014-11-11 22:20:42 199.99.51.58 GET /xyzportal/portal.php - 80 - 199.99.50.128 - 401 1 2148074248 0 

Контраст, что к записям IIS для запроса от рабочей машины. Обратите внимание на 2-й вход действительно включают имя пользователя для Windows:

2014-11-11 22:56:40 199.99.51.58 GET /xyzportal/portal.php - 80 - 199.99.50.128 - 401 2 5 0 
2014-11-11 22:56:40 199.99.51.58 GET /xyzportal/portal.php - 80 MYDOMAIN\jreichert 199.99.50.128 - 200 0 0 93 

Машины с IP-адресом 199.99.50.128 является балансировкой нагрузки.

Я вхожу в систему в том же домене и на обеих машинах.

+0

Я обнаружил, что явным образом создаю учетные данные. Дим-учетные данные. Как NetworkCredential = Новый NetworkCredential (пользователь, пароль) - затем присвойте учетные данные свойству httpWebRequest.Credentials запрос успешно. Я все еще не понимаю, почему это происходит только на одной машине. –

ответ

0

Вы не сказали, но если вы используете прокси-сервер, то вы не сказали, что HttpRequest использовать учетные данные AD для прокси, и поэтому вы получаете 401 Несанкционированного ошибки, т.е. вы отказываете доступ через прокси. Если да, попробуйте это, чтобы прямо сказать это ...

HttpRequest.Proxy.Credentials = System.Net.CredentialCache.DefaultCredentials 

У меня была точно такая же проблема, и она решена.

+0

Этот ответ сам по себе не пригодится. Почему 'DefaultCredentials' адресует проблему? – neontapir

+0

Спасибо за предложение.Это решение не сработало в моем случае. FWIW Я не думаю, что запрос маршрутизируется через прокси-сервер: на рабочей станции в панели управления нет параметров прокси-сервера> Свойства обозревателя> Соединения> Настройки локальной сети. –

0

Значение keepalive должно быть равно true. Установка keepalive = true устраняет мою проблему. На следующей странице объясняет роль KeepAlive в рукопожатии аутентификации:

http://www.innovation.ch/personal/ronald/ntlm.html

Я до сих пор не уверен, почему запрос не работает на < 1% от рабочих станций в моей клиентской базе, когда KeepAlive = ложь. Все, что я знаю, устанавливает keepalive = true, поэтому запрос работает на 100% рабочих станций.

Дополнительная информация: keepalive должен быть установлен в true, если протоколом аутентификации является Kerebos. Запрос работает, если протокол аутентификации NTLM. Я не знаю, почему Kerebos используется только на двух рабочих станциях, где запрос не работает.

 Смежные вопросы

  • Нет связанных вопросов^_^