Невнимательность + кривые руки + новые технологии = OWA\ECP Logon Loop.

Microsoft меня постоянно развлекает своими новыми технологиями. То супер-пупер-современная-и-надежная ReFS, которая падает от неаккуратного прикосновения в непонятное что-то, которое потом без резервной копии и не восстановить (ситуация относится к Windows Server 2012, новую итерацию я еще не пробовал), то истерики Exchange от криптографии нового поколения (Cryptography Next Generation, CNG). И вроде бы все эти моменты известны, но есть нюансы, как обычно.

Разворачивал я тут недавно новый сервер Exchange, и решил выписать ему сертификат новым модным способом (обычно я использую либо запрос с помощью New-ExchangeCertificate, либо запрос с помощью certreq -new и файла request.inf, а тут меня научили запрашивать его прямо из MMC с помощью мастера Create Custom Request). То ли я был уставший, то ли не выспавшийся, но накосячил знатно.

В запросе без использования шаблона есть три принципиальных момента:

  1. Надо указать формат хранения ключа, и по дефолту это CNG, да. Т.е. обязательно надо сменить тип на Legacy Key. Сначала я думал, что я это сделал, но сейчас уже не уверен…
  2. В Extended Key Usage указать Server Authentication, как минимум. Тоже сделал.
  3. И в KeyType указать Exchange (не тот Exchange, это Exchange от PKI). И вот тут я забылся… А по умолчанию там Signature.

И в итоге вы получите готовый запрос в формате PKCS#10, который можно скормить выдающему CA с помощью certreq -submit. Но, т.к. у вас не указан шаблон в запросе, то шаблон нужно будет указать руками, например вот так: certreq -submit -attrib ‘CertificateTemplate:WebServer’ <Путь к файлу запроса>

Но обращаю внимание, что СА плевать хотел на определения шаблона, если вы скармливаете ему кастомный файл запроса. Т.е. он плевал на криптопровайдера, на возможность экспорта ключа и т.п. Т.е. то, что в запросе имеет приоритет.

В итоге я получил сертификат и повесил его на IIS. И вот тут меня настигло что-то под названием OWA\ECP Logon Loop. Это такая ситуация, что при вводе логина\пароля в форму FBA, вас постоянно возвращает к вводу логина\пароля. Поведение это описано в статье базы знаний (https://support.microsoft.com/en-us/kb/3032024) и в блоге Jason Slaughter (https://blogs.technet.microsoft.com/jasonsla/2015/01/15/the-one-with-the-fba-redirect-loop). Но я же был свято уверен, что у меня никакой не CNG, а обычный простенький сертификатик из старенького СА, до модернизации которого все не дойдут руки…

Станкевич говорит: Если у тебя проблемы с Kerberos – смотри на DNS. Если DNS в порядке… снова смотри на DNS.

То же самое он говорит и про эту ситуацию: смотри на сертификат. Если с ним все в порядке – еще раз посмотри на сертификат. И потом еще.

Фишка в том, что внешне сертификат выглядит идеальным: имена, SAN, доверие – ну все, как на картинке. Дьявол кроется глубже:

Надо его проверить с помощью certutil. Проверяется он так: certuril -store my <Serial Number> (если сертификат установлен в Personal Store сервера) или так certutil <Путь к файлу сертификата> (если сертификат не установлен).

Если видите строчку Provider = Microsoft Software Key Storage Provider – Хьюстон, у нас проблемы. Это и есть тот самый проклятый CNG. Должно быть Provider = Microsoft RSA SChannel Cryptographic Provider или, на худой конец, Provider = Microsoft Strong Cryptographic Provider (провайдер так же выбирается на уровне формирования запроса, но он не влияет на CNG\Legacy, для каждого типа свой набор провайдеров и они не пересекаются)

Меняете сертификат на «нормальный» и все заводится.

Куда еще можно посмотреть для диагностики? Посмотрите в лог HttpProxy/OWA, например. Или в лог IIS для Front-End. Там можно увидеть характерные записи вида «CorrelationID=<empty>;NoCookies=302».

Можно посмотреть что происходит с помощью Fiddler, там видно вот такую последовательность (HTTP Method, Path, StatusCode), которая начинает зацикливаться:

GET, /owa, 302

GET, /owa/auth/logon.aspx, 200

GET, /owa/auth/logon.aspx, 200

POST, /owa/auth.owa, 302

GET, /owa, 302

В общем вот такие дела бывают… И еще раз процитирую Сашу Станкевича: видишь OWA Logon Loop – смотри в сертификаты. С вероятностью в 99% корень проблемы в нем.

Реклама
Невнимательность + кривые руки + новые технологии = OWA\ECP Logon Loop.

Невнимательность + кривые руки + новые технологии = OWA\ECP Logon Loop.: 15 комментариев

  1. Хехехе, добро пожаловать в клуб! Когда Паша с месяц назад с темже пришел, с типа-опа, я его сразу отругал- а зачем, мол не командлетом выписывал? От этого все зло :)

  2. Небольшая поправочка. Я говорил: «Скорее всего проблема в сертификате. Если ты уверен, что проблема не в нём, то скорее всего проблема в сертификате!». Вот :) .

  3. Олега, ты прости, но это не CNG проклятый, а эксчендж-тим, который за 10(!) лет так и не запилил поддержку православного CNG. Доколе можно терпеть хлам времён NT4 (я про CAPI1)? На дворе 21-й век, всё-таки.

    > Т.е. он плевал на криптопровайдера, на возможность экспорта ключа и т.п.

    не то, чтобы плевал. Он про это ничего не знает. В запросе могут быть опциональные атрибуты, но это для администратора, а не для CA.

    > Microsoft RSA SChannel Cryptographic Provider

    имхо, Microsoft Enhanced RSA and AES Cryptographic Provider лучше будет. У него шире поддержка по алгоритмам и ключам.

  4. >Олега, ты прости, но это не CNG проклятый, а эксчендж-тим, который за 10(!) лет так и не запилил поддержку православного CNG.
    Вадя, это профдеформация у меня во всей красе. Exchange — он привычный и родной, а этот ваш модный CNG с ним не работает :) Хотя я, конечно же, понимаю, что корень зла не в команде PKI.
    По остальным пунктам скажу только, что я не настоящий пикиайщик, я только учусь :)

  5. Я бы сказал, что эта проблема ни к CNG ни к Exchange’у напрямую не относится — она вообще платформенная, ибо .NET, с точки зрения криптографии, очень отстаёт от новомодных тенденций. Ну а так как Exchange жиздится на нём по полной программе, вот и соответствующий эффект.

  6. Ну так все в отстающих, (а я бы добавил) — Exchnange 2016,TMG, ADFS 2012R2, Lync/S4Bда даже ни в богомерзкой Vmware 6.0 нет поддержки супер новой CNG, который православный, но всеми вышеперечисленными продуктами не поддерживаемый. Мир жесток. :)

  7. Это, типа, шутка или просто неправильно прочитанное выше :) ?
    А Дима заработал 100 баллов ;) !

  8. Саша всё правильно написал про дотнеты и производные от него. Но я бы не сказал, что CNG — какой-то суперновомодный. Ему 10 лет уже. И это не CNG с эксченджем не дружит, а наоборот. Потому что все, кто юзают нативные COM’ы (например, тот же аутлук) или нативные функции Win32 — те с CNG дружат по умолчанию. Даже аутлук 2003 (которому чуть больше, чем 10 лет) умеет CNG (если установлен на висте и выше).

  9. Тоже полностью согласен. А «новомодные тенденции» мне нужно было взять в кавычки :) .

  10. Он такой же «суперновомодный», как и IPv6. Которому тоже 15 лет, в обед, но его хоть начинают использовать, а с CNG даже конь не валялся. В общем- все тлен.:) А сто баллов то за что, за ПравдуЪ?

  11. Не-не-не. CNG используют тоже. Например, по умолчанию начиная с Windows Server 2008, CA сервер использует провайдер CNG для ключей. И тому есть ряд важных причин. Как минимум, чтобы использовать SHA2 подписи. И CNG решает ряд других важных вопросов (которые большинству людей не кажутся очевидными).

  12. Александр:

    Хм. Делал недавно ровно то же самое. Запрос сертификата из MMC, в качестве Крипто-провайдера «Microsoft Software Key Storage Provider». Т.е. по идее должны были бы быть проблемы. Но их нет. Логон проходит штатно. Версия Exchange 14.3 (Build 123.4).

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

w

Connecting to %s