Причина отказа ошибка kerberos ticket expired 0x96c73a20 - TopOshibok.ru - решение и исправление самых разных ошибок

Содержание

Ошибка: сбой проверки подлинности Kerberos
Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:
Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам
Симптомы
Причина
Решение
Вычисление максимального размера маркера
Известные проблемы, влияющие на MaxTokenSize
Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене
Симптомы
Причина
Типы шифрования Kerberos
Проверка подлинности NTLM
Решение
Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4
Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256
Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4
Дополнительная информация
Ошибка проверки подлинности kerberos windows server 2019
Идентификация и доступ в Active Directory
Протокол аутентификации kerberos
Детальная проверка kerberos от начала логирования
Ошибка проверки подлинности kerberos windows server 2019
Спрашивающий
Общие обсуждения
Все ответы

В ходе удаленной отладки может возникнуть следующее сообщение об ошибке:

Эта ошибка возникает, когда монитор удаленной отладки Visual Studio выполняется от имени учетной записи локальной системы (LocalSystem) или учетной записи сетевой службы (NetworkService). Работая под одной из этих учетных записей, удаленный отладчик должен установить соединение с аутентификацией на основе Kerberos, чтобы иметь возможность возвращать данные главному компьютеру отладчика Visual Studio.

Проверка подлинности Kerberos невозможна при следующих условиях:

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

Служба Kerberos на контроллере домена была отключена.

Если аутентификация на основе Kerberos недоступна, следует сменить учетную запись, от имени которой выполняется монитор удаленной отладки Visual Studio. Инструкции см. в статье Ошибка: службе удаленного отладчика Visual Studio не удается подключиться к этому компьютеру.

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

Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:

На целевом компьютере войдите в меню Пуск и выберите в меню Стандартные пункт Командная строка.

В окне командной строки введите:

В первой строке ответа ping будет выведено полное имя компьютера и IP-адрес, возвращаемый службой DNS для указанного компьютера.

Источник

Эта статья поможет вам решить проблемы с ошибкой проверки подлинности Kerberos, когда пользователь принадлежит к многим группам.

Применяется к: Windows 10 — все выпуски, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 327825

Симптомы

Дополнительные сведения о контексте ошибки см. в ссылке HTTP 400 Bad Request (Запросзагона слишком долго) ответов на запросы HTTP.

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

Такое поведение происходит в любой из поддерживаемых в настоящее время Windows версиях. Сведения о поддерживаемых версиях Windows см. в Windows.

Причина

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

В рамках службы проверки подлинности ExchangeWindows создает маркер для представления пользователя для целей авторизации. Этот маркер (также называемый контекстом авторизации) включает идентификаторы безопасности (SID) пользователя и siD-коды всех групп, к которой принадлежит пользователь. Он также включает все SID-данные, хранимые в атрибуте учетной sIDHistory записи пользователя. Kerberos хранит этот маркер в структуре данных сертификата атрибута привилегий (PAC) в билете Kerberos Ticket-Getting (TGT). Начиная с Windows Server 2012, Kerberos также сохраняет маркер в структуре данных Active Directory Claims (Dynamic Access Control) в билете Kerberos. Если пользователь является членом большого количества групп, и если существует много утверждений для пользователя или используемого устройства, эти поля могут занимать много пробелов в билете.

Маркер имеет фиксированный максимальный размер MaxTokenSize (). Транспортные протоколы, такие как удаленный вызов процедуры (RPC) и HTTP, зависят от значения при выделении буферов MaxTokenSize для операций проверки подлинности. MaxTokenSize имеет следующее значение по умолчанию в зависимости от версии Windows, которая создает маркер:

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

Другие факторы также влияют на максимальное число групп. Например, УАИ для глобальных и локальных доменных групп имеют меньшие требования к пространству. Windows Server 2012 и более поздние версии добавляют сведения о претензиях в билет Kerberos, а также сжимаются SID-данные ресурсов. Обе функции изменяют требования к пространству.

Решение

Чтобы устранить эту проблему, обновим реестр на каждом компьютере, который участвует в процессе проверки подлинности Kerberos, включая клиентские компьютеры. Рекомендуется обновить все системы на Windows, особенно если пользователям необходимо войти в несколько доменов или лесов.

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

На каждом из этих компьютеров установите запись реестра для MaxTokenSize большего значения. Эту запись можно найти в HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters подкайке. Компьютеры должны перезапустить после внести это изменение.

Дополнительные сведения об определении нового значения см. в разделе Вычисление максимального размера маркера MaxTokenSize в этой статье.

Например, рассмотрим пользователя, используюшего веб-приложение, которое опирается на SQL Server клиента. В рамках процесса проверки подлинности клиент SQL Server передает маркер пользователя в SQL Server базу данных. В этом случае необходимо настроить запись реестра на каждом MaxTokenSize из следующих компьютеров:

В Windows Server 2012 (и более поздних версиях) Windows можно войти в журнал события (Event ID 31), если размер маркера преодолеет определенный порог. Чтобы включить такое поведение, необходимо настроить параметр групповой политики Конфигурация компьютераАдминистративные шаблоныSystemKDCWarning для больших билетов Kerberos.

Вычисление максимального размера маркера

TokenSize = 1200 + 40d + 8s

Для Windows Server 2012 (и более поздних версий) эта формула определяет свои компоненты следующим образом:

Windows Сервер 2008 R2 и более ранние версии используют ту же формулу. Тем не менее, в этих версиях число членов группы домена и локальной группы является частью значения d, а не значения s.

Если у вас есть значение 0x0000FFFF (64K), вы можете быть в состоянии буферить примерно MaxTokenSize 1600 D-класса SID или примерно 8000 S-class SIDs. Однако на значение, которое можно безопасно использовать, влияет ряд других факторов, в том числе MaxTokenSize следующие:

Если вы используете доверенные учетные записи делегирования, каждый SID требует в два раза больше места.

Если у вас несколько трастов, настройте эти траста для фильтрации siD-систем. Эта конфигурация снижает влияние размера билета Kerberos.

Если вы используете Windows Server 2012 или более поздний вариант, на требования к пространству SID также влияют следующие факторы:

В 2019 г. Корпорация Майкрософт отправила обновления в Windows, которые изменили конфигурацию неподготовленного делегирования для Kerberos на отключенную. Дополнительные сведения см. в статью Updates to TGT delegation across incoming trusts in Windows Server.

Так как сжатие SID ресурсов широко используется и неконтентированное делегированное число неограниченно, 48000 или больше должны стать достаточными для MaxTokenSize всех сценариев.

Известные проблемы, влияющие на MaxTokenSize

Для большинства реализаций должно быть достаточно значения в MaxTokenSize 48 000 bytes. Это значение по умолчанию в Windows Server 2012 и более поздних версиях. Однако, если вы решите использовать большее значение, просмотрите известные проблемы в этом разделе.

Ограничение размера в 1010 групповых SID для маркера доступа к LSA

Эта проблема аналогична тому, что пользователь, у которого слишком много членов группы, не может проверить подлинность, но расчеты и условия, которые регулируют проблему, отличаются. Например, пользователь может столкнуться с этой проблемой при использовании проверки подлинности Kerberos или Windows проверки подлинности NTLM. Дополнительные сведения см. в статью Ведение журнала учетной записи пользователя, в которую входит более 1010групп, на компьютере на Windows сервере.

Известная проблема при использовании значений MaxTokenSize более 48 000

Для смягчения вектора атаки на службу internet Information Server (IIS) использует ограниченный размер буфера http-запроса в 64 КБ. Билет Kerberos, который является частью http-запроса, закодирован как Base64 (6 битов, расширенный до 8 битов). Таким образом, билет Kerberos использует 133 процента от первоначального размера. Поэтому, если максимальный размер буфера в IIS составляет 64 КБ, билет Kerberos может использовать 48 000 битов.

Если задать запись реестра значению, которое превышает 48000 bytes, и буферное пространство используется для siDs, может возникнуть ошибка MaxTokenSize IIS. Однако если вы установите запись реестра до 48 000 бит и используете пространство для SID-файлов и утверждений, возникает ошибка MaxTokenSize Kerberos.

Известные проблемы при использовании значений MaxTokenSize больше 65 535

Мы также определили, что протокол IKE IPSEC не позволяет BLOB-адресу безопасности быть больше 66 536 битов, и он также не будет иметь значения, когда задавалось большее MaxTokenSize значение.

Источник

Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене

Применяется к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 4492348

Симптомы

Компьютер в детском домене леса Службы домена Active Directory (AD DS) не может получить доступ к службе, которая находится в другом домене в одном лесу. При запуске сетевого следа на сообщениях на клиентском компьютере и с клиентского компьютера этот след содержит следующие сообщения Kerberos:

На контроллере домена детского домена viewer событий записи следующую запись события 14:

Причина

Эта проблема возникает при настройке домена ребенка (или только клиента) следующим образом:

Типы шифрования Kerberos

Шифрование RC4 считается менее безопасным, чем более новые типы шифрования, AES128-CTS-HMAC-SHA1-96 и AES256-CTS-HMAC-SHA1-96. Руководства по безопасности, такие как руководство по технической реализации Windows 10 безопасности, предоставляют инструкции по повышению безопасности компьютера, настроив его на использование только шифрования AES128 и/или AES256 (см. типы шифрования Kerberos, чтобы предотвратить использование наборов шифрования DES и RC4).

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

На очень высоком уровне контроллер домена (DC) отвечает за управление запросами доступа в собственном домене. В рамках процесса проверки подлинности Kerberos dc проверяет, что клиент и служба могут использовать один и тот же тип шифрования Kerberos. Однако, когда клиент запрашивает доступ к службе в другом доверяемом домене, dc клиента должен «передать» клиенту dc в домен службы. Когда dc создает билет на передачу, вместо сравнения типов шифрования клиента и службы, он сравнивает типы шифрования клиента и доверия.

Проблема возникает из-за конфигурации самого доверия. В Active Directory объект домена имеет связанные доверенные объекты домена (TDOs), которые представляют каждый домен, которому он доверяет. Атрибуты TDO описывают отношения доверия, включая типы шифрования Kerberos, поддерживаемые доверием. Связь по умолчанию между детским доменом и родительским доменом — это двунаружное транзитное доверие, которое поддерживает тип шифрования RC4. Оба родительского и детского домена имеют TDOs, которые описывают эту связь, в том числе тип шифрования.

Проверка подлинности NTLM

После сбоя проверки подлинности Kerberos клиент пытается вернуться к проверке подлинности NTLM. Однако если проверка подлинности NTLM отключена, у клиента нет других альтернатив. Поэтому попытка подключения сбой.

Решение

Чтобы устранить эту проблему, используйте один из следующих методов:

Выбор зависит от ваших потребностей в безопасности и необходимости свести к минимуму нарушения или поддерживать обратную совместимость.

Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4

Этот метод добавляет новые типы шифрования в конфигурацию доверия и не требует изменений для клиента или службы. В этом методе для настройки доверия используется средство командной ksetup строки.

Чтобы настроить тип доверия шифрования Kerberos, откройте окно командной подсказки на домене DC в доверенного домена и введите следующую команду:

В этой команде представлено полностью квалифицированное доменное имя (FQDN) доверяемого домена.

В примере, в котором находится корневой домен (где находится служба) и это детский домен (где находится клиент), откройте окно командной подсказки на dc и введите следующую contoso.com child.contoso.com contoso.com команду:

После завершения этой команды dc может успешно создать переходный билет, который клиент может использовать для child.contoso.com достижения contoso.com dc.

Так как связь между двумя доменами является двунастройным транзитным доверием, настройте другую сторону доверия, открыв окно Командная подсказка на dc и введите child.contoso.com следующую команду:

Дополнительные сведения о средстве ksetup см. в ksetup.

Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256

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

Полные инструкции по изменению типов шифрования, которые могут использовать клиенты, см. в Windows Конфигурации для поддерживаемого типа шифрования Kerberos.

Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4

Этот метод напоминает метод 1 в том, что вы настраивает атрибуты доверия.

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

При использовании этого метода настройте доверие с помощью оснастки Active Directory Domains and Trusts MMC. Чтобы использовать этот метод, выполните следующие действия:

В доменах Active Directory и Trusts перейдите к надежному объекту домена (в contoso.com примере). Щелкните правой кнопкой мыши объект, выберите свойства и выберите трасты.

В поле Домены, которые доверяют этому домену (входящие трасты), выберите доверчивый домен (в child.domain.com примере).

Выберите свойства, выберите другой домен поддерживает шифрование Kerberos AES, а затем выберите ОК.

Чтобы проверить конфигурацию доверия, выберите Проверка в диалоговом окне доверчивый домен.

В случае доверия в одну сторону доверенный домен перечисляет доверчивый домен как входящий, а доверчивый домен — как исходящую.

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

На вкладке Trusts нажмите кнопку ОК.

Перейдите к объекту домена для доверяемой области ( child.contoso.com ).

Дополнительная информация

Дополнительные сведения о TDOs см. в следующих статьях:

Дополнительные сведения о типах шифрования Kerberos см. в следующих статьях:

Источник

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

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

Источник

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

Этот форум закрыт. Спасибо за участие!

Спрашивающий

trans

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

trans

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

Все ответы

trans

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

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

trans

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

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

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

trans

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

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

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

trans

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

trans

У вас dc виртуальный или физический сервер?

trans

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

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

Источник

Обновлено 03.08.2017

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

Она должна хранить информацию, о всех объектах 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, то что он позволяет изолировать сетевой транспорт от протоколов аутентификации, если по простому, то эти протоколы становятся независимыми от протоколов передачи данных по сети, и приложению вообще до лампочки, какой из них использовать.

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

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

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

Давайте рассматривать каким образом происходит проверка подлинности Kerberos в домене Active Directory. И так пользователь или же компьютер, пытаются войти в локальную сеть домена, именно протокол Kerberos удостоверяется в подлинности указанных реквизитов, в следствии чего выдает пакет данных, а точнее билет или тикет (Ticket), по правильному он называется TGT (Ticket Granting Ticket).

Теперь когда у пользователя или компьютера есть билет TGT, он может его предоставлять любому сервису или ресурсу. В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS). Данный билет будет идентифицировать прошедшего проверку подлинности пользователя на сервере. Пользователь предоставит TGS билет для доступа к серверу, он его примет и подтвердит прохождение проверки подлинности. Вот тут Kerberos и показывает все свои достоинства, ему требуется лишь один сетевой вход и после получения им билета TGT он проходит проверку подлинности для всего домена целиком, что дает ему возможность получать идентификационные билеты на доступ к службам, не вводя ни каких учетных данных, все эти операции осуществляются за счет встроенных клиентов и служб Kerberos в Kerberos.

За счет высокого уровня безопасности протокола Kerberos, при передаче данных вы не увидите пароли или значения хэш в открытом виде. Еще одним требованием к работе с данным протоколом, выступает системное время, которое не может расходится с временем на контроллере домена более чем 5 минут

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

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

Человек видит поля ввода логина и пароля у себя на компьютере
Компьютер получив от пользователя первичные данные делает запрос к контроллеру домена, а точнее к службе Key Distribution Center, где передает KDC имя пользователя в открытом виде, имя домена и текущее время на рабочей станции, еще раз напоминаю, что оно не должно отличаться от времени на контроллере домена более ,чем на 5 минут. Значение текущего времени передается в зашифрованном виде, и будет выступать аутентификатором. Напоминаю, что ключ шифрования (пользовательский ключ) формируется из пароля пользователя, как результат хеширования.

Служба KDC видит обращение с компьютера и начинает поиск пользователя в Active Directory, проверяет его пользовательский ключ и расшифровывает аутентификатор, если по русски она получает время отправления запроса. После чего Key Distribution Center создает два тикета. Первый это сессионный ключ, он нужен для шифрования данных между клиентом и KDC. Второй тикет, это билет на получение билета (Ticket-Granting Ticket (TGT)), как только он появился у пользователя, тот сможет запрашивать тикеты для сервисов и серверов. Сам TGT билет состоит из таких частей: копия ключа сессии, время окончания жизни билета и имя пользователя. TGT шифруется с использованием мастер ключа самой службы Key Distribution Center, поэтому пользователь не может его расшифровать.
Как только эти билеты сформированы Key Distribution Center шифрует аутентификатор пользователя (time stamp) и сессионный ключ, с помощью пользовательского ключа и спокойно передает их пользователю.

Так как у пользователя есть его, пользовательский ключ, он спокойно расшифровывает билеты от Key Distribution Center и проверяет аутентификатор. В итоге он теперь обладает и ключем сессии и TGT ключом, теперь первый этап Kerberos закончен и пользователю больше не нужно в этой сессии заказывать эти билеты.
Далее клиент хочет получить доступ на сервис, так как у него уже есть ключ на получение других ключей (TGT), для доступа к сервису он предоставляет KDC, свой Ticket-Granting Ticket и штамп времени, которые шифрует сессионным ключом.
KDC получает этот запрос и билеты, расшифровывает их используя свой ключ. Контроллер домена подтверждает, что запрос поступил именно от нужного пользователя.

Следующим шагом Key Distribution Center, генерирует два тикета (Service Ticket (TGS)), один для обратившегося клиента, а второй для сервиса, к которому клиент обращается. Каждый из тикетов, будет содержать имя пользователя, кто просит доступ, кто должен получить запрос, штамп времени, рассказывающий, когда создан тикет, и срок его жизни, а так же новый ключ Kcs. Kcs — это ключ для сервиса и клиента, в задачи которого входит обеспечение безопасного взаимодействия между ними. Далее KDC шифрует билет сервиса, используя для этого системный ключ сервера и вкладывает этот билет внутрь билета клиента, у которого так же есть свой Kcs ключ.
Теперь все это дело шифруется сессионным ключом и передается клиенту.

Клиент получает билет, расшифровывает его с помощью сессионного ключа и видит свой TGS тикет, и Kcs сервиса, клиент не может прочитать Kcs предназначенный для сервиса

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

Когда сервер с сервисом, получает эту информацию, он сразу видит пакет от KDC предназначенный для него с ключом TGS (Kcs). Он расшифровывает им штамп времени от клиента.
Так как у обоих участников есть TGS ключ, они могут быть обо уверены, что клиент правильно идентифицирован, т. к. для шифрования маркера времени был использован Kcs . В случае необходимости ответа сервера клиенту, сервер воспользуется ключом Kcs . Клиент будет знать, что сервер правильно идентифицирован, поскольку сервер должен использовать, чтобы получить Kcs.

Блог did5.ru

Просматривал журнал на своем рабочем компьютере с Windows 7 и наткнулся на любопытную ошибку. (у коллеги на компьютере с Windows XP таких ошибок нет)

EventID 4

EventSourceName Kerberos

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера PC1$. Использовалось конечное имя cifs/PC2.domain.ru. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером.

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

Самое интересное, что PC1 и PC2 находятся в другой подсети и почему эта ошибка отобразилась в моем журнале – непонятно!

В интернете пишут, что ошибка возникает из-за DNS, в котором могут быть прописаны разные узлы с одним и тем же IP-адресом. Но у меня в DNS было все нормально, записей с одним IP не было.

Решил глянуть, что происходит в WINS. Мысль оказалась верной. При поиске по IP адресу, вылезло сразу 3 машины на один айпи. Потер все совпадающие записи с сервера WINS и надеюсь, что ошибки пропадут.

Нашли опечатку в тексте? Пожалуйста, выделите ее и нажмите Ctrl+Enter! Спасибо!

Активация Windows Server 2019 Core

Остается еще активировать ваш сервер, надеюсь, что у вас в локальной сети развернут и настроен KMS сервер. Выбираем 11 пункт. В параметрах активации Windows, у вас будут пункты:

Просмотр сведений о лицензии
Активация Windows
Установка ключа продукта
Вернуться в главное меню

Просмотрим текущее состояние активации Windows Server 2019 Core. Выбираем пункт 1. У вас откроется окно командной строки, вы увидите работу скрипта slmgr. В моем примере я вижу редакцию ОС, ее тип Volume и то, что активация не выполнена, ошибка 0x0C004F056.

Попробуем активировать сервер, выбираем пункт 2. Если KMS есть, то все отработает, если его нет ,то получите ошибку «0x8007232B DNS-имя не существует».

Если нужно поменять ключ продукта, то выберите пункт 3, и у вас откроется еще одно графическое окошко.

В Windows Server 2019 Core по умолчанию уже включена служба удаленно управления WinRM, поэтому дополнительно ее настраивать не нужно. В окне PowerShell введите:

В итоге я спокойно подключился и ввел команду ipconfig, где вижу ранее настроенный ip-адрес.

На этом я хочу закончить базовую установку и настройку Windows Server 2019 Core. В будущих статьях я вам расскажу ,как включать «Удаленное управление» через оснастку, научу настраивать правила брандмауэра. С вами был Иван Семин .автор и создать IT портала Pyatilistnik.org.

Связанные статьи:

(100%) (100%) (100%) (100%) (100%) (RANDOM — 50%)

Comments

Дякую! Допомогли вирішити дану проблему )

Не помогло. Брэндмауэр отключил даже. И все равно сервер никто не может дажи пинговать. Хотя сервак пингует ПК

А что именно не помогло исправить? Настройка не сохраняется? Эта заметка посвящена тому, как включить конкретную настройку.

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

Что касается пинга Windows хостов, то особо на это не стоит обращать внимания, так как по умолчанию все Windows машины настроены не отвечать на пинги. То есть если машина не отвечает на пинг, то это не означает, например, что не будет доступа к сетевой папке, которая размещена на ней.

Клавиши функций Internet Explorer

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

HKEY_USERSSoftwareMicrosoftInternet ExplorerMainFeatureControl — если определено на уровне пользователя
HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternet ExplorerMainFeatureControl — если определено на уровне машины

Клавиши функций должны создаваться в одном из этих местоположений в зависимости от того, хотите ли вы включить или отключить эту функцию:

для всех пользователей на компьютере
только для определенной учетной записи

Эти ключи должны быть созданы по соответствующему пути. В ключе должно быть объявлено значение DWORD, которое iexplorer.exe называется. Значение каждого ключа по умолчанию должно быть верным или ложным в зависимости от нужного параметра функции. По умолчанию значение обоих ключей функций и FEATURE_INCLUDE_PORT_IN_SPN_KB908209 FEATURE_USE_CNAME_FOR_SPN_KB911149 , является ложным. Для полноты, вот пример экспорта реестра, поверив ключ функции, чтобы включить номера портов в билете Kerberos на значение true:

Источник

Содержание

Ошибка: сбой проверки подлинности Kerberos
Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:
Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам
Симптомы
Причина
Решение
Вычисление максимального размера маркера
Известные проблемы, влияющие на MaxTokenSize
Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене
Симптомы
Причина
Типы шифрования Kerberos
Проверка подлинности NTLM
Решение
Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4
Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256
Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4
Дополнительная информация
Ошибка проверки подлинности kerberos windows server 2019
Идентификация и доступ в Active Directory
Протокол аутентификации kerberos
Детальная проверка kerberos от начала логирования
Ошибка проверки подлинности kerberos windows server 2019
Спрашивающий
Общие обсуждения
Все ответы

В ходе удаленной отладки может возникнуть следующее сообщение об ошибке:

Проверка подлинности Kerberos невозможна при следующих условиях:

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

Служба Kerberos на контроллере домена была отключена.

Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:

На целевом компьютере войдите в меню Пуск и выберите в меню Стандартные пункт Командная строка.

В окне командной строки введите:

Источник

Применяется к: Windows 10 — все выпуски, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 327825

Симптомы

Причина

Решение

Вычисление максимального размера маркера

TokenSize = 1200 + 40d + 8s

Для Windows Server 2012 (и более поздних версий) эта формула определяет свои компоненты следующим образом:

Если вы используете доверенные учетные записи делегирования, каждый SID требует в два раза больше места.

Известные проблемы, влияющие на MaxTokenSize

Ограничение размера в 1010 групповых SID для маркера доступа к LSA

Известная проблема при использовании значений MaxTokenSize более 48 000

Известные проблемы при использовании значений MaxTokenSize больше 65 535

Источник

Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене

Применяется к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 4492348

Симптомы

На контроллере домена детского домена viewer событий записи следующую запись события 14:

Причина

Эта проблема возникает при настройке домена ребенка (или только клиента) следующим образом:

Типы шифрования Kerberos

Проверка подлинности NTLM

Решение

Чтобы устранить эту проблему, используйте один из следующих методов:

Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4

В этой команде представлено полностью квалифицированное доменное имя (FQDN) доверяемого домена.

Дополнительные сведения о средстве ksetup см. в ksetup.

Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256

Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4

Этот метод напоминает метод 1 в том, что вы настраивает атрибуты доверия.

Выберите свойства, выберите другой домен поддерживает шифрование Kerberos AES, а затем выберите ОК.

Чтобы проверить конфигурацию доверия, выберите Проверка в диалоговом окне доверчивый домен.

На вкладке Trusts нажмите кнопку ОК.

Перейдите к объекту домена для доверяемой области ( child.contoso.com ).

Дополнительная информация

Дополнительные сведения о TDOs см. в следующих статьях:

Дополнительные сведения о типах шифрования Kerberos см. в следующих статьях:

Источник

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

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

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

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

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

Источник

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

Этот форум закрыт. Спасибо за участие!

Спрашивающий

trans

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

trans

Все ответы

trans

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

trans

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

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

trans

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

trans

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

trans

У вас dc виртуальный или физический сервер?

trans

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

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

Источник

В продолжение давней темы про использование двухфакторной аутентификации в ОС GNU/Linux позвольте рассказать про схему работы и настройку аутентификации с помощью Kerberos. В этой статье мы рассмотрим процесс настройки MIT Kerberos для аутентификации пользователей по сертификатам и ключевым парам, находящимся на USB-токене. Также материалы, изложенные в статье, можно использовать для настройки аутентификации в домене Windows.

Краткое введение

Для начала проведем небольшой ликбез по терминологии Kerberos и рассмотрим доступные реализации этого протокола в ОС на базе GNU/Linux. Сразу оговорюсь, что мне не удалось найти однозначного перевода терминов, использующихся в Kerberos, поэтому для избежания путаницы основные термины я буду дублировать на английском.
Итак, начнем. Если процитировать Википедию, то

Kerberos – сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован, в первую очередь, на клиент-серверную модель и обеспечивает взаимную аутентификацию – оба пользователя через сервер подтверждают личности друг друга.

Стоит отметить, что Kerberos в первую очередь является протоколом, а не конкретной системой аутентификации. Его реализации используются в различных операционных системах, в том числе и в Windows, как метод аутентификации пользователей в домене. Существует несколько open source реализаций протокола Kerberos, например оригинальная MIT Kerberos и Heimdal. Такой зоопарк возник из-за ограничений США на экспорт криптографических средств защиты информации, на сегодня эта ситуация вокруг MIT Kerberos уже улеглась. В статье мы рассмотрим процесс настройки для MIT Kerberos V5.

Терминология Kerberos

Билет (ticket) – временные данные, выдаваемые клиенту для аутентификации на сервере, на котором располагается необходимая служба.
Клиент (client) – некая сущность в сети (пользователь, хост или сервис), которая может получить билет от Kerberos.
Центр выдачи ключей (key distribution center, KDC) – сервис, выдающий билеты Kerberos.
Область (realm) – сеть, используемая Kerberos, состоящая из серверов KDC и множества клиентов. Имя realm регистрозависимо, обычно пишется в верхнем регистре и совпадает с именем домена.
Принципал (principal) – уникальное имя для клиента, для которого разрешается аутентификация в Kerberos. Записывается в виде root[/instance]@REALM.

Файлы настроек Kerberos

На сервере:

/etc/krb5kdc/kdc.conf — настройки KDC

На клиенте и сервере:

/etc/kbr5.conf — настройки сервера аутентификации (описание realms, доменных имен и других настроек)

Настройка рабочего окружения

Для начала необходимо развернуть среду, в которой будет производиться аутентификация. Наиболее просто это сделать, взяв две виртуальные машины, находящиеся в одной подсети. Достаточно установить на одну виртуальную машину какую-нибудь Ubuntu (это будет наш сервер), а затем клонировать ее и получить клиента. При написании статьи я воспользовался свежей Ubuntu 12.10 (x86) и виртуальной машиной от VMWare. Чтобы виртуальным машинам было удобнее видеть друг друга по сети, стоит переключить сетевые карты в Bridged-режим.
Важно! Следите за тем, чтобы время на клиенте и сервере было синхронизировано, это необходимо для корректной работы Kerberos.

Настройка сети

Клиенты Kerberos ищут свои сервера по доменным именам, поэтому необходимо настроить DNS и убедиться, что имена серверов успешно разрешаются. В нашем примере достаточно занести доменное имя сервера в /etc/hosts, что я и сделал. Схема «сети» изображена ниже.

Установка необходимых пакетов

На сервере нам потребуются:

krb5-kdc – сервис KDC
krb5-admin-server – административный сервер Kerberos (он ведет контроль учетных записей пользователей)
krb5-pkinit – модуль расширения Kerberos для аутентификации по сертификатам

На клиент надо поставить следующие пакеты:

krb5-user – базовый набор утилит для работы клиентской аутентификации
krb5-config – файлы настроек Kerberos
krb5-pkinit
libpam-krb5 – модуль PAM для использования Kerberos-аутентификации
pcscd, opensc, libengine-pkcs11-openssl – пакеты, необходимые для работы с токенами

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

Default realm: AKTIV-TEST.RU
Имена серверов (admin server и KDC): aktiv-test.ru (он же прописан в /etc/hosts на клиенте)
Пользователь: testuser@AKTIV-TEST.RU

Настройка Kerberos

Базовые настройки

После установки пакетов на сервере нужно инициализировать realm командой

$ sudo krb5_newrealm

А на клиенте – обновить файлы конфигурации:

$ sudo dpkg-reconfigure krb5-config

Также на клиенте и сервере надо добавить следующие строки в /etc/krb5.conf:

[domain_realm] .aktiv-test.ru = AKTIV-TEST.RU aktiv-test.ru = AKTIV-TEST.RU

Теперь создадим на сервере нового пользователя c именем testuser

$ sudo kadmin.local # username = testuser # password = test # добавляем нового пользователя и устанавливаем его пароль kadmin.local:$ addprinc testuser # ... kadmin.local:$ quit

На клиенте теперь можно проверить, правильно ли мы настроили сеть и Kerberos:

$ kinit testuser@AKTIV-TEST.RU # вводим пароль пользователя $ klist # и видим выданный ticket, после чего его можно удалить следующей командой $ kdestroy

Настройка аутентификации по открытому ключу

Для работы модуля pkinit нам придется воспользоваться openssl в качестве мини-УЦ, чтобы создать ключевые пары и сертификаты клиента и сервера.

На сервере:

Создадим ключевую пару и сертификат нашего «УЦ». Здесь мы сгененируем ключ УЦ и создадим самоподписанный сертификат с помощью openssl. В реальном мире ключ естественно надо надежно защитить от попадания в чужие руки.

$ openssl genrsa -out cakey.pem 2048 # ... $ openssl req -key cakey.pem -new -x509 -out cacert.pem # ...

Создадим ключевую пару для KDC, заявку на сертификат и выпишем его сами себе.
Здесь нам потребуется специальный файл расширений OpenSSL (pkinit_extensions), в котором будут указаны дополнительные поля сертификатов, используемых в Kerberos. В частности, мы зададим:

Extended Key Usage (EKU) – идентификатор (OID), говорящий о том, как планируется использовать сертификат
otherName – поле, задающее нашего принципала, для которого выписывается сертификат

$ openssl genrsa -out kdckey.pem 2048 # создание запроса $ openssl req -new -out kdc.req -key kdckey.pem # подпись запроса $ REALM=AKTIV-TEST.RU; export REALM $ CLIENT=aktiv-test.ru; export CLIENT # содержимое файла pkinit_extensions см. по ссылке выше $ openssl x509 -req -in kdc.req -CAkey cakey.pem -CA cacert.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc_cert –CAcreateserial

После этого перенесем следующие файлы в /var/lib/krb5kdc/:

kdc.pem
kdckey.pem
cacert.pem

На сервере отредактируем настройки Kerberos (файл /etc/krb5kdc/kdc.conf) для использования ключей и сертификатов сервера и УЦ:

[kdcdefaults]     kdc_tcp_ports = 88     pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem     pkinit_anchors = FILE:/var/lib/krb5kdc/cacert.pem [realms]     AKTIV-TEST.RU = {         database_name = /var/lib/krb5kdc/principal         admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab         acl_file = /etc/krb5kdc/kadm5.acl         key_stash_file = /etc/krb5kdc/stash         max_life = 10h 0m 0s         max_renewable_life = 7d 0h 0m 0s         master_key_type = des3-hmac-sha1         supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3         default_principal_flags = +preauth     }

Далее на сервере необходимо включить предварительную аутентификацию для нашего пользователя.

$ kadmin.local kadmin.local$: modprinc +requires_preauth testuser

Дальнейшие действия будем выполнять на клиенте

Отформатируем токен

$ pkcs15-init --erase-card -p rutoken_ecp $ pkcs15-init --create-pkcs15 --so-pin "87654321" --so-puk "" $ pkcs15-init --store-pin --label "User PIN" --auth-id 02 --pin "12345678" --puk "" --so-pin "87654321" –finalize

Сгенерируем на токене ключевую пару RSA 2048 бит и создадим заявку на сертификат. Важно заметить, что пути до библиотек engine_pkcs11.so и opensc-pkcs11.so на вашей системе могут отличатся, поэтому сначала стоит проверить их расположение.

# на данном шаге важно запомнить ID ключевой пары, его мы используем позже $ pkcs15-init -G rsa/2048 --auth-id 02 --id 42 --label "testuser's key" --public-key-label "testuser's public key" # ... $ openssl # на multiarch-системах opensc-pkcs11.so и engine_pkcs11.so могут лежать в других местах OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/openssl/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:opensc-pkcs11.so (dynamic) Dynamic engine loading support [Success]: SO_PATH:/usr/lib/openssl/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: LIST_ADD:1 [Success]: LOAD [Success]: MODULE_PATH:opensc-pkcs11.so Loaded: (pkcs11) pkcs11 engine OpenSSL> req -engine pkcs11 -new -key 1:42 -keyform engine -out client.req -subj "/C=RU/ST=Moscow/L=Moscow/O=Aktiv/OU=dev/CN=testuser/emailAddress=testuser@mail.com" engine "pkcs11" set. PKCS#11 token PIN: OpenSSL> quit

После этого мы получим файл-заявку client.req, которую необходимо поместить на сервер и выписать сертификат пользователя на основе данных УЦ:

$ REALM=AKTIV-TEST.RU; export REALM $ CLIENT=testuser; export CLIENT $ openssl x509 -CAkey cakey.pem -CA cacert.pem -req -in client.req -extensions client_cert -extfile pkinit_extensions -out client.pem

Затем стоит перезапустить сервер и KDC:

$ /etc/init.d/krb5-admin-server restart $ /etc/init.d/krb5-kdc restart

На выходе работы openssl мы получим файл с сертификатом клиента client.pem. Его нужно перенести на клиентскую машину, положить в /etc/krb5/ и записать на токен:

$ pkcs15-init --store-certificate client.pem --auth-id 02 --id 42 --format pem

И в завершение нам потребуется внести в файл конфигурации Kerberos настройку, которая укажет, какие данные использовать для аутентификации (в нашем случае это сертификат УЦ и путь до модуля PKCS#11). В документации MIT Kerberos указаны различные параметры, которые позволяют настроить выбор аутентификационных данных на токене, в нашем же случае мы просто указываем модуль PKCS#11, поскольку в данной ситуации этого достаточно.

[libdefaults] default_realm = AKTIV-TEST.RU # путь к сертификату УЦ pkinit_anchors = FILE:/etc/krb5/cacert.pem # путь к модулю PKCS#11 pkinit_identities = PKCS11:/usr/lib/opensc-pkcs11.so

Проверим, можем ли мы получить ticket на клиенте, используя данные с токена:

$ kinit testuser # на этом этапе у нас должны спросить PIN-код от токена $ klist

Настройка PAM-аутентификации с использованием Kerberos

Ранее при настройке клиентской машины мы поставили пакет libpam-krb5. Он поможет нам выполнить аутентификацию в Kerberos при входе в систему, а также в приложениях, использующих системную аутентификацию (например login, lightdm и проч.). Для подключения модуля PAM достаточно выполнить команду

$ sudo pam-auth-update

и выбрать в диалоге необходимые модули аутентификации. Для более тонкой настройки можно заглянуть в файл /etc/pam.d/common-auth и отредактировать его по желанию. Структуру файла я описывал в предыдущей статье.

Заключение

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

Полезные ссылки

Описание протокола Kerberos
Официальная документация
Инструкция по настройке от сообщества Ubuntu
Настройка PKINIT

Обновлено 03.08.2017

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

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

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

Давайте рассматривать каким образом происходит проверка подлинности Kerberos в домене Active Directory. И так пользователь или же компьютер, пытаются войти в локальную сеть домена, именно протокол Kerberos удостоверяется в подлинности указанных реквизитов, в следствии чего выдает пакет данных, а точнее билет или тикет (Ticket), по правильному он называется TGT (Ticket Granting Ticket).

Теперь когда у пользователя или компьютера есть билет TGT, он может его предоставлять любому сервису или ресурсу. В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS). Данный билет будет идентифицировать прошедшего проверку подлинности пользователя на сервере. Пользователь предоставит TGS билет для доступа к серверу, он его примет и подтвердит прохождение проверки подлинности. Вот тут Kerberos и показывает все свои достоинства, ему требуется лишь один сетевой вход и после получения им билета TGT он проходит проверку подлинности для всего домена целиком, что дает ему возможность получать идентификационные билеты на доступ к службам, не вводя ни каких учетных данных, все эти операции осуществляются за счет встроенных клиентов и служб Kerberos в Kerberos.

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

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

Человек видит поля ввода логина и пароля у себя на компьютере
Компьютер получив от пользователя первичные данные делает запрос к контроллеру домена, а точнее к службе Key Distribution Center, где передает KDC имя пользователя в открытом виде, имя домена и текущее время на рабочей станции, еще раз напоминаю, что оно не должно отличаться от времени на контроллере домена более ,чем на 5 минут. Значение текущего времени передается в зашифрованном виде, и будет выступать аутентификатором. Напоминаю, что ключ шифрования (пользовательский ключ) формируется из пароля пользователя, как результат хеширования.

Служба KDC видит обращение с компьютера и начинает поиск пользователя в Active Directory, проверяет его пользовательский ключ и расшифровывает аутентификатор, если по русски она получает время отправления запроса. После чего Key Distribution Center создает два тикета. Первый это сессионный ключ, он нужен для шифрования данных между клиентом и KDC. Второй тикет, это билет на получение билета (Ticket-Granting Ticket (TGT)), как только он появился у пользователя, тот сможет запрашивать тикеты для сервисов и серверов. Сам TGT билет состоит из таких частей: копия ключа сессии, время окончания жизни билета и имя пользователя. TGT шифруется с использованием мастер ключа самой службы Key Distribution Center, поэтому пользователь не может его расшифровать.
Как только эти билеты сформированы Key Distribution Center шифрует аутентификатор пользователя (time stamp) и сессионный ключ, с помощью пользовательского ключа и спокойно передает их пользователю.

Так как у пользователя есть его, пользовательский ключ, он спокойно расшифровывает билеты от Key Distribution Center и проверяет аутентификатор. В итоге он теперь обладает и ключем сессии и TGT ключом, теперь первый этап Kerberos закончен и пользователю больше не нужно в этой сессии заказывать эти билеты.
Далее клиент хочет получить доступ на сервис, так как у него уже есть ключ на получение других ключей (TGT), для доступа к сервису он предоставляет KDC, свой Ticket-Granting Ticket и штамп времени, которые шифрует сессионным ключом.
KDC получает этот запрос и билеты, расшифровывает их используя свой ключ. Контроллер домена подтверждает, что запрос поступил именно от нужного пользователя.

Следующим шагом Key Distribution Center, генерирует два тикета (Service Ticket (TGS)), один для обратившегося клиента, а второй для сервиса, к которому клиент обращается. Каждый из тикетов, будет содержать имя пользователя, кто просит доступ, кто должен получить запрос, штамп времени, рассказывающий, когда создан тикет, и срок его жизни, а так же новый ключ Kcs. Kcs — это ключ для сервиса и клиента, в задачи которого входит обеспечение безопасного взаимодействия между ними. Далее KDC шифрует билет сервиса, используя для этого системный ключ сервера и вкладывает этот билет внутрь билета клиента, у которого так же есть свой Kcs ключ.
Теперь все это дело шифруется сессионным ключом и передается клиенту.

Клиент получает билет, расшифровывает его с помощью сессионного ключа и видит свой TGS тикет, и Kcs сервиса, клиент не может прочитать Kcs предназначенный для сервиса

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

Когда сервер с сервисом, получает эту информацию, он сразу видит пакет от KDC предназначенный для него с ключом TGS (Kcs). Он расшифровывает им штамп времени от клиента.
Так как у обоих участников есть TGS ключ, они могут быть обо уверены, что клиент правильно идентифицирован, т. к. для шифрования маркера времени был использован Kcs . В случае необходимости ответа сервера клиенту, сервер воспользуется ключом Kcs . Клиент будет знать, что сервер правильно идентифицирован, поскольку сервер должен использовать, чтобы получить Kcs.

Remove From My Forums

Общие обсуждения
Приветствую.

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

Все ответы

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

Расхождения во времени нет, везде стоит правильное. 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
  18 марта 2017 г. 13:31
  Дополнил
Хм, команды dcdiag и repadmin /showrepl не проходят на сервере. Видимо, нужно что-то доустанавливать?

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

Слава России!
Какие действия предпринять?

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

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

Это Режим восстановления службы каталогов, так? Там такая же ситуация…
Да, пишет, что команды такие не найдены.

Результаты:

Doing initial required tests
Testing server: Default-First-Site-NameMY-PC
Starting test: Connectivity
......................... MY-PC passed test Connectivity
Doing primary tests
Testing server: Default-First-Site-NameMY-PC
Starting test: Advertising
......................... MY-PC passed test Advertising
Starting test: FrsEvent
......................... MY-PC passed test FrsEvent
Starting test: DFSREvent
There are warning or error events within the last 24 hours after the SYSVOL has
been shared. Failing SYSVOL replication problems may cause Group Policy
problems.
......................... MY-PC failed test DFSREvent
Starting test: SysVolCheck
......................... MY-PC passed test SysVolCheck
Starting test: KccEvent
A warning event occurred. EventID: 0x80000734
Time Generated: 03/18/2017 19:27:21
Event String:
The local domain controller could not connect with the following domain contro
ller hosting the following directory partition to resolve distinguished names.
A warning event occurred. EventID: 0x80000734
Time Generated: 03/18/2017 19:28:49
Event String:
The local domain controller could not connect with the following domain contro
ller hosting the following directory partition to resolve distinguished names.
A warning event occurred. EventID: 0x80000734
Time Generated: 03/18/2017 19:31:51
Event String:
The local domain controller could not connect with the following domain contro
ller hosting the following directory partition to resolve distinguished names.
......................... MY-PC passed test KccEvent
Starting test: KnowsOfRoleHolders
......................... MY-PC passed test KnowsOfRoleHolders
Starting test: MachineAccount
......................... MY-PC passed test MachineAccount
Starting test: NCSecDesc
......................... MY-PC passed test NCSecDesc
Starting test: NetLogons
......................... MY-PC passed test NetLogons
Starting test: ObjectsReplicated
......................... MY-PC passed test ObjectsReplicated
Starting test: Replications
......................... MY-PC passed test Replications
Starting test: RidManager
......................... MY-PC passed test RidManager
Starting test: Services
Invalid service startup type: NtFrs on MY-PC, current value DISABLED,
expected value AUTO_START
NtFrs Service is stopped on [MY-PC]
......................... MY-PC failed test Services
Starting test: SystemLog
A warning event occurred. EventID: 0x80080002
Time Generated: 03/18/2017 18:47:46
Event String: VMCI: Not supported in Safe Boot Mode.
A warning event occurred. EventID: 0x80080002
Time Generated: 03/18/2017 18:47:46
Event String: VMCI: Not supported in Safe Boot Mode.
An error event occurred. EventID: 0xC0001B58
Time Generated: 03/18/2017 18:48:09
Event String:
The Link-Layer Topology Discovery Mapper I/O Driver service failed to start du
e to the following error:
An error event occurred. EventID: 0xC0001B58
Time Generated: 03/18/2017 18:48:09
Event String:
The Link-Layer Topology Discovery Responder service failed to start due to the
following error:
An error event occurred. EventID: 0xC0001B72
Time Generated: 03/18/2017 18:48:18
Event String:
The following boot-start or system-start driver(s) failed to load:
An error event occurred. EventID: 0xC0001B6F
Time Generated: 03/18/2017 18:50:19
Event String:
The Software Protection service terminated with the following error:
A warning event occurred. EventID: 0x80080002
Time Generated: 03/18/2017 19:00:31
Event String: VMCI: Not supported in Safe Boot Mode.
A warning event occurred. EventID: 0x80080002
Time Generated: 03/18/2017 19:00:31
Event String: VMCI: Not supported in Safe Boot Mode.
An error event occurred. EventID: 0xC0001B58
Time Generated: 03/18/2017 19:00:55
Event String:
The Link-Layer Topology Discovery Mapper I/O Driver service failed to start du
e to the following error:
An error event occurred. EventID: 0xC0001B58
Time Generated: 03/18/2017 19:00:55
Event String:
The Link-Layer Topology Discovery Responder service failed to start due to the
following error:
An error event occurred. EventID: 0xC0001B72
Time Generated: 03/18/2017 19:01:04
Event String:
The following boot-start or system-start driver(s) failed to load:
An error event occurred. EventID: 0xC0001B6F
Time Generated: 03/18/2017 19:03:05
Event String:
The Software Protection service terminated with the following error:
A warning event occurred. EventID: 0x80040033
Time Generated: 03/18/2017 19:20:25
Event String:
An error was detected on device DeviceHarddisk1DR1 during a paging operatio
n.
An error event occurred. EventID: 0x0000002E
Time Generated: 03/18/2017 19:25:18
Event String:
The time service encountered an error and was forced to shut down. The error w
as: 0x80070700: An attempt was made to logon, but the network logon service was not starte
d.
An error event occurred. EventID: 0xC0001B6F
Time Generated: 03/18/2017 19:25:18
Event String: The Windows Time service terminated with the following error:
An error event occurred. EventID: 0x0000002E
Time Generated: 03/18/2017 19:25:33
Event String:
The time service encountered an error and was forced to shut down. The error w
as: 0x80070005: Access is denied.
An error event occurred. EventID: 0xC0001B6F
Time Generated: 03/18/2017 19:25:33
Event String: The Windows Time service terminated with the following error:
A warning event occurred. EventID: 0x8000001D
Time Generated: 03/18/2017 19:26:45
Event String:
The Key Distribution Center (KDC) cannot find a suitable certificate to use fo
r smart card logons, or the KDC certificate could not be verified. Smart card logon may no
t function correctly if this problem is not resolved. To correct this problem, either veri
fy the existing KDC certificate using certutil.exe or enroll for a new KDC certificate.
A warning event occurred. EventID: 0x000003F6
Time Generated: 03/18/2017 19:27:13
Event String:
Name resolution for the name _ldap._tcp.Default-First-Site-Name._sites.dc._msd
cs.EXITYRWED.COM timed out after none of the configured DNS servers responded.
An error event occurred. EventID: 0xC00038D6
Time Generated: 03/18/2017 19:27:16
Event String:
The DFS Namespace service could not initialize cross forest trust information
on this domain controller, but it will periodically retry the operation. The return code i
s in the record data.
A warning event occurred. EventID: 0x0000000C
Time Generated: 03/18/2017 19:27:16
Event String:
Time Provider NtpClient: This machine is configured to use the domain hierarch
y to determine its time source, but it is the AD PDC emulator for the domain at the root o
f the forest, so there is no machine above it in the domain hierarchy to use as a time sou
rce. It is recommended that you either configure a reliable time service in the root domai
n, or manually configure the AD 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 dis
able the NtpClient.
A warning event occurred. EventID: 0x0000A001
Time Generated: 03/18/2017 19:27:19
Event String:
The Security System could not establish a secured connection with the server l
dap/EXITYRWED.COM/EXITYRWED.COM@EXITYRWED.COM. No authentication protocol was available.
An error event occurred. EventID: 0xC00038D6
Time Generated: 03/18/2017 19:27:31
Event String:
The DFS Namespace service could not initialize cross forest trust information
on this domain controller, but it will periodically retry the operation. The return code i
s in the record data.
An error event occurred. EventID: 0xC00038D6
Time Generated: 03/18/2017 19:27:46
Event String:
The DFS Namespace service could not initialize cross forest trust information
on this domain controller, but it will periodically retry the operation. The return code i
s in the record data.
An error event occurred. EventID: 0xC00038D6
Time Generated: 03/18/2017 19:28:01
Event String:
The DFS Namespace service could not initialize cross forest trust information
on this domain controller, but it will periodically retry the operation. The return code i
s in the record data.
An error event occurred. EventID: 0xC00038D6
Time Generated: 03/18/2017 19:28:16
Event String:
The DFS Namespace service could not initialize cross forest trust information
on this domain controller, but it will periodically retry the operation. The return code i
s in the record data.
An error event occurred. EventID: 0xC00038D6
Time Generated: 03/18/2017 19:28:31
Event String:
The DFS Namespace service could not initialize cross forest trust information
on this domain controller, but it will periodically retry the operation. The return code i
s in the record data.
An error event occurred. EventID: 0xC00038D6
Time Generated: 03/18/2017 19:28:46
Event String:
The DFS Namespace service could not initialize cross forest trust information
on this domain controller, but it will periodically retry the operation. The return code i
s in the record data.
An error event occurred. EventID: 0xC00038D6
Time Generated: 03/18/2017 19:29:01
Event String:
The DFS Namespace service could not initialize cross forest trust information
on this domain controller, but it will periodically retry the operation. The return code i
s in the record data.
An error event occurred. EventID: 0xC00038D6
Time Generated: 03/18/2017 19:29:16
Event String:
The DFS Namespace service could not initialize cross forest trust information
on this domain controller, but it will periodically retry the operation. The return code i
s in the record data.
A warning event occurred. EventID: 0x000727AA
Time Generated: 03/18/2017 19:29:17
Event String:
The WinRM service failed to create the following SPNs: WSMAN/MY-PC.EXITYRWE
D.COM; WSMAN/MY-PC.
An error event occurred. EventID: 0xC00038D6
Time Generated: 03/18/2017 19:29:31
Event String:
The DFS Namespace service could not initialize cross forest trust information
on this domain controller, but it will periodically retry the operation. The return code i
s in the record data.
An error event occurred. EventID: 0xC00038D6
Time Generated: 03/18/2017 19:29:46
Event String:
The DFS Namespace service could not initialize cross forest trust information
on this domain controller, but it will periodically retry the operation. The return code i
s in the record data.
An error event occurred. EventID: 0x00000469
Time Generated: 03/18/2017 19:32:02
Event String:
The processing of Group Policy failed because of lack of network connectivity
to a domain controller. This may be a transient condition. A success message would be gene
rated once the machine gets connected to the domain controller and Group Policy has succes
fully processed. If you do not see a success message for several hours, then contact your
administrator.
An error event occurred. EventID: 0xC0001B63
Time Generated: 03/18/2017 19:32:32
Event String:
A timeout (30000 milliseconds) was reached while waiting for a transaction res
ponse from the VMTools service.
An error event occurred. EventID: 0x00000422
Time Generated: 03/18/2017 19:32:50
Event String:
The processing of Group Policy failed. Windows attempted to read the file \EX
ITYRWED.COMsysvolEXITYRWED.COMPolicies{31B2F340-016D-11D2-945F-00C04FB984F9}gpt.ini f
rom a domain controller and was not successful. Group Policy settings may not be applied u
ntil this event is resolved. This issue may be transient and could be caused by one or mor
e of the following:
An error event occurred. EventID: 0xC0001B63
Time Generated: 03/18/2017 19:33:20
Event String:
A timeout (30000 milliseconds) was reached while waiting for a transaction res
ponse from the VMTools service.
A warning event occurred. EventID: 0x80040033
Time Generated: 03/18/2017 19:35:09
Event String:
An error was detected on device DeviceHarddisk1DR1 during a paging operatio
n.
......................... MY-PC failed test SystemLog
Starting test: VerifyReferences
......................... MY-PC passed test VerifyReferences
Running partition tests on : ForestDnsZones
Starting test: CheckSDRefDom
......................... ForestDnsZones passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... ForestDnsZones passed test CrossRefValidation
Running partition tests on : DomainDnsZones
Starting test: CheckSDRefDom
......................... DomainDnsZones passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... DomainDnsZones passed test CrossRefValidation
Running partition tests on : Schema
Starting test: CheckSDRefDom
......................... Schema passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... Schema passed test CrossRefValidation
Running partition tests on : Configuration
Starting test: CheckSDRefDom
......................... Configuration passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... Configuration passed test CrossRefValidation
Running partition tests on : EXITYRWED
Starting test: CheckSDRefDom
......................... EXITYRWED passed test CheckSDRefDom
Starting test: CrossRefValidation
......................... EXITYRWED passed test CrossRefValidation
Running enterprise tests on : EXITYRWED.COM
Starting test: LocatorCheck
......................... EXITYRWED.COM passed test LocatorCheck
Starting test: Intersite
......................... EXITYRWED.COM passed test Intersite
C:UsersAdministrator>

C:UsersAdministrator>repadmin /showrepl
Repadmin: running command /showrepl against full DC localhost
Default-First-Site-NameMY-PC
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: d2a920f2-0aba-4558-8bbf-bafae0a6f75c
DSA invocationID: d2a920f2-0aba-4558-8bbf-bafae0a6f75c

У вас dc виртуальный или физический сервер?

Как и написал в шапке — WinServer 2008 r2 в редакции core, установленный на VMware.
Результаты:
```
         A warning event occurred.  EventID: 0x000727AA
Time Generated: 03/18/2017   19:29:17
Event String:
The WinRM service failed to create the following SPNs: WSMAN/MY-PC.EXITYRWE
D.COM; WSMAN/MY-PC.
```
Как я понимаю, пойти предложенным мной путём — включить протоколирование 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 (какой именно — нужно смотреть в документации
по Диспетчеру серверов для старшей версии). Надеюсь, вы это проделали?

Слава России!
У вас dc сейчас в Safe Mode загружен?

Проверьте диск на ошибки chkdsk том /F

Выложите ipconfig /All с dc

Нет, не в Safe mode. Ошибок проверка не выявила.
- Изменено
  ianbramv
  18 марта 2017 г. 16:18
setspn -Q WSMAN/MY-PC.EXITYRWED.COM

setspn -Q WSMAN/MY-PC

Пишет:
```
Checking domain DC=EXITYRWED,DC=COM
No such SPN found.
```
2. Как настроен DNS (вопрос — потому что был ряд сообщений, заставляющих подозревать неверную настройку)? Поскольку ваш домен неизвестен интернету, то в качестве серверов DNS для всех компьютеров-членов домена, включая сам контроллер
домена, в качестве сервера DNS должен быть указан только контроллер домена. Проверяется настройка DNS командой ipconfig /all

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

Для установки нужен доступ во внешний интернет, а с моего DC его нет. Получается, неправильная настройка?

PS C:UsersAdministrator> ipconfig /All
Windows IP Configuration
Host Name . . . . . . . . . . . . : MY-PC
Primary Dns Suffix  . . . . . . . : EXITYRWED.COM
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : EXITYRWED.COM
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
Physical Address. . . . . . . . . : 00-0C-29-9E-68-9C
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::d1db:efad:9595:d804%21(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.2.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 352324649
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-20-32-A4-71-00-0C-29-9E-68-9C
DNS Servers . . . . . . . . . . . : ::1
127.0.0.1
NetBIOS over Tcpip. . . . . . . . : Enabled
Tunnel adapter isatap.{27BAD0B8-B269-4C61-9544-CE5813DC921D}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #20
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
PS C:UsersAdministrator>

Приветствую.

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

Вопрос хотел уточнить: у вас эта самая Windows 10 — она в том же домене, что и Windows Server 2K8 R2 Core?

Если нет, то расскажите, как настроены (и настроены ли) доверительные отношения между этими доменами, если Win10 вообще член домена?

Для установки нужен доступ во внешний интернет, а с моего DC его нет. Получается, неправильная настройка?

Не понял, зачем там доступ в интернет для установки — для активации, что ли?

Я про другое писал — про возможность найти ваш этот DC с машины под Win10, с которой вы к нему подключаетесь — для этого и нужен правильно настроенный DNS. Если они в одном домене, конечно. Но сначала расскажите про домены:
а то я не успел рассмотреть подробно ipconfig /all с Win10, но некие сомнения он у меня зародил

Слава России!
- Изменено
  M.V.V. _
  18 марта 2017 г. 21:36
Когда я включаю DC — да, я могу в Диспетчере серверов найти его и по имени, и по IP. Собственно, уже при подключении возникает ошибка.

Получается, DC находится в домене , это видно на экране авторизации при запуске системы. Win10 не находится в этом домене: при попытке в свойствах системы указать его возникает ошибка «домен не существует или к нему
невозможно подключиться». Хотя имя и пароль запрашивает для применения операции.

Microsoft Windows [Version 10.0.14393]
(c) Корпорация Майкрософт (Microsoft Corporation), 2016. Все права защищены.
C:WINDOWSsystem32>set
ALLUSERSPROFILE=C:ProgramData
APPDATA=C:UsersianbramvAppDataRoaming
AV_APPDATA=C:UsersianbramvAppDataRoaming
CommonProgramFiles=C:Program FilesCommon Files
CommonProgramFiles(x86)=C:Program Files (x86)Common Files
CommonProgramW6432=C:Program FilesCommon Files
COMPUTERNAME=Z510
ComSpec=C:WINDOWSsystem32cmd.exe
HOMEDRIVE=C:
HOMEPATH=Usersianbramv
KMP_DUPLICATE_LIB_OK=TRUE
LOCALAPPDATA=C:UsersianbramvAppDataLocal
LOGONSERVER=\Z510
NUMBER_OF_PROCESSORS=8
OS=Windows_NT
Path=C:ProgramDataOracleJavajavapath;C:Program Files (x86)InteliCLS Client;C:Program FilesInteliCLS Client;C:Windowssystem32;C:Windows;C:WindowsSystem32Wbem;C:WindowsSystem32WindowsPowerShellv1.0;C:Program FilesIntelIntel(R) Management Engine ComponentsDAL;C:Program FilesIntelIntel(R) Management Engine ComponentsIPT;C:Program Files (x86)IntelIntel(R) Management Engine ComponentsDAL;C:Program Files (x86)IntelIntel(R) Management Engine ComponentsIPT;C:WINDOWSsystem32;C:WINDOWS;C:WINDOWSSystem32Wbem;C:WINDOWSSystem32WindowsPowerShellv1.0;C:Program Files (x86)SkypePhone;C:Usersianbramv.dnxbin;C:Program FilesMicrosoft DNXDnvm;C:Program Files (x86)NVIDIA CorporationPhysXCommon;C:WINDOWSsystem32;C:WINDOWS;C:WINDOWSSystem32Wbem;C:WINDOWSSystem32WindowsPowerShellv1.0;C:UsersianbramvAppDataLocalMicrosoftWindowsApps
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 60 Stepping 3, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=3c03
ProgramData=C:ProgramData
ProgramFiles=C:Program Files
ProgramFiles(x86)=C:Program Files (x86)
ProgramW6432=C:Program Files
PROMPT=$P$G
PSModulePath=C:WINDOWSsystem32WindowsPowerShellv1.0Modules
PUBLIC=C:UsersPublic
SystemDrive=C:
SystemRoot=C:WINDOWS
TEMP=C:UsersianbramvAppDataLocalTemp
TMP=C:UsersianbramvAppDataLocalTemp
USERDOMAIN=Z510
USERDOMAIN_ROAMINGPROFILE=Z510
USERNAME=ianbramv
USERPROFILE=C:Usersianbramv
VBOX_MSI_INSTALL_PATH=C:Program FilesOracleVirtualBox
VS140COMNTOOLS=C:Program Files (x86)Microsoft Visual Studio 14.0Common7Tools
windir=C:WINDOWS
C:WINDOWSsystem32>

C:WINDOWSsystem32>hostname
Z510
C:WINDOWSsystem32>

Вопрос хотел уточнить: у вас эта самая Windows 10 — она в том же домене, что и Windows Server 2K8 R2 Core?

Если нет, то расскажите, как настроены (и настроены ли) доверительные отношения между этими доменами, если Win10 вообще член домена?

Добрый День.

Судя по:

USERDOMAIN=Z510
USERDOMAIN_ROAMINGPROFILE=Z510
USERNAME=ianbramv
USERPROFILE=C:Usersianbramv
LOGONSERVER=\Z510

ПК Z510 не член домена, если я не прав, поправьте меня коллеги

по сему ошибка керберос при попытке управления через winrm winrs это нормально.

Просто необходимо
выполнить настойку доверенного хоста и способа аутентификации

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

Настроить интернет-подключение для установки всех обновлений системы и компонент.

Пробую ввести все три команды, что Вы привели, и в ответ получаю, по очереди:

Invalid gateway parameter (Default). It should be a valid IPv4 address.

The object is already in the list.

C:UsersAdministrator>netsh dnsclient add dnsserver "Local Area Connection" Default Gatew
ay IP 2
The syntax supplied for this command is not valid. Check help for the correct syntax.
Usage: add dnsservers [name=]<string> [address=]<IP address>
[[index=]<integer>] [[validate=]yes|no]
Parameters:
Tag            Value
name         - The name or index of the interface where DNS
servers are added.
address      - The IP address for the DNS server you are adding.
index        - Specifies the index (preference) for the specified
DNS server address.
validate     - Specifies whether validation of the DNS server setting
will be performed. The value is yes by default.
Remarks: Adds a new DNS server IP address to the statically-configured list.
By default, the DNS server is added to the end of the list.  If an
index is specified, the DNS server will be placed in that position
in the list, with other servers being moved down to make room.
If DNS servers were previously obtained through DHCP, the new
address will replace the old list. If Validate switch is yes,
then the newly added DNS server is validated.

Так, кажется понял. Заменил Default Gateway на шлюз IP адреса подключения к интернету из Win10. На что заменить IP 2? Где взять второй шлюз? Запутался…
- Изменено
  ianbramv
  20 марта 2017 г. 11:19

Установил NET Framework и Windows Management Framework. При попытке ввести команду

%windir%system32Configure-SMRemoting.exe

Получаю:

'C:Windowssystem32Configure-SMRemoting.exe' is not recognized as an internal or external command,operable program or batch file.

Что делать?

Содержание

Ошибка: сбой проверки подлинности Kerberos
Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:
Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам
Симптомы
Причина
Решение
Вычисление максимального размера маркера
Известные проблемы, влияющие на MaxTokenSize
Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене
Симптомы
Причина
Типы шифрования Kerberos
Проверка подлинности NTLM
Решение
Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4
Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256
Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4
Дополнительная информация
Ошибка проверки подлинности kerberos windows server 2019
Идентификация и доступ в Active Directory
Протокол аутентификации kerberos
Детальная проверка kerberos от начала логирования
Ошибка проверки подлинности kerberos windows server 2019
Спрашивающий
Общие обсуждения
Все ответы

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

В ходе удаленной отладки может возникнуть следующее сообщение об ошибке:

Проверка подлинности Kerberos невозможна при следующих условиях:

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

Служба Kerberos на контроллере домена была отключена.

Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:

На целевом компьютере войдите в меню Пуск и выберите в меню Стандартные пункт Командная строка.

В окне командной строки введите:

Источник

Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам

Применяется к: Windows 10 — все выпуски, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 327825

Симптомы

Причина

Решение

Вычисление максимального размера маркера

TokenSize = 1200 + 40d + 8s

Для Windows Server 2012 (и более поздних версий) эта формула определяет свои компоненты следующим образом:

Если вы используете доверенные учетные записи делегирования, каждый SID требует в два раза больше места.

Известные проблемы, влияющие на MaxTokenSize

Ограничение размера в 1010 групповых SID для маркера доступа к LSA

Известная проблема при использовании значений MaxTokenSize более 48 000

Известные проблемы при использовании значений MaxTokenSize больше 65 535

Источник

Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене

Применяется к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 4492348

Симптомы

На контроллере домена детского домена viewer событий записи следующую запись события 14:

Причина

Эта проблема возникает при настройке домена ребенка (или только клиента) следующим образом:

Типы шифрования Kerberos

Проверка подлинности NTLM

Решение

Чтобы устранить эту проблему, используйте один из следующих методов:

Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4

В этой команде представлено полностью квалифицированное доменное имя (FQDN) доверяемого домена.

Дополнительные сведения о средстве ksetup см. в ksetup.

Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256

Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4

Этот метод напоминает метод 1 в том, что вы настраивает атрибуты доверия.

Выберите свойства, выберите другой домен поддерживает шифрование Kerberos AES, а затем выберите ОК.

Чтобы проверить конфигурацию доверия, выберите Проверка в диалоговом окне доверчивый домен.

На вкладке Trusts нажмите кнопку ОК.

Перейдите к объекту домена для доверяемой области ( child.contoso.com ).

Дополнительная информация

Дополнительные сведения о TDOs см. в следующих статьях:

Дополнительные сведения о типах шифрования Kerberos см. в следующих статьях:

Источник

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

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

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

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

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

Источник

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

Этот форум закрыт. Спасибо за участие!

Спрашивающий

trans

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

trans

Все ответы

trans

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

trans

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

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

trans

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

trans

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

trans

У вас dc виртуальный или физический сервер?

trans

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

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

Источник

Содержание

Ошибка: сбой проверки подлинности Kerberos
Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:
Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам
Симптомы
Причина
Решение
Вычисление максимального размера маркера
Известные проблемы, влияющие на MaxTokenSize
Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене
Симптомы
Причина
Типы шифрования Kerberos
Проверка подлинности NTLM
Решение
Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4
Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256
Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4
Дополнительная информация
Ошибка проверки подлинности kerberos windows server 2019
Идентификация и доступ в Active Directory
Протокол аутентификации kerberos
Детальная проверка kerberos от начала логирования
Ошибка проверки подлинности kerberos windows server 2019
Спрашивающий
Общие обсуждения
Все ответы

В ходе удаленной отладки может возникнуть следующее сообщение об ошибке:

Проверка подлинности Kerberos невозможна при следующих условиях:

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

Служба Kerberos на контроллере домена была отключена.

Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:

На целевом компьютере войдите в меню Пуск и выберите в меню Стандартные пункт Командная строка.

В окне командной строки введите:

Источник

Применяется к: Windows 10 — все выпуски, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 327825

Симптомы

Причина

Решение

Вычисление максимального размера маркера

TokenSize = 1200 + 40d + 8s

Для Windows Server 2012 (и более поздних версий) эта формула определяет свои компоненты следующим образом:

Если вы используете доверенные учетные записи делегирования, каждый SID требует в два раза больше места.

Известные проблемы, влияющие на MaxTokenSize

Ограничение размера в 1010 групповых SID для маркера доступа к LSA

Известная проблема при использовании значений MaxTokenSize более 48 000

Известные проблемы при использовании значений MaxTokenSize больше 65 535

Источник

Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене

Применяется к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 4492348

Симптомы

На контроллере домена детского домена viewer событий записи следующую запись события 14:

Причина

Эта проблема возникает при настройке домена ребенка (или только клиента) следующим образом:

Типы шифрования Kerberos

Проверка подлинности NTLM

Решение

Чтобы устранить эту проблему, используйте один из следующих методов:

Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4

В этой команде представлено полностью квалифицированное доменное имя (FQDN) доверяемого домена.

Дополнительные сведения о средстве ksetup см. в ksetup.

Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256

Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4

Этот метод напоминает метод 1 в том, что вы настраивает атрибуты доверия.

Выберите свойства, выберите другой домен поддерживает шифрование Kerberos AES, а затем выберите ОК.

Чтобы проверить конфигурацию доверия, выберите Проверка в диалоговом окне доверчивый домен.

На вкладке Trusts нажмите кнопку ОК.

Перейдите к объекту домена для доверяемой области ( child.contoso.com ).

Дополнительная информация

Дополнительные сведения о TDOs см. в следующих статьях:

Дополнительные сведения о типах шифрования Kerberos см. в следующих статьях:

Источник

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

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

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

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

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

Источник

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

Этот форум закрыт. Спасибо за участие!

Спрашивающий

trans

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

trans

Все ответы

trans

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

trans

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

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

trans

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

trans

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

trans

У вас dc виртуальный или физический сервер?

trans

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

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

Источник

Обновлено 03.08.2017

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

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

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

Давайте рассматривать каким образом происходит проверка подлинности Kerberos в домене Active Directory. И так пользователь или же компьютер, пытаются войти в локальную сеть домена, именно протокол Kerberos удостоверяется в подлинности указанных реквизитов, в следствии чего выдает пакет данных, а точнее билет или тикет (Ticket), по правильному он называется TGT (Ticket Granting Ticket).

Теперь когда у пользователя или компьютера есть билет TGT, он может его предоставлять любому сервису или ресурсу. В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS). Данный билет будет идентифицировать прошедшего проверку подлинности пользователя на сервере. Пользователь предоставит TGS билет для доступа к серверу, он его примет и подтвердит прохождение проверки подлинности. Вот тут Kerberos и показывает все свои достоинства, ему требуется лишь один сетевой вход и после получения им билета TGT он проходит проверку подлинности для всего домена целиком, что дает ему возможность получать идентификационные билеты на доступ к службам, не вводя ни каких учетных данных, все эти операции осуществляются за счет встроенных клиентов и служб Kerberos в Kerberos.

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

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

Человек видит поля ввода логина и пароля у себя на компьютере
Компьютер получив от пользователя первичные данные делает запрос к контроллеру домена, а точнее к службе Key Distribution Center, где передает KDC имя пользователя в открытом виде, имя домена и текущее время на рабочей станции, еще раз напоминаю, что оно не должно отличаться от времени на контроллере домена более ,чем на 5 минут. Значение текущего времени передается в зашифрованном виде, и будет выступать аутентификатором. Напоминаю, что ключ шифрования (пользовательский ключ) формируется из пароля пользователя, как результат хеширования.

Служба KDC видит обращение с компьютера и начинает поиск пользователя в Active Directory, проверяет его пользовательский ключ и расшифровывает аутентификатор, если по русски она получает время отправления запроса. После чего Key Distribution Center создает два тикета. Первый это сессионный ключ, он нужен для шифрования данных между клиентом и KDC. Второй тикет, это билет на получение билета (Ticket-Granting Ticket (TGT)), как только он появился у пользователя, тот сможет запрашивать тикеты для сервисов и серверов. Сам TGT билет состоит из таких частей: копия ключа сессии, время окончания жизни билета и имя пользователя. TGT шифруется с использованием мастер ключа самой службы Key Distribution Center, поэтому пользователь не может его расшифровать.
Как только эти билеты сформированы Key Distribution Center шифрует аутентификатор пользователя (time stamp) и сессионный ключ, с помощью пользовательского ключа и спокойно передает их пользователю.

Так как у пользователя есть его, пользовательский ключ, он спокойно расшифровывает билеты от Key Distribution Center и проверяет аутентификатор. В итоге он теперь обладает и ключем сессии и TGT ключом, теперь первый этап Kerberos закончен и пользователю больше не нужно в этой сессии заказывать эти билеты.
Далее клиент хочет получить доступ на сервис, так как у него уже есть ключ на получение других ключей (TGT), для доступа к сервису он предоставляет KDC, свой Ticket-Granting Ticket и штамп времени, которые шифрует сессионным ключом.
KDC получает этот запрос и билеты, расшифровывает их используя свой ключ. Контроллер домена подтверждает, что запрос поступил именно от нужного пользователя.

Следующим шагом Key Distribution Center, генерирует два тикета (Service Ticket (TGS)), один для обратившегося клиента, а второй для сервиса, к которому клиент обращается. Каждый из тикетов, будет содержать имя пользователя, кто просит доступ, кто должен получить запрос, штамп времени, рассказывающий, когда создан тикет, и срок его жизни, а так же новый ключ Kcs. Kcs — это ключ для сервиса и клиента, в задачи которого входит обеспечение безопасного взаимодействия между ними. Далее KDC шифрует билет сервиса, используя для этого системный ключ сервера и вкладывает этот билет внутрь билета клиента, у которого так же есть свой Kcs ключ.
Теперь все это дело шифруется сессионным ключом и передается клиенту.

Клиент получает билет, расшифровывает его с помощью сессионного ключа и видит свой TGS тикет, и Kcs сервиса, клиент не может прочитать Kcs предназначенный для сервиса

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

Когда сервер с сервисом, получает эту информацию, он сразу видит пакет от KDC предназначенный для него с ключом TGS (Kcs). Он расшифровывает им штамп времени от клиента.
Так как у обоих участников есть TGS ключ, они могут быть обо уверены, что клиент правильно идентифицирован, т. к. для шифрования маркера времени был использован Kcs . В случае необходимости ответа сервера клиенту, сервер воспользуется ключом Kcs . Клиент будет знать, что сервер правильно идентифицирован, поскольку сервер должен использовать, чтобы получить Kcs.

Блог did5.ru

EventID 4

EventSourceName Kerberos

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера PC1$. Использовалось конечное имя cifs/PC2.domain.ru. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером.

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

Нашли опечатку в тексте? Пожалуйста, выделите ее и нажмите Ctrl+Enter! Спасибо!

Активация Windows Server 2019 Core

Просмотр сведений о лицензии
Активация Windows
Установка ключа продукта
Вернуться в главное меню

Если нужно поменять ключ продукта, то выберите пункт 3, и у вас откроется еще одно графическое окошко.

В итоге я спокойно подключился и ввел команду ipconfig, где вижу ранее настроенный ip-адрес.

Связанные статьи:

(100%) (100%) (100%) (100%) (100%) (RANDOM — 50%)

Comments

Дякую! Допомогли вирішити дану проблему )

Не помогло. Брэндмауэр отключил даже. И все равно сервер никто не может дажи пинговать. Хотя сервак пингует ПК

Клавиши функций Internet Explorer

HKEY_USERSSoftwareMicrosoftInternet ExplorerMainFeatureControl — если определено на уровне пользователя
HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternet ExplorerMainFeatureControl — если определено на уровне машины

для всех пользователей на компьютере
только для определенной учетной записи

Содержание

Ошибка: сбой проверки подлинности Kerberos
Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:
Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам
Симптомы
Причина
Решение
Вычисление максимального размера маркера
Известные проблемы, влияющие на MaxTokenSize
Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене
Симптомы
Причина
Типы шифрования Kerberos
Проверка подлинности NTLM
Решение
Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4
Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256
Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4
Дополнительная информация
Ошибка проверки подлинности kerberos windows server 2019
Идентификация и доступ в Active Directory
Протокол аутентификации kerberos
Детальная проверка kerberos от начала логирования
Ошибка проверки подлинности kerberos windows server 2019
Спрашивающий
Общие обсуждения
Все ответы

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

В ходе удаленной отладки может возникнуть следующее сообщение об ошибке:

Проверка подлинности Kerberos невозможна при следующих условиях:

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

Служба Kerberos на контроллере домена была отключена.

Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:

На целевом компьютере войдите в меню Пуск и выберите в меню Стандартные пункт Командная строка.

В окне командной строки введите:

Источник

Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам

Применяется к: Windows 10 — все выпуски, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 327825

Симптомы

Причина

Решение

Вычисление максимального размера маркера

TokenSize = 1200 + 40d + 8s

Для Windows Server 2012 (и более поздних версий) эта формула определяет свои компоненты следующим образом:

Если вы используете доверенные учетные записи делегирования, каждый SID требует в два раза больше места.

Известные проблемы, влияющие на MaxTokenSize

Ограничение размера в 1010 групповых SID для маркера доступа к LSA

Известная проблема при использовании значений MaxTokenSize более 48 000

Известные проблемы при использовании значений MaxTokenSize больше 65 535

Источник

Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене

Применяется к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 4492348

Симптомы

На контроллере домена детского домена viewer событий записи следующую запись события 14:

Причина

Эта проблема возникает при настройке домена ребенка (или только клиента) следующим образом:

Типы шифрования Kerberos

Проверка подлинности NTLM

Решение

Чтобы устранить эту проблему, используйте один из следующих методов:

Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4

В этой команде представлено полностью квалифицированное доменное имя (FQDN) доверяемого домена.

Дополнительные сведения о средстве ksetup см. в ksetup.

Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256

Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4

Этот метод напоминает метод 1 в том, что вы настраивает атрибуты доверия.

Выберите свойства, выберите другой домен поддерживает шифрование Kerberos AES, а затем выберите ОК.

Чтобы проверить конфигурацию доверия, выберите Проверка в диалоговом окне доверчивый домен.

На вкладке Trusts нажмите кнопку ОК.

Перейдите к объекту домена для доверяемой области ( child.contoso.com ).

Дополнительная информация

Дополнительные сведения о TDOs см. в следующих статьях:

Дополнительные сведения о типах шифрования Kerberos см. в следующих статьях:

Источник

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

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

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

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

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

Источник

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

Этот форум закрыт. Спасибо за участие!

Спрашивающий

trans

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

trans

Все ответы

trans

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

trans

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

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

trans

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

trans

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

trans

У вас dc виртуальный или физический сервер?

trans

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

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

Источник

Содержание

Ошибка: сбой проверки подлинности Kerberos
Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:
Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам
Симптомы
Причина
Решение
Вычисление максимального размера маркера
Известные проблемы, влияющие на MaxTokenSize
Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене
Симптомы
Причина
Типы шифрования Kerberos
Проверка подлинности NTLM
Решение
Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4
Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256
Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4
Дополнительная информация
Ошибка проверки подлинности kerberos windows server 2019
Идентификация и доступ в Active Directory
Протокол аутентификации kerberos
Детальная проверка kerberos от начала логирования
Ошибка проверки подлинности kerberos windows server 2019
Спрашивающий
Общие обсуждения
Все ответы

В ходе удаленной отладки может возникнуть следующее сообщение об ошибке:

Проверка подлинности Kerberos невозможна при следующих условиях:

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

Служба Kerberos на контроллере домена была отключена.

Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:

На целевом компьютере войдите в меню Пуск и выберите в меню Стандартные пункт Командная строка.

В окне командной строки введите:

Источник

Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам

Применяется к: Windows 10 — все выпуски, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 327825

Симптомы

Причина

Решение

Вычисление максимального размера маркера

TokenSize = 1200 + 40d + 8s

Для Windows Server 2012 (и более поздних версий) эта формула определяет свои компоненты следующим образом:

Если вы используете доверенные учетные записи делегирования, каждый SID требует в два раза больше места.

Известные проблемы, влияющие на MaxTokenSize

Ограничение размера в 1010 групповых SID для маркера доступа к LSA

Известная проблема при использовании значений MaxTokenSize более 48 000

Известные проблемы при использовании значений MaxTokenSize больше 65 535

Источник

Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене

Применяется к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 4492348

Симптомы

На контроллере домена детского домена viewer событий записи следующую запись события 14:

Причина

Эта проблема возникает при настройке домена ребенка (или только клиента) следующим образом:

Типы шифрования Kerberos

Проверка подлинности NTLM

Решение

Чтобы устранить эту проблему, используйте один из следующих методов:

Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4

В этой команде представлено полностью квалифицированное доменное имя (FQDN) доверяемого домена.

Дополнительные сведения о средстве ksetup см. в ksetup.

Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256

Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4

Этот метод напоминает метод 1 в том, что вы настраивает атрибуты доверия.

Выберите свойства, выберите другой домен поддерживает шифрование Kerberos AES, а затем выберите ОК.

Чтобы проверить конфигурацию доверия, выберите Проверка в диалоговом окне доверчивый домен.

На вкладке Trusts нажмите кнопку ОК.

Перейдите к объекту домена для доверяемой области ( child.contoso.com ).

Дополнительная информация

Дополнительные сведения о TDOs см. в следующих статьях:

Дополнительные сведения о типах шифрования Kerberos см. в следующих статьях:

Источник

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

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

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

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

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

Источник

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

Этот форум закрыт. Спасибо за участие!

Спрашивающий

trans

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

trans

Все ответы

trans

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

trans

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

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

trans

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

trans

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

trans

У вас dc виртуальный или физический сервер?

trans

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

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

Источник

Обновлено 03.08.2017

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

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

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

Давайте рассматривать каким образом происходит проверка подлинности Kerberos в домене Active Directory. И так пользователь или же компьютер, пытаются войти в локальную сеть домена, именно протокол Kerberos удостоверяется в подлинности указанных реквизитов, в следствии чего выдает пакет данных, а точнее билет или тикет (Ticket), по правильному он называется TGT (Ticket Granting Ticket).

Теперь когда у пользователя или компьютера есть билет TGT, он может его предоставлять любому сервису или ресурсу. В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS). Данный билет будет идентифицировать прошедшего проверку подлинности пользователя на сервере. Пользователь предоставит TGS билет для доступа к серверу, он его примет и подтвердит прохождение проверки подлинности. Вот тут Kerberos и показывает все свои достоинства, ему требуется лишь один сетевой вход и после получения им билета TGT он проходит проверку подлинности для всего домена целиком, что дает ему возможность получать идентификационные билеты на доступ к службам, не вводя ни каких учетных данных, все эти операции осуществляются за счет встроенных клиентов и служб Kerberos в Kerberos.

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

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

Человек видит поля ввода логина и пароля у себя на компьютере
Компьютер получив от пользователя первичные данные делает запрос к контроллеру домена, а точнее к службе Key Distribution Center, где передает KDC имя пользователя в открытом виде, имя домена и текущее время на рабочей станции, еще раз напоминаю, что оно не должно отличаться от времени на контроллере домена более ,чем на 5 минут. Значение текущего времени передается в зашифрованном виде, и будет выступать аутентификатором. Напоминаю, что ключ шифрования (пользовательский ключ) формируется из пароля пользователя, как результат хеширования.

Служба KDC видит обращение с компьютера и начинает поиск пользователя в Active Directory, проверяет его пользовательский ключ и расшифровывает аутентификатор, если по русски она получает время отправления запроса. После чего Key Distribution Center создает два тикета. Первый это сессионный ключ, он нужен для шифрования данных между клиентом и KDC. Второй тикет, это билет на получение билета (Ticket-Granting Ticket (TGT)), как только он появился у пользователя, тот сможет запрашивать тикеты для сервисов и серверов. Сам TGT билет состоит из таких частей: копия ключа сессии, время окончания жизни билета и имя пользователя. TGT шифруется с использованием мастер ключа самой службы Key Distribution Center, поэтому пользователь не может его расшифровать.
Как только эти билеты сформированы Key Distribution Center шифрует аутентификатор пользователя (time stamp) и сессионный ключ, с помощью пользовательского ключа и спокойно передает их пользователю.

Так как у пользователя есть его, пользовательский ключ, он спокойно расшифровывает билеты от Key Distribution Center и проверяет аутентификатор. В итоге он теперь обладает и ключем сессии и TGT ключом, теперь первый этап Kerberos закончен и пользователю больше не нужно в этой сессии заказывать эти билеты.
Далее клиент хочет получить доступ на сервис, так как у него уже есть ключ на получение других ключей (TGT), для доступа к сервису он предоставляет KDC, свой Ticket-Granting Ticket и штамп времени, которые шифрует сессионным ключом.
KDC получает этот запрос и билеты, расшифровывает их используя свой ключ. Контроллер домена подтверждает, что запрос поступил именно от нужного пользователя.

Следующим шагом Key Distribution Center, генерирует два тикета (Service Ticket (TGS)), один для обратившегося клиента, а второй для сервиса, к которому клиент обращается. Каждый из тикетов, будет содержать имя пользователя, кто просит доступ, кто должен получить запрос, штамп времени, рассказывающий, когда создан тикет, и срок его жизни, а так же новый ключ Kcs. Kcs — это ключ для сервиса и клиента, в задачи которого входит обеспечение безопасного взаимодействия между ними. Далее KDC шифрует билет сервиса, используя для этого системный ключ сервера и вкладывает этот билет внутрь билета клиента, у которого так же есть свой Kcs ключ.
Теперь все это дело шифруется сессионным ключом и передается клиенту.

Клиент получает билет, расшифровывает его с помощью сессионного ключа и видит свой TGS тикет, и Kcs сервиса, клиент не может прочитать Kcs предназначенный для сервиса

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

Когда сервер с сервисом, получает эту информацию, он сразу видит пакет от KDC предназначенный для него с ключом TGS (Kcs). Он расшифровывает им штамп времени от клиента.
Так как у обоих участников есть TGS ключ, они могут быть обо уверены, что клиент правильно идентифицирован, т. к. для шифрования маркера времени был использован Kcs . В случае необходимости ответа сервера клиенту, сервер воспользуется ключом Kcs . Клиент будет знать, что сервер правильно идентифицирован, поскольку сервер должен использовать, чтобы получить Kcs.

Блог did5.ru

EventID 4

EventSourceName Kerberos

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера PC1$. Использовалось конечное имя cifs/PC2.domain.ru. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером.

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

Нашли опечатку в тексте? Пожалуйста, выделите ее и нажмите Ctrl+Enter! Спасибо!

Активация Windows Server 2019 Core

Просмотр сведений о лицензии
Активация Windows
Установка ключа продукта
Вернуться в главное меню

Если нужно поменять ключ продукта, то выберите пункт 3, и у вас откроется еще одно графическое окошко.

В итоге я спокойно подключился и ввел команду ipconfig, где вижу ранее настроенный ip-адрес.

Связанные статьи:

(100%) (100%) (100%) (100%) (100%) (RANDOM — 50%)

Comments

Дякую! Допомогли вирішити дану проблему )

Не помогло. Брэндмауэр отключил даже. И все равно сервер никто не может дажи пинговать. Хотя сервак пингует ПК

Клавиши функций Internet Explorer

HKEY_USERSSoftwareMicrosoftInternet ExplorerMainFeatureControl — если определено на уровне пользователя
HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternet ExplorerMainFeatureControl — если определено на уровне машины

для всех пользователей на компьютере
только для определенной учетной записи

Источник

Check logon audits for errors in usernames

by Claire Moraa

Claire likes to think she’s got a knack for solving problems and improving the quality of life for those around her. Driven by the forces of rationality, curiosity,… read more

Updated on September 11, 2023

The Kerberos pre-authentication failed error indicates that the domain controller failed to authenticate the user.
This may be due to the user intentionally entering an incorrect password, or it may indicate that an unauthorized person is attempting to access your network.
Always ensure you have a stable internet connection for verification to take place.

The Kerberos pre-authentication failed error indicates that the user cannot log in to Windows or any other network resource. This error occurs when there’s a problem with the Kerberos pre-authentication process.

It can occur if you use an incorrect username or password if your computer is offline or not connected to the network, or if an error occurs when connecting to a domain controller.

Why am I getting the Event ID 4771 error?

This error means that you tried to connect to a server using Kerberos pre-authentication, but the server did not respond to your request. In Windows, Kerberos pre-authentication verifies a user’s credentials before the KDC authenticates them.

If the pre-authentication fails, the user will be prompted for their password. For some users, the error code was Event ID 4771. Kerberos pre-authentication failed 0x18 on their PCs. For this code, the issue is a bad password. However, for Event ID 4771, this can happen for several reasons:

Server clock mismatch – The likely cause is that your computer’s clock is out of sync with the server’s clock. This can happen if your computer was offline for a long time and returned online but failed to synchronize its clock.
Incorrect password – Most users who encountered the Event ID 4771 error admitted to having recently changed their passwords. However, for unique IDs such as Event ID 4771 status 0x12, it means that the user’s credentials have been revoked.
Cached credentials – Cached credentials are used to reduce login times and to improve security because they’re obtained automatically from the directory server. However, when you changed passwords, they may cause conflicts.
Wrong domain – Make sure that you’re logging on to an account from the same domain as the computer you’re connecting from; otherwise, there will be no way for Active Directory to verify your credentials correctly.

How can I solve the Event ID 4771 error?

1. Enable failed logon auditing

Hit the Windows + R keys to open the Run command.
Type secpol.msc in the dialog box and hit Enter.
Navigate to the following location: Security settings/Local Policy/Audit Policies/Audit Logon Events
Double-click on Audit logon events, select Success/Failure, then click on Apply and OK.

This will generate a security event whenever a user attempts to log into a domain-joined computer and fails. Failed logon auditing will allow you to see when users have attempted to log onto the network unsuccessfully and to identify any duplicates.

Then, you can rename the accounts with duplicate names on one or more servers, or create new accounts for them with unique names.

2. Delete cached passwords

Hit the Windows key, type cmd in the search bar and click Open.
Type the following commands and hit Enter after each one: psexec -i -s -d cmd.exe rundll32 keymgr.dll KRShowKeyMgr
A list of stored usernames and passwords will appear. Delete them from your server and restart your PC.

This happens because the Kerberos subsystem caches the old password in memory. When you change the password, it doesn’t get cleared from memory until it expires.

The Kerberos client then tries to use the old cached password, which doesn’t work because it has been changed on the domain controller.

Read more about this topic

0x80040e14 SQL Server Error: How to Fix It
Fix: LSA is Unable to Obtain an RPC Connection
Fix: Remote Desktop Services is Currently Busy Error
Event ID: 10036 Distributed COM [Fix]
wsmprovhost.exe: What is it & How to Stop its High CPU Usage

3. Enable audit logon

Hit the Windows key, type Powershell in the search bar and click Run as administrator.
Type the following command and hit Enter: auditpol /set /subcategory:”logon” /failure:enable

When you enable logon auditing, it helps you determine if someone is trying to gain unauthorized access to your systems by guessing passwords or attempting other brute-force attacks.

Hopefully, you have bypassed the Event ID 4771 Kerberos pre-authentication failed error with one of these methods.

You may also come across an Event ID 4768, where your Kerberos authentication ticket is requested. If so, don’t hesitate to check out our expert article.

In the comment section below, let us know what solution fixed this error for you.

Источник

У меня в среднем 17-18 событий аудита сбоев в час, записанных в журнале событий безопасности контроллера домена Windows 2012R2, связанных с попытками рядового сервера Windows 2008R2 получить билет службы Kerberos

A Kerberos service ticket was requested. 

Account Information: 
Account Name:   [email protected] 
Account Domain: ACME.COM 
Logon GUID: {00000000-0000-0000-0000-000000000000} 

Service Information: 
Service Name:   krbtgt/ACME.COM 
Service ID: S-1-0-0 

Network Information: 
Client Address: ::ffff:192.168.1.15 
Client Port:    28904 

Additional Information: 
Ticket Options: 0x60810010 
Ticket Encryption Type: 0xFFFFFFFF 
Failure Code:   0xE 
Transited Services: - 

This event is generated every time access is requested to a resource such as a computer or a Windows service. The service name indicates the resource to which access was requested. 

This event can be correlated with Windows logon events by comparing the Logon GUID fields in each event. The logon event occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket. 

Ticket options, encryption types, and failure codes are defined in RFC 4120.

Код ошибки 0xE указывает неподдерживаемый тип аутентификации. Я отслеживал трафик между серверами с помощью Wireshark и вижу, что сервер Windows 2008R2 делает запрос к контроллеру домена, чтобы начать сеанс, используя тип шифрования aes256-cts-hmac-sha1-96. Этот запрос отклоняется с кодом ошибки «Тип шифрования не поддерживается», а ошибка аудита записывается в журнал событий. Затем сервер Windows 2008 отправляет список из 5 типов шифрования, и с него контроллер домена отвечает выбранным типом: ARCFOUR-HMAC-MD5. После этого трафик продолжается в обычном режиме, и я предполагаю, что 2 сервера используют согласованные параметры шифрования. Нет другой проблемы, которую я вижу между двумя серверами. Любые предложения о том, как избавиться от этих событий? Это просто вопрос политики аудита? Может быть, я могу заставить сервер Windows 2008R2 запускать свои запросы с другим набором параметров протоколов шифрования?

2017-02-26 16:17

2
ответа

Вам необходимо повысить свой DFL, чтобы использовать более новые (около 2008 года) типы шифрования AES. Обратите внимание, что при поднятии с 2003 года пароли учетной записи krbtgt будут изменены (оба), и это может привести к последствиям, поэтому вы должны быть готовы перезапустить серверы / службы по мере необходимости для восстановления.

Кроме того, вам не следует включать тип шифрования DES, если он вам не нужен, и даже отключение типов шифрования RC4 и использование только AES предпочтительнее, если оно совместимо с вашей средой, поскольку безопасность RC4 является неоптимальной.

Для получения дополнительной информации смотрите следующее:

https://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx

2017-02-26 19:28

Здесь странно, что DC 2012 R2 отклоняет тип шифрования на основе AES256, поскольку он поддерживается по умолчанию. В вашем домене настроены групповые политики, которые целенаправленно ограничивают поддерживаемые типы шифрования по умолчанию?

Я бы запустил отчет RSOP на вашем DC и проверил, что настроено. В частности, проверьте Windows Settings - Security Settings - Local Policies - Security Options раздел. Там есть настройка, которая называется Сетевая безопасность: настройте типы шифрования, разрешенные для Kerberos, которые можно настроить так, чтобы запретить один или несколько алгоритмов AES. В некоторых организациях это отключено для лучшей поддержки устаревших клиентов, которые не поддерживают более новые типы шифрования.

2017-02-26 18:18

Источник