Политика Kerberos Kerberos Policy

Область применения Applies to

Описание параметров политики Kerberos и ссылки на описания параметров политики. Describes the Kerberos Policy settings and provides links to policy setting descriptions.

Протокол проверки подлинности Kerberos версии 5 предоставляет механизм проверки подлинности по умолчанию и данные авторизации, необходимые пользователю для доступа к ресурсу и выполнения задачи с этим ресурсом. The Kerberos version 5 authentication protocol provides the default mechanism for authentication services and the authorization data necessary for a user to access a resource and perform a task on that resource. Сокращая срок действия билетов Kerberos, вы снижаете риск кражи и успешного использования учетных данных законного пользователя злоумышленником. By reducing the lifetime of Kerberos tickets, you reduce the risk of a legitimate user’s credentials being stolen and successfully used by an attacker. Однако это также увеличивает расходы на авторизацию. However, this also increases the authorization overhead. В большинстве сред эти параметры не требуется менять. In most environments, these settings should not need to be changed.

Эти параметры политики находятся в \Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy. These policy settings are located in \Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy.

В следующих темах рассматриваются вопросы реализации и практические советы, расположение политики, значения по умолчанию для типа сервера или GPO, соответствующие различия в версиях операционной системы, вопросы безопасности (включая возможные уязвимости параметров каждого параметра), возможные меры противодействия и потенциальное влияние на каждый параметр. The following topics provide a discussion of implementation and best practices considerations, policy location, default values for the server type or GPO, relevant differences in operating system versions, security considerations (including the possible settings vulnerabilities of each setting), countermeasures you can take, and the potential impact for each setting.

Kerberos Authentication Overview Kerberos Authentication Overview

Область применения. Windows Server (Semi-Annual Channel), Windows Server 2016 Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016

Kerberos — это протокол проверки подлинности, который используется для проверки удостоверения пользователя или узла. Kerberos is an authentication protocol that is used to verify the identity of a user or host. В этом разделе содержатся сведения о проверке подлинности Kerberos в Windows Server 2012 и Windows 8. This topic contains information about Kerberos authentication in Windows Server 2012 and Windows 8.

Описание функции Feature description

Операционные системы Windows Server реализуют протокол проверки подлинности Kerberos версии 5 и расширения для проверки подлинности с помощью открытого ключа, переноса данных авторизации и делегирования. The Windows Server operating systems implement the Kerberos version 5 authentication protocol and extensions for public key authentication, transporting authorization data, and delegation. Клиент проверки подлинности Kerberos реализован в качестве поставщика услуг поддержки безопасности ( ) , и доступ к нему можно получить через интерфейс поставщика поддержки безопасности ( SSPI ) . The Kerberos authentication client is implemented as a security support provider (SSP), and it can be accessed through the Security Support Provider Interface (SSPI). Начальная проверка подлинности пользователя интегрирована с — архитектурой единого входа Winlogon. Initial user authentication is integrated with the Winlogon single sign-on architecture.

Kerberos центр распространения ключей ( KDC ) интегрирован с другими службами безопасности Windows Server, которые работают на контроллере домена. The Kerberos Key Distribution Center (KDC) is integrated with other Windows Server security services that run on the domain controller. В качестве базы данных учетных записей безопасности в KDC используется база данных домен Active Directory Services домена. The KDC uses the domain’s Active Directory Domain Services database as its security account database. Доменные службы Active Directory необходимы для реализации Kerberos по умолчанию в рамках домена или леса. Active Directory Domain Services is required for default Kerberos implementations within the domain or forest.

Практическое применение Practical applications

Преимущества использования Kerberos для — проверки подлинности на основе домена: The benefits gained by using Kerberos for domain-based authentication are:

Делегированная проверка подлинности. Delegated authentication.

Службы, работающие в операционных системах Windows, могут олицетворять клиентский компьютер при доступе к ресурсам от имени клиента. Services that run on Windows operating systems can impersonate a client computer when accessing resources on the client’s behalf. Во многих случаях служба может выполнить свою работу для клиента путем доступа к ресурсам на локальном компьютере. In many cases, a service can complete its work for the client by accessing resources on the local computer. Когда клиентский компьютер проходит проверку подлинности в службе, протоколы NTLM и Kerberos предоставляют сведения авторизации, которые требуются службе для локального олицетворения клиентского компьютера. When a client computer authenticates to the service, NTLM and Kerberos protocol provide the authorization information that a service needs to impersonate the client computer locally. Однако некоторые распределенные приложения спроектированы таким образом, чтобы — Служба внешнего интерфейса должна использовать удостоверение клиентского компьютера при подключении к серверным — службам на других компьютерах. However, some distributed applications are designed so that a front-end service must use the client computer’s identity when it connects to back-end services on other computers. Проверка подлинности Kerberos поддерживает механизм делегирования, позволяющий службе действовать от имени клиента при подключении к другим службам. Kerberos authentication supports a delegation mechanism that enables a service to act on behalf of its client when connecting to other services.

Единый вход. Single sign on.

Использование проверки подлинности Kerberos в домене или в лесу позволяет пользователю или службе получать доступ к ресурсам, разрешенным администраторами, без многократного ввода учетных данных. Using Kerberos authentication within a domain or in a forest allows the user or service access to resources permitted by administrators without multiple requests for credentials. После первоначального входа в систему домена через функцию Winlogon протокол Kerberos управляет учетными данными по всему лесу при каждой попытке доступа к ресурсам. After initial domain sign on through Winlogon, Kerberos manages the credentials throughout the forest whenever access to resources is attempted.

Возможность взаимодействия. Interoperability.

Реализация протокола Kerberos V5 основана на — спецификациях стандартов, которые рекомендуются для использования в задачах Интернет-проектирования ( ) . The implementation of the Kerberos V5 protocol by Microsoft is based on standards-track specifications that are recommended to the Internet Engineering Task Force (IETF). Поэтому в операционных системах Windows протокол Kerberos лежит в основе взаимодействия с другими сетями, в которых для проверки подлинности также используется протокол Kerberos. As a result, in Windows operating systems, the Kerberos protocol lays a foundation for interoperability with other networks in which the Kerberos protocol is used for authentication. Кроме того, корпорация Майкрософт публикует документацию «Протоколы Windows», содержащую сведения о реализации протокола Kerberos. In addition, Microsoft publishes Windows Protocols documentation for implementing the Kerberos protocol. Документация содержит технические требования, ограничения, зависимости и — поведение конкретного протокола Windows для реализации протокола Kerberos корпорацией Майкрософт. The documentation contains the technical requirements, limitations, dependencies, and Windows-specific protocol behavior for Microsoft’s implementation of the Kerberos protocol.

Более эффективная проверка подлинности на серверах. More efficient authentication to servers.

Перед применением Kerberos можно использовать проверку подлинности NTLM, которая требует подключения сервера приложений к контроллеру домена для проверки подлинности каждого клиентского компьютера или службы. Before Kerberos, NTLM authentication could be used, which requires an application server to connect to a domain controller to authenticate every client computer or service. При использовании протокола Kerberos устанавливать возобновляемую билеты сеансов заменяют сквозную — проверку подлинности. With the Kerberos protocol, renewable session tickets replace pass-through authentication. Сервер не обязательно должен быть подключен к контроллеру домена, ( если не требуется проверка сертификата атрибута привилегий ( Pac ) ) . The server is not required to go to a domain controller (unless it needs to validate a Privilege Attribute Certificate (PAC)). Вместо этого сервер может проверить подлинность клиентского компьютера путем проверки учетных данных, предоставленных клиентом. Instead, the server can authenticate the client computer by examining credentials presented by the client. Клиентские компьютеры могут получить учетные данные для определенного сервера однократно и затем использовать их в течение всего сеанса после входа в сеть. Client computers can obtain credentials for a particular server once and then reuse those credentials throughout a network logon session.

Взаимная проверка подлинности. Mutual authentication.

С помощью протокола Kerberos сторона на любом конце сетевого подключения может проверить, что сторона на противоположном конце является субъектом, за которого себя выдает. By using the Kerberos protocol, a party at either end of a network connection can verify that the party on the other end is the entity it claims to be. NTLM не позволяет клиентам проверять удостоверение сервера или включать один сервер для проверки удостоверения другого. NTLM does not enable clients to verify a server’s identity or enable one server to verify the identity of another. Проверка подлинности NTLM предназначена для сетевой среды, в которой серверы считаются подлинными. NTLM authentication was designed for a network environment in which servers were assumed to be genuine. В протоколе Kerberos такого допущения нет. The Kerberos protocol makes no such assumption.

Записки 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, надеемся, что данная статья поможет устранить пробелы и получить первоначальные знания, которые затем можно расширить и углубить уже осмысленно подойдя к прочтению более серьезных материалов.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал: