Remkomplekty.ru

IT Новости из мира ПК
57 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

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

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

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Не поможете в такой ситуации? Это тоже связано с ошибкой Kerberos. На контроллере домена (windows 2003 сервер) netdiag выдает такую ошибку:

Kerberos test. . . . . . . . . . . : Failed
[FATAL] Kerberos does not have a ticket for host/mserver.moffice.xxxxx.ru.
У клиентов это проявляется тем, что не всегда они могут попадать на ресурсы домена и выскакивают ошибки типа этой:

(ID5719) Для домена MOFFICE нет доступного контроллера домена. Ошибка:
Отсутствуют серверы, которые могли бы обработать запрос на вход в сеть. .
Убедитесь в том, что компьютер подключен к сети и повторите попытку. Если ошибка повторяется, обратитесь к сетевому администратору.

(ID40961) Системе безопасности не удалось установить безопасное подключение к серверу ldap/mserver.moffice.xxxxx.ru/moffice.xxxxx.ru@moffice.xxxxx.ru. Отсутствуют доступные протоколы проверки подлинности.

(ID40960) Система безопасности обнаружила попытку атаки для понижения роли сервера cifs/MSERVER. Полученный от протокола проверки подлинности Kerberos код ошибки: «Отсутствуют серверы, которые могли бы обработать запрос на вход в сеть.
(0xc000005e)».

(ID1053) Не удалось определить имя пользователя или компьютера. (Указанный домен не существует или к нему невозможно подключиться. ). Обработка групповой политики прекращена.

Можете что-нибудь подсказать по этому поводу?

Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору Mew
У клиентского ПК нет билета Керберос. Как вариант — синхронизация времени с сервером — интервал не должен превышать 5 минут.

Добавлено:
Следующим этапом имеет смысл удалить пк из домена, удалить его УЗ, потом добавить пк заново.

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Event Type: Warning
Event Source: W32Time
Event Category: None
Event ID: 12
Date: 10.12.2007
Time: 15:59:53
User: N/A
Computer: MSERVER
Description:
Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the PDC emulator for the domain at the root of the forest, so there is no machine above it in the domain hierarchy to use as a time source. It is recommended that you either configure a reliable time service in the root domain, or manually configure the PDC to synchronize with an external time source. Otherwise, this machine will function as the authoritative time source in the domain hierarchy. If an external time source is not configured or used for this computer, you may choose to disable the NtpClient.
***

Event Type: Warning
Event Source: NETLOGON
Event Category: None
Event ID: 5773
Date: 10.12.2007
Time: 9:42:29
User: N/A
Computer: MSERVER
Description:
The following DNS server that is authoritative for the DNS domain controller locator records of this domain controller does not support dynamic DNS updates:

DNS server IP address: 217.16.16.30
Returned Response Code (RCODE): 4
Returned Status Code: 9004

USER ACTION
Configure the DNS server to allow dynamic DNS updates or manually add the DNS records from the file ‘%SystemRoot%System32ConfigNetlogon.dns’ to the DNS database.

Event Type: Error
Event Source: DNS
Event Category: None
Event ID: 6702
Date: 09.12.2007
Time: 15:07:20
User: N/A
Computer: MSERVER
Description:
DNS server has updated its own host (A) records. In order to ensure that its DS-integrated peer DNS servers are able to replicate with this server, an attempt was made to update them with the new records through dynamic update. An error was encountered during this update, the record data is the error code.

If this DNS server does not have any DS-integrated peers, then this error
should be ignored.

If this DNS server’s Active Directory replication partners do not have the correct IP address(es) for this server, they will be unable to replicate with it.

To ensure proper replication:
1) Find this server’s Active Directory replication partners that run the DNS server.
2) Open DnsManager and connect in turn to each of the replication partners.
3) On each server, check the host (A record) registration for THIS server.
4) Delete any A records that do NOT correspond to IP addresses of this server.
5) If there are no A records for this server, add at least one A record corresponding to an address on this server, that the replication partner can contact. (In other words, if there multiple IP addresses for this DNS server, add at least one that is on the same network as the Active Directory DNS server you are updating.)
6) Note, that is not necessary to update EVERY replication partner. It is only necessary that the records are fixed up on enough replication partners so that every server that replicates with this server will receive (through replication) the new data.

Добавить новый сервер в диспетчер сервера, получить ошибку Kerberos 0x80090322

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

Однако, когда я добавляю новый сервер в диспетчер сервера, я получаю ошибку Kerberos: 0x80090322. У меня довольно длинное сообщение об ошибке, которое я опубликую ниже. Я провел некоторое тестирование и узнал, что на самом деле я могу настроить удаленный сеанс Powershell на сервер с использованием проверки подлинности Kerberos:

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

Читать еще:  Как устранить ошибку

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

Сообщение об ошибке, которое относится к коду ошибки 0x80090322:

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

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

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

  1. Проверьте средство просмотра событий событий, связанных с аутентификацией.
  2. Измените метод аутентификации; добавьте целевой компьютер в настройку конфигурации WinRM TrustedHosts или используйте транспорт HTTPS. Обратите внимание, что компьютеры в списке TrustedHosts могут быть не аутентифицированы.
  3. Для получения дополнительной информации о конфигурации WinRM запустите следующую команду: winrm help config.

Чтобы вернуться к пронумерованным элементам сообщения об ошибке:

  1. Для этого я использую учетную запись администратора домена.
  2. Не знаю, как это изменить в диспетчере сервера, поэтому я полагаю, что это должно быть сделано по умолчанию.
  3. Я запускаю внутри домена, запустив диспетчер сервера в качестве администратора домена.
  4. На сервере фактически есть следующие 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
  5. Оба компьютера находятся в одном домене.
  6. На клиентской машине нет событий.
  7. Не нужно делать это.

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

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

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

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

  • Автор: Уваров А.С.
  • 04.07.2016

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

Читать еще:  Vba 6 ошибка

Рассмотрим каким образом происходит аутентификация клиента по протоколу 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

Общие обсуждения

Имеется хост-система Windows 10 и установленная на VMware Windows Server 2008 r2 Core. Серверной версии присвоен ip-адрес. С помощью Диспетчера серверов Windows 10 пытаюсь подключиться по ip для удаленного управления, но выдается «Ошибка проверки подлинности Kerberos». Какие действия предпринять?

  • Изменен тип Petko Krushev Microsoft contingent staff, Moderator 18 апреля 2017 г. 6:32
Читать еще:  Что делать если ошибка isdone dll

Все ответы

Сразу оговорюсь, что в делах администрирования я совсем новичок.

Расхождения во времени нет, везде стоит правильное. winrm включен на Windows Server. Какие логи нужно посмотреть? Спасибо.

Не знаю, насколько это связано, но еще не могу зайти ни в одну службу Active Directory — будь то домены и доверие, сайты и службы и т.д. Отовсюду сыпятся ошибки вроде «указанный домен не существует или к нему невозможно подключиться».

  • Изменено ianbramv 18 марта 2017 г. 11:39

В RSAT ведь и входит Диспетчер серверов, насколько я понимаю? Проблема была изначально, у меня просто появилась задача подключиться к серверу через этот диспетчер.

Через Управление компьютером > Подключиться к другому компьютеру возникает «Ошибка (5). Отказано в доступе».

Хм, команды dcdiag и repadmin /showrepl не проходят на сервере. Видимо, нужно что-то доустанавливать?

Хм, команды dcdiag и repadmin /showrepl не проходят на сервере. Видимо, нужно что-то доустанавливать?

Эти команды необходимо выполнить на DC а не на рядовом сервере, зайдите на DC локально и выполните и выложите вывод команд

Я не волшебник, я только учусь MCP, MCTS, CCNA. Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку «Предложить как ответ» или «Проголосовать за полезное сообщение». Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий. Блог IT Инженера, Twitter.

  • Изменено Alexander Rusinov Moderator 18 марта 2017 г. 13:31 Дополнил

Хм, команды dcdiag и repadmin /showrepl не проходят на сервере. Видимо, нужно что-то доустанавливать?

Как не проходят? Пишут, что команда не найдена, или как?

Какие действия предпринять?

Я бы для диагностики включил протколирование событий Kerberos на Windows 10 и на сервере. И смотрел бы в журналах событий Системы ошибки Kerberos на них и на контроллерах домена.

Эти команды необходимо выполнить на DC а не на рядовом сервере, зайдите на DC локально и выполните и выложите вывод команд
Это Режим восстановления службы каталогов, так? Там такая же ситуация.

Как я понимаю, пойти предложенным мной путём — включить протоколирование Kerberos, чтобы увидеть конкретные события с его ошибками — вы не решились.

Тогда будем пытаться делать вывод из имеющейся информации. Из того, что приведено, подозрительны две вещи:

1. То событие, которое я оставил в цитате — оно может служить причиной проблем с аутентификацией по Kerberos. Проверьте, зарегистрированы ли указанные в нём SPN, а если зарегистрированы — то на кого:

setspn -Q WSMAN/MY-PC.EXITYRWED.COM

setspn -Q WSMAN/MY-PC

Они должны быть зарегистрированы на MY-PC

2. Как настроен DNS (вопрос — потому что был ряд сообщений, заставляющих подозревать неверную настройку)? Поскольку ваш домен неизвестен интернету, то в качестве серверов DNS для всех компьютеров-членов домена, включая сам контроллер домена, в качестве сервера DNS должен быть указан только контроллер домена. Проверяется настройка DNS командой ipconfig /all

PS Вообще, насколько я помню, для подключения с помощью Диспетчера серверов из старших версий Windows к Win2K8 R2 на последней требовалось устанавливать обновлённый Windows Management Framework (какой именно — нужно смотреть в документации по Диспетчеру серверов для старшей версии). Надеюсь, вы это проделали?

Ошибка при подключении по RDP (Исправление шифрования CredSSP)

13 марта Microsoft опубликовал описание уязвимости CVE-2018-0886 в протоколе проверки подлинности CredSSP, который в частности используется при подключении по RDP к терминальным серверам. Позже Microsoft опубликовал, что будет блокировать подключения к необновлённым серверам, где присутствует данная уязвимость. В связи с чем многие заказчики столкнулись с проблемами подключения по RDP.

В частности, в Windows 7 можно увидеть ошибку: «Произошла ошибка проверки подлинности. Указанная функция не поддерживается»

В Windows 10 ошибка расписана более подробно, в частности сказано «Причиной ошибки может быть исправление шифрования CredSSP»:

Для обхода ошибки со стороны клиента многие советуют отключить групповую политику, путём установки значения Encryption Oracle Remediation в Vulnerable:
с помощью gpedit.msc в Конфигурация компьютера / Административные шаблоны / Система / Передача учётных данных, слева выбрать «Исправление уязвимости шифрующего оракула» (забавный конечно перевод), в настройках поставить «Включено» и выбрать «Оставить уязвимость».

или через реестр (т.к., например, в Windows Home нет команды gpedit.msc):

REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2

НО! Так делать не нужно! Т.к. таким образом вы оставляете уязвимость и риски перехвата вашего трафика и пр. конфиденциальные данные, включая пароли. Единственный случай, когда это может быть необходимо, это когда у вас вообще нет другой возможности подключиться к удалённому серверу, кроме как по RDP, чтобы установить обновления (хотя у любого облачного провайдера должна быть возможность подключения к консоли сервера). Сразу после установки обновлений, политики нужно вернуть в исходное состояние.

Если доступ к удалённому серверу есть, то ещё, как временная мера, можно отключить требование NLA (Network Level Authentication), и сервер перестанет использовать CredSSP. Для этого достаточно в Свойствах системы, на вкладке удалённые подключения снять соответствующую галку «Разрешить подключения только с компьютеров, на которых работает удалённый рабочий стол с проверкой подлинности на уровне сети»:

Но, это тоже неправильный подход.

Правильный подход — это всего-лишь установить нужные обновления на операционную систему, закрывающие уязвимость CVE-2018-0886 в CredSSP, причём, как серверную, куда вы подключаетесь, так и клиентскую, с которой вы подключаетесь.

Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector
×
×