Почему WinINET переключается с использования Kerberos на NTLM при ответе на запрос аутентификации при использовании проверки подлинности Windows?
В настоящее время мы проводим тестирование среды Sharepoint, размещенной в IIS8.5 (в Windows 2012R2), с использованием Loadrunner 11.52. Мы используем механизм воспроизведения на основе WinINET, так как при попытке использовать реализацию сокетов LR возникли проблемы с SSL.
Аутентификация для сайта настроена так, чтобы разрешить аутентификацию Windows. Все пользователи являются уникальными пользователями Active Directory.
У нас есть проблема, когда после запуска 50 пользователей пользователи начинают отказывать из-за невозможности аутентификации.
Мы зафиксировали как успешную (первые 50 пользователей) аутентификацию, так и неудачную (пользователи после первых 50) аутентификацию с использованием Fiddler.
При первоначальной загрузке веб-страницы сервер возвращает 401 с заголовками аутентификации, как и ожидалось:
Запрос:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Отклик:
HTTP/1.1 401 Unauthorized
Content-Type: text/plain; charset=utf-8
Server: Microsoft-IIS/8.5
SPRequestGuid: ad71f69c-0b10-d049-46c6-1f0b1f7bd574
request-id: ad71f69c-0b10-d049-46c6-1f0b1f7bd574
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 2
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:13:44 GMT
Content-Length: 16
Proxy-Support: Session-Based-Authentication
401 UNAUTHORIZED
Затем WinINET обрабатывает это соответствующим образом, возвращая маркер авторизации Kerberos, который принимает сервер:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate YIISMQYGKwYBBQUCoIISJTCCEiGgMDAuB...<long-auth-token-string>...=
Отклик:
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/html; charset=utf-8
Expires: Wed, 11 Mar 2015 07:13:44 GMT
Last-Modified: Thu, 26 Mar 2015 07:13:44 GMT
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5
X-SharePointHealthScore: 0
X-AspNet-Version: 4.0.30319
SPRequestGuid: ad71f69c-db17-d049-46c6-15c51828a26e
request-id: ad71f69c-db17-d049-46c6-15c51828a26e
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 40
SPIisLatency: 0
WWW-Authenticate: Negotiate oYGzMIGwoAMKAQChCw...<long auth token>...=
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:13:44 GMT
Content-Length: 80492
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html dir="ltr" lang="en-US">
<head><meta name="GENERATOR" content="Microsoft SharePoint" /><
...
Некоторые из Google предположили, что "YIIS" в начале токена авторизации указывает, что он выбрал Kerberos в ответ на Negotiate вариант аутентификации. Это прекрасно работает для первых 50 пользователей, которых мы запускаем (каждый с уникальными учетными данными пользователя AD).
Однако для 51-го пользователя и каждого последующего пользователя WinINET начинает пытаться использовать вместо этого проверку подлинности NTLM, которую сервер отклоняет. Запрос (такой же, как ранее успешный пользователь):
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Ответ (такой же, как у ранее успешного пользователя):
HTTP/1.1 401 Unauthorized
Content-Type: text/plain; charset=utf-8
Server: Microsoft-IIS/8.5
SPRequestGuid: 6a71f69c-6b4f-d049-46c6-1e90257415f1
request-id: 6a71f69c-6b4f-d049-46c6-1e90257415f1
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 1
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 16
Proxy-Support: Session-Based-Authentication
401 UNAUTHORIZED
Затем клиент отправляет запрос на авторизацию:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate TlRMTVNTUAABAAA...<short NTLM auth token>...==
Некоторое гугление предполагает, что T1R в начале токена авторизации означает, что на этот раз он решил использовать NTLM вместо Kerberos, который использовался для всех пользователей вплоть до этого.
Сервер отвечает еще 401 на это:
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate TlRMTVNTUAACAAAACAAIADgAAAAVgonicMgf76hzy7QAAAAAAAAAAL4AvgBAAA...<long NTLM auth token>=
SPRequestGuid: 6a71f69c-cb6b-d049-46c6-14cbc16d1ea9
request-id: 6a71f69c-cb6b-d049-46c6-14cbc16d1ea9
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 1
SPIisLatency: 0
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 0
Proxy-Support: Session-Based-Authentication
Затем Wininet отправляет еще один запрос на аутентификацию следующим образом:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAKIAAACEAYQBu...<much longer NTLM token>...=
Что приводит к другому 401:
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5
SPRequestGuid: 6a71f69c-cb6b-d049-46c6-18ce53703ae9
request-id: 6a71f69c-cb6b-d049-46c6-18ce53703ae9
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 236
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 0
Proxy-Support: Session-Based-Authentication
В этот момент WinINET, кажется, сдается, и передает 401 в LoadRunner, который затем отказывает пользователю.
Первые 50 пользователей продолжают работать в обычном режиме. Мы также можем загрузить другого пользователя вручную через IE, пока эти 50 еще работают. Мы также можем подождать некоторое время, и в конечном итоге мы сможем запустить больше пользователей.
Итак, здесь, кажется, есть две проблемы:
- Почему WinINET меняет использование NTLM-аутентификации вместо Kerberos после запуска 50 пользователей?
- Почему сервер отклоняет аутентификацию NTLM.
Буду очень признателен за любые идеи о том, что может быть причиной этого и / или как я могу продолжить расследование. Я подозреваю, что это может быть какой-то лимит Active Directory, который блокирует работу Kerberos на период после того, как 50 пользователей прошли аутентификацию, однако я не знаю, как это доказать / опровергнуть.
Благодарю.