Ошибка проверки подлинности kerberos windows server 2012 r2

Обновлено: 04.07.2024

Я настраиваю лабораторную среду Windows. Он имеет контроллер домена Win2012R2 (srv001), и я хотел бы добавить еще один сервер Win2012R2 в домен (srv003). На самом деле все идет хорошо. Я дал новому серверу статический IP-адрес в той же подсети, что и DC, указал его на правильный DNS-сервер и добавил сервер в домен.

Здесь нет проблем. Я побежал Enable-PSRemoting на удаленном сервере проблем тоже нет.

Почему диспетчеру сервера не нравится мой новый сервер? Тем более что возможно настроить удаленный Powershell с использованием того же протокола, на который жалуется Server Manager.

Не удалось обновить конфигурацию со следующей ошибкой: не удалось получить метаданные с сервера из-за следующей ошибки: WinRM не может обработать запрос. При использовании проверки подлинности Kerberos произошла следующая ошибка с кодом ошибки 0x80090322: Произошла неизвестная ошибка безопасности. Возможные причины:

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

После проверки вышеуказанных проблем попробуйте следующее:

Я использую учетную запись администратора домена, чтобы сделать это.
Не уверен, как это изменить в диспетчере сервера, поэтому я полагаю, что по умолчанию это должно быть сделано.
Я бегу внутри домена, запускаю Диспетчер серверов как администратор домена.
На самом деле на сервере есть следующие имена участников-служб, которых я не коснулся:
1. DFSR-12F9A27C-BF97-4787-9364-D31B6C55EB04 / srv003.rwwilden01.local
2. TERMSRV / SRV003
3. TERMSRV / srv003.rwwilden01.local
4. WSMAN / srv003
5. WSMAN / srv003.rwwilden01.local
6. RestrictedKrbHost / SRV003
7. HOST / SRV003
8. RestrictedKrbHost / srv003.rwwilden01.local
9. HOST / srv003.rwwilden01.local
Хорошо, я наконец понял это. Я еще раз внимательно посмотрел журнал событий удаленного сервера. Он содержал ошибку со следующим текстом ошибки:

После того, как я удалил служебную учетную запись, все стало работать так, как я хотел.

11.09.2019

Windows Server 2012 R2

комментариев 20
Пошаговая инструкция по настройке на веб-сайте IIS на Windows Server 2012 R2 прозрачной авторизации доменных пользователей в режиме SSO (Single Sign-On) по протоколу Kerberos.

На веб сервере запустите консоль IIS Manager, выберите нужный сайт и откройте раздел Authentication. Как вы видите, по умолчанию разрешена только анонимная аутентификация (Anonymous Authentication). Отключаем ее и включаем Windows Authentication (IIS всегда сначала пытается выполнить анонимную аутентификацию).

Открываем список провайдеров, доступных для Windows аутентификации (Providers). По умолчанию доступны два провайдера: Negotiate и NTLM. Negotiate – это контейнер, который в качестве первого метода проверки подлинности использует Kerberos, если эта аутентификация не удается, используется NTLM. Необходимо, чтобы в списке провайдеров метод Negotiate стоял первым.

Предположим, у нас имеется ферма IIS серверов. В этом случае оптимально создать отдельную учетную запись в AD и привязать SPN записи к ней. Из-под этой же учетной записи будут запускать целевой Application Pool нашего сайта.

Создадим доменную учетную запись iis_service. Убедимся, что SPN записи для этого объекта не назначены (атрибут servicePrincipalName пустой).

$Setspn /s HTTP/webportal.contoso.loc contoso\iis_service$

Таким образом, мы разрешим этой учетной записи расшифровывать тикеты Kerberos при обращении пользователей к данным адресам и аутентифицировать сессии.

Проверить настройки SPN у учетной записи можно так:

setspn /l iis_service

Совет. Kerberos не будет работать корректно при наличии дублирующих SPN у разных записей домена. С помощью следующей команды, убедитесь, что дубликатов SPN в домене нет: setspn –x
Следующий этап – настройка в IIS Application Pool для запуска из-под созданной сервисной учетной записи.

Выберите Application Pool сайта (в нашем примере это DefaultAppPool).

Откройте раздел настроек Advanced Settings и перейдите к параметру Identity.

Измените его с ApplicationPoolIdentity на contoso\iis_service.

Затем в консоли IIS Manager перейдите на свой сайт и выберите секцию Configuration Editor.

В выпадающем меню перейдите в раздел system.webServer > security > authentication > windowsAuthentication

Измените useAppPoolCredentials на True.

Тем самым мы разрешим IIS использовать доменную учетку для расшифровки билетов Kerberos от клиентов.

Перезапустим IIS командой:

Аналогичную настройку нужно выполнить на всех серверах веб-фермы.
Примечание. В моем примере, на IE11 сразу авторизоваться не получилось. Пришлось добавить адрес в доверенные и в настройках Trusted Zones Sites выставить значение параметра User Authentication -> Logon на Automatic logon with current user name and password
Запускаем Fiddler, в браузере открываем целевой сайт. В левом окне находим строку обращения к сайте. Справа переходим на вкладку Inspectors. Строка Authorization Header (Negotiate) appears to contain a Kerberos ticket, говорит о том, что для авторизации на IIS сайте использовался протокол Kerberos.

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

Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:
- Она должна хранить информацию, о всех объектах Active Directory, среди которых: пользователи, группы безопасности, компьютеры, принтеры и другие объекты идентификации. Под объектом идентификации (identity) подразумевается, некое представление сущности, в задачи которой входит выполнение каких-либо действий в корпоративной сети. Простой пример, есть пользователь Вася и он работает с документами в общей папке на сервере. Эти документы имеют защиту на доступ, который определяет список контроля доступа (Access Contro l List, ACL). Доступом у нужным файлам, управляет подсистема безопасности сервера, где лежит папка, и при обращении к ней он производит сравнение объекта идентификации пользователя с теми объектами, которые присутствуют в его списке ACL, и уже на основании этого, он принимает решение предоставить или запретить пользователю доступ. Так как службы, компьютеры, группы и другие объекты выполняют определенные вещи в локальной сети, то у каждого из них есть свой объект идентификации. Данный объект содержит много информации, уникальной для каждого из них, например, имя пользователя, его идентификатор безопасности (Security Identifier, SID), пароль. Так, что хранилище объектов идентификации, является неотъемлемой частью Identity and Access. Все данные в Active Directory, располагаются в каталоге AD, которым управляет контроллер домена.
- Проверка подлинности объекта идентификации. Тут общий принцип такой, когда пользователь обращается к документу, то сервер его ему не покажет, пока тот, не подтвердит подлинность объекта идентификации, который фигурирует в запросе. Чтобы все это сделать, у пользователя есть некая секретная информация, которая известна ему и инфраструктуре IDA, вот эти данные как раз и сравниваются с теми, что есть в хранилище объектов идентификации в момент проверки подлинности.
Протокол аутентификации kerberos

Чем хороша операционная система Windows, так это тем, что она очень унифицированная, за счет интерфейса SSPI (Security Support Provider Interface). SSPI - это механизм операционной системы Windows в задачи которого идет, предоставление приложениям не зависеть от различных решений протоколов аутентификации, позволяя работать абсолютно с любыми из них, если перефразировать, то любое приложение может использовать любой протокол аутентификации. Еще очень большой плюс интерфейса SSPI, то что он позволяет изолировать сетевой транспорт от протоколов аутентификации, если по простому, то эти протоколы становятся независимыми от протоколов передачи данных по сети, и приложению вообще до лампочки, какой из них использовать.

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

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

Пользовательский ключ - когда системный администратор заводит новую учетную запись пользователя, значение его пароля используется при создании ключа, он хранится рядом с самим объектом пользователя AD. И как написано выше, это ключ знают контроллер домена и пользователь, две стороны.

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

Ключ службы (service key) - тут все просто, очень часто системные администраторы для запуска службы создают отдельного доменного пользователя, в следствии чего служба получит его ключ, но если она запускается под учетной записью системы (LocalSystem), то получит ключ компьютера.

Междоменный ключ (inter-realm key). Этот ключ обеспечивает междоменную аутентификацию и используется для обеспечения доверительных отношений в среде Aсtive Directory.
- Давайте рассматривать каким образом происходит проверка подлинности Kerberos в домене Active Directory. И так пользователь или же компьютер, пытаются войти в локальную сеть домена, именно протокол Kerberos удостоверяется в подлинности указанных реквизитов, в следствии чего выдает пакет данных, а точнее билет или тикет (Ticket), по правильному он называется TGT (Ticket Granting Ticket).
Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей). TGT шифруется при помощи ключа, общего для служб KDC, то есть клиент не может прочитать информацию из своего билета. Этот билет используется клиентом для получения других билетов.
- Теперь когда у пользователя или компьютера есть билет TGT, он может его предоставлять любому сервису или ресурсу. В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS). Данный билет будет идентифицировать прошедшего проверку подлинности пользователя на сервере. Пользователь предоставит TGS билет для доступа к серверу, он его примет и подтвердит прохождение проверки подлинности. Вот тут Kerberos и показывает все свои достоинства, ему требуется лишь один сетевой вход и после получения им билета TGT он проходит проверку подлинности для всего домена целиком, что дает ему возможность получать идентификационные билеты на доступ к службам, не вводя ни каких учетных данных, все эти операции осуществляются за счет встроенных клиентов и служб Kerberos в Kerberos.
Сам Ticket-Granting Service состоит из двух вещей, первая это копия сессионного ключа и информация о клиенте. Все эти данные зашифрованы ключом, общим между сервисом к которому идет обращение и KDC. Это означает, что пользователь не сможет посмотреть эти данные, а вот служба или сервер к которому идет обращение да.
За счет высокого уровня безопасности протокола Kerberos, при передаче данных вы не увидите пароли или значения хэш в открытом виде. Еще одним требованием к работе с данным протоколом, выступает системное время, которое не может расходится с временем на контроллере домена более чем 5 минут
Сам SPN будет хранится в атрибуте Service-Principal-Name, у той учетной записи к которой он привязан и под которым стартует служба. Таким образом, SPN связывает воедино все части процесса. Клиент знает, к какой службе он хочет получить доступ. И при запросе ключа он строит строку SPN, к примеру, при помощи функции DsMakeSpn. Сервер KDC, получив эти данные, может найти учетную запись, под которой стартует эта служба, и, используя ключ этой учетной записи из Active Directory, создать билет доступа к службе и зашифровать его этим ключом.

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

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

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

Я настраиваю лабораторную среду Windows. У этого есть контроллер домена Win2012R2 (srv001), и я хотел бы добавить еще один сервер Win2012R2 в домен (srv003). На самом деле все идет хорошо. Я дал новому серверу статический IP-адрес в той же подсети, что и DC, указал на нужный DNS-сервер и добавил сервер в домен.

Здесь нет проблем. Я запускал Enable-PSRemoting на удаленном сервере, там проблем не было.

Почему менеджеру сервера не нравится мой новый сервер? Тем более, что можно настроить удаленный Powershell, используя тот же протокол, о котором говорит диспетчер сервера.

Ошибка обновления конфигурации со следующей ошибкой: метаданные не удалось получить с сервера из-за следующей ошибки: WinRM не может обработать запрос. При использовании проверки подлинности Kerberos произошла ошибка с кодом ошибки 0x80090322: произошла неизвестная ошибка безопасности. Возможные причины:
1. Недопустимое имя пользователя или пароль.
2. Kerberos используется, если не указан метод аутентификации и имя пользователя.
3. Kerberos принимает имена пользователей домена, но не локальные имена пользователей.
4. Имя участника службы (SPN) для имени и порта удаленного компьютера не существует.
5. Клиент и удаленные компьютеры находятся в разных доменах, и между двумя доменами нет доверия.
После проверки вышеуказанных проблем попробуйте выполнить следующее:
1. I use a domain admin account to do this.
2. Not sure how to change this in Server Manager so I suppose the default should do it.
3. I'm running inside the domain, starting Server Manager as a domain admin.
4. The server actually has the following SPN's which I haven't touched:
  1. Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/srv003.rwwilden01.local
  2. TERMSRV/SRV003
  3. TERMSRV/srv003.rwwilden01.local
  4. WSMAN/srv003
  5. WSMAN/srv003.rwwilden01.local
  6. RestrictedKrbHost/SRV003
  7. HOST/SRV003
  8. RestrictedKrbHost/srv003.rwwilden01.local
  9. HOST/srv003.rwwilden01.local
  Хорошо, я, наконец, понял это. Я еще раз взглянул на журнал событий на удаленном сервере. Он содержит ошибку со следующим текстом ошибки:
  
  После того как я удалил учетную запись службы, все началось, как я думал.
  
  Читайте также:

Ошибка проверки подлинности kerberos windows server 2012 r2

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

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

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