Протокол аутентификации kerberos: Настройка Kerberos-аутентификации с использованием смарт-карт / Хабр

Настройка Kerberos-аутентификации с использованием смарт-карт / Хабр

В продолжение давней темы про использование двухфакторной аутентификации в ОС 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/krb5kdc/kdc.conf — настройки KDC

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

• /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 для аутентификации по сертификатам

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

• krb5-user – базовый набор утилит для работы клиентской аутентификации
• krb5-config – файлы настроек Kerberos
• krb5-pkinit
• libpam-krb5 – модуль PAM для использования Kerberos-аутентификации
• pcscd, opensc, libengine-pkcs11-openssl – пакеты, необходимые для работы с токенами

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

• Default realm: AKTIV-TEST. RU
• Имена серверов (admin server и KDC): aktiv-test.ru (он же прописан в /etc/hosts на клиенте)
• Пользователь: [email protected]

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

После установки пакетов на сервере нужно инициализировать realm командой

$ sudo krb5_newrealm

А на клиенте – обновить файлы конфигурации:

$ sudo dpkg-reconfigure krb5-config

Также на клиенте и сервере надо добавить следующие строки в /etc/krb5.conf:

[domain_realm]
.aktiv-test.ru = AKTIV-TEST.RU
aktiv-test.ru = AKTIV-TEST.RU

Теперь создадим на сервере нового пользователя c именем testuser

$ sudo kadmin.local
# username = testuser
# password = test
# добавляем нового пользователя и устанавливаем его пароль
kadmin.local:$ addprinc testuser
# ...
kadmin.local:$ quit

На клиенте теперь можно проверить, правильно ли мы настроили сеть и Kerberos:

$ kinit testuser@AKTIV-TEST. RU
# вводим пароль пользователя
$ klist
# и видим выданный ticket, после чего его можно удалить следующей командой
$ kdestroy

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

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

На сервере:

Создадим ключевую пару и сертификат нашего «УЦ». Здесь мы сгененируем ключ УЦ и создадим самоподписанный сертификат с помощью openssl. В реальном мире ключ естественно надо надежно защитить от попадания в чужие руки.

$ openssl genrsa -out cakey.pem 2048 
# ...
$ openssl req -key cakey.pem -new -x509 -out cacert.pem
# ...

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

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

$ openssl genrsa -out kdckey.pem 2048 
# создание запроса
$ openssl req -new -out kdc.req -key kdckey.pem
# подпись запроса
$ REALM=AKTIV-TEST.RU; export REALM
$ CLIENT=aktiv-test.ru; export CLIENT
# содержимое файла pkinit_extensions см. по ссылке выше
$ openssl x509 -req -in kdc.req -CAkey cakey.pem -CA cacert.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc_cert –CAcreateserial

После этого перенесем следующие файлы в /var/lib/krb5kdc/:

• kdc.pem
• kdckey.pem
• cacert.pem

На сервере отредактируем настройки Kerberos (файл /etc/krb5kdc/kdc.conf) для использования ключей и сертификатов сервера и УЦ:

[kdcdefaults]
    kdc_tcp_ports = 88
    pkinit_identity = FILE:/var/lib/krb5kdc/kdc. pem,/var/lib/krb5kdc/kdckey.pem
    pkinit_anchors = FILE:/var/lib/krb5kdc/cacert.pem
[realms]
    AKTIV-TEST.RU = {
        database_name = /var/lib/krb5kdc/principal
        admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
        acl_file = /etc/krb5kdc/kadm5.acl
        key_stash_file = /etc/krb5kdc/stash
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
        default_principal_flags = +preauth
    }

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

$ kadmin.local
kadmin.local$: modprinc +requires_preauth testuser

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

Отформатируем токен

$ pkcs15-init --erase-card -p rutoken_ecp
$ pkcs15-init --create-pkcs15 --so-pin "87654321" --so-puk ""
$ pkcs15-init --store-pin --label "User PIN" --auth-id 02 --pin "12345678" --puk "" --so-pin "87654321" –finalize

Сгенерируем на токене ключевую пару RSA 2048 бит и создадим заявку на сертификат. Важно заметить, что пути до библиотек engine_pkcs11.so и opensc-pkcs11.so на вашей системе могут отличатся, поэтому сначала стоит проверить их расположение.

# на данном шаге важно запомнить ID ключевой пары, его мы используем позже
$ pkcs15-init -G rsa/2048 --auth-id 02 --id 42 --label "testuser's key" --public-key-label "testuser's public key"
# ...
$ openssl
# на multiarch-системах opensc-pkcs11.so и engine_pkcs11.so могут лежать в других местах
OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/openssl/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:opensc-pkcs11.so
(dynamic) Dynamic engine loading support
[Success]: SO_PATH:/usr/lib/openssl/engines/engine_pkcs11.so
[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:opensc-pkcs11.so
Loaded: (pkcs11) pkcs11 engine
OpenSSL> req -engine pkcs11 -new -key 1:42 -keyform engine -out client.req -subj "/C=RU/ST=Moscow/L=Moscow/O=Aktiv/OU=dev/CN=testuser/emailAddress=testuser@mail.
  com"
engine "pkcs11" set.
PKCS#11 token PIN: 
OpenSSL> quit

После этого мы получим файл-заявку client.req, которую необходимо поместить на сервер и выписать сертификат пользователя на основе данных УЦ:

$ REALM=AKTIV-TEST.RU; export REALM
$ CLIENT=testuser; export CLIENT
$ openssl x509 -CAkey cakey.pem -CA cacert.pem -req -in client.req -extensions client_cert -extfile pkinit_extensions -out client.pem

Затем стоит перезапустить сервер и KDC:

$ /etc/init.d/krb5-admin-server restart
$ /etc/init.d/krb5-kdc restart

На выходе работы openssl мы получим файл с сертификатом клиента client.pem. Его нужно перенести на клиентскую машину, положить в /etc/krb5/ и записать на токен:

$ pkcs15-init --store-certificate client.pem --auth-id 02 --id 42 --format pem

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

[libdefaults]
    default_realm = AKTIV-TEST.RU
# путь к сертификату УЦ
    pkinit_anchors = FILE:/etc/krb5/cacert.pem
# путь к модулю PKCS#11
    pkinit_identities = PKCS11:/usr/lib/opensc-pkcs11.so

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

$ kinit testuser
# на этом этапе у нас должны спросить PIN-код от токена
$ klist	

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

$ sudo pam-auth-update

и выбрать в диалоге необходимые модули аутентификации. Для более тонкой настройки можно заглянуть в файл /etc/pam.d/common-auth и отредактировать его по желанию. Структуру файла я описывал в предыдущей статье.

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

• Описание протокола Kerberos
• Официальная документация
• Инструкция по настройке от сообщества Ubuntu
• Настройка PKINIT

Kerberos для специалиста по тестированию на проникновение. Часть 1. Теория

Вступление

На мой взгляд специалисту по тестированию на проникновение инфраструктуры на базе Active Directory важно понимать общее устройство протокола Kerberos. Вот лишь несколько причин почему:

• Знание устройства протокола Kerberos необходимо для понимания ряда классических атак.
• Периодически появляются новые атаки, но прежде чем приступать к их эксплуатации, необходимо разобраться к каким последствиям они могут привести. Без знания Kerberos это порой затруднительно, либо вовсе невозможно.
• Личная чуйка, что если человек называет себя специалистом, то он должен обладать несколько более глубокими знаниями, чем название инструмента или кнопки, на которую надо нажать.

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

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

В первой части будет рассмотрено устройство Kerberos в общем случае, а также реализация Kerberos в Active Directory.

К материалу не стоит относится как к истине в последней инстанции. Только дураки не сомневаются.

Экскурс. Краткий и исторический

Протокол Kerberos был разработан в MIT, как часть научно-исследовательского проекта Афина, предназначенного для создания распределенной образовательной среды. К 1988 году проект достиг поставленных целей. В частности, было опубликовано описание протокола Kerberos v4, являющегося основой системы единого входа в разработанную среду. Предыдущие версии 1-3 были ранними прототипами и не использовались за пределами MIT.

В 1989 году состоялся официальный релиз Kerberos v4.

Однако протоколу было куда развиваться. Например, можно выделить следующие недостатки Kerberos v4:

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

C целью устранения приведенных недостатков в 1993 году вышел новый протокол Kerberos v5.

В 1999 году Microsoft объявила о поддержке Kerberos v5 в своей будущей операционной системе Windows 2000, что было впоследствии реализовано в качестве соответствующего компонента Active Directory. До этого для аутентификации в рабочих группах на базе операционной системы Windows использовался протокол NT LAN Manager (NTLM), одна из версий которого (NTLM v2) применяется для локальной аутентификации в современных системах до сих пор. Подробное рассмотрение протокола NTLM v2 выходит за рамки статьи. Важно отметить, что указанный протокол также обладает рядом недостатков, которые было решено избежать при внедрении Kerberos v5 в Windows 2000.

В настоящее время Kerberos v5 можно считать довольно возрастным протоколом, тем не менее он используется во множестве различных систем, а не только в Active Directory. Вот неполный перечень:

• Amazon Web Services
• Apple macOS
• Google Cloud
• Microsoft Azure
• Oracle Solaris
• Red Hat Linux

Всюду далее речь будет идти именно о Kerberos v5. Для читаемости Kerberos v5 будет называться просто Kerberos.

Требования к протоколу Kerberos

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

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

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

  Любопытный факт: Kerberos разрабатывался до появления SSL.

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

  • Необходимо минимизировать количество критических объектов, которые требуется защищать.
  • Добавление нового, удаление старого, изменение текущего секрета у клиента или сервиса не должно требовать уведомления всех остальных участников протокола. Думаю, полезной будет следующая иллюстрация:

Варианты сетей без и c выделенным доверенным центром

• Должна поддерживаться технология единого входа (Single Sign-On). Это ограничение обусловлено тем, что пользователю неудобно каждый раз при обращении к ресурсу заново вводить пароль.
• Успешное окончание работы протокола должно означать успешную взаимную аутентификацию сторон.
• В результате работы протокола между клиентом и сервисом должен быть сформирован секретный сессионный ключ. Знание сессионного ключа позволяет злоумышленнику расшифровать некоторые старые сообщения, но организовать новую сессию с использованием уже известного сессионного ключа не получится.

Список терминов

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

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

Важно не путать:

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

Сервер – сетевой объект, обеспечивающий функционирование одного или нескольких сервисов. Примеры серверов: файловый сервер, почтовый сервер.

Клиент – объект, обращающийся к сервису с целью получения доступа к ресурсам. Примеры клиентов: учетная запись или рабочая станция пользователя.

Область действия (Realm) – совокупность клиентов, серверов и сервисов, участвующих в протоколе Kerberos.

Принципал (Principal) – это строка, полностью идентифицирующая участника протокола Kerberos.

Принципал может быть именем сервиса (Service Principal Name), или именем клиента (User Principal Name). Форматы принципалов для клиентов и сервисов различаются.

Принципал клиента имеет следующую форму: principal-name[/instance-name]@REALM Пример: имя пользователя — Ivan, а область действия - DOMAIN.LOCAL, то полный принципал будет [email protected].

Расширение instance-name является опциональным и позволяет любому пользователю иметь более одного принципала. Так, если Ivan является администратором области DOMAIN.LOCAL, имя принципала будет Ivan/[email protected], и у этого принципала будут другие права (и удостоверяющие данные).

Принципал сервиса имеет следующую форму: service-name/host[:port]@REALM, где

• service-name – это специфичная для приложения строка, идентифицирующая сервис на этом хосте.
• host – это доменное имя хоста, на котором работает сервис
• port — порт на котором запущена служба.

Пример: для сервиса ftp, работающего на хосте с именем fileserver. example.com в области @EXAMPLE.COM, имя принципала сервиса будет ftp/[email protected].

Почему такое внимание уделяется этим именам? В дальнейшем будет понятнее, но уже сейчас можно отметить, что в Kerberos для идентификации сервера требуется именно принципал (имя), тогда как в NTLM может использоваться IP-адрес.

Примечание: возможность использования IP-адресов была добавлена в новых клиентах Windows.

Рассмотрим пример: есть рабочая станция (DNS-имя: station.domain.local, IP-адрес: 192.168.10.12) с общедоступной сетевой папкой scan. При открытии проводника и переходу по UNC-пути \\station.domain.local\scan будет использоваться Kerberos, но при указании UNC-пути \\192.168.10.12\scan будет использоваться NTLM, так как принципал отсутствует. В частности, поэтому администраторы не любят отключать NTLM, так как устаревшее сетевое оборудование (принтеры, роутеры и пр.) может быть настроено со статическими IP-адресами или вовсе не поддерживать Kerberos.

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

KDC включает в себя следующие компоненты:

• База данных Kerberos, предназначенная для хранения информации о всех принципалах и их секретах.
• Сервер аутентификации (Authentication Server, AS), обрабатывающий запросы на аутентификацию клиентов к области действия протокола Kerberos;
• Сервер выдачи разрешений (Ticket Granting Server, TGS), обрабатывающий запросы на аутентификацию к определенному сервису, функционирующего в составе указанной области действия.

Проиллюстрируем вышесказанное следующей зарисовкой:

Участники протокола Kerberos

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

Иллюстрация порядка изложения материала

Начнем от общего и перейдем к частному.

Житейская аналогия

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

1. Посетитель приходит на вход и показывает охраннику свой паспорт.
2. Охранник проверяет наличие посетителя в базе данных.
3. Охранник выдает посетителю суточный билет на посещение парка.
4. Посетитель выбирает понравившийся ему аттракцион и идет на кассу, чтобы получить билет.
5. На кассе проверяют суточный билет посетителя и выдают билет на аттракцион.
6. Посетитель идет на выбранный аттракцион и показывает смотрителю аттракциона, полученный на кассе билет.
7. Смотритель проверяет билет и пропускает посетителя.
8. Посетитель при желании может посмотреть бейджик смотрителя, чтобы убедиться, что он действительно сотрудник парка.

Если посетитель захотел пойти на другой аттракцион, он снова идет на кассу и показывает суточный билет. Далее повторяется процесс из шагов 5, 6, 7 только с другим смотрителем и другим аттракционом.

По верхам в общем виде

Теперь по аналогии рассмотрим упрощенную схему аутентификации с использованием Kerberos:

Общая схема обмена запросами в Kerberos

1. Клиент отправляет запрос на аутентификацию к области действия.
2. Сервер аутентификации проверяет подлинность Клиента с использованием Базы данных Kerberos.
3. Сервер выдает Клиенту разрешение (пока просто назовем его TGT) на получение отдельных разрешений (далее – ST), требующимся для доступа к сервисам, входящим в область действия.
4. С использованием полученного на шаге №3 разрешения (TGT) Клиент запрашивает разрешение на доступ к Сервису А («ST для А»).
5. Сервер выдачи разрешений проверяет TGT и выдает Клиенту ST для доступа к сервису А.
6. Клиент с использованием «ST для А» запрашивает у Сервиса А доступ к его ресурсам.
7. Сервис А проверяет «ST для А» и предоставляет Клиенту доступ к своим ресурсам. При необходимости сервис также проходит аутентификацию перед клиентом.

В дальнейшем при необходимости доступа к другому сервису:

8. С использованием полученного на шаге №3 разрешения (TGT) Клиент запрашивает разрешение на доступ к Сервису Б («ST для Б»).
9. Сервер выдачи разрешений проверяет TGT и выдает Клиенту ST для доступа к сервису Б.
10. Клиент с использованием «ST для Б» запрашивает у Сервиса Б доступ к его ресурсам.
11. Сервис Б проверяет «ST для Б» и предоставляет Клиенту доступ к своим ресурсам.

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

Теперь переназовем передаваемые сообщения в соответствие с RFC:

• Запрос на аутентификацию к области действия (шаг 1) — сообщение KRB_AS_REQ.
• Ответ сервера на запрос аутентификации клиента (шаг 3) – сообщение KRB_AS_REP.
• Разрешение на получение разрешений – TGT (Ticket Granting Ticket).

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

Примечание: в различных источниках часто встречается словосочетание «TGT билет», но в аббревиатуре TGT уже заложено слово «билет» — Ticket Granting Ticket, поэтому правильнее говорить просто «TGT».

• Запрос на доступ к сервису (шаг 4) – сообщение KRB_TGS_REQ.

• Ответ сервера выдачи разрешений (шаг 5) – сообщение KRB_TGS_REP.

• Разрешение на доступ к сервису – ST (Service Ticket) Другие встречающиеся названия: TGS билет, билет сервиса, мандат сервиса.

• Запрос клиента на аутентификацию к сервису (шаг 6) – сообщение KRB_AP_REQ.

• Опциональный ответ с аутентификацией сервиса перед клиентом (шаг 7) – сообщение KRB_AP_REP.

Чтобы проще было запомнить:

• KRB ~ KeRBeros
• AS ~ Authentication Server
• REP ~ REsPonse
• REQ ~ REQuest
• AP ~ APplication server

Далее каждый запрос будет разобран подробнее.

Разбор аутентификации в Kerberos согласно RFC

В начале имеются три участника протокола Kerberos:

1. Клиент
2. Сервис
3. Центр распределения ключей

Каждый из участников обладает своим долговременным секретом (ключом). Кроме того, центр распределения ключей обладает секретами всех участников.

Рис. 3 — Первоначальное распределение секретов

Алгоритм формирования ключа

Ключ формируется как результат работы хэш-функции под названием string2key. Хэш может вычисляться разными способами в зависимости от соответствующих настроек Kerberos, в частности поддерживаются следующие алгоритмы:

Название алгоритма (etype)	Способ вычисления ключа
RC4_HMAC_MD5	NT-хэш пароля участника
AES128_CTS_HMAC_SHA1_96	PBKDF2(пароль, соль*, kvno**, 128)
AES256_CTS_HMAC_SHA1_96	PBKDF2(пароль, соль*, kvno**, 256)

В последних версиях Windows по умолчанию используется шифрование AES. Но для совместимости с системами ниже Windows Vista и Windows 2008 Server необходима поддержка алгоритма RC4.

Соль формируется следующим образом:

• Для доменных пользователей: полностью определенное имя домена заглавными буквами (FQDN) + регистр зависимое имя пользователя.

  Пример: DOMAIN.LOCALuser

• Для компьютеров: FQDN + host + регистр зависимое имя компьютера без $ в конце.

  Пример: DOMAIN.LOCALhostcomputer.domain.local

kvno — key version number (в переводе — номер версии ключа). kvno представляет собой счетчик, увеличивающий значение каждый раз при смене пароля.

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

Источники:

• Kerberos from Hacker recipes
• A Note on Calculating Kerberos Keys for AD Accounts (snovvcrash)

KRB_AS_REQ

Клиент отправляет серверу аутентификации запрос, содержащий:

• Принципал клиента
• Срок жизни билета

Примечание: если это не первый материал по Kerberos, который вы читаете и возникает вопрос, почему отсутствует предварительная аутентификации, то поясню – это дополнительная настройка протокола, которая в «классической» реализации по умолчанию отключена. В реализации Kerberos для Active Directory, указанная настройка напротив по умолчанию активна и этот случай будет рассмотрен чуть позже.

KRB_AS_REP

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

Первое сообщение зашифровано с использованием секрета клиента и содержит:

• Сессионный ключ для KDC
• Метка времени
• Срок жизни TGT

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

Примечание: время жизни TGT определяется, как наименьшее время среди запрошенного клиентом и хранящегося в настройках центра распределения ключей.

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

KRB_TGS_REQ

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

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

Приняв запрос, сервер выдачи разрешений прежде всего выполняет проверку полученных данных. Сначала с использованием секрета KDC сервер расшифровывает TGT (1) и по метке времени со сроком действия убеждается, что TGT не протух (2).

Далее сервер извлекает сессионный ключ для KDC. Несмотря на то, что указанный ключ был создан в KDC, нужды хранить его в базе Kerberos нет. Действительно, TGT не может быть изменен кем-либо кроме KDC, поэтому полученным из него данным можно доверять.

Возникает важный вопрос — почему можно быть уверенным, что TGT не отправлен злоумышленником, перехватившим его при прослушивании сетевого трафика? Для этого в запросе прилагается аутентификатор. Аутентификатор зашифрован с использованием сессионного ключа KDC, который мог быть извлечен из KRB_AS_REP запроса только определенным клиентом. Метка времени добавляется с целью предотвращения атак методом повтора, чтобы злоумышленник не смог вставить в свой запрос старый аутентификатор клиента, перехваченный из прошлых сообщений.

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

KRB_TGS_REP

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

• Сессионный ключ для общения с сервисом
• Метка времени
• Срок жизни TGS билета
• Принципал сервиса

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

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

KRB_AP_REQ

Клиент отправляет сервису запрос на получение доступа, содержащий:

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

Приняв запрос, сервис прежде всего выполняет проверку полученных данных. Сначала с использованием своего секрета сервис расшифровывает TGS (1) и по метке времени со сроком действия убеждается, что TGS не протух (2). Далее сервис извлекает сессионный ключ.

TGS билет не может быть изменен кем-либо кроме того, кто знает секрет сервиса, а это KDC и сам сервис. Сервис доверяет KDC, таким образом извлеченным из TGS билета данным сервис также может доверять.

Аналогично KRB_TGS_REQ расшифровывается аутентификатор и выполняются другие проверки. Обратите внимание, что сервис удостоверяется в подлинности клиента, не обращаясь к KDC.

KRB_AP_REP

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

Kerberos в Active Directory

«Чтобы донести идею её надо рассказать три раза, но разными словами» (с)

Рассмотрим реализацию Kerberos в Active Directory. Уточним терминологию, теперь:

Область действия – домен.

Центр распределения ключей – контроллер домена.

Сервер аутентификации и сервер выдачи разрешений – оба объединены в рамках одного компонента, функционирующего на контроллере домена.

База данных Kerberos – в Active Directory информация о секретах пользователей хранится на контроллерах домена в файле ntds. dit.

krbtgt – название учетной записи, по умолчанию создаваемой вместе с доменом и обладающей секретом контроллера домена.

В итоге с учетом переименований получается следующая структура:

В целом в Active Directory Kerberos работает согласно RFC, но есть ряд особенностей. Рассмотрим указанные особенности на следующем примере.

Доменная аутентификация пользователя к рабочей станции в Active Directory

Изначально на рабочей станции активно следующее диалоговое окно:

Пользователь вводит свои учетные данные (название домена, имя учетной записи, пароль) и жмет «OK». Далее компонент, ответственный за отображение диалогового окна, передает запрос на аутентификацию пользователя с использованием введенных данных в локальный центр безопасности (Local Security Authority, LSA). Центр содержит различные динамические библиотеки, предоставляющие функции для процедур аутентификации, смены паролей, а также выдачи токенов. Указанные библиотеки вызываются и работают в контексте процесса lsass. exe (Local Security Authority Subsystem Service).

В зависимости от запроса для его обработки согласовывается соответствующая библиотека. Примеры библиотек и протоколов:

• msv1_0.dll (NTLM)
• kerberos.dll (Kerberos)
• SChannel.dll (TLS/SSL)
• WDigest.dll (digest аутентификация)

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

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

В итоге имеем следующую картину:

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

Далее процесс, обеспечивающий аутентификацию пользователя, обращается к контроллеру домена с использованием сформированного ключа. Здесь проявляется одна из особенностей реализации Kerberos в Active Directory – предварительная аутентификация по умолчанию включена.

KRB_AS_REQ с предварительной аутентификацией

В этом случае клиент отправляет серверу аутентификации запрос, содержащий:

• Принципал клиента
• Метку времени, зашифрованную с использованием секрета клиента

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

KRB_AS_REP (AD)

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

В ответе появилась еще одна особенность, а именно новое поле «PAC» в содержимом TGT.

PAC (Privilege Attribute Certificate) это данные, предназначенные для авторизации пользователя. Ранее уже отмечалось, что кроме аутентификации Kerberos может использоваться при авторизации, но не пояснялось как. Поле PAC изначально было предусмотрено в RFC без конкретного описания содержимого. Какая информация передается в PAC и как она обрабатывается зависит от конкретной реализации Kerberos.

В Active Directory PAC среди прочего содержит следующую информацию:

• Идентификатор безопасности (SID) учетной записи пользователя
• Идентификаторы групп, в которых состоит пользователь

Указанная информация дважды подписывается. Одна подпись принадлежит krbtgt, а вторая сервису, к которому обращался клиент (в случае KRB_AS_REP тоже krbtgt).

KRB_TGS_REQ (AD)

Запрос производится аналогично рассмотренному ранее в RFC.

KRB_TGS_REP (AD)

PAC из TGT, полученный в предыдущем сообщении, помещается в TGS билет. В этот раз PAC подписывается не только с использованием секрета krbtgt, но и секрета системы.

LOGON

С использованием сессионного ключа LSA извлекает подписанный PAC из TGS билета. LSA проверяет подпись PAC при помощи секрета системы и далее с учетом добытых из PAC доменных групп безопасности формирует процесс Winlogon c соответствующим токеном доступа клиента.

Опционально система может запросить контроллер домена выполнить дополнительную проверку подписи с PAC с помощью секрета krbtgt.

Итог

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

Ссылки на используемые источники

• Kerberos Protocol Tutorial (Fulvio Ricciardi)
• Kerberos and Windows Security Series (Robert Broeckelmann)
• Статья с pro-ldap.ru
• Блог Pixis
• Фундаментальная статья c tarlogic. com (Eloy Pérez)
• Документация Microsoft
• How to Kerberos? its components and function (Sheeraz Ali)
• Windows authentication attacks part 2 – kerberos (Ahmed Sultan)

Картинка для обложки взята отсюда.

Что такое Kerberos? Объяснение аутентификации Kerberos

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

A Kerberos — это система или маршрутизатор, обеспечивающий шлюз между пользователями и Интернетом. Таким образом, это помогает предотвратить проникновение кибер-злоумышленников в частную сеть. Это сервер, называемый «посредником», потому что он идет между конечными пользователями и веб-страницами, которые они посещают в Интернете.

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

Kerberos появился одновременно с системой доменных имен (DNS) — 1983 — так оно и есть уже какое-то время. Первоначально он был разработан для образовательного проекта Массачусетского технологического института под названием Project Athena, но сегодня он поддерживает широкий спектр функций, включая реализацию единого входа (SSO), и служит протоколом аутентификации для веб-сайтов. Многие популярные операционные системы, в том числе Windows, имеют встроенный Kerberos. Kerberos — широко используемая служба, которую, как и DNS, большинство пользователей даже не подозревают об использовании.

Kerberos — надежное решение для обеспечения безопасности по четырем основным причинам: 

это зрело

Kerberos уже давно используется, что с точки зрения безопасности многое говорит о его эффективности.

Соответствует современным требованиям к распределенным системам

Kerberos отвечает требованиям современных распределенных систем. Он обеспечивает безопасную аутентификацию в открытых средах с небезопасными каналами связи.

Это архитектурно правильно

Надежная, хорошо продуманная архитектурная основа Kerberos позволяет ему развиваться и интегрироваться с другими системами.

Он интегрирован в популярные операционные системы

Kerberos уже интегрирован в популярные операционные системы и программные приложения и стал важным компонентом ИТ-инфраструктуры. Это технология авторизации по умолчанию в Microsoft Windows. Он использует стороннюю авторизацию билетов и надежную криптографию, чтобы хакерам было сложнее получить доступ к корпоративной сети. С помощью Kerberos организации могут получить доступ к Интернету, не беспокоясь о своей безопасности.

Kerberos — это надежное решение для обеспечения безопасности предприятий любого размера. Но как именно работает аутентификация Kerberos?

Kerberos использует криптографию с симметричным ключом и центр распространения ключей (KDC) для аутентификации и проверки личности пользователя. KDC включает в себя три аспекта:

1. Сервер выдачи билетов (TGS), который соединяет пользователя с сервисным сервером (SS)
2. База данных Kerberos, в которой хранятся пароли и идентификационные данные всех проверенных пользователей 
3. Сервер аутентификации (AS), который выполняет первоначальную аутентификацию

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

Аутентификация Kerberos — это многоэтапный процесс, состоящий из следующих компонентов: 

1. Клиент, который инициирует запрос на обслуживание от имени пользователя
2. Сервер, на котором размещена служба, к которой пользователю необходим доступ
3. AS, выполняющая аутентификацию клиента. Если аутентификация прошла успешно, клиенту выдается билет на выдачу билетов (TGT) или токен аутентификации пользователя, что является доказательством того, что клиент прошел аутентификацию.
4. KDC и его три компонента: AS, TGS и база данных Kerberos
5. Приложение TGS, которое выдает сервисные билеты 

Преимущества аутентификации Kerberos

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

Контроль доступа

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

Взаимная аутентификация

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

Ограниченный срок действия билета

Каждый билет в Kerberos имеет временные метки и данные о времени жизни, а продолжительность проверки подлинности контролируется администраторами.

Многоразовая аутентификация

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

Безопасность

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

Каковы недостатки Kerberos?

Kerberos — это эффективный метод управления угрозами безопасности. Однако есть некоторые проблемы. Некоторые из наиболее распространенных недостатков включают в себя:

Единая точка отказа

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

Каждой сетевой службе нужен набор ключей Kerberos

Сетевым службам, которым требуются разные имена хостов, потребуется собственный набор ключей Kerberos, что может вызвать проблемы с кластером и виртуальным хостингом.

Строгие требования к времени

Конфигурации даты и времени хостов должны быть синхронизированы с предопределенными ограничениями. В противном случае аутентификация завершится ошибкой из-за ограниченного количества билетов.

Поток протокола Kerberos включает три секретных ключа: хэш клиента/пользователя, секретный ключ TGS и секретный ключ SS. Ниже приведены основные этапы выполнения протокола:

1. Начальный запрос аутентификации клиента — Поток протокола начинается с входа клиента в домен. На этом этапе пользователь запрашивает у AS TGT или токен аутентификации. Запрос TGT отправляется в KDC Kerberos.
2.  Проверка учетных данных клиента  – KDC должен проверить учетные данные пользователя, чтобы отправить зашифрованный сеансовый ключ и TGT. AS проверяет доступность TGS и клиентов в базе данных. Если оба значения найдены, AS генерирует секретный ключ. Он также создает ключ сеанса (SK1), который шифруется с помощью секретного ключа пользователя и TGT с сетевым адресом клиента, идентификатором (ID), отметкой времени, временем жизни и SK1. Затем секретный ключ TGS шифрует билет.
3. Расшифровка сообщения  – Клиент использует хэш или секретный ключ клиента/пользователя для извлечения TGT и SK1 и расшифровки сообщения, а затем создает аутентификатор, который проверяет TGS.
4. Запрос на доступ с использованием TGT  — Затем клиент запрашивает билет у SS, отправляя аутентификатор и извлеченный TGT в TGS.
5. Создание билета для файлового сервера — Секретный ключ TGS используется для расшифровки TGT от клиента и извлечения SK1. TGS также расшифровывает аутентификатор и проверяет его соответствие сетевому адресу и идентификатору клиента, а также гарантирует, что срок действия TGT не истек, используя извлеченную метку времени. Если все проверки выполнены успешно, KDC сгенерирует общий ключ сеанса службы (SK2) для целевого сервера и клиента. Затем KDC создает билет службы с сетевым адресом клиента, идентификатором, отметкой времени и SK2. Этот билет будет зашифрован с помощью секретного ключа сервера, а клиент получит служебный билет и SK2, который будет зашифрован с помощью SK1.
6. Аутентификация с использованием билета файла  — Затем клиент использует билет файла для аутентификации, расшифровывая сообщение с помощью SK1 и извлекая SK2. При этом будет создан другой аутентификатор, зашифрованный с помощью SK2, который включает в себя идентификатор клиента, сетевой адрес и отметку времени. Затем клиент отправляет билет службы вместе с новым аутентификатором на целевой сервер.
7. Расшифровка и аутентификация целевого сервера . В качестве последнего шага в протоколе Kerberos целевой сервер затем расшифровывает билет службы и извлекает SK2, используя секретный ключ сервера. SK2 расшифровывает аутентификатор, и выполняются проверки, чтобы убедиться, что сетевой адрес и идентификатор клиента из билета службы и аутентификатора совпадают. После того, как все проверки выполнены и выполнены, клиент получит сообщение от сервера о том, что сервер и клиент аутентифицировали друг друга.

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

Это наиболее распространенные методы взлома Kerberos.

Пройти билет

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

Заполнение учетных данных или грубая сила

Это автоматизированная и непрерывная попытка угадать пароль пользователя. Большинство этих атак будут нацелены на службу выдачи билетов и первоначальной продажи билетов.

Понижение уровня шифрования

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

Теневая атака постоянного тока

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

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

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

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

Решение Fortinet FortiWeb можно настроить для использования протокола Kerberos для делегирования аутентификации. FortiWeb использует Kerberos для предоставления ранее прошедшим проверку подлинности клиентам доступа к веб-приложениям. Продукт поддерживает два типа аутентификации Kerberos: 

FortiWeb проверяет сертификат уровня защищенных сокетов (SSL) пользователя, используя центр сертификации (CA), указанный в конфигурации члена пула серверов или политике сервера. Затем FortiWeb получит билет службы Kerberos, чтобы разрешить клиенту доступ к указанному веб-приложению.

Пользователи вводят имя пользователя и пароль в форме аутентификации на языке гипертекстовой разметки (HTML). Затем FortiWeb получает билет службы Kerberos для клиента, чтобы разрешить доступ к указанному веб-приложению.

Что такое Kerberos и как он работает?

A  Kerberos  – это система или маршрутизатор, обеспечивающий шлюз между пользователями и Интернетом. Таким образом, это помогает предотвратить проникновение кибер-злоумышленников в частную сеть.

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

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

Можно ли взломать Kerberos?

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

Обзор аутентификации

Kerberos | Microsoft Узнайте

Редактировать

Твиттер LinkedIn Фейсбук Электронная почта

• Статья
• 29.07.2021
• 2 минуты на чтение

Применяется к: Windows Server 2022, Windows Server 2019, Windows Server 2016

Kerberos — это протокол проверки подлинности, который используется для проверки личности пользователя или хоста. В этом разделе содержится информация о проверке подлинности Kerberos в Windows Server 2012 и Windows 8.

Описание функции

Операционные системы Windows Server реализуют протокол проверки подлинности Kerberos версии 5 и расширения для проверки подлинности с открытым ключом, передачи данных авторизации и делегирования. Клиент проверки подлинности Kerberos реализован как поставщик поддержки безопасности (SSP), и к нему можно получить доступ через интерфейс поставщика поддержки безопасности (SSPI). Первоначальная аутентификация пользователя интегрирована с архитектурой единого входа Winlogon.

Центр распространения ключей Kerberos (KDC) интегрирован с другими службами безопасности Windows Server, работающими на контроллере домена. KDC использует базу данных доменных служб Active Directory домена в качестве базы данных учетных записей безопасности. Доменные службы Active Directory необходимы для реализации Kerberos по умолчанию в домене или лесу.

Практические приложения

Преимущества использования Kerberos для проверки подлинности на основе домена:

• Делегированная проверка подлинности.

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

• Единый вход.

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

• Совместимость.

  Реализация протокола Kerberos V5 корпорацией Майкрософт основана на спецификациях отслеживания стандартов, которые рекомендованы Инженерной группе Интернета (IETF). В результате в операционных системах Windows протокол Kerberos закладывает основу для взаимодействия с другими сетями, в которых протокол Kerberos используется для проверки подлинности. Кроме того, Microsoft публикует документацию по протоколам Windows для реализации протокола Kerberos. Документация содержит технические требования, ограничения, зависимости и особенности поведения протокола Windows для реализации Microsoft протокола Kerberos.

• Более эффективная аутентификация на серверах.

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