1. Windows Server 2008 / Windows Vista
2. Windows Server 2008 R2 / Windows 7
3. Windows Server 2012 / Windows 8

Протокол 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