Появилась необходимость установить ОС Windows Server 2012. Само собой разумеется, решил установить pGina на новую машину для аутентификации пользователей на LDAP-серверах офиса. Я уже описывал некоторые отличия в работе разных ОС в дополнениях к статье о pGina, но поскольку столкнулся с дополнительными трудностями настройки как самой программы, так и связки ОС с LDAP, решил об этом рассказать отдельно с картинками.
Документация достаточно подробно объясняет теорию и описывает настройки pGina и её плагинов. В третьей версии программы было сделано множество улучшений. Был значительно переписан код, настройки некоторых плагинов (в том числе и нужный нам LDAP Authentication) были интегрированы в основной интерфейс программы и, в целом, стали понятнее. Часть настроек LDAP-плагина была перенесена в новый под названием "Local Machine". В их числе - всё, что связано с авторизацией, назначением или требованием принадлежности пользователей группам ОС и т.д.
Логика каждого плагина разделена на три части: Authentication Stage, Authorization Stage, Gateway Stage (соответственно, этап аутентификации, этап авторизации и этап доступа), каждые из которых можно включать или отключать при настройке. LDAP-плагин отвечает теперь только за аутентификацию.
Теперь стало возможно использовать несколько LDAP-серверов, добавляя их через пробел в строчке "LDAP Host(s)". Необходимо сделать всего несколько настроек: указать SSL-порт (636), отметить галочку "Use SSL" и заполнить поле "DN Pattern". На картинке подразумевается, что все пользователи в LDAP находятся на одном уровне. Если у вас это не так, то надо установить галочку "Search for DN" и заполнить поля ниже.
Для проверки работы плагина теперь появилась вкладка "Simulation", в которой можно проверить изменённые настройки. Это очень удобно:
Первоначально мне никак не удавалось установить корректное SSL/TLS соединение между pGina и LDAP-сервером. Дело было не в CA-сертификате, с помощью которого был подписан сертифика LDAP, который надо было добавить в список доверенных центров ОС, о чем я писал в статье ранее - это уже было мною проделано. Чтоб выяснить, в чем было дело, пришлось использовать сетевой сниффер Wireshark. Я "зазеркалил" (функция "mirror") на свиче порт LDAP-сервера на порт своего компьютера, после чего удалось отследить этапы установления TLS - сессии между серверами.
После обмена сообщениями Client Hello, Server Hello, Certificate соединение завершалось до установления рукопожатия (handshake). Дело было явно связано с работой протокола TLSv1.2. Я решил проверить работу с разными версиями SSL/TLS. После поиска в интернете выяснилось, как научить Windows Server 2012 работать с версией протокола TLSv1.1. Для этого необходимо создать и запустить следующий reg-файл (или создать все перечисленные пункты вручную с помощью regedit). Дочитайте до конца заметки прежде чем решить, вносить изменения в реестр или нет, так как это может повлиять на работу системы обновлений ОС (об этом ниже).
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
Здесь указано, что клиентским TLS - соединениям не нужно использовать версию 1.2, вместо неё можно использовать 1.1. Чтобы вернуть возможность работы с TLSv1.2, измените значение ...\TLS 1.2\Client\"Enabled" с 0 на 1 в редакторе реестра либо удалите добавленные строчки совсем.
Снова отслеживаем работу сниффером:
Теперь появились нужные фразы: Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message и т.д. Осталось проверить это во вкладке "Simulation" pGina с использованием рабочего LDAP-аккаунта. Аутентификация осуществляется успешно, о чем нам сообщается.
Проблема стыковки двух сервисов по протоколу TLSv1.2, по-видимому, связана с Openssl. На LDAP-сервере у меня используется последняя стабильная версия openssl-1.0.1c. Возможно, дело связано с поддержкой так называемого "TLS 1.2 Suite B" - набора алгоритмов шифрования, хэширования, поддержка которых ожидается в версии openssl-1.1. Что ж, подожду, когда она станет стабильной, тогда и установлю на сервере, а до тех пор буду использовать TLSv1.1 - для меня это не проблема.
Необходимо убедиться, что запрет работы клиентских соединений по протоколу TLS 1.2 не приведёт к неработоспособности каких-то других серверных сервисов. У меня отказалась работать система обновлений ОС:
Теперь при попытке получить обновления получаем ошибку в Event viewer: "A fatal error occurred while creating an SSL client credential. The internal error state is 10013.". Я решил, что в качестве временного решения буду периодически менять значение настройки реестра (...\TLS 1.2\Client\"Enabled") с "0" на "1" на время обновления ОС вручную, после чего возвращать ее обратно. Возможно, в вашем случае это неприемлемо. Окончательное решение проблемы, видимо, случится с обновлением Openssl.
Поскольку, как уже было сказано, LDAP-плагин pGina отвечает только за аутентификацию, этапы Authorization и Gateway можно настроить в плагине Local Machine. Здесь можно указать автоматически авторизовывать всех пользователей, прошедших аутентификацию ("Authorize all autenticated users"). Если пользователь уже имеет локальный аккаунт в ОС, можно проверить пароль, не обращаясь в LDAP ("Always authenticate local users"). Можно требовать для успешной авторизации принадлежность определенной группе ("Require membership in one of the following local groups:"), указав эту группу ниже. Настройка "Mirror groups from local user" используется при сравнении списка групп ОС, к которым принадлежит пользователь с временным списком групп плагина, который создается на этапе Gateway. На основании этого сравнения принимается решение о добавлении пользователя в члены той или иной группы ОС. Подробнее об этой и других настройках плагина можно почитать в документации. Я решил, что эту опцию лучше оставить включенной. Сама возможность сделать пользователя, прошедшего аутентификацию и авторизацию, членом дополнительной группы реализована в списке "Mandatory Groups". Поскольку я доверяю своим пользователям, у меня там прописана группа "Remote Desktop Users". Без принадлежности этой группе, даже после успешной аутентификации, никто на сервер с помощью Remote Desktop попасть не сможет. На этапе Gateway также происходит создание локального аккаунта в ОС, если он до этого не существовал.
Осталось добавить, что для работы соединений Remote Desktop ОС Windows Server 2012 при установленном сервисе pGina необходимо изменение уровня безопасности на RDP. Вот где это нужно сделать: в Local Computer Policy: 'Computer Configuration' - 'Administrative Templates' - 'Windows Components' - 'Remote Desktop Services' - 'Remote Desktop Session Host' - 'Security' - 'Require use of specific security layer for remote (RDP) connections'. Дважды щёлкаем мышкой и указываем 'enabled', а ниже выбираем 'Security Layer': 'RDP'.
Экран ввода логина/пароля новой версии pGina выглядит современно:
Комментариев нет:
Отправить комментарий