Протокол 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 со штампом локального времени системы клиента, зашифрованным хешем пароля пользователя.
- Kerberos: AS Request Cname: user Realm: testlab Sname: krbtgt/testlab</pre>
- 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.
- Kerberos: KRB_ERROR - KDC_ERR_PREAUTH_REQUIRED (25)
- KrbError: KRB_ERROR (30)
- EData:
- MethodData:
- Padata: PA-ETYPE-INFO2 (19)
- PaEtypeInfo2:
- EtypeInfo2Entry:
+ Etype: aes256-cts-hmac-sha1-96 (18)
- EtypeInfo2Entry:
+ Etype: rc4-hmac (23)
- EtypeInfo2Entry:
+ Etype: des-cbc-md5 (3)
- EtypeInfo2Entry:
+ Etype: des-cbc-crc (1)
+ Padata: PA-ENC-TIMESTAMP (2)
+ Padata: PA-PK-AS-REQ (16)
+ Padata: PA-PK-AS-REP_OLD/ PA_PK_AS_REQ_WINDOWS_OLD/ PA_PK_AS_REP_WINDOWS_OLD (15)
Клиент отправляет AS-REQ повторно. В этот раз в запросе используется PA-ENC-TIMESTAMP с зашифрованным временем. Для шифрования выбирается самый сильный алгоритм из тех, которые прислал сервер на предыдущем шаге (в нашем случае это AES256).
- Kerberos: AS Request Cname: user Realm: testlab Sname: krbtgt/testlab
- AsReq: Kerberos AS Request
- KdcReq: KRB_AS_REQ (10)
- PaData:
- PaData: PA-ENC-TIMESTAMP (2)
- KrbEncTimestamp: Encrypted Timestamp Pre-authentication
- PaEncTsEnc:
+ EType: aes256-cts-hmac-sha1-96 (18)
- ReqBody:
- Etype:
+ EType: aes256-cts-hmac-sha1-96 (18)
+ EType: aes128-cts-hmac-sha1-96 (17)
+ EType: rc4-hmac (23)
+ EType: des-cbc-md5 (3)
+ EType: des-cbc-crc (1)
+ EType: rc4-hmac-exp (24)
+ EType: Unknown Encryption Type (0xff79)
Кроме этого в теле запроса (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 вернёт:
- Kerberos: KRB_ERROR - KDC_ERR_PREAUTH_REQUIRED (25)
- KrbError: KRB_ERROR (30)
- EData:
- MethodData:
- Padata: PA-ETYPE-INFO2 (19)
- PaEtypeInfo2:
- EtypeInfo2Entry:
+ Etype: aes256-cts-hmac-sha1-96 (18)
- EtypeInfo2Entry:
+ Etype: des-cbc-md5 (3)
При запросе билета к host/srv клиент явно заявит в EType только про поддержку AES:
- Kerberos: TGS Request Realm: TESTLAB.ORG Sname: host/windows7.testlab.org
- TgsReq: Kerberos TGS Request
- KdcReq: KRB_TGS_REQ (12)
- ReqBody:
- Etype:
+ EType: aes256-cts-hmac-sha1-96 (18)
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, в рабочем окружении к выбору объектов политики следует отнестить более осторожно.
Аутентификация для рабочей станции пройдёт штатно, а вот с аутентификацией пользователей картина будет следующая:
Какой пользователь и к какому сервису обращается не видно. Заглянем в сами пакеты.
Первый AS-REQ:
- Kerberos: AS Request
- AsReq: Kerberos AS Request
- KdcReq: KRB_AS_REQ (10)
- PaData:
- PaData: PA-FX-Fast (136)
- PaFxFastRequest:
- ArmoredData:
- Armor:
+ ArmorType: FX_FAST_ARMOR_AP_REQUEST (1)
Видно, что в PaData помещён только метод PA-FX-Fast, который по факту содержит зашифрованный сессионным ключём рабочей станции набор данных, которые при выключенном Kerberos armoring находятся в теле запроса в незашифрованном виде (имя клиента, сервиса, область Kerberos итд).
Согласно RFC 6113 (п.5.4.2) в AS-REQ PA-FX-Fast выглядит следующим образом:
PA-FX-FAST-REQUEST ::= CHOICE {armored-data [0] KrbFastArmoredReq,…}
Где 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 это:
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 так же малоинтересен злоумышленнику, так как он тоже зашифрован и все «полезные» данные прячет в этом же методе:
- Kerberos: KRB_ERROR - KDC_ERR_PREAUTH_REQUIRED (25)
- KrbError: KRB_ERROR (30)
+ ErrorCode: KDC_ERR_PREAUTH_REQUIRED (25)
- EData:
- MethodData:
- Padata: PA-FX-Fast (136)
- PaFxFastReply:
- ArmoredData:
- EncFastRep:
+ EType: aes256-cts-hmac-sha1-96 (18)
Вот как это описано в 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.
Полезные ссылки:
Encryption Type Selection in Kerberos Exchanges
Windows Configurations for Kerberos Supported encryption Type
Windows Logon Options in Vista/2008: Part One of Two
Windows Server 2008 Group Policy settings for interoperability with non-Microsoft Kerberos realms
Hunting down DES in order to securely deploy Kerberos
How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 1
How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 2
А как на 2008 r2 включить DES
2Dmitry
Это делается через аттрибут msDS-SupportedEncryptionTypes для конкретной учётки, либо через групповую политику для группы объектов.