Настройка kerberos windows server 2008

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Аутентификация в системах Windows. Часть 2 — Kerberos

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

Протокол Kerberos был разработан в Массачусетском технологическом институте (MIT) в рамках проекта «Афина» в 1983 году и долгое время использовался в качестве образовательного, пока версия 4 не была сделана общедоступной. В настоящий момент принята в качестве стандарта и широко используется следующая версия протокола Kerberos 5.

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

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

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

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

Основой инфраструктуры Kerberos является Центр распространения ключей (Key Distribution Center, KDC), который является доверенным центром аутентификации для всех участников сети (принципалов). Область Kerberos (Realm) — пространство имен для которых данный KDC является доверенным, как правило это область ограниченная пространством имен домена DNS, в Active Directory область Kerberos совпадает с доменом AD. Область Kerberos записывается в виде соответствующего ему доменного имени DNS, но в верхнем регистре. Принципалом или учетной записью Kerberos является любой участник отношений безопасности: учетная запись пользователя, компьютер, сетевая служба и т.д.

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

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

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

Рассмотрим каким образом происходит аутентификация клиента по протоколу Kerberos.

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

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

Убедившись, что метка времени действительна KDC выдает клиенту сеансовый ключ и билет (тикет) на получение билета (ticket granting ticket, TGT), который содержит копию сеансового ключа и сведения о клиенте, TGT шифруется с помощью долговременного ключа KDC и никто кроме него билет расшифровать не может. Сеансовый ключ шифруется с помощью долговременного ключа клиента, а полученная от клиента метка времени возвращается обратно, зашифрованная уже сеансовым ключом. Билет на получение билета является действительным в течении 8 часов или до завершения сеанса пользователя.

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

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

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

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

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

Теоретически теперь данный ключ следует передать как клиенту, так и серверу. Но KDC имеет защищенный канал и установленные доверительные отношения только с клиентом, поэтому он поступает по-другому. Экземпляр сеансового ключа для клиента он шифрует сессионным ключом, а копию сеансового ключа для сервера он объединяет с информацией о клиенте в сеансовый билет (session ticket), который шифрует закрытым ключом сервера, после чего также отправляет клиенту, дополнительно зашифровав сессионным ключом.

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

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

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

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

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

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

Источник

Kerberos: что нового?

Протокол Kerberos достаточно хорошо описан в документе «How the Kerberos Version 5 Authentication Protocol Works». Реализация протокола Kerberos в Windows Server 2003 компанией Microsoft достаточно близка к стандарту RFC 1510. С тех пор прошло 10 лет. Успели выйти Windows Server 2008, 2008 R2, 2012, готовится к выходу Windows Server 2012 R2. Сам стандарт обновился до версии RFC 4120, к которому уже согласовано большое количество дополнений. К сожалению, я нигде не видел (возможно плохо искал) документа, описывающего изменения произошедшие в протоколе Kerberos и в его реализации компанией Microsoft. Поэтому попробую восполнить этот пробел.

Так как меня интересует реализация конкретного вендора, то изменения прежде всего будут привязаны к операционным системам Windows.

Windows Server 2008/Windows Vista

Улучшения следующие (отсюда и отсюда):

Поддержка алгоритма шифрования AES как для самого протокола аутентификации (TGT, сервисные билеты, сессионные ключи) так и для механизма клиент-серверного взаимодействия (сообщений Generic Security Service).
В связи с появлением роли контролеров домена только для чтения (RODC) появились отдельные учётные записи krbtgt для каждого такого контроллера с ограниченной областью действия .
OCSP Stapling . Позволяет снизить нагрузку на сеть при аутентификации по сертификатам, благодаря тому, что контроллер домена кеширует ответы OCSP респондера.

Сам стандарт обновился с RFC 1510 до RFC 4120. Пункт, описывавший в RFC 1510 разрешённые алгоритмы шифрования был вынесен в 2 новых стандарта – RFC 3961 и RFC 3962. OCSP Stapling описан в RFC 4557.

Из интересного относительно алгоритмов шифрования:

The following encryption and checksum mechanisms MUST be supported:

Encryption: AES256-CTS-HMAC-SHA1-96 [RFC3962]
Checksums: HMAC-SHA1-96-AES256 [RFC3962]

The following mechanisms from [RFC3961] and [RFC3962] SHOULD be supported:

Encryption: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD
Checksums: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128

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

The PA-ENC-TIMESTAMP method MUST be supported by clients, but whether it is enabled by default MAY be determined on a realm-by-realm basis. If the method is not used in the initial request and the error KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an acceptable method, the client SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-authentication method.

Эта процедура реализована в Windows Server 2008/Windows Vista.

Теперь посмотрим немного подробнее на улучшения.

В свойствах учётной записи появились 2 новых пункта, связанные с AES:

Реализовано за счёт нового аттрибута msDS-SupportedEncryptionType.

Что означают эти галки? По умолчанию они не выставлены и в учётной записи msDS-SupportedEncryptionType не задан. Это значит, что при запросе сервисного билета (сервис запускается в контексте учётной записи), по-умолчанию для его шифррования будет использоваться RC4. При включении этих опций соответствующий алгоритм шифрования будет добавлен в список поддерживаемых алгоритмов при шифровании сервисного билета.

Процедура запроса TGT увеличилась на два шага. Теперь, по умолчанию, клиент Windows Server 2008/Windows Vista в первом запросе AS-REQ НЕ отправляет в поле paData метод PA-ENC-TIMESTAMP со штампом локального времени системы клиента, зашифрованным хешем пароля пользователя.

— AsReq: Kerberos AS Request — KdcReq: KRB_AS_REQ (10) — PaData: + SequenceOfHeader: + PaData: PA-PAC-REQUEST (128)

В ответ KDC возвращает KRB_ERROR c KDC_ERR_PREAUTH_REQUIRED (так как по-умолчанию преаутентификация должна быть пройдена), который содержит метод PA-ETYPE-INFO2 с указанием алгоритмов шифрования, которые поддерживает KDC.

Клиент отправляет AS-REQ повторно. В этот раз в запросе используется PA-ENC-TIMESTAMP с зашифрованным временем. Для шифрования выбирается самый сильный алгоритм из тех, которые прислал сервер на предыдущем шаге (в нашем случае это AES256).

Кроме этого в теле запроса (ReqBody) содержится последовательность поддерживаемых клиентом алгоритмов шифрования (как описано в RFC 4537). В дальнейшем будет использоватся наиболее сильный из тех, который поддерживают и клиент и KDC (в случае с Vista/Server 2008 это будет AES 256 по умолчанию). Процедура согласования алгоритмов шифрования очень подробно описана здесь.

Windows Server 2008 R2/Windows 7

Улучшения следующие (взято здесь, здесь и здесь):

Алгоритм шифрования DES по-умолчанию выключен . Используются AES256-CTS-HMAC-SHA1-96, AES128-CTS-HMAC-SHA1-96, RC4-HMAC.
Поддержка ECC (elliptic curve cryptography) при аутентификации по смарт-картам, использующим сертификаты X.509. Каких либо дополнительных настроек нет. Но оборудование должно поддерживать ECC.
Forest Search Order . Позволяет аутентифицироваться между разными лесами (областями Kerberos) по коротким именам (леса).

Отказ от использования DES (и части других слабых криптографических алгоритмов) прописан в RFC 6649. Впрочем, Windows никогда не использовала DES, если это специально не настраивалось через соответствующий аттрибут учётной записи. Более старые версии (Windows 2000/2003/XP) использовали RC4, новые (Windows 2008/Vista/2008R2/7) используют AES. Поддержка ECC описана в RFC 5349.

При поднятии уровня домена до Windows Server 2008 R2 немного меняется процедура обработки аттрибута msDS-SupportedEncryptionType. Если он пустой (по-умолчанию), то при шифровании сервисного билета будет использоваться AES (а не RC4, как в случае с Windows Server 2008).

В групповых политиках появились следующие ключи связанные с Kerberos:

Use forest search order
Require strict target SPN match on remote procedure calls

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

Кроме этого появилась дополнительная настройка безопасности, в которой можно выбрать используемые Керберосом алгоритмы шифрования – «Network Security: Configure Encryption types allowed for Kerberos»:

Если эта настройка не включена, то по умолчанию будут использоваться AES и RC4 (DES по-умолчанию выключен, как я писал выше). Включая эту политику, можно задействовать произвольный набор алгоритмов шифрования для протокола Керберос.

Например, можно сильно затянуть безопасность, включив только AES256_HMAC_SHA1 (не забываем, что это приведёт к тому, что клиенты, не знающие про AES, например Windows XP, не смогут работать в домене). В этом случае число алгоритмов шифрования сильно уменьшится. KRB_ERROR вернёт:

При запросе билета к host/srv клиент явно заявит в EType только про поддержку AES:

Windows Server 2012/Windows 8

Улучшения следующие (взято здесь и здесь):

Kerberos Armoring (Flexible Authentication Secure Tunneling, FAST). Механизм защиты пользовательских данных в процессе преаутентификации. Описан в стандарте RFC 6113. Позволяет защищать KRB_AS_REQ/KRB_ERROR сессионным ключём рабочей станции, на которой происходит аутентификация пользователя. При этом, следует помнить, что механизм не применим к защите процедуры преаутентифкации самой рабочей станции.
Ограниченное делегирование (constrained delegation) в разных доменах/лесах . Процедура ограниченного делегирования была реализована ещё в Windows Server 2003 за счёт введения дополнительного аттрибута msDS-AllowedToDelegateTo. Но было достаточно жёсткое ограничение – механизм работал только в рамках одного домена. В Windows Server 2012 это ограничение снято. Более того, механизм работает и за пределами одного леса. То есть, фронт-энд и бэк-энд могут находиться в разных лесах. Новый аттрибут msDS-AllowedToActOnBehalfOfOtherIdentity отвечает за новый сценарий работы ограниченного делегирования. Подробнее здесь и здесь.
Поддержка утверждений (claims) – нового типа авторизационных данных, которые позволяют использовать помимо стандартных данных типа логина/пароля более широкий набор идентификационных данных и правил доступа. Подробно о claim’ах и о том, как с ними работать писал Дмитрий Буланов здесь, здесь и здесь.
Compound authentication – расширение FAST, которое позволяет клиентам использовать TGT, выданные устройствам.
Сжатие ресурсных групп . В предыдущих версиях Windows при выпуске TGT он содержал в поле PAC набор универсальных и глобальных групп, в которые входил пользователь. При этом, процедуре сжатия подвергались общие части SID (SID Namespace) групп, которые находились в домене пользователя. То есть по факту SID Namespace хранился только в одном экземпляре. В Windows Server 2012 сжимаются так же локальные группы в ресурсном домене и группы из SID History. Подробнее о процедуре сжатия можно посмотреть здесь, здесь и здесь. По умолчанию она включена. Но её можно выключить на контроллере домена через ключ реестра DisableResourceGroupsFields в HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemKdcParameters. При единице сжатие выключено.
Увеличение размера токена . Токен теперь можно увеличить до 48Кб. Либо через правку реестра (ключ MaxTokenSize в HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters), либо через групповые политики.

В групповых политиках появились следующие ключи, связанные с Kerberos:

KDC support for claims, compound authentication and Kerberos armoring – включение поддержки claim’ов, compound authentication и Kerberos armoring на стороне KDC.
Warning for large Kerberos tickets – включает появление предупреждений в логе контроллера домена, в случае когда в процессе аутентификации будут использоваться токены больше указанного размера.
Specify KDC proxy servers for Kerberos clients – указывает прокси-серверы KDC, которые должен использовать клиент, если он не может найти контроллер домена.
Disable revocation checking for the SSL certificate of KDC proxy servers – позволяет отключить проверку списка отзыва сертификатов SSL для прокси-серверов KDC.
Fail authentication requests when Kerberos armoring is not available
Support compound authentication – включение поддержки для compound authentication.
Set maximum Kerberos SSPI context token buffer size – позволяет задать максимальный размер токена.
Kerberos client support for claims, compound authentication and Kerberos armoring – включение поддержки claim’ов, compound authentication и Kerberos armoring на стороне клиента.

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

KDC support for claims, compound authentication and Kerberos armoring – должна применяться к контроллерам домена, рекомендую использовать Always provide claims
Kerberos client support for claims, compound authentication and Kerberos armoring – должна применяться к клиентам (рабочим станциям и пользователям)
Fail authentication requests when Kerberos armoring is not available

Для тестовых целей можно использовать Default Domain Policy, в рабочем окружении к выбору объектов политики следует отнестить более осторожно.

Аутентификация для рабочей станции пройдёт штатно, а вот с аутентификацией пользователей картина будет следующая:

Какой пользователь и к какому сервису обращается не видно. Заглянем в сами пакеты.

Видно, что в PaData помещён только метод PA-FX-Fast, который по факту содержит зашифрованный сессионным ключём рабочей станции набор данных, которые при выключенном Kerberos armoring находятся в теле запроса в незашифрованном виде (имя клиента, сервиса, область Kerberos итд).

Согласно RFC 6113 (п.5.4.2) в AS-REQ PA-FX-Fast выглядит следующим образом:

Где KrbFastArmoredReq содержит:

KrbFastArmoredReq ::= SEQUENCE <
armor [0] KrbFastArmor OPTIONAL,
— Contains the armor that identifies the armor key.
— MUST be present in AS-REQ.
req-checksum [1] Checksum,
— For AS, contains the checksum performed over the type
— KDC-REQ-BODY for the req-body field of the KDC-REQ
— structure;
— For TGS, contains the checksum performed over the type
— AP-REQ in the PA-TGS-REQ padata.
— The checksum key is the armor key, the checksum
— type is the required checksum type for the enctype of
— the armor key, and the key usage number is
— KEY_USAGE_FAST_REQ_CHKSUM.
enc-fast-req [2] EncryptedData, — KrbFastReq —
— The encryption key is the armor key, and the key usage
— number is KEY_USAGE_FAST_ENC.
…
>

KrbFastReq ::= SEQUENCE <
fast-options [0] FastOptions,
— Additional options.
padata [1] SEQUENCE OF PA-DATA,
— padata typed holes.
req-body [2] KDC-REQ-BODY,
— Contains the KDC request body as defined in Section
— 5.4.1 of [RFC4120].
— This req-body field is preferred over the outer field
— in the KDC request.
…
>

То есть механизм защиты преаутентификационных данных, реализованный в Windows Server 2012 полностью соответствует RFC 6113. В последнем описании есть интересный пункт FastOption, в котором, например, можно указать, чтобы данные пользователя при использовании FAST не скрывались:

FastOptions ::= KerberosFlags
— reserved(0),
— hide-client-names(1)

Но по-умолчанию, этого не происходит и KDC по факту обрабатывает первичный запрос как запрос от анонимного пользователя. Процедура обработки таких запросов описана в RFC 6112:

The Kerberos response defined in [RFC4120] contains the client identity in cleartext. This makes traffic analysis straightforward. The hide-client-names option is designed to complicate traffic analysis. If the hide-client-names option is set, the KDC implementing PA-FX-FAST MUST identify the client as the anonymous principal [RFC6112] in the KDC reply and the error response.

Что интересно, высылаемый в ответ пакет KRB_ERROR так же малоинтересен злоумышленнику, так как он тоже зашифрован и все «полезные» данные прячет в этом же методе:

Вот как это описано в RFC 6113:

The KDC MUST include all the padata elements such as PA-ETYPE-INFO2 and padata elements that indicate acceptable pre-authentication mechanisms [RFC4120] in the KrbFastResponse structure.

Следующие запросы/ответы выглядят точно так же. Весь обмен ценной информацией идёт через шифрованный канал, реализованный методом PA-FX-Fast.