центр распространения ключей

Центр распространения ключей (KDC) реализуется как служба домена. Он использует Active Directory в качестве базы данных учетной записи и глобальный каталог для направления ссылок в Кдкс в других доменах.

Как и в других реализациях протокола Kerberos, KDC представляет собой единый процесс, который предоставляет две службы:

Служба проверки подлинности (AS)

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

Служба Ticket-Granting (TGS)

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

KDC для домена размещается на контроллере домена, как и Active Directory домена. Обе службы запускаются автоматически с помощью локального центра безопасности (LSA) контроллера домена и выполняются в рамках процесса LSA. Ни одна из служб не может быть остановлена. Если KDC недоступен для сетевых клиентов, Active Directory также недоступен, а контроллер домена больше не управляет этим доменом. Система обеспечивает доступность этих и других доменных служб, позволяя каждому домену иметь несколько контроллеров домена и всех узлов. Любой контроллер домена может принимать запросы проверки подлинности и запросы на предоставление билетов, адресованные в KDC домена.

Имя участника безопасности , используемое KDC в любом домене, — krbtgt, как указано в RFC 4120. Учетная запись для этого субъекта безопасности создается автоматически при создании нового домена. Учетная запись не может быть удалена, а имя изменить нельзя. Значение случайного пароля назначается учетной записи автоматически системой во время создания домена. Пароль для учетной записи KDC используется для получения криптографического ключа для шифрования и расшифровки TGT, которую он выдает. Пароль для учетной записи доверия домена используется для получения ключа между областями для шифрования ссылочных билетов.

Все экземпляры KDC в домене используют учетную запись домена для субъекта безопасности KRBTGT. Клиенты разадресают сообщения в KDC домена, включая имя участника службы, «KRBTGT» и имя домена. Оба элемента информации также используются в билетах для выяснения выдающего центра. Сведения о формах имен и соглашениях об адресации см. в документе RFC 4120.

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

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

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

Аутентификация в системах 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 protocol registry entries and KDC configuration keys in Windows

This article describes registry entries about Kerberos version 5 authentication protocol and Key Distribution Center (KDC) configuration.

Original product version: В Windows 10, version 2004, Windows 7 Service Pack 1, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: В 837361

Summary

Kerberos is an authentication mechanism that is used to verify user or host identity. Kerberos is the preferred authentication method for services in Windows.

If you are running Windows, you can modify Kerberos parameters to help troubleshoot Kerberos authentication issues, or to test the Kerberos protocol. To do so, add or modify the registry entries that are listed in the following sections.

This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, see How to back up and restore the registry in Windows.

After you finish troubleshooting or testing the Kerberos protocol, remove any registry entries that you add. Otherwise, performance of your computer may be affected.

Registry entries and values under the Parameters key

The registry entries that are listed in this section must be added to the following registry subkey:

If the Parameters key isn’t listed under Kerberos, you must create the key.

Default Value: 5 (minutes)

This value is the maximum time difference that’s permitted between the client computer and the server that accepts Kerberos authentication.

Default Value: 0

This value indicates whether events are logged in the system event log. If this value is set to any non-zero value, all Kerberos-related events are logged in the system event log.

The events logged may include false positives where the Kerberos client retries with different request flags that then succeed. Therefore, do not assume that you have a Kerberos problem when you see an event logged based on this setting. For more information, see How to enable Kerberos event logging .

Default Value: 1465 (bytes)

This value is the maximum User Datagram Protocol (UDP) packet size. If the packet size exceeds this value, TCP is used.

The default for this value in Windows Vista and later version of Windows is 0, so UDP is never used by the Windows Kerberos Client.

Default Value: 120 (seconds)

This value is the time that Windows waits for the KDC to start before Windows gives up.

Default Value: 10 (seconds)

This value is the time Windows waits for a response from a KDC.

Default Value: 10 (seconds)

This value is the time between successive calls to the KDC if the previous call failed.

Default Value: 3

This value is the number of times that a client will try to contact a KDC.

This value indicates the default encryption type for pre-authentication. Default value is RC4 is 23 (decimal) or 0x17 (hexadecimal)

When you want to use AES, set the value to one of the following values:

• aes256-cts-hmac-sha1-96: 18 or 0x12
• aes128-cts-hmac-sha1-96: 17 or 0x11

This value indicates the default encryption type for pre-authentication.

Default Value: 10 (minutes)

It’s the time-out value that’s used to invalidate a domain controller from a different site in the domain controller cache.

Default Value: 30 (minutes)

It’s the time-out value that’s used to invalidate a domain controller in the same site in the domain controller cache.

Default Value: FALSE

This value contains a flag that indicates whether to use 128-bit encryption for datagram packets.

Default Value: 6

This value is the number of KDC referrals that a client pursues before the client gives up.

Default Value: 0xFFFFFFFF

This value is a list of flags that indicate the type and the level of logging that is requested. This kind of logging can be collected on the component level of Kerberos by bitwise or by one or more of the macros that are described in the following table. Some of the below output requires checked version of kerberos.dll (for example the DEB_TRACE_SPN_CACHE). If this level of troubleshooting is required, contact microsoft support for assistance.

Macro Name	Value	Note
DEB_ERROR	0x00000001	It’s the default InfoLevel for checked builds. It produces error messages across components.
DEB_WARN	0x00000002	This macro generates warning messages across components. In some cases, these messages can be ignored.
DEB_TRACE	0x00000004	This macro enables general tracing events.
DEB_TRACE_API	0x00000008	This macro enables user API tracing events that are logged on entry and on exit to an externally exported function that is implemented through SSPI.
DEB_TRACE_CRED	0x00000010	This macro enables credentials tracing.
DEB_TRACE_CTXT	0x00000020	This macro enables context tracing.
DEB_TRACE_LSESS	0x00000040	This macro enables logon session tracing.
DEB_TRACE_TCACHE	0x00000080	Not implemented
DEB_TRACE_LOGON	0x00000100	This macro enables logon tracing such as in LsaApLogonUserEx2() .
DEB_TRACE_KDC	0x00000200	This macro enables tracing before and after calls to KerbMakeKdcCall() .
DEB_TRACE_CTXT2	0x00000400	This macro enables extra context tracing.
DEB_TRACE_TIME	0x00000800	This macro enables the time skew tracing that is found in Timesync.cxx.
DEB_TRACE_USER	0x00001000	This macro enables user API tracing that is used together with DEB_TRACE_API and that is found mostly in Userapi.cxx.
DEB_TRACE_LEAKS	0x00002000
DEB_TRACE_SOCK	0x00004000	This macro enables Winsock-related events.
DEB_TRACE_SPN_CACHE	0x00008000	This macro enables events that are related to SPN cache hits and misses.
DEB_S4U_ERROR	0x00010000	Not implemented
DEB_TRACE_S4U	0x00020000
DEB_TRACE_BND_CACHE	0x00040000
DEB_TRACE_LOOPBACK	0x00080000
DEB_TRACE_TKT_RENEWAL	0x00100000
DEB_TRACE_U2U	0x00200000
DEB_TRACE_LOCKS	0x01000000
DEB_USE_LOG_FILE	0x02000000	Not implemented

Default Value: 12000 (Decimal). Starting Windows Server 2012 and Windows 8, the default value is 48000.

This value is the maximum value of the Kerberos token. Microsoft recommends that you set this value to less than 65535. For more information, see Problems with Kerberos authentication when a user belongs to many groups.

Default Value: 15 minutes

This value is used by the system when purging Service Principal Names (SPN) cache entries. On domain controllers, the SPN cache is disabled. Clients and member servers use this value to age out and purge negative cache entries (SPN not found). Valid SPN cache entries (for example, not negative cache) are not deleted after 15 minutes of creation. However, the SPNCacheTimeout value is also used to reduce the SPN cache to a manageable size — when the SPN cache reaches 350 entries the system will use this value to scavenge / cleanup old and unused entries.

Default Value: 15 minutes

This value is the lifetime of the S4U negative cache entries that are used to restrict the number of S4U proxy requests from a particular computer.

Default Value: 15 minutes

This value is the lifetime of tickets that are obtained by S4U proxy requests.

Default Value: 0 (false)

Possible values: 0 (false) or any non-zero value (true)

This value indicates whether the client will contact the primary domain controller for Authentication Service Requests (AS_REQ) if the client receives a password expiration error.

Default Value: Any RFC 1510 value

This value indicates whether there are more options that must be sent as KDC options in Ticket Granting Service requests (TGS_REQ).

Default Value: 0 (This setting is 0 because of Dynamic Host Configuration Protocol and network address translation issues.)

Possible values: 0 (false) or any non-zero value (true)

This value indicates whether a client IP address will be added in AS_REQ to force the Caddr field to contain IP addresses in all tickets.

Default Value: 600 seconds

This value is the time that Kerberos waits before it tries to renew a Ticket Granting Ticket (TGT) before the ticket expires.

Default Value: 0

Possible values: 0 (false) or any non-zero value (true)

This value indicates whether session keys are exported with initial or with cross realm TGT authentication. The default value is false for security reasons.

With active Credential Guard in Windows 10 and later versions of Windows, you cannot enable sharing the TGT session keys with applications anymore.

Registry entries and values under the Kdc key

The registry entries that are listed in this section must be added to the following registry subkey:

If the Kdc key is not listed under Services, you must create the key.

Default Value: 0

Possible values: 0 (false) or any non-zero value (true)

This value indicates whether IP addresses will be added in the Ticket-Granting Service Reply (TGS_REP).

Default Value: 1

Possible values: 0 (false) or any non-zero value (true)

This value indicates whether IP addresses for the TGS_REQ and the TGT Caddr field will be checked.

Default Value: 10 (seconds)

This value is the time that an initial TCP endpoint connection will be kept open to receive data before it disconnects.

Default Value: 1465 (decimal, bytes)

This value is the maximum UDP packet size in TGS_REP and Authentication Service Replies (AS_REP) messages. If the packet size exceeds this value, the KDC returns a KRB_ERR_RESPONSE_TOO_BIG message that requests that the client switches to TCP.

Increasing MaxDatagramReplySize may increase the likelihood of Kerberos UDP packets being fragmented.

Default Value: 2

• 1 (decimal) or 0x1 (hexadecimal): Audit SPN unknown errors.
• 2 (decimal) or 0x2 (hexadecimal): Log PKINIT errors. (PKINIT is an Internet Engineering Task Force (IETF) Internet draft for Public Key Cryptography for Initial Authentication in Kerberos.)
• 4 (decimal) or 0x4 (hexadecimal): Log all KDC errors.
• 8 (decimal) or 0x8 (hexadecimal): Log KDC warning event 25 in the system log when user asking for S4U2Self ticket doesn’t have sufficient access to target user.
• 16 (decimal) or 0x10 (hexadecimal): Log audit events on encryption type (ETYPE) and bad options errors. This value indicates what information the KDC will write to event logs and to audits.

Default Value: 1 for checked build, 0 for free build

This value indicates whether debug logging is on (1) or off (0).

If the value is set to 0x10000000 (hexadecimal) or 268435456 (decimal), specific file or line information will be returned in the edata field of KERB_ERRORS as PKERB_EXT_ERROR errors during a KDC processing failure.