Способы аутентификации в домене

Служба каталога ALD Pro построена на базе FreeIPA и поддерживает три вида аутентификации: LDAP Bind, Kerberos и частично NTLM.

Аутентификация по протоколу LDAP

Простая аутентификация или привязка (bind) является самым распространенным, но при этом не самым безопасным способом аутентификации, т.к. пароль передается на сервер открытым текстом.

Поэтому во избежание разглашения учетных данных при выполнении авторизованных LDAP-запросов с использованием простой аутентификации рекомендуется всегда использовать шифрованный протокол LDAPS или включать StartTLS:

ldapsearch -H ldaps://dc-1.ald.company.lan -D 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' -W

А также командой с ключом -ZZ:

ldapsearch -ZZ -H ldap://dc-1.ald.company.lan -D 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' -W

Для лучшего понимания угрозы приведен пример, как делать категорически запрещается:

ldapsearch -H ldap://dc-1.ald.company.lan -D 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' -W

Из программы Wireshark можно увидеть, см. Пароль пользователя открытым текстом в запросе bindRequest, что злоумышленник, у которого будет доступ к просмотру сетевых пакетов, может легко извлечь пароль «AstraLinux_172» из запроса, если канал связи не будет зашифрован:

Рисунок 29 Пароль пользователя открытым текстом в запросе bindRequest

Для проведения простой аутентификации LDAP-каталог хранит хэш пароля в атрибуте userPassword. Алгоритм проверки аутентичности работает следующим образом:

• Пользователь передает на сервер свое имя и пароль в открытом виде.

• Сервер извлекает из каталога хэш пароля для указанного пользователя.

• Пароль, полученный в запросе на аутентификацию, хэшируется тем же алгоритмом и сравнивается со значением, полученным из каталога. Если значения совпали, аутентификация считается успешной.

Хэширование паролей выполняется автоматически при изменении пароля, по умолчанию используется устойчивый к взлому алгоритм PBKDF2-SHA256:

ldapsearch -H ldaps://dc-1.ald.company.lan -o ldif-wrap=no -D 'cn=Directory Manager' -W -b 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' | grep 'userPassword::' | cut -d" " -f2 | base64 -d

Где:

• опция -o ldif-wrap=no - выводит текст без переноса в одну строку, если она не помещается в 80 символов, что полезно использовать в bash командах и скриптах;

• командой grep мы делаем поиск строки с полем userPassword:: и два символа «:» означают что строка закодирована в кодировке base64;

• командой cut отрезаем по символу пробел значение пароля во второй колонке;

• командой base64 -d значение из base64 декодируем в текст.

Результат выполнения, декодированный из base64 пароль пользователя admin:

{PBKDF2-SHA256}AAAIAPiA62CPFChuE0ZU908GI9DjhCb3fXPR4mWPH9/0molxZd7/nWEGglROvy6WCXqri61+Wi76wyVSop6igG2JQR2RyHSI7Fxarm7Ur/2Fri70hw4kBlO9Ih...

Если включить режим миграции пользователей, то при создании новых учетных записей в атрибут userPassword можно будет записать хэш пароля, при этом поддерживается целый ряд алгоритмов: CRYPT, CRYPT-MD5, CRYPT-SHA256, CRYPT-SHA512, MD5, SHA, SHA256, SHA384, SHA512, SMD5, SSHA, SSHA256, SSHA384, SSHA512.

sudo ipa config-mod --enable-migration=true
sudo ipa user-add userName --setattr userPassword='{TYPE}HASH'

Для завершения миграции пользователю потребуется один раз выполнить простую LDAP-аутентификацию, чтобы сервер смог сгенерировать недостающие ключи. Для этого на сервере существует даже специальная страница миграции, доступная по адресу https://dc-1.ald.company.lan/ipa/migration/, см. Страница LDAP-аутентификации для завершения миграции пользователей.

Рисунок 30 Страница LDAP-аутентификации для завершения миграции пользователей

Аутентификация по протоколу Kerberos

Основным протоколом аутентификации в домене является Kerberos V5. Три участника процедуры аутентификации:

• Клиент (Client) — субъект, желающий получить доступ к ресурсу.

• Сервер приложения (Application Server, AP) — служба, к ресурсу которой клиент хочет получить доступ.

• Центр распределения ключей (Key Distribution Center, KDC) — доверенная сторона, отвечающая за аутентификацию (Authentication Service, AS) пользователей и выпуск билетов для доступа к сетевым службам в домене (Ticket Granting Server, TGS).

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

Рисунок 31 Начало аутентификации пользователя Алисы

Шаг (1) Пользователь Алиса через приложение графического входа (Fly Display Manager Greet) передает стеку модулей аутентификации (Pluggable Authentication Modules, PAM) логин и пароль в открытом виде. За аутентификацию в домене отвечает модуль /usr/lib/x86_64-linux-gnu/security/pam_sss.so, см. файл /etc/pam.d/common-auth:

cat /etc/pam.d/common-auth

Результат выполнения:

...
auth [success=1 default=ignore] pam_sss.so use_first_pass
...

Шаг (2) Библиотека libpam загружает Клиентскую библиотеку pam_sss.so, через функции которой обращается к Ответчику /usr/lib/x86_64-linux-gnu/sssd/sssd_pam. Ответчик обращается к Бэкенду, который порождает процесс krb5_child для аутентификации в домене по протоколу Kerberos V5.

Керберос клиент рассчитывает долгосрочный мастер-ключ Алисы (UPN long-term key или Master key) и может удалить из памяти компьютера пароль в открытом виде для повышения устойчивости системы к взлому. Хэш является соленым, к паролю добавляется основное имя принципала, включающее логин пользователя и реалм домена. В соответствии с политикой Kerberos для хэширования может использоваться алгоритм AES128_CTS_HMAC_SHA1_96 или AES256_CTS_HMAC_SHA1_96.

Шаг (3) Клиент отправляет запрос службе аутентификации Центра распределения ключей (Key Distribution Center, KDC). В четвертой версии протокола на этом шаге никакие учетные данные не требовались, т.к. ответ будет зашифрован долгосрочным ключом пользователя, и способность расшифровать ответ является подтверждением того, что пользователь является тем, за кого себя выдает. Но с пятой версии протокола сервер отклонит запрос и потребует предварительную аутентификацию. В качестве аутентификатора выступает метка времени, зашифрованная симметричным алгоритмом с помощью долгосрочного ключа клиента. Такая проверка существенно затрудняет кибератаки, так как лишает злоумышленника возможности запросить TGT-билет на любого пользователя в системе.

Шаг (4) KDC расшифровывает аутентификатор, используя хэш пароля Алисы из LDAP-каталога, см. Обработка запроса на стороне KDC, создание и отправка TGT-билета. Ключи для аутентификации по протоколу Kerberos хранятся в атрибуте krbPrincipalKey, который представляет из себя бинарный объект, зашифрованный мастер-ключом KDC (krbMKey). Если процедура расшифровки завершилась успешно и полученная временная метка расходится со временем сервера не более, чем на 5 минут, то считается, что предварительная аутентификация пройдена успешно. По этой причине для корректной работы протокола важна синхронизация времени между всеми участниками.

Рисунок 32 Обработка запроса на стороне KDC, создание и отправка TGT-билета

Шаг (5) Для повышения безопасности системы KDC генерирует временный сессионный ключ (S1) для последующей передачи его клиенту, чтобы использовать в дальнейшем для шифрования сообщений между клиентом и KDC вместо хэша пароля пользователя.

Шаг (6) Несмотря на то, что сессионный ключ был сгенерирован сервером, в домене может быть несколько контроллеров, и Клиент вправе обратиться с последующим запросом к любому из них. Учитывая случайный характер сессионного ключа, другой контроллер домена не сможет рассчитать его математически, поэтому сессионный ключ следует передать ему в явном виде. По протоколу Kerberos ответственность за передачу сессионного ключа возлагается на клиента, для чего ему выдается зашифрованный билет на выдачу билетов (Ticket-granting ticket, TGT), который он должен предъявлять в KDC при последующих обращениях.

Внутри TGT-билета содержится имя пользователя, сессионный ключ и информация по сроку действия билета. Билет зашифрован симметричным алгоритмом с помощью долгосрочного ключа KDC (хэш пароля служебной учетной записи KRBTGT, Key Distribution Center Service Account), поэтому расшифровать его можно только на контроллере, и подделать билет на стороне Клиента невозможно.

Шаг (7) Сессионный ключ и билет шифруются симметричным алгоритмом с помощью долгосрочного ключа клиента, поэтому только клиент сможет расшифровать сообщение, подтверждая этим фактом, что является тем, за кого себя выдает. Данная проверка аутентичности считается основной.

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

Шаг (8) Клиент расшифровывает сессионный ключ и TGT билет своим долгосрочным ключом, см. Запрос от клиента на получение сервисного билета с помощью TGT-билета. Возможность использования этих данных в последующих запросах означает, что Клиент является тем, за кого себя выдает. Если результат расшифровки окажется недействительным, значит ответ получен от подставного Центра распределения ключей. Долгосрочный ключ может быть удален из памяти компьютера за ненадобностью для повышения безопасности системы.

Рисунок 33 Запрос от клиента на получение сервисного билета с помощью TGT-билета

Шаг (9) Процесс krb5_child сохраняет TGT билет в связке ключей Linux и передает результаты по цепочке Бэкенд — Ответчик — Клиентская библиотека, после чего Клиентская библиотека отправляет запрос на получение сервисного билета на доступ к серверу приложения, в котором содержится имя пользователя (user principal name), имя сервера приложения (service principal name), билет на выдачу билетов (TGT) и аутентификатор. В качестве аутентификатора выступает метка времени, зашифрованная симметричным алгоритмом с помощью сессионного ключа S1. В качестве имени сервиса при входе в компьютер выступает host/pc-fqdn.

На этом шаге TGT билет закодирован только долгосрочным ключом KDC, но этого достаточно, чтобы злоумышленник, перехвативший сообщение, не смог подделать запросы, т.к. он не располагает сессионным ключом S1.

Шаг (10) KDC расшифровывает информацию из TGT билета, используя долгосрочный ключ KDC из LDAP-каталога, после чего ему становится доступна следующая информация: имя пользователя, сессионный ключ S1 и срок действия билета, см. Обработка запроса на сессионный ключ и выдача сессионного ключа по запросу клиента.

Рисунок 34 Обработка запроса на сессионный ключ и выдача сессионного ключа по запросу клиента

Сервер расшифровывает аутентификатор, используя сессионный ключ из TGT билета, и, если полученное значение расходится со временем сервера не более, чем на 5 минут, то считается, что аутентификация пройдена успешно.

Шаг (11) Для повышения безопасности протокола KDC генерирует новый сессионный ключ (S2) для последующей передачи его клиенту, чтобы использовать в дальнейшем для шифрования сообщений между клиентом и сервером приложения вместо сессионного ключа S1.

Шаг (12) Ключ S2 был сгенерирован сервером KDC и его следует передать Серверу приложения. По протоколу Kerberos ответственность за передачу ключа возлагается на клиента, для чего ему выдается зашифрованный сервисный билет (Service ticket, ST), который он должен предъявлять серверу приложения.

Внутри ST-билета содержится имя пользователя, сессионный ключ и информация по сроку действия билета. Билет зашифрован симметричным алгоритмом с помощью долгосрочного ключа Сервера приложения, поэтому расшифровать его сможет только сервер приложения, и подделать билет на стороне Клиента невозможно.

У приложения может быть отдельная учетная запись, но может использоваться и учетная запись компьютера, на котором это приложение работает. В нашем случае это пароль компьютера, в который мы хотим войти.

Шаг (13) После передачи сервисного билета Клиенту информация о ключах больше не требуется и может быть удалена для повышения безопасности системы.

Шаг (14) Клиент расшифровывает сессионный ключ S2 и сервисный билет ST известным ему сессионным ключом S1. Возможность использования этих данных в последующих запросах означает, что Клиент является тем, за кого себя выдает. Если результат расшифровки окажется недействительным, значит ответ получен от подставного Центра распределения ключей.

Шаг (15) Клиент отправляет серверу приложения запрос на аутентификацию, в котором содержится имя пользователя, сервисный билет (ST) и аутентификатор. В качестве аутентификатора выступает метка времени, зашифрованная симметричным алгоритмом с помощью сессионного ключа S2.

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

Шаг (16) Сервер приложения, в роли которого выступает служба SSSD на пользовательском компьютере, извлекает хэш пароля из файла /etc/krb5.keytab для расшифровки запроса. Используя этот долгосрочный ключ, служба SSSD может расшифровать информацию из сервисного билета (ST), после чего ей становится доступна следующая информация: имя пользователя, сессионный ключ S2 и срок действия билета. SSSD расшифровывает аутентификатор, используя сессионный ключ S2 из сервисного билета, и, если полученное значение расходится со временем компьютера не более, чем на 5 минут, то считается, что аутентификация пройдена успешно (см. Запроса клиента к службе с помощью сервисного ключа).

Рисунок 35 Запроса клиента к службе с помощью сервисного ключа

Получив подтверждение, что вход в компьютер хочет выполнить действительно Алиса, приложение Display Manager запускает рабочий стол (Fly Windows Manager, fly-wm) от имени этого пользователя.

Сервисный билет на доступ к хосту более не требуется, поэтому он не сохраняется в связке ключей, и вы не увидите его в выводе команды klist, но на контроллере в журнале /var/log/auth.log вы можете найти подтверждение, что такой билет запрашивался и был предоставлен рабочей станции.

Аутентификация по протоколу NTLM

Служба каталога FreeIPA тесно интегрирована с файловым сервером Samba, в котором реализована поддержка NTLM-протокола для возможности аутентификации пользователей по логину/паролю, например, если подключение выполняется не по доменному имени сервера, а по его IP адресу. Для этого у пользователей в каталоге есть атрибут ipaNTHash, который обновляется плагином ipa_pwd_extop каждый раз при смене пароля.

Рассмотрим поток данных при аутентификации по протоколу NTLM в упрощенном виде, см. Поток данных при NTLM-аутентификации:

• Клиент обращается к Сервису с запросом на аутентификацию (1) и получает в ответ случайное число длиной 8 байт, которое ему нужно подписать, используя свой пароль, для подтверждения аутентичности (2).

• Клиент подписывает сообщение и передает его Сервису (3), который пересылает подпись вместе с исходным сообщением на Контроллер Домена (4).

• Контроллер проверяет подпись и возвращает PAC сертификат, если проверка аутентичности пройдена успешно (5).

Рисунок 36 Поток данных при NTLM-аутентификации

Интеграция Samba реализует представленную схему не полностью: служба Winbind, которая отвечает за NTLM аутентификацию на стороне Samba, не передает контроллеру домена информацию для проверки аутентичности пользователя, а выполняет ее самостоятельно, получая значение атрибута ipaNTHash из каталога напрямую через модуль ipasam. Доступ к этому атрибуту предоставляется учетной записи файлового сервера через назначение роли CIFS server. Роль по умолчанию не используется. Необходимо назначить ее вручную через интерфейс FreeIPA.

Указанный способ интеграции допустим, если Samba устанавливается на контроллер домена, но создает дополнительную точку уязвимости, если Samba используется отдельно, как сервер общего доступа к файлам. Учитывая вышеизложенное, ИТ-директорам нужно либо отключать возможность NTLM-аутентификации в домене, либо делегировать управление файловыми серверами тем же администраторам, кто управляет контроллерами домена.

Аутентификация с использованием OTP

Описание процесса аутентификации

С версии 4.0.0 FreeIPA поддерживает аутентификацию OTP (One Time Password), которая используется как второй фактор для входа в систему в рамках многофакторной аутентификации (MFA). OTP - это одноразовый пароль, который генерируется для каждого сеанса и действует только ограниченный промежуток времени. Это повышает безопасность учётных записей, так как для входа требуется не только основной пароль, но и одноразовый код, генерируемый токеном.

При аутентификации в службе, поддерживающей FreeIPA (например, веб-интерфейс FreeIPA/ALD Pro или при запуске kinit), пользователь вводит основной пароль и одноразовый код (OTP), сгенерированный его устройством.

Для генерации одноразовых кодов используется стандарт TOTP (Time-Based One-Time Password). Клиентское приложение для генерации кодов можно выбрать любое, которое поддерживает TOTP. Примеры таких приложений: Aladdin 2FA, Google Authenticator, FreeOTP, Microsoft Authenticator и другие. Эти приложения позволяют сканировать QR-код, который формируется при создании OTP-токена для пользователя, и генерировать одноразовые коды, которые необходимо вводить для завершения аутентификации.

Включение двухфакторной аутентификации

• для домена;

• для пользователя.

Для настройки двухфакторной аутентификации необходимо включить использование OTP для всего домена или для конкретных пользователей. Это два независимых процесса:

Для всего домена

Если требуется, чтобы все пользователи домена использовали двухфакторную аутентификацию, необходимо включить использование OTP для домена. Все пользователи в домене будут обязаны использовать OTP для входа в систему.

ipa config-mod --user-auth-type=otp

Также это можно сделать через веб-интерфейс FreeIPA:

1. Перейдите в IPA-сервер → Конфигурация → Стандартные типы аутентификации пользователей.

2. Установите параметр Двухфакторная аутентификация (пароль + OTP).

Для конкретного пользователя

Если необходимо включить использование OTP только для определённого пользователя, выполните команду:

ipa user-mod --user-auth-type=otp <username>

Также это можно сделать через веб-интерфейс FreeIPA:

1. Перейдите в раздел Пользователи.

2. Перейдите в редактирование пользователя <username>.

3. Во вкладке Параметры установите Типы аутентификации пользователей в Двухфакторная аутентификация (пароль + OTP).

Примечание

В случае, если у пользователя создан токен, он сможет войти только с использованием OTP кода. Если токен не был создан, у пользователя сохраняется возможность входить только с паролем, без необходимости ввода OTP кода.

Информация о созданных токенах хранится в контейнере: cn=otp,dc=ald,dc=company,dc=lan

Создание OTP-токена для пользователя

Для каждого пользователя необходимо создать OTP-токен. Этот токен будет генерировать одноразовый код для двухфакторной аутентификации. Пользователь может сам создать токен для себя, администратор - для любого пользователя.

Через командную строку

Для создания нового OTP-токена для пользователя выполните команду:

ipa otptoken-add --owner=<username>

После выполнения команды будет сгенерирован QR-код, который необходимо отсканировать с помощью любого приложения для двухфакторной аутентификации, поддерживающего стандарт TOTP (например: Aladdin 2FA, Google Authenticator, FreeOTP и другие).

Пример выполнения команды:

Полный формат команды:

ipa otptoken-add [ID] [options]

где [options] - это ключи, которые могут принимать следующие значения:

• -h, --help: Показать справку по команде.

• --type=['totp', 'hotp', 'TOTP', 'HOTP']: Тип токена. Возможные значения:

• totp или TOTP — Time-Based One-Time Password (TOTP).

• hotp или HOTP — HMAC-Based One-Time Password (HOTP).

• --desc=STR: Описание токена.

• --owner=STR: Назначенный пользователь токена (по умолчанию: self).

• --disabled=BOOL: Отметить токен как отключённый (по умолчанию false).

• –not-before=DATETIME: Начало срока действия токена (формат: день и время).

• --not-before=DATETIME: Начало срока действия токена (формат: день и время).

• --vendor=STR: Имя поставщика токена.

• --model=STR: Модель токена.

• --serial=STR: Серийный номер токена.

• --key: Секрет токена (формат Base32; по умолчанию генерируется случайный).

• --algo=['sha1', 'sha256', 'sha384', 'sha512']: Алгоритм хеширования токена.

• --digits=['6', '8']: Количество цифр, которые будет содержать каждый код токена.

• --offset=INT: Разница времени между токеном TOTP и сервером FreeIPA.

• --interval=INT: Продолжительность действия кода токена TOTP (в секундах).

• --counter=INT: Начальный счётчик токена HOTP.

• --setattr=STR: Установить атрибут для пары имя/значение.

• --addattr=STR: Добавить пару атрибут/значение.

• --no-qrcode: Не показывать QR-код.

• --all: Получить и вывести все атрибуты, возвращаемые сервером.

• --raw: Вывести записи в том виде, в котором они хранятся на сервере.

• --no-members: Подавить обработку атрибутов участия.

Через веб-интерфейс FreeIPA

Токен также можно добавить через веб-интерфейс. Перейдите в раздел Пользователи, выберите пользователя <username>, в меню Действия выберите Добавить OTP токен и отсканируйте QR-код, который будет отображен, с помощью вашего приложения для двухфакторной аутентификации.

Вход с помощью одноразового пароля

После настройки двухфакторной аутентификации, процесс входа в ALD Pro будет следующим:

1. Введите логин

2. Стандартный пароль + OTP код (например, password123123456)

Синхронизация токена

Через командную строку

Если аутентификация с использованием OTP не работает, возможно, проблема заключается в расхождении времени между сервером и клиентом. Для синхронизации токена выполните команду:

ipa otptoken-sync [TOKEN] [options]

Параметры команды:

• [TOKEN]: Идентификатор токена .

• --user=<username>: Имя пользователя, для которого производится синхронизация токена.

• --first-code=<first_code>: Первый одноразовый код.

• --second-code=<second_code>: Второй одноразовый код.

Через веб-интерфейс FreeIPA

Для синхронизации токена через веб-интерфейс выполните следующие шаги:

1. Перейдите на страницу входа в веб-интерфейс FreeIPA

2. Нажмите на ссылку «Синхронизировать OTP-токен»

3. Введите имя пользователя и пароль.

4. Введите два одноразовых кода (OTP).

5. (Опционально) Укажите идентификатор токена.

6. Нажмите кнопку «Синхронизировать OTP-токен».

После успешной синхронизации вы сможете войти в систему, используя ваш пароль и одноразовый код (OTP)

Важно: Если синхронизация не помогает, создайте новый токен для пользователя.

Дополнительные команды

Для управления OTP-токенами используйте следующие команды:

• otpconfig-mod — изменение параметров конфигурации OTP;

• otpconfig-show — отображение текущей конфигурации OTP;

• otptoken-add — добавление нового токена OTP;

• otptoken-mod — изменение существующего токена OTP;

• otptoken-del — удаление токена OTP;

• otptoken-find — поиск токенов OTP;

• otptoken-show — показ сведений о токене OTP;

• otptoken-sync — синхронизация токена OTP.