Какой хэш используется при аутентификации пользователя по протоколу kerberos

Обновлено: 09.01.2025

В операционных системах Windows 2000/2003/2008 используются расширения протокола Kerberos, повышающие уровень безопасности процедуры аутентификацию клиентов. Расширение PKINIT предоставляет возможность использовать асимметричные криптографические алгоритмы, появилась возможность интерактивной регистрации пользователя с помощью микропроцессорных карточек (смарт карты, USB-ключи и т. п.).

В основу расширений, обеспечивающих аутентификацию с открытым ключом, положена спецификация PKINIT. Существуют способы интеграции шифрования на основе открытого ключа в протокол Kerberos. В сущности, эти методы не преобразовывают среду Kerberos в архитектуру с с полностью автономной аутентификацией (процесс всегда будет зависеть от присутствия KDC), однако они исключают необходимость в коллективно используемом секрете, основанном на пароле многократного применения.

Получив запрос, KDC сначала пытается проверить достоверность сертификата пользователя:

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

Проверив достоверность предуатентификационных данных, КDС ищет в службе каталога Microsoft Active Directory Domain Services учетную запись пользователя по значению имени UPN (User Principal Name) пользователя, которое указано в поле Subject Alternative Name (альтернативное имя владельца) сертификата. На основании информации, хранящейся в найденной учетной записи, KDC формирует билет ТGТ таким же образом, как при стандартном режиме аутентификации Kerberos, который мы рассмотрели в первой части.

Однако для защиты сгенерированного сеансового ключа KDC использует открытый ключ пользователя, подписывает ответ, используя свой закрытый ключ, а также включает в ответ свой сертификат.

Получив ответ от Kerberos KDC, клиент сначала проверяет подпись KDC, и затем с использованием своего закрытого ключа (хранящегося на смарт карте) расшифровывает сеансовый ключ.

Использование полученного билета ТGТ и все дальнейшее взаимодействие клиента с KDC происходят по стандартному протоколу Kerberos.

Смарт карта, закрытый ключ и сертификат открытого ключа не используются до следующей регистрации пользователя в системе.

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

Закрытый ключ ей не понадобится до следующей регистрации в системе.

Методика PKINIT позволяет реализовать двухфакторную аутентификацию пользователя на этапе предаутентификации протокола Kerberos – пользователь должен иметь смарт карту (с хранящимися в памяти карты сертификатом и закрытым ключом), и знать ее PIN-код (чтобы иметь возможность использовать закрытый ключ для формирования цифровой подписи). Следует отметить, что закрытый ключ и сертификат обычно хранятся в разных областях памяти смарт карты.

Таким образом, использование смарт карт и цифровых сертификатов стандарта Х.509 позволяет усилить функции безопасности ОС семейства Microsoft Windows за счет:

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

Леонид Шапиро

Kerberos — сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован, в первую очередь, на клиент-серверную модель и обеспечивает взаимную аутентификацию — оба пользователя через сервер подтверждают личности друг друга. Данная модель является одним из вариантов протокола аутентификации Нидхема — Шрёдера на основе доверенной третьей стороны. [1]

Содержание

История создания

Kerberos был создан MIT в качестве решения проблем с безопасностью сети. Протокол Kerberos использует стойкую криптографию, так что клиент может идентифицироваться на сервере (и обратно) через незащищенное сетевое соединение. Kerberos это и имя сетевого протокола аутентификации и общий термин для описания программ, где он реализован (например, Kerberos telnet). Доступно несколько свободных реализаций этого протокола, работающих на множестве операционных систем. Massachusetts Institute of Technology (MIT), где Kerberos был первоначально разработан, продолжает разрабатывать собственный пакет Kerberos. Он обычно использовался в США как криптографический продукт, и в этом качестве попадал под действие ограничений на экспорт. MIT Kerberos доступен в виде порта (security/krb5). Heimdal Kerberos это другая реализация версии 5, которая разрабатывалась исключительно вне США для обхода экспортных ограничений (и поэтому часто включалась в некоммерческие реализации UNIX(R)). Heimdal Kerberos доступен в виде порта (security/heimdal), его минимальный комплект включен в базовую установку FreeBSD. [2]

Терминология Kerberos

Билет (ticket) – временные данные, выдаваемые клиенту для аутентификации на сервере, на котором располагается необходимая служба.
Клиент (client) – некая сущность в сети (пользователь, хост или сервис), которая может получить билет от Kerberos.
Центр выдачи ключей (key distribution center, KDC) – сервис, выдающий билеты Kerberos.
Область (realm) – сеть, используемая Kerberos, состоящая из серверов KDC и множества клиентов. Имя realm регистрозависимо, обычно пишется в верхнем регистре и совпадает с именем домена.
Принципал (principal) – уникальное имя для клиента, для которого разрешается аутентификация в Kerberos. Записывается в виде root[/instance]@REALM. [3]

Общие сведения

Протокол Kerberos был специально разработан для того, чтобы обеспечить надежную аутентификацию пользователей.

Предусматривается, что начальный обмен информацией между клиентом и сервером происходит в незащищённой среде, а передаваемые пакеты могут быть перехвачены и модифицированы.

Протокол Kerberos может использовать централизованное хранение аутентификационных данных и является основой для построения механизмов Single Sign-On (возможность использования единой учетной записи пользователя для доступа к любым ресурсам области).

Протокол основан на понятии Ticket (билет).

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей).

Когда пользователь выполняет первичную аутентификацию, после успешного подтверждения его подлинности KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT). В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS).

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

Работая с протоколом Kerberos, необходимо, чтобы системные часы всех участвующих во взаимодействии узлов были синхронизированы.

В качестве примера реализации протокола Kerberos имеет смысл отметить доменную аутентификацию пользователей в операционных системах Microsoft, начиная с Windows 2000. [4]

Развитие протокола

Ранние версии

Ранние версии Kerberos (c 1 по 3) были созданы внутри МIT и использовались в целях тестирования. Эти реализации содержали существенные ограничения и были полезны только для изучения новых идей и выявления проблем, которые могли возникнуть во время разработки.

Kerberos 4

Kerberos 4 впервые была опубликована 24 января 1989 года. Она стала первой версией, распространяемой за пределами MIT, подготовленной для нескольких производителей, которые включили её в свои операционные системы. Кроме того, другие крупные проекты по распределённым системам (например, AFS) использовали идеи Kerberos 4 для своих систем аутентификации. Основными разработчиками данной версии были Стив Миллер (Steve Miller) и Клиффорд Ньюман (Clifford Neuman). Основы того, что должно было стать Kerberos 4, были описаны в техническом плане «Афина», а окончательный вариант был закреплён в исходном коде эталонной реализации, опубликованной MIT. Однако из-за ограничений на экспорт программного обеспечения, использующего шифрование, наложенных американским правительством, Kerberos 4 не мог быть распространён за пределами Соединённых Штатов. Так как Kerberos 4 при шифровании использовал алгоритм DES, организации за пределами США не могли по закону использовать данное программное обеспечение. В ответ на это команда разработчиков из MIT создала специальную версию Kerberos 4, исключив из неё весь код, касающийся шифрования. Данные меры позволили обойти ограничение на экспорт. Позже Эррол Янг (Errol Young) в Университете связи Австралии (Bond University of Australia) добавил в эту версию собственную реализацию DES. Она называлась «E-Bones» (сокращение от «encrypted bones») и могла свободно распространяться за пределами США. В 2006 году было объявлено о прекращении поддержки Kerberos 4.

Kerberos 5

С целью преодоления проблем безопасности предыдущей версии Джоном Колем (John Kohl) и Клиффордом Ньюманом (Clifford Neuman) была разработана 5 версия протокола, которая в 1993 году была опубликована в RFC 1510. По прошествии времени, в 2005 спецификацией начала заниматься IETF Kerberos work group. Опубликованные ими документы включают в себя:

характеристики шифрования и контрольной суммы (RFC 3961);
продвинутый стандарт шифрования Advanced Encryption Standard (AES) (RFC 3962);
Kerberos 5 «The Kerberos Network Authentication Service (V5)» (RFC 4120), уточняет некоторые аспекты RFC 1510, и намерен использоваться для более подробного и четкого описания;
новое издание GSS-API спецификации «The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2.» (RFC 4121).

В июне 2006 года был представлен RFC 4556 описывающий расширение для 5-й версии под названием PKINIT (англ. public key cryptography for initial authentication in Kerberos). Данный RFC описывал, как использовать асимметричное шифрование на этапе аутентификации клиента. На следующий год (2007) MIT сформировали Kerberos Консорциум (Kerberos Consortium) по содействию дальнейшему развитию.

Использование и распространение

Распространение реализации Kerberos происходит в рамках авторского права аналогичного правам для BSD. В настоящее время множество ОС поддерживают данный протокол, в число которых входят: Windows 2000 и более поздние версии, которые используют Kerberos как метод аутентификации в домене между участниками. Некоторые дополнения к этому протоколу отражены в RFC 3244 «Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols». Документ RFC 4757 описывает использование RC4 Kerberos в Windows; различные UNIX и UNIX подобные ОС (Apple Mac OS X, Red Hat Enterprise Linux 4, FreeBSD, Solaris, AIX, OpenVMS). При этом существует две наиболее используемые реализации с открытым исходным кодом — MIT Kerberos и Heimdal, последняя из которых была изначально создана в Швеции из-за ограничений на экспорт криптографического ПО из США (англ.) [5] .

Как работает Kerberos?

Пользователь вводит имя и пароль на клиентской машине.
Клиентская машина выполняет над паролем одностороннюю функцию (обычно хэш), и результат становится секретным ключом клиента/пользователя.

Аутентификация клиента

Клиент отсылает запрос (AS_REQ) на СА для получения аутентификационных верительных данных и последующего их предоставления TGS серверу (впоследствии он будет их использовать для получения мандатов без дополнительных запросов на применение секретного ключа пользователя.) Данный запрос содержит:

Идентификатор клиента, его метка времени и идентификатор сервера.

Сессионный ключ Клиент/TGS, идентификатор TGS и время жизни мандата, зашифрованные секретным ключом клиента.
TGT (который включает идентификатор и сетевой адрес клиента, метку времени KDC, период действия мандата и сессионный ключ Клиент/TGS), зашифрованный секретным ключом TGS.

Авторизация клиента на TGS

Для запроса сервиса клиент формирует запрос на TGS (TGS_REQ) содержащий следующие данные:

TGT, полученный ранее и идентификатор сервиса.
Аутентификатор (составленный из ID клиента и временного штампа), зашифрованный на Сессионном Ключе Клиент/TGS.

После получения TGS_REQ, TGS извлекает из него TGT и расшифровывает его используя секретный ключ TGS. Это дает ему Сессионный Ключ Клиент/TGS. Им он расшифровывает аутентификатор. Затем он генерирует сессионный ключ клиент/сервис и посылает ответ (TGS_REP) включающий:

мандат сервиса (который содержит ID клиента, сетевой адрес клиента, метку времени KDC, время действия мандата и Сессионный Ключ клиент/сервис) зашифрованный секретным ключом сервиса.
Сессионный ключ клиент/сервис, идентификатор сервиса и время жизни мандата, зашифрованные на Сессионном Ключе Client/TGS.

Запрос сервиса клиентом

Зашифрованный мандат сервиса полученный ранее.
Новый аутентификатор, зашифрованный на сессионном ключе клиент/сервис, и включающий ID клиента и метку времени.

Метку времени, указанную клиентом + 1, зашифрованную на сессионном ключе клиент/сервис.

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

Сервер предоставляет клиенту требуемый сервис. [6]

Принцип работы

Kerberos 4

Kerberos 4 в значительной степени основан на протоколе Нидхема-Шрёдера, но с двумя существенными изменениями.

Как результат, протокол Kerberos 4 содержит два логических компонента:

Сервер аутентификации (сокр. СА, англ. Authentication Server, сокр. AS)
Сервер выдачи мандатов или разрешений (англ. Ticket Granting Server, сокр. TGS).

В случае удачной проверки СА генерирует случайный сеансовый ключ, который будет совместно использоваться клиентом и TGS (данный ключ защищает дальнейшие запросы мандатов у TGS на другие сервисы). KDC создает 2 копии сессионного ключа: одну для клиента и одну для TGS.

Детали последнего шага — отправки мандата службы серверу приложений — не стандартизировались Kerberos 4, поэтому его реализация полностью зависит от приложения.

Kerberos 5

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

Для решения данной проблемы было решено создать расширяемый протокол с возможностью использования на различных платформах на основе технологии ASN.1. Это позволило использовать в транзакциях различные типы шифрования. Благодаря этому была реализована совместимость с предыдущей версией. Кроме того у KDC появляется возможность выбирать наиболее безопасный протокол шифрования, поддерживаемый участвующими сторонами.

Кроме того оригинальный протокол Kerberos 4 подвержен перебору по словарю. Данная уязвимость связана с тем, что KDC выдает по требованию зашифрованный TGT любому клиенту. Важность данной проблемы также подчеркивает то, что пользователи обычно выбирают простые пароли.

Чтобы усложнить проведение данной атаки, в Kerberos 5 было введено предварительное установление подлинности. На данном этапе KDC требует, чтобы пользователь удостоверил свою личность прежде, чем ему будет выдан мандат.

Настройка Kerberos 5

Настройка клиента Kerberos 5 выполняется гораздо проще, чем настройка сервера. Как минимум, вы должны установить пакеты клиента и сформировать для своих клиентов правильный файл конфигурации krb5.conf. Версии rsh и rlogin, поддерживающие Kerberos, также потребуют некоторых изменений в конфигурации.

1.Убедитесь в том, что между клиентом Kerberos и KDC время синхронизировано. За дополнительной информаций обратитесь к разделу Настройка сервера Kerberos 5. Помимо этого, до установки на компьютере клиентских программ Kerberos необходимо убедиться в корректной работе DNS.

2.Установите пакеты krb5-libs и krb5-workstation на всех клиентских компьютерах вашей сферы. Вы должны поместить собственную версию файла /etc/krb5.conf на клиентские компьютеры; обычно это тот же файл krb5.conf, что и на KDC.

3.До того как определённая рабочая станция в вашей сфере позволит пользователям подключиться, используя rsh и rlogin, использующие Kerberos, на этом компьютере необходимо установить пакет xinetd, и создать для него собственную запись узла в базе данных Kerberos. Серверным программам kshd и klogind также понадобится получить ключи своих учётных записей служб.

Воспользовавшись kadmin добавьте учётную запись компьютера для этой рабочей станции. Именем экземпляра в этом случае будет имя рабочей станции. Так как вам никогда больше не понадобится вводить пароль для этой учётной записи, и вероятно, вы не будет против сильного пароля, воспользуйтесь параметром -randkey команды addprinc для программы kadmin для создания учётной записи и присвоения ей случайного пароля:

Обратите внимание, после создания учётной записи, вы можете извлечь ключи рабочей станции, выполнив команду kadmin на самой рабочей станции и воспользовавшись командой ktadd в kadmin:

Чтобы использовать версии rsh и rlogin, поддерживающие Kerberos, вы должны включить klogin, eklogin и kshell.

Использование и распространение

Распространение реализации Kerberos происходит в рамках авторского права аналогичного правам для BSD.

В настоящее время множество ОС поддерживают данный протокол, в число которых входят:

Windows 2000 и более поздние версии, которые используют Kerberos как метод аутентификации в домене между участниками. Некоторые дополнения к этому протоколу отражены в «Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols». Документ описывает использование RC4 Kerberos в Windows;
различные UNIX и UNIX подобные ОС (Apple Mac OS X, Red Hat Enterprise Linux 4, FreeBSD, Solaris, AIX, OpenVMS). При этом существует две наиболее используемые реализации с открытым исходным кодом — MIT Kerberos и Heimdal, последняя из которых была изначально создана в Швеции из-за ограничений на экспорт криптографического ПО из США. [9]

Применение для централизованной аутентификации

Применение протокола Kerberos для централизованной аутентификации в связке с централизованным созданием хранением и раздачей учетных записей (например, посредством каталога на базе OpenLDAP) позволяет создать «домен UNIX», полностью состоящий из машин под управлением свободного программного обеспечения. Такое решение может применяться в корпоративном секторе, а аутентификация по смарт-картам будет приятным бонусом как для администраторов, так и для пользователей сети компании. [10]

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

Общие сведения

Протокол Kerberos был специально разработан для того, чтобы обеспечить надежную аутентификацию пользователей.

Протокол основан на понятии Ticket (билет).

В качестве примера реализации протокола Kerberos имеет смысл отметить доменную аутентификацию пользователей в операционных системах Microsoft, начиная с Windows 2000.

Как работает аутентификация Kerberos?

Рассмотрим, как осуществляется аутентификация посредством протокола Kerberos.

В процессе аутентификации задействованы следующие основные компоненты:

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

Она ведет базу ученых данных с информацией обо всех участниках безопасности (security principal) своей области. Если речь идет о сетях Windows 2000/2003/2008, понятию «область Kerberos» соответствует понятие «домен».

Вместе с информацией о каждом security principal в базе данных KDC сохраняется криптографический ключ, известный только этому объекту и службе KDC. Указанный ключ, который называют долговременным, используется для связи пользователя системы безопасности с центром распределения ключей.

Примечание: В большинстве практических реализаций протокола Kerberos долговременные ключи создаются на основе пароля пользователя.

Итак, рассмотрим процесс аутентификации пользователя.

1. Получив приглашение на ввод имени пользователя, пароля и домена, пользователь указывает эти данные.

2. Затем компьютер пользователя обращается к службе KDC[1] и передает ей имя пользователя, имя домена, а также текущее время на рабочей станции пользователя, при этом имя пользователя передается в открытом виде, текущее время на рабочей станции пользователя передается в зашифрованном виде и является аутентификатором. Ключ шифрования формируется из пароля пользователя в результате хеширования. См. рис. 1.

3. Служба KDC ищет пользователя в AD, выявляет мастер ключ пользователя, который основан на пароле пользователя и расшифровывает аутентификатор, т. е. получает время отправки запроса. Разница во времени отправки запроса и текущего времени на контроллере домена не должно превышать определенного значения, установленного политикой протокола Kerberos[2].

4. Затем KDC создает два объекта:

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

b. билет на получение билета Ticket-Granting Ticket (TGT). TGT включает: вторую копию ключа сессии, имя пользователя, время окончания жизни билета. Билет на получение билета шифруется с использованием собственного мастер ключа службы KDC, который известен только KDC, т. е. TGT может быть расшифрован только самой службой KDC.

5. Служба KDC зашифровывает аутентификатор пользователя (time stamp) и ключ сессии с помощью ключа клиента. После этого эти данные отправляются клиенту. См. Рис. 2.

6. Компьютер клиента получает информацию от службы KDC, проверяет аутентификатор, расшифровывает ключ сессии.

7. Теперь клиент обладает ключом сессии и TGT, что предоставляет возможность безопасного взаимодействия со службой KDC. Клиент аутентифицирован в домене и получает возможность осуществлять доступ к ресурсам домена, используя протокол Kerberos.

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

1. Клиент обращается к службе KDC. Клиент представляет KDC свой TGT и маркер времени, которые зашифрованы с помощью ключа сессии, известного службе KDC.

2. KDC расшифровывает TGT, используя свой собственный ключ. Маркер времени расшифровывается с помощью сессионного ключа. Теперь KDC может подтвердить, что запрос пришел от «правильного» пользователя, т. к. этот пользователь может использовать этот сессионный ключ. См. рис. 3

3. Затем KDC создает пару билетов, один для клиента, один для сервера, к ресурсам которого клиент должен будет получать доступ. Каждый билет содержит имя пользователя, запрашивающего доступ, получателя запроса, маркер времени, показывающий, когда был создан билет, а также срок жизни билета. Оба билета будут также содержать новый ключ, K_cs который, таким образом известен и клиенту и серверу. Этот ключ будет обеспечивать возможность безопасного взаимодействия между ними. KDC шифрует билет сервера, используя мастер – ключ сервера, затем вкладывает билет сервера внутрь билета клиента, который также содержит ключ K_cs

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

5. Получив билет, клиент расшифровывает его с помощью сессионного ключа, т. е. K_cs становится доступным клиенту, K_cs доступен также и серверу. Клиент не может прочитать билет сервера, т. к. он зашифрован на ключе сервера. См. Рисунок 5

Рисунок 5

6. Клиент зашифровывает маркер времени с помощью ключа, K_cs затем отправляет маркер времени и билет сервера самому серверу, к ресурсам которого пытается получить доступ клиент. См. Рис. 6

7. Получив эту информацию, на первом этапе сервер расшифровывает свой билет, используя свой долговременный ключ. Это предоставляет возможность получить доступ к K_cs , с помощью которого будет на втором этапе расшифрован маркер времени, полученный от клиента.

8. Теперь и клиент, и сервер обладают ключом K_cs. Следовательно, сервер может быть уверен в том, что клиент правильно идентифицирован, т. к. для шифрования маркера времени был использован K_cs . В случае необходимости ответа сервера клиенту, сервер воспользуется ключом K_cs . Клиент будет знать, что сервер правильно идентифицирован, поскольку сервер должен использовать, чтобы получить K_cs .

Разумеется, представленное в статье описание процедур аутентификации на основе Kerberos является упрощенным, тем не менее, мне представляется, что в значительной степени упростит понимание базовых принципов работы протокола. Если же читателя заинтересует более глубокое понимание работы Kerberos, то могу предложить ознакомиться с материалами, представленными в списке литературы.

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

Леонид Шапиро

Список литературы

[1] Чтобы обратиться к службе KDC на контроллере домена, необходимо выполнить разрешение имени этой службы в IP-адрес. Этот процесс выполняется с помощью службы DNS, т.е. компьютер клиента должен «знать» адрес сервера DNS.

В продолжение давней темы про использование двухфакторной аутентификации в ОС GNU/Linux позвольте рассказать про схему работы и настройку аутентификации с помощью Kerberos. В этой статье мы рассмотрим процесс настройки MIT Kerberos для аутентификации пользователей по сертификатам и ключевым парам, находящимся на USB-токене. Также материалы, изложенные в статье, можно использовать для настройки аутентификации в домене Windows.

Для начала проведем небольшой ликбез по терминологии Kerberos и рассмотрим доступные реализации этого протокола в ОС на базе GNU/Linux. Сразу оговорюсь, что мне не удалось найти однозначного перевода терминов, использующихся в Kerberos, поэтому для избежания путаницы основные термины я буду дублировать на английском.
Итак, начнем. Если процитировать Википедию, то

Kerberos – сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован, в первую очередь, на клиент-серверную модель и обеспечивает взаимную аутентификацию – оба пользователя через сервер подтверждают личности друг друга.

Стоит отметить, что Kerberos в первую очередь является протоколом, а не конкретной системой аутентификации. Его реализации используются в различных операционных системах, в том числе и в Windows, как метод аутентификации пользователей в домене. Существует несколько open source реализаций протокола Kerberos, например оригинальная MIT Kerberos и Heimdal. Такой зоопарк возник из-за ограничений США на экспорт криптографических средств защиты информации, на сегодня эта ситуация вокруг MIT Kerberos уже улеглась. В статье мы рассмотрим процесс настройки для MIT Kerberos V5.

Билет (ticket) – временные данные, выдаваемые клиенту для аутентификации на сервере, на котором располагается необходимая служба.
Клиент (client) – некая сущность в сети (пользователь, хост или сервис), которая может получить билет от Kerberos.
Центр выдачи ключей (key distribution center, KDC) – сервис, выдающий билеты Kerberos.
Область (realm) – сеть, используемая Kerberos, состоящая из серверов KDC и множества клиентов. Имя realm регистрозависимо, обычно пишется в верхнем регистре и совпадает с именем домена.
Принципал (principal) – уникальное имя для клиента, для которого разрешается аутентификация в Kerberos. Записывается в виде root[/instance]@REALM.

Файлы настроек Kerberos

На сервере:

На клиенте и сервере:

/etc/kbr5.conf — настройки сервера аутентификации (описание realms, доменных имен и других настроек)

Для начала необходимо развернуть среду, в которой будет производиться аутентификация. Наиболее просто это сделать, взяв две виртуальные машины, находящиеся в одной подсети. Достаточно установить на одну виртуальную машину какую-нибудь Ubuntu (это будет наш сервер), а затем клонировать ее и получить клиента. При написании статьи я воспользовался свежей Ubuntu 12.10 (x86) и виртуальной машиной от VMWare. Чтобы виртуальным машинам было удобнее видеть друг друга по сети, стоит переключить сетевые карты в Bridged-режим.
Важно! Следите за тем, чтобы время на клиенте и сервере было синхронизировано, это необходимо для корректной работы Kerberos.

Настройка сети

Клиенты Kerberos ищут свои сервера по доменным именам, поэтому необходимо настроить DNS и убедиться, что имена серверов успешно разрешаются. В нашем примере достаточно занести доменное имя сервера в /etc/hosts, что я и сделал. Схема «сети» изображена ниже.

Установка необходимых пакетов

На сервере нам потребуются:

krb5-kdc – сервис KDC
krb5-admin-server – административный сервер Kerberos (он ведет контроль учетных записей пользователей)
krb5-pkinit – модуль расширения Kerberos для аутентификации по сертификатам

На клиент надо поставить следующие пакеты:

Базовые настройки

После установки пакетов на сервере нужно инициализировать realm командой
А на клиенте – обновить файлы конфигурации:
Также на клиенте и сервере надо добавить следующие строки в /etc/krb5.conf:
Теперь создадим на сервере нового пользователя c именем testuser
На клиенте теперь можно проверить, правильно ли мы настроили сеть и Kerberos:

Настройка аутентификации по открытому ключу

Для работы модуля pkinit нам придется воспользоваться openssl в качестве мини-УЦ, чтобы создать ключевые пары и сертификаты клиента и сервера.

На сервере:

Extended Key Usage (EKU) – идентификатор (OID), говорящий о том, как планируется использовать сертификат
otherName – поле, задающее нашего принципала, для которого выписывается сертификат

kdc.pem
kdckey.pem
cacert.pem

Дальнейшие действия будем выполнять на клиенте

Ранее при настройке клиентской машины мы поставили пакет libpam-krb5. Он поможет нам выполнить аутентификацию в Kerberos при входе в систему, а также в приложениях, использующих системную аутентификацию (например login, lightdm и проч.). Для подключения модуля PAM достаточно выполнить команду
и выбрать в диалоге необходимые модули аутентификации. Для более тонкой настройки можно заглянуть в файл /etc/pam.d/common-auth и отредактировать его по желанию. Структуру файла я описывал в предыдущей статье.

Читайте также: