2016-06-24 7 views
0

У меня проблема с аутентификацией NLTM в Microsoft Exchange 2010. Я создаю приложение для извлечения некоторых данных из EWS Exchange и с тех пор, как у меня включен NTLM на Exchange сервер. Мне нужно убедиться, что мои запросы следуют процедуре рукопожатия NTLM. Я исследовал процедуру, и я понимаю, что она состоит из шести шагов, которые делают 4-стороннее рукопожатие. Ниже приводится поясненный ниже фрагмент ниже:Проблема NTLM не работает или находится не в правильном порядке, к Exchange 2013

1: C --> S GET ... 

2: C <-- S 401 Unauthorized 
       WWW-Authenticate: NTLM 

3: C --> S GET ... 
       Authorization: NTLM <base64-encoded type-1-message> 

4: C <-- S 401 Unauthorized 
       WWW-Authenticate: NTLM <base64-encoded type-2-message> 

5: C --> S GET ... 
       Authorization: NTLM <base64-encoded type-3-message> 

6: C <-- S 200 Ok 

Письмо C обозначает клиента, а буква S обозначает сервер. Более подробную информацию о NLTM можно найти here, которую я также использую для справки.

Таким образом, клиент выдает запрос GET, на который сервер отвечает 401, сообщая клиенту, что ему нужно идентифицировать себя. Он также отправляет метод проверки подлинности в соответствующий заголовок, который в этом случае является NTLM. Затем клиент отправляет то, что известно как сообщение типа 1, которое содержит имя хоста и доменное имя клиента. Затем сервер отвечает так называемым сообщением типа 2, которое содержит вызов NTLM. Затем клиент отвечает другим запросом, Type-3 Message, которое содержит имя пользователя, домен, имя хоста и два ответа.

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

Теперь, чтобы проверить, что я могу отправлять запросы через NTLM в направлении EWS, я использовал инструмент под названием SoapUI, чтобы отправить мой запрос SOAP. SoapUI имеет встроенную функцию для обработки NTLM, поэтому я просто вводил имя пользователя, пароль и домен там, и он обрабатывает рукопожатие NTLM с сервером при отправке запроса. Теперь все это прекрасно работает через SoapUI, запросы проходят через рукопожатие, и в итоге я получаю ответ от сервера 200. Чтобы показать это, я использовал Microsoft Message Analyzer для проверки входящих и исходящих HTTP-запросов. Это запросы между SoapUI и сервером, которые произошли, когда я отправил исходный запрос из SoapUI.

SoapUI request

Как вы можете видеть, что эти запросы следуют выше диаграммы в том виде, в котором рукопожатие, как предполагается, произойдет.

Теперь, поворотный момент. Я делаю все это, теоретически то же самое, через мое приложение. В приложении на основе Node я использую библиотеку this для отправки запросов в EWS, в свою очередь, она также использует библиотеку this для обработки рукопожатия NTLM. Поэтому, кроме меня, чтобы указать имя пользователя, пароль, URL, домен и имя хоста, я ничего не могу сделать, чтобы сломать это. Поэтому я отформатирую свой запрос с помощью библиотеки и выдаю его только, чтобы убедиться, что он не может пройти аутентификацию через NTLM. Я заглянул в обе эти библиотеки, и я вижу, что httpntlm следует протоколу квитирования NTLM и, в конце концов, отправляет соответствующий токен NTLM, но я не могу понять, что не так. Вот как выглядит поток HTTP, когда я выдаю запрос из своего приложения.

Application HTTP

Теперь, просто посмотрев на это, предыдущее изображение, которое вы можете обнаружить различия. Прежде всего, первоначальный запрос и ответ, которые не имеют заголовков аутентификации, отсутствуют. Я не уверен, что они являются необязательными в этом рукопожатии NTLM, поэтому библиотека опускает их, а SoapUI нет?

Также почему второе изображение заголовок аутентификации для NTLMv2 во втором изображении и только для NTLM в первом. Я знаю, что есть две версии NTLM, и у меня они оба включены на сервере, но почему в запросах это иначе указано. Я не могу найти ни одну из библиотек, определяющих NTLMv2.

Во втором изображении также кажется, что сообщение типа 2, возможно, никогда не было ответом с сервера?

В любом случае, я не могу понять, что здесь происходит и почему это основное отличие в потоке http. Любая помощь будет оценена по достоинству.

ответ

0

Обновлена ​​поддержка NTLMv2 для [email protected]. см. [email protected] модуль для этого. Вы можете установить 1.2.0 и использовать пример на странице github.

@next - это тег сборки для ews-javascript-api, который скоро будет выпущен из dev (дорожка milestone 0.9 на github).

Открытые вопросы для этого в guthub для более быстрого разрешения.

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

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