Доменная авторизация что это

Как мы переходили на доменную авторизацию AD в 1С (двигаем SSO в компании)

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

Данный кейс с реальной практики, проект начался в начале 2019 и все «n» баз были переведены в течении полугода на доменную авторизацию (надеюсь все понимают, что это значит), но мне больше нравится SSO.

Значит что имеем:

Windows Server 2016 + AD (не рассматриваем как настраивать)

CentOS 7 + Haproxy + Comodo SSL Wildcard

Windows Server 2016 + IIS + 1C

Опишу вкратце что и как взаимодействует, вся инфраструктура доменная (кроме unix подобных), сервер с 1С-на нем поднята только 1С, сама БД на SQL-ных серверах они нам не нужны сейчас. Все публикации работают по https. конечно есть и подключение сервер база (их мы тоже не будем рассматривать так как доменная авторизация в таком режиме работает сразу и без проблем. Значит клиент с доменным устройством Windows 10 вошел в систему с доменной учеткой запускает 1С в которой прописана ссылка на базу например https://1cbase.yourdomain.com, обращается в к haproxy, тот в свою очередь согласно правилам адресует его на нужный сервер с этой базой, далее IIS принимает соединение, подхватывает доменные учетные данные и передает их в 1С. Ниже схемка:

Примерная схема работы

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

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

Haproxy, просто ставим с репозитория и корректируем конфиг, в моем случае сервис обслуживает не только 1С а и другие WEBы, по этому у меня настройка с 80 редиректор в 443, но для 1С в клиенте нужно писать сразу https так как клиент 1С не воспринимает редирект и прописав http вы просто никуда не попадете. Плюс который для меня важен в такой схеме что на моем маршрутизаторе открыт только 80 и 443 порты и на этом все, я не делаю для каждой БД другой порт и т.д., просто устанавливаешь в своей команде стандарт названия баз и передаешь в ТП что б они знали и могли прописать базу. хотя и это автоматизировано и у каждого сотрудника согласно должности свой список баз. Так вот ссылка всегда будет иметь нормальный для меня вид. например https://rt.yourdomain.com или https://ut.yourdomain.com или https://erp.yourdomain.com. Подняли haproxy (у меня HA-Proxy version 2.0.13) и добавляем конфиг

Можно так же использовать сертификаты Let’s Encrypt но у меня есть подписанный ЦС, а еще может быть что клиент 1С на разных ОС будет ругаться на Let’s Encrypt. Если у вас кластер 1С тогда нужно добавить еще один сервер rt_db_srv02 в backend rt_db_server

Настройка IIS, тут уже будет больше картинок.

После инстала IIS, включаем только 80й порт остальные нам не нужны так как ssl будет занимается haproxy. На картинке ниже роли, которые нужно поднять:

компоненты IIS

Я это все делаю с помощью Ansible, поэтому готовых команд PS под рукой нет. Идем дальше и не к настройке IIS, а к установке 1С:

Ставим все кроме хранилища, ковертора и проверки целосности

По стандарту заходим в консоль администрирования 1С подключаем базу и тд. В клиенте 1С на сервере на котором бы будем делать публикацию прописываем имя сервера (у нас же AD и DNS внутренний) можно без порта, но естественно если порт у вас отличный от стандартного (например, подняли еще одну службу на 1640), то его писать тоже нужно типа server1С1:1641, но если у вас кластер тогда пишем так server1С1;server1С2 (server1С1:1641;server1С2:1641) и нормальные имена нужно прописывать обязательно, так как это пойдет в конфиг IIS. Чуть не забыл, после инсталляции 1С службу, которую она создаст, необходимо запустить от имени доменного пользователя, на сервер 1С его нужно будет сделать админом, а в домене может быть обычным пользователем. главное что б мог читать пользователей с AD. Например

запуск службы от доменного пользователя

Публикуем базу как обычно, все по дефолту, с необходимыми галочками в hs/ws

И тут возвращаемся к IIS, тут уже будет публикация в 1С в сайте по умолчанию, но мы ее не трогаем пока что. это как эталон конфига. Делаем паку в C:\inetpub\wwwroot\, например rt.yourdomain.com, ну что б было все красиво и понятно тому, кто придет на этот сервер после нас или с нами. Добавляем новый веб-сайт (это, я думаю, понятно как) и заполняем:

Настройки веб-сайт

Веб сайт есть, а далее вместе с ним создается и пул приложений. который нам больше всего и нужно, так как в нем мы задаем кто будет авторизовать креды пользователей в 1С и расшифровывать karberos. Для этого нам нужен еще один доменный пользователь желательно отдельный, например iis_service (создаём помним пароль)))

Так он выглядит стандартно:

Приводим его в нужный вид, редактируя удостоверение:

Тюним, Режим управления выставляем Классический и нужно что б это удостоверение использовалось для этого делаем в редакторе конфигурации сервер (путь system.webServer/security/authentication/windowsAuthentication).

IIS настроен, переходим к нашей новой публикации rt.yourdomain.com, для начала выставляем проверку подлинности:

Копируем конфиг публикации, то есть с наше стандартной публикации берем два файла default.vrd и web.config копируем в папку C:\inetpub\wwwroot\rt.yourdomain.com, отлично. Чуть поправим конфиг, буквально удалим в одно строчке символы, что б наши ссылки были короче и красивей. В файле default.vrd удаляем как на картинке и именно так. даже если что-то было после / мы это удаляем:

делаем так

Ну и по классике что б не было кракозябликов в 1С то правим настройку страницы ошибок для нашей публикации rt.yourdomain.com:

С этим все готово. Для корректной работы, необходимо в AD прописать spn запись, это просто заходим на домен контроллер и запускаем команды, в которых пишем нашу публикацию и нашего пользователя, который расшифровывает kerberos:

В 1С пользователю вставляем авторизацию как на картинке:

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

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

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

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, то полный принципал будет Ivan@DOMAIN.LOCAL.

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

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

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

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

Почему такое внимание уделяется этим именам? В дальнейшем будет понятнее, но уже сейчас можно отметить, что в 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 для А» и предоставляет Клиенту доступ к своим ресурсам. При необходимости сервис также проходит аутентификацию перед клиентом.

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

1. С использованием полученного на шаге №3 разрешения (TGT) Клиент запрашивает разрешение на доступ к Сервису Б («ST для Б»).
2. Сервер выдачи разрешений проверяет TGT и выдает Клиенту ST для доступа к сервису Б.
3. Клиент с использованием «ST для Б» запрашивает у Сервиса Б доступ к его ресурсам.
4. Сервис Б проверяет «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.

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

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

Разбор аутентификации в 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) + регистр зависимое имя пользователя.

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

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

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

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, которые рассмотрим в следующей части.

3 Авторизация

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

Затем система собирает информацию о членстве субъекта безопасности (т. е. пользователя) в группах. Нередко пользователь принадлежит к нескольким точно определенным группам — локальным (Local), доменным (Domain Local), глобальным (Global) и универсальным (Universal) — в результате обычных процедур назначения членства.

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

Сразу после аутентификации система собирает идентификаторы SID учетной записи и сведения о членстве в группах в объекте, называемом маркером доступа (Access Token).

Если пользователю нужно получить доступ к объекту (например, файлу, папке, принтеру, разделу реестра), защищенному разрешениями NTFS, то процесс (например, Windows Explorer), выступающий от имени пользователя, предоставляет свой маркер доступа.

Каждый объект NTFS располагает списком элементов управления доступом Access Control Entry (ACE), которые, в сущности, представляют собой знакомые разрешения NTFS (например, Allow Read – разрешить чтение, Allow Write – разрешить запись). Набор элементов ACE, назначенных пользователям и группам, составляет список управления доступом Access Control List (ACL) данного объекта.

Маркер доступа, содержащий учетную запись и группы, с которыми связан пользователь, определяет эффективные разрешения пользователя. Процесс авторизации заключается в разрешении или отказе в доступе к определенному объекту на основе сравнения маркера доступа с ACL объекта. Авторизацию обеспечивает Security Reference Monitor (справочный монитор безопасности) системы Windows .

4.Отчетность

Отчетность (Accounting). Если в Windows режим аудита активизирован, то система сохраняет событие аутентификации в журнале Security, и это последний компонент системы управления доступом – отчетность. Большинство сложных событий начальной регистрации и последующей авторизации происходят за несколько секунд и скрыты от пользователя. Все сложные операции возлагаются на протокол аутентификации.

Локальная и доменная регистрация

При регистрации пользователя одна из первых задач Windows – определить, относится ли процедура только к локальной машине или к учетной записи домена. Пользователи, регистрирующиеся от имени локальной учетной записи, имеют доступ только к ресурсам своего компьютера и только если информация об учетной записи пользователя содержится в локальной базе данных SAM. Если пользователям нужно обратиться к ресурсам на удаленном компьютере без аутентификации в домене, то их учетные записи должны быть продублированы в локальной базе данных SAM каждого доступного компьютера. Учетные записи в каждом компьютере-участнике должны быть синхронизированы (одинаковые имена регистрации, пароли и сроки действия учетных данных на всех машинах). В противном случае положение значительно усложняется. Трудно обслуживать одноранговые (P2P) сети средних размеров, в которых применяются только локальные процедуры регистрации.

На контроллер домена не распространяется требование синхронизации нескольких учетных записей пользователей на разных компьютерах. При доменной аутентификации компьютеры, зарегистрированные в домене, отыскивают контроллеры домена, чтобы предъявить учетные данные доменной учетной записи пользователя при запросах аутентификации. Таким образом, если удаленный пользователь пытается получить доступ к локальному ресурсу какой-нибудь машины, то этот компьютер просит контроллер домена проверить аутентичность запрашивающего пользователя. Учетные записи пользователя домена располагаются только на контроллере домена и создаются лишь один раз. Любой компьютер-участник, которому нужно удостоверить учетную запись в домене, может обратиться к контроллерам домена в любое время. Проблемы синхронизации имен регистрации, паролей и сроков их действия не возникает, так как учетные данные и управление учетной записью осуществляются только в одном месте – на контроллере домена. Независимо от типа регистрации (локальной или доменной), Windows должна аутентифицировать запрос пользователя.

Настраиваем доменную аутентификацию на сетевом оборудовании

22.01.2015
itpro
Windows Server 2012 R2
комментариев 7

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

Не все сетевое оборудование популярных вендоров (CISCO, HP, Huawei) поддерживает функционал для непосредственного обращения к каталогу LDAP, и такое решение не будет универсальным. Для решения нашей задачи подойдет протокол AAA (Authentication Authorization and Accounting), фактически ставший стандартом де-факто для сетевого оборудования. Клиент AAA (сетевое устройство) отправляет данные авторизующегося пользователя на сервер RADIUS и на основе его ответа принимает решение о предоставлении / отказе доступа.

Протокол Remote Authentication Dial In User Service (RADIUS) в Windows Server 2012 R2 включен в роль NPS (Network Policy Server). В первой части статьи мы установим и настроим роль Network Policy Server, а во второй покажем типовые конфигурации сетевого устройств с поддержкой RADUIS на примере коммутаторов HP Procurve и оборудования Cisco.

Установка и настройка сервера с ролью Network Policy Server

Как правило, сервер с ролью NPS рекомендуется устанавливать на выделенном сервере (не рекомендуется размещать эту роль на контроллере домена). В данном примере роль NPS мы будем устанавливать на сервере с Windows Server 2012 R2.

Откройте консоль Server Manager и установите роль Network Policy Server (находится в разделе Network Policy and Access Services).

После окончания установки запустите mmc-консоль управления Network Policy Server. Нас интересуют три следующих раздела консоли:

1. RADIUS Clients — содержит список устройств, которые могут аутентифицироваться на сервере
2. Connection Request Policies – определяет типы устройств, которые могут аутентифицироваться
3. Network Polices – правила аутентификации

Добавим нового клиента RADIUS (это будет коммутатор HP ProCurve Switch 5400zl), щелкнув ПКМ по разделу RADIUS Clients и выбрав New. Укажем:

• Friendly Name:sw-HP-5400-1
• Address (IP or DNS): 10.10.10.2
• Shared secret (пароль/секретный ключ): пароль можно указать вручную (он должен быть достаточно сложным), либо сгенерировать с помощью специальной кнопки (сгенерированный пароль необходимо скопировать, т.к. в дальнейшем его придется указать на сетевом устройстве).

Отключим стандартную политику (Use Windows authentication for all users) в разделе Connection Request Policies, щелкнув по ней ПКМ и выбрав Disable.

Создадим новую политику с именем Network-Switches-AAA и нажимаем далее. В разделе Сondition создадим новое условие. Ищем раздел RADIUS Client Properites и выбираем Client Friendly Name.

В качестве значения укажем sw-?. Т.е. условие будет применяться для всех клиентов RADIUS, начинающийся с символов :”sw-“. Жмем Next->Next-> Next, соглашаясь со всеми стандартными настройками.

Далее в разделе Network Policies создадим новую политику аутентификации. Укажите ее имя, например Network Switch Auth Policy for Network Admins. Создадим два условия: в первом условии Windows Groups, укажем доменную группу, члены которой могут аутентифицироваться (учетные записи сетевых администраторов в нашем примере включены в группу AD Network Admins) Второе условие Authentication Type, выбрав в качестве протокола аутентификации PAP.

Далее в окне Configure Authentication Methods снимаем галки со всех типов аутентификации, кроме Unencrypted authentication (PAP. SPAP).

В окне Configure Settings изменим значение атрибута Service-Type на Administrative.

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

И, напоследок, переместим новую политику на первое место в списке политик.

Настройка сетевого оборудования для работы с сервером RADUIS

Осталось настроить наше сетевое оборудование для работы с сервером Radius. Подключимся к нашему коммутатору HP ProCurve Switch 5400 и внесем следующе изменение в его конфигурацию (измените ip адрес сервера Raduis и пароль на свои).

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

Не закрывая консольное окно коммутатора (это важно!, иначе, если что-то пойдет не так, вы более не сможете подключиться к своему коммутатору), откройте вторую telnet-сессию. Должно появиться новое окно авторизации, в котором будет предложено указать имя и пароль учетной записи. Попробуйте указать данные своей учетной записи в AD (она должна входить в группу Network Admins ). Если подключение установлено – вы все сделали правильно!

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

Для Cisco ASA конфигурация будет выглядеть так:

Совет. Если что то-не работает, проверьте:

• Совпадают ли секретные ключи на сервере NPS и коммутаторе (для теста можно использоваться простой пароль).
• Указан ли правильный адрес NPS сервера в конфигурации. Пингуется ли он?
• Не блокируют ли межсетевые экраны порты 1645 и 1646 между коммутатором и сервером?
• Внимательно изучите логи NPS сервера

Предыдущая статья Следующая статья