как проверить kerberos windows

Kerberos Authentication Overview

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

Kerberos — это протокол проверки подлинности, который используется для проверки удостоверения пользователя или узла. в этом разделе содержатся сведения о проверке подлинности Kerberos в Windows Server 2012 и Windows 8.

Описание компонента

Операционные системы Windows Server реализуют протокол проверки подлинности Kerberos версии 5 и расширения для проверки подлинности с помощью открытого ключа, переноса данных авторизации и делегирования. Клиент проверки подлинности Kerberos реализуется в качестве поставщика поддержки безопасности (SSP). Получить к нему доступ можно через интерфейс поставщика поддержки безопасности (SSPI). Начальная проверка подлинности пользователя интегрирована в архитектуру единого входа Winlogon.

Центр распространения ключей Kerberos (KDC) встроен в другие службы безопасности Windows Server, работающие на контроллере домена. В качестве базы данных учетных записей безопасности в KDC используется база данных домен Active Directory Services домена. Доменные службы Active Directory необходимы для реализации Kerberos по умолчанию в рамках домена или леса.

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

Проверка подлинности Kerberos на уровне домена обеспечивает следующие преимущества.

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

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

Единый вход.

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

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

Реализация протокола Kerberos V5 Майкрософт основана на стандартных спецификациях отслеживания, рекомендованных IETF. Поэтому в операционных системах Windows протокол Kerberos лежит в основе взаимодействия с другими сетями, в которых для проверки подлинности также используется протокол Kerberos. Кроме того, корпорация Майкрософт публикует документацию «Протоколы Windows», содержащую сведения о реализации протокола Kerberos. документация содержит технические требования, ограничения, зависимости и поведение протокола, зависящего от Windows, для реализации протокола Kerberos корпорацией майкрософт.

Более эффективная проверка подлинности на серверах.

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

Получив эти данные 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 и устранении неполадок делегирования

Поддержка разработчиков IIS августовский выпуск

Проверка подлинности Kerberos и устранении неполадок делегирования

IIS 6.0

В следующем техническом документе описывается настройка делегирования в Microsoft Windows Server 2003. В документе имеются специальные сведения для балансировки сетевой нагрузки (NLB), но включает прекрасным подробные сведения о настройке делегированные сценарий без использования балансировки сетевой Нагрузки. Чтобы просмотреть этот документ, посетите следующий веб-узел корпорации Майкрософт:

http://technet.microsoft.com/en-us/library/cc757299.aspxПримечание. Использование имен HTTP участника-службы (SPN), особенно при использовании балансировки сетевой Нагрузки.

Другой популярный Kerberos проблема недавно была необходимость обеспечить для нескольких пулов приложений использовать то же имя DNS. К сожалению при использовании Kerberos для делегирования учетных данных в разных пулах приложений нельзя привязать же имя участника службы (SPN). Это невозможно из-за структуры Kerberos. Протокол Kerberos требует нескольких общих секретов для правильной работы протокола. С помощью того же имени участника-службы для различных пулов приложений, мы исключить один из этих общих секретов. В службе каталогов Active Directory не поддерживает такую настройку протокола Kerberos из-за проблемы безопасности.

Настройка SPN таким образом вызывает сбой проверки подлинности Kerberos. Возможным способом решения этой проблемы может быть использование протоколов. Первоначальная проверка подлинности между клиентом и сервером под управлением IIS будет обрабатываться с помощью протокола проверки подлинности NTLM. Kerberos будет обрабатывать проверки подлинности между сервером IIS и ресурсов сервера базы данных.

Microsoft Internet Explorer 6 или более поздней версии

Обозреватель клиента могут возникнуть проблемы, например получение повторного входа запрашивает учетные данные или сообщения об ошибке «401 Access Denied» на сервере под управлением служб IIS. Мы нашли следующие две проблемы, которые могут способствовать решению этих проблем:

299838 не удается согласовать проверку подлинности Kerberos после обновления до Internet Explorer 6

815141 конфигурация усиленной безопасности Internet Explorer изменяет работу в Интернете

IIS 5.0 и IIS 6.0

После обновления IIS 4.0 до IIS 5.0 или IIS 6.0 делегирования может работать неправильно, или возможно кто-то или приложения был изменен свойство метабазы NTAuthenticationProviders.
Дополнительные сведения о том, как устранить эту проблему, щелкните следующий номер статьи базы знаний Майкрософт:

248350 сбой проверки подлинности Kerberos после обновления IIS 4.0 до IIS 5.0

Определенной области проблем может возникнуть при задании имени участника службы

Определение имени сервера

Определите ли вы подключаетесь к веб-узлу, фактические NetBIOS-имя сервера или псевдоним, например имя DNS (например, www.microsoft.com). Если вы обращаетесь к веб-серверу по имени, фактическое имя сервера, новое имя участника службы (SPN) необходимо зарегистрировать с помощью средства Setspn из состава Windows 2000 Server Resource Kit. Поскольку это имя службы неизвестно службе каталогов Active Directory, службы предоставления билетов (TGS) не выдает билет для проверки подлинности пользователя. Это вынуждает клиента используйте следующий метод проверки подлинности, который используется NTLM для повторного согласования. Если веб-сервер отвечает на DNS-имя www.microsoft.com, но сервер с именем webserver1.development.microsoft.com, необходимо зарегистрировать www.microsoft.com в Active Directory на сервере, на котором выполняется под управлением служб IIS. Для этого необходимо загрузить средство Setspn и установить его на сервере, на котором выполняется IIS.

При использовании Windows Server 2003 и IIS 6 средства Setspn для Microsoft Windows Server 2003 можно загрузить из следующей папки:

http://support.microsoft.com/kb/970536Чтобы определить ли вы подключаетесь с помощью фактическое имя, попытайтесь подключиться к серверу с помощью фактическое имя сервера, а не DNS-имя. Если не удается подключиться к серверу, обратитесь к разделу «Проверьте компьютер доверенным для делегирования».

Если можно подключиться к серверу, выполните следующие действия, чтобы назначить имя SPN для имени DNS, который используется для подключения к серверу.

Установите средство Setspn.

На сервере под управлением служб IIS откройте окно командной строки и откройте папку C:\Program Files\Resource комплект.

Выполните следующую команду, чтобы добавить это новое имя участника службы (www.microsoft.com) в Active Directory для сервера:

Появится сообщение, подобное приведенному ниже:
Registering ServicePrincipalNames for CN=webserver1,OU=Domain Controllers,DC=microsoft,DC=comHTTP/www.microsoft.com
Updated object

Чтобы просмотреть список имен SPN на сервере, чтобы видеть это новое значение, введите следующую команду на сервере под управлением служб IIS:

-L Setspn имя_веб-сервераОбратите внимание, что нет необходимости регистрировать все службы. Многие типы служб, например HTTP, W3SVC, WWW, RPC, CIFS (доступ к файлам), WINS и источники бесперебойного питания (ИБП), укажите сопоставляются с типом службы по умолчанию с именем узла. Например если клиентское программное обеспечение использует имя SPN HTTP/webserver1.microsoft.com, чтобы создать подключение HTTP к веб-серверу на сервере webserver1.microsoft.com, но это имя участника службы не зарегистрирован на сервере, контроллере домена Windows 2000 будут автоматически сопоставляться подключение HOST/webserver1.microsoft.com. Это сопоставление применяется только в том случае, если веб-служба выполняется под локальной системной учетной записью.

Убедитесь, что компьютер является доверенным для делегирования

Если этот сервер IIS входит в состав домена, но не является контроллером домена, компьютер должен быть доверенным для делегирования Kerberos для правильной работы. Чтобы сделать это, выполните следующие действия.

На контроллере домена нажмите кнопку Пуск, выделите пункт Настройкаи выберите пункт Панель управления.

На панели управления откройте Администрирование.

Дважды щелкните Active Directory-пользователи и компьютеры.

Под именем своего домена щелкните компьютеры.

В списке найдите сервер IIS, щелкните правой кнопкой мыши имя сервера и выберите пункт Свойства.

Делегирование и Microsoft ASP.NET

Дополнительные сведения о конфигурации для делегирования учетных данных при использовании приложения ASP.NET щелкните следующий номер статьи базы знаний Майкрософт:

Как 810572 настроить приложение ASP.NET для делегирования

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

Ссылки

305971 Windows 2000 Server запрашивает учетные данные пользователя домена

Включение регистрации событий Kerberos как 262177

326985 способы устранения проблем, связанных с Kerberos в службах IIS

Веб-конференции TechNet 842861 : проверка подлинности Kerberos, устранение неполадок, связанных с Microsoft SQL Server и безопасные веб-приложения

Всегда, не стесняйтесь отправить идеи по разделам требуется в дальнейшем адресована столбцов или с помощью базы знаний
Спросите для его форму.

Источник

Как проверить kerberos windows

Добрый день уважаемые читатели, не так давно у меня на работе была задача по настройке групп доступности SQL на Windows кластере, там клиентам сделали красивый веб-инструментарий, все замечательно, теперь клиент ждет следующего развития ситуации, а именно настройка и внедрение механизма Single Sign-On (SSO) или по русски единая точка аутентификация, мы с вами уже с ней знакомились при настройке Vmware vCenter Server. Данный механизм работает на протоколе шифрования kerberos, о котором мы и поговорим. Мы рассмотрим как происходит проверка подлинности kerberos в Active Directory, так как понимание принципов работы, поможет вам в реализации единой точки аутентификации.

Идентификация и доступ в Active Directory

Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:

Протокол аутентификации kerberos

Именно за счет провайдеров Security Support Provider (SSP) сделан механизм аутентификации. Операционная система Windows уже имеет встроенные модули, но никто не мешает программистам, взять и написать свой и подключить его к SSPI

Протокол аутентификации kerberos пришел на смену устаревшему и уже с точки зрения не безопасному, протоколу NTLM, он был основным до Windows 2000. Протокол Kerberos всегда используется в построении механизмов Single Sign-On. В его основе лежит такой принцип, что если двум участникам известен некий ключ и у них есть возможность подтвердить это, то они смогут однозначно идентифицировать друг друга.

Междоменный ключ (inter-realm key). Этот ключ обеспечивает междоменную аутентификацию и используется для обеспечения доверительных отношений в среде Aсtive Directory.

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей). TGT шифруется при помощи ключа, общего для служб KDC, то есть клиент не может прочитать информацию из своего билета. Этот билет используется клиентом для получения других билетов.

Сам Ticket-Granting Service состоит из двух вещей, первая это копия сессионного ключа и информация о клиенте. Все эти данные зашифрованы ключом, общим между сервисом к которому идет обращение и KDC. Это означает, что пользователь не сможет посмотреть эти данные, а вот служба или сервер к которому идет обращение да.

Еще очень важным моментом, является тот фактор, что служба KDC, должна точно знать к какому именно сервису идет обращение и каким ключом шифрования производить обработку. Для этого есть такой механизм, как Service Principal Names, по сути это уникальный идентификатор службы, который будет прописан в вашей базе Active Directory. Из требований к нему, он должен быть уникален в рамках леса. Каждая служба, которая будет использовать Kerberos, должна иметь зарегистрированный SPN. Без правильно настроенного идентификатора протокол для этой службы или сервера работать не будет.

Сам SPN будет хранится в атрибуте Service-Principal-Name, у той учетной записи к которой он привязан и под которым стартует служба. Таким образом, SPN связывает воедино все части процесса. Клиент знает, к какой службе он хочет получить доступ. И при запросе ключа он строит строку SPN, к примеру, при помощи функции DsMakeSpn. Сервер KDC, получив эти данные, может найти учетную запись, под которой стартует эта служба, и, используя ключ этой учетной записи из Active Directory, создать билет доступа к службе и зашифровать его этим ключом.

Как производится настройка SPN мною уже была описана в одной из статей.

Детальная проверка kerberos от начала логирования

Давайте еще в картинках я расскажу более детально как происходит проверка подлинности kerberos, от момента ввода пароля пользователем. И так:

Источник