Когда я начал настраивать ADFS, то в голове мелькнула мысль: «когда всё заработает, напишу статью на Хабре, глядишь инвайт перепадёт». Но после нескольких дней возни я зашёл в тупик, решить задачу не удалось, и я решил написать эту статью в надежде, что кто то более опытный всё-таки решил эту проблему, или решение найдется в процессе обсуждения. Но это было вчера, во сне я обдумал проблему, и теперь статья про то, как я одолел ADFS. Ничего гениального, в процессе решения я понял, что во многих вопросах я «плаваю», но тем не менее, этого решения я не нашел в гугле, может я и в поиске «плаваю».
Всё началось с того, что наша компания решила внедрить Lync Online. Не буду описывать процесс внедрения, тут уже есть описание. Внедрение прошло успешно, но было несколько проблем.
Первая проблема
Проблема была связана с сертификатом на ADFS-сервере — он был выдан нашим внутренним CA. Для компьютеров в домене это не доставляло проблем, так как сертификат нашего CA через групповые политики установлен в доверенные корневые центры сертификации. Для компьютеров, не введенных в домен, проблема решалась ручным добавлением, что уже было не очень удобно. Также для этих компьютеров пришлось донастроить CA, добавив HTTP CDP в сертификат для ADFS. Но проблема встала во весь рост с мобильными устройствами, так как добавление сертификата в доверенные корневые центры сертификации не тривиально для них.
Было решено поставить имеющийся сертификат от Go Daddy на имя *.contoso.ru, только смущало, что мой домен для доверия был corp.contoso.ru, и имя ADFS-сервера было fs.corp.contoso.ru, и данный сертификат оказывался невалидным. Но оказалось, что замена сертификата и имени сервера не проблема, после чего сервер успешно стал зваться fs.contoso.ru, и проблемы с сертификатом были устранены.
Вторая проблема
Собственно она и послужила причиной написания этой статьи. Для того, чтобы ADFS работал и за пределами корпоративной сети, решили внедрять ADFS Proxy. Для его работы надо пробросить 443 порт в корпоративную сеть на ADFS Proxy-сервер. Но 443 порты оказались в дефиците, они заняты кучей сервисов.
И тут я вспомнил, что в процессе внедрения где то видел статью, в которой описывалась настройка ADFS на альтернативный порт. Нашел, стал настраивать — не работает. Поигрался с перезагрузками служб, серверов, пулов, IIS — не работает, затыкается на шаге 3, AD FS 2.0 Proxy Configuration Wizard не может соединиться с ADFS-сервером и установить доверие. Еще нашел такую статью, но там немного не те альтернативные порты, там меняются порты между ADFS и ADFSProxy, а не порты работы службы.
Битва
Решил проанализировать пакеты. Оказалось, что шаг 3 из приведенной ссылки не может быть успешно завершен, потому что не смотря ни на binding сайта, ни на настройки Set-ADFSProxyProperties -HttpsPort 444, wizard упрямо шлет запросы на 443 порт ADFS-сервера, и нет ни ключей запуска, ни файлов с конфигами, чтобы указать ему, куда надо стучаться.
Тогда я решил обойти проблему с помощью http proxy, эта опция доступна на шаге 3. Установил Application Request Routing в IIS, настроил правила роутинга запросов (типа «все запросы на порт 1555 перенаправляются на fs.contoso.ru:444), проверяю через браузеры — ура, всё работает! Запускаю wizard, указываю адрес прокси, порт 1555, запускаю тест — и снова ошибка. Смотрю запросы — wizard отправляет запрос „connect fs.contoso.ru:443“. Понятно, ARR не поддерживает connect tunneling, надо искать прокси, который поддерживает.
Установил на ADFS-сервер Fiddler, в настройках разрешил удаленные подключения, включил захват HTTPS CONNECTS, decrypt, в правила добавил следующие строчки в раздел OnBeforeRequest:
if (oSession.url.toLowerCase() == "fs.contoso.ru:443") oSession.url = "fs.contoso.ru:444" — меняем request url(тот самый „connect fs.contoso.ru:443“)
if (oSession.host.toLowerCase() == "fs.contoso.ru") oSession.host = "fs.contoso.ru:444" — перенаправляем запросы внутри тоннеля на нужный порт
oSession.utilReplaceInRequest("https://fs.contoso.ru/","https://fs.contoso.ru:444/") — в теле запроса меняем ссылки на нужные.
В такой комбинации тест проходит, wizard завершается удачно, веб-ссылки ADFS снаружи работают, на портал portal.microsoftonline.com пускает, т.е. наш ADFS Proxy заработал!
Но это мы выполнили шаг 3 из инструкции Microsoft, так что теперь, в терминологии книги „Гедель, Эшер, Бах: эта бесконечная гирлянда“ (отсюда, спасибо celen!), надо вытолкнуться снова в эту инструкцию и попробовать продолжить настройку. Да и от посредника-прокси хочется избавиться. Выполняю шаги 4 и 6 (у меня работает без шага 5), снова пробую wizard без указания proxy, чтобы перенастроить его на работу без прокси, но результат тот же — он шлет запросы на 443 порт. Тогда пробую просто удалить настройки proxy командой Set-ADFSProxyProperties -ForwardProxyUrl "", выключаю Fiddler, перезапускаю службу, смотрю в логах и вижу, что служба удачно работает без http-прокси, сайты открываются, Lync подключился. Цель достигнута!
Резюме
Таким образом, с помощью временного прокси мне удалось подключить ADFS Proxy к ADFS и потом убрать этот самый прокси, оба сервера работают на порту 444 (http порт я не менял). Данный метод будет полезен небольшим компаниям, у которых дефицит внешних ip-адресов, а office 365 пользоваться хочется. Ну и пожелание компании Microsoft — исправьте инструкцию, что то в ней не так)
Автор: habus
