Ошибка security kerberos

 Success! It appears the error in my last message was (obviously) the place to look for a solution. A quick Google search brought me to this page Opens a new window in which a similar problem is described. The accepted answers for this problem list a few sites that may hold the answer. In the end, it was this one Opens a new window that brought me to a solution.

In the event that the linked pages disappear, I will provide a quick rundown of what happened and what steps I took to resolve the issue. All of the unnecessary and ultimately worthless «fixes» I attempted will not be mentioned in this review.

As stated, the issue began when a user arrived in IT complaining about a missing home folder drive. In trying to investigate the issue while a help desk tech visited the affected machine, I discovered that I could not access \domain.com which is the beginning of the home folder location (\domain.comfolderfolderhome). After several failed attempts to fix the issue, I discovered the error mentioned in my previous post. As mentioned, the second linked page in this reply brought me to a website where a similar problem was being discussed. The owner of that blog mentioned using a third-party tool called ADFind to query his AD environment for the SPN in the error. When that search yielded no results, he tried the «catch-all» SPN by adjusting the command to read (in my case):

adfind -f "servicePrincipalName=HOST/domain.com" -gcb

For me, this returned a value for a recently-added Federation Services service account. I had been attempting to build an ADFS server to prepare my environment for our soon-to-be move to O365. Since the first attempt at configuring the ADFS server failed, the ADFS service account could be deleted without issue. Deleting this AD account made the \domain.com location immediately available.

Thank you to both of the respondents to this thread.

При попытке ручной репликации данных между контроллерами домена Active Directory в остатке Active Directory Sites and Services (dssite.msc) появилась ошибка:

The following error occurred during the attempt to synchronize naming context from Domain Controller X to Domain Controller Y.
The target principal name is incorrect.
This operation will not continue.

При проверке репликации с помощью repadmin, у одного из DC появляется ошибка:

(2148074274) The target principal name is incorrect.

В журнале событий DC есть такие ошибки:

Source: Security-Kerberos
Event ID: 4

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server DC2. The target name used was cifs/DC2.winitpro.ru. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (winitpro.ru) is different from the client domain (winiptro.ru), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Event ID 3210:

Failed to authenticate with \DC, a Windows NT domain controller for domain WINITPRO.

Event ID 5722:

The session setup from the computer 1 failed to authenticate. The name of the account referenced in the security database is 2. The following error occurred:

В первую очередь проверьте:

1. Доступность проблемного контроллера домена с помощью простого ICMP ping
2. Проверьте, что на нем доступен порт TCP 445 и опубликованы сетевые папки SysVol и NetLogon;

Если все ОК, значит проблема в том, между контроллерами домена нарушен безопасный канал передачи данных. Проверьте его с помощью PowerShell команды:

Test-ComputerSecureChannel -Verbose

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

Чтобы исправить проблему, нужно сбросить этот пароль. Сначала нужно найти текущий контроллер домена с FSMO ролью PDC.

netdom query fsmo |find "PDC"

В нашем примере PDC находится на MSK-DC02. Мы будем исопользовать это имя в команде
netdom resetpwd
далее.

Остановите службу Kerberos Key Distribution Center (KDC) на контроллере домена, на котором появляется ошибка “The target principal name is incorrect” и измените тип запуска на Disabled. Можно изменить настройки службы из консоли services.msc или с помощью PowerShell:

Get-Service kdc -ComputerName msk-dc03 | Set-Service –startuptype disabled –passthru

Перезагрузите этот контроллер домена.

Теперь нужно сбросить безопасный канал связи с контроллером домена с ролью PDC:

netdom resetpwd /server:msk-dc02 /userd:winitproadministrator /passwordd:*

Укажите пароль администратора домена.

Перезагрузите проблемный DC и запустите службу KDC. Попробуйте запустить репликацию и проверить ошибки.

repadmin /syncall
repadmin /replsum
repadmin /showrepl

Если репликация успешно выполнена, в журнале Directory Service Event Viewerа должно появится событие Event ID 1394:

All Problems preventing updates to the Active Directory Domain Services database have been cleared. New Updates to the Active Directory Domain Services database are succeeding. The Net Logon service has restarted

Проверьте состояние вашего домена и контроллеров домена Active Directory согласно этого гайда.

Обновлено 31.08.2022

Добрый день! Уважаемые читатели и гости одного из популярнейших IT блогов России Pyatilistnik.org. В прошлый раз мы с вами устранили причину черного экрана в Windows 10, так как эта ошибка перекочевала и в самую последнюю на текущий момент версию 1903, ая яй Microsoft. Сегодня я вам покажу, как решается ошибка ID 6, мы разберем параметр MaxTokenSize, отвечающий за размер билета Kerberos. Мы разберем, ситуации, когда его следует увеличить и на сколько. Благодаря этим действиям вы решите много проблем с применением GPO, запуска оснасток и прохождения аутентификации в разных сервисах. Уверен, что это будет полезная информация.

Описание ошибки Security-Kerberos ID 6 и ID 40960

У меня в организации давно идет переезд со старых серверов с Windows Server 2008 R2 на Windows Server 2016-19. На одном из старых серверов, у сотрудника технической поддержки возник ряд сложностей, а именно:

• При открытии оснастки «Active Directory — Пользователи и компьютеры» у него выскочила ошибка, о сетевой недоступности контроллера домена

• При запуске Data ONTAP 7G, выскакивала ошибка доступа (https://kb.netapp.com/app/answers/answer_view/a_id/1001986/)
• При открытии под данной учетной записью пользователя на данном сервере корпоративного сервиса в браузере, выскакивала ошибка, о его недоступности с кодом 400 (HTTP 400 Bad Request/The webpage cannot be found).

• К пользователю не применяются групповые политики
• Не получается зайти в SQL. Мы получаем ошибку:

При попытке обратиться по протоколу CIFS на контроллер домена, в моем случае, это \ROOT (root.pyatilistnik.org), я получал ошибку:

А должно быть вот так.

Так же мое внимание привлекло предупреждение:

Из события с кодом ID 6, вам говорят, про какой-то параметр реестра MaxTokenSize и количество групп, к которым принадлежит пользователь, давайте разбираться, что это за зверь.

Что такое MaxTokenSize и каково его влияние

По мере роста срока службы Active Directory учетные записи пользователей становятся членами все большего числа групп безопасности. В некоторых случаях это может вызвать проблемы, которые обычно трудно распознать. Они часто выглядят как случайные сбои или сбои приложения: сбои приложения групповой политики, запуск веб-сайта, заканчивающийся ошибкой HTTP 400, сеанс входа в систему невозможен.

Информация о членстве в группе, используемая для создания токена доступа, отправляется в зашифрованном виде в билете Kerberos. Часть билета Kerberos, используемая для хранения этой информации о членстве в группе, называется Сертификатом атрибута привилегии (Privilege Attribute Certificate — PAC), для инкапсуляции информации, связанной с авторизацией, в соответствии с RFC4120. Информация авторизации, включенная в PAC, включает идентификаторы безопасности, информацию профиля пользователя, такую ​​как полное имя, домашний каталог и количество неверных паролей. Идентификаторы безопасности (SID), включенные в PAC, представляют текущий SID пользователя и любые экземпляры истории SID и членства в группах безопасности в пределах текущих групп доменов, групп доменов ресурсов и универсальных групп.

Если для максимального размера токена установлено слишком малое значение для хранения всей информации о членстве в группе для пользователя, токен не будет содержать полного членства в группах. Пользователь не сможет пройти проверку подлинности, поскольку маркер Kerberos, созданный во время попыток проверки подлинности, имеет фиксированный максимальный размер. Транспортные протоколы, такие как удаленный вызов процедур (RPC) и HTTP, полагаются на значение MaxTokenSize, когда они выделяют пространство памяти для обработки аутентификации. Это значение изменилось со времен Windows 2000. Сейчас мы находимся в самых последних версиях Windows со значением 48K.

В итоге MaxTokenSize — это предопределенный буфер для размещения запросов авторизации в токене Kerberos, который получил пользователь. По сути, Kerberos использует этот буфер авторизации, чтобы позволить таким протоколам, как HTTP, устанавливать распределение памяти для функций аутентификации. Таким образом, параметр MaxTokenSize сообщит Windows, насколько большим может быть запрос на проверку подлинности с использованием протокола, например, HTTP, до того, как запрос не будет выполнен.

История размера MaxTokenSize

• Windows 2000 имел размер 8000 байт
• Windows 2000 SP2 — 12 000 байт
• Windows 2003 — 12 000 байт
• Windows XP — 12 000 байт
• Windows Vista — 12 000 байт
• Windows 7 — 12 000 байт
• Windows 2008 — 12 000 байт
• Windows 2008 R2 — 12 000 байт
• Windows 8 — 48 000 байт
• Windows 2012 — 48 000 байт
• Windows 8.1 — 48 000 байт
• Windows 2012 R2 — 48 000 байт
• Windows 10 — 48 000 байт
• Windows Server 2019 — 48 000 байт

О чем не догадывается пользователь

Так что же происходит, когда пользователь пытается представить токен доступа, который больше, чем буфер MaxTokenSize, определенный на удаленном сервере Windows? Маркер доступа пользователя будет автоматически уменьшен в соответствии с настроенным размером буфера. Это означает, что SID (ключи) будут удалены с токена доступа во время запроса. SID, требуемый для доступа к ресурсу, может быть отфильтрован и привести к сообщению об отказе в доступе пользователю, даже если у него действительно есть соответствующие права в списке управления доступом. Выше я привел пример ошибки обращения в сетевому ресурсу.

Другая распространенная проблема, которая приводит к проблемам с буфером MaxTokenSize, связана с добавлением пользователей в большое количество групп. Большинство компаний растут и растет их инфраструктура Active Directory, и, по моему опыту, нередки проблемы MaxTokenSize после того, как пользователь был перенесен несколько раз (Мигрирован), а очистка членства в группе не проверена. Как только токен Kerberos пользователя растет и превосходит буфер MaxTokenSize, он начинает видеть сообщения об ошибках от приложений, использующих Kerberos для аутентификации.

По моему мнению, максимальный размер MaxTokenSize по умолчанию до Windows 7/2008 R2 был слишком низким и привел к тому, что многие бессонные ночи и заявки на устранение проблем, были вызваны именно этим фактором. Для администраторов Exchange, есть глубокое осознание проблемы MaxTokenSize, когда небольшие группы пользователей не смогли успешно установить соединения Outlook Anywhere (RPC/HTTP) с серверами клиентского доступа, но большинство пользователей могли без каких-либо проблем. Эти проблемы всегда являются скрытыми по своей природе, потому что их трудно устранить, и они могут казаться спорадическими по своей природе, что приводит к потере времени на устранение неисправностей.

Поле, содержащее идентификаторы безопасности участников группы в маркере доступа, теоретически может содержать не более 1024 идентификаторов безопасности. На самом деле это не 1024, а 1024 — 9 — это 1015 SID! Если пользователь состоит в более чем 1015 группах, LSA не может создать маркер доступа во время попытки входа в систему. В этом случае при входе пользователя отображается следующее сообщение об ошибке:

Расчет размера токена Kerberos

Существует математическая формула для расчета значения токена для пользователя: Microsoft документирует его в этой статье (https://support.microsoft.com/fr-fr/help/327825/problems-with-kerberos-authentication-when-a-user-belongs-to-many-grou), и мы можем взять его здесь:

TokenSize = 1200 байт + (40 байт X d ) + (8 байт X s )

• d : Представляет количество локальных групп, к которым принадлежит пользователь + количество универсальных групп вне домена учетной записи пользователя + количество групп, представленных в истории SID.
• s : представляет количество глобальных групп, к которым принадлежит пользователь + количество универсальных групп в домене учетной записи пользователя.
• 1200: представляет приблизительное значение для остальной части билета. Это значение может варьироваться в зависимости от таких факторов, как длина доменного имени DNS, имя клиента и другие факторы.

Мы можем использовать этот скрипт powershell для расчета стоимости билета для пользователя. Он использует формулу выше. Однако существует менее известный метод перечисления групп, к которым принадлежит пользователь, через команду NTDSUTIL / group membership evaluation, а затем запустить имя учетной записи NOMDEDOMAIN (https://support.microsoft.com/en-us/help/328889/logging-on-a-user-account-that-is-a-member-of-more-than-1010-groups-ma).

Как узнать текущий размер токена Kerberos у пользователя и компьютера

Для того, чтобы посмотреть текущие параметры размера MaxTokenSize на компьютере, вы можете воспользоваться оболочкой PowerShell. Открываем ее и вводим команду:

Как видим в моей Windows 10 значение у MaxTokenSize 48 КБ.

Чтобы узнать размер MaxTokenSize у текущего пользователя можно воспользоваться специальным скриптом, который выложил один инженер Microsoft, проходим по ссылке (https://gallery.technet.microsoft.com/scriptcenter/Check-for-MaxTokenSize-520e51e5) или у меня. Нажимаем загрузить скрипт.

Соглашаемся с лицензионным соглашением.

У вас выскочит уведомление, что он не имеет цифровой подписи, и нужно нажать R, чтобы его запустить, это связано с политикой Set-ExecutionPolicy, которая по умолчанию блокирует такие скрипты, как запускать скрипты и менять политику я подробно описывал, кому интересно посмотрите.

Далее вас спросят для какой операционной системы вы хотите рассчитать, это влияет только на то, будет ли выявлено превышение, так как я напомню, что у каждой версии операционной системы параметр MaxTokenSize может иметь свои значения. Я выберу для Windows 10 и нажимаю 6. В итоге мы видим, что мой пользователь Барбоскин имеет размер буфера MaxTokenSize в 4928 байт и до 48 000 мне очень далеко, так же там есть информация:

• There are 48 groups in the token. — общее количество групп в которых состоит пользователь
• There are 0 SIDs in the users SIDHistory. — есть ли группы из-за SIDHistory
• There are 4 SIDs in the users groups SIDHistory attributes. — атрибуты SID
• 7 are domain global scope security groups. — количество глобальных групп
  3 are domain local security groups. — количество доменных групп
  6 are universal security groups inside of the users domain. — количество универсальных групп
  22 are universal security groups outside of the users domain. — универсальные группы безопасности вне домена пользователя

Управление ограничением размера MaxTokenSize

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

• Вы можете уменьшить количество групп в которые входит пользователь, так сказать провести аудит, я сомневаюсь, что ему нужны сотни групп или тысяча
• Второй вариант, это увеличить или локально или массово на всех компьютерах со старой версией ОС параметр MaxTokenSize до 48 000, максимальное значение 64 КБ.

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

Увеличить MaxTokenSize через реестр Windows

Откройте редактор реестра Windows и перейдите в ветку:

Где вам необходимо создать DWORD (32-bit) Value с именем MaxTokenSize и значением 48 000

Увеличить MaxTokenSize через групповую политику

Для массового применения настройки мы с вами воспользуемся всеми прелестями групповой политики. Откройте оснастку «Управление групповой политикой» и создайте новый объект GPO.

Нас интересует настройка:

Выставите «Включено» и значение 48000. Напоминаю, что после сохранения настроек, вы должны дождаться, когда политика отреплецируется на все контроллеры домена, это 5 минут. После чего вы должны или принудительно обновить групповую политику или дождаться штатного автоматического обновления, это 90-120 минут, после чего, чтобы MaxTokenSize заработал, сервер нужно перезагрузить, иначе он будет работать со старым значением.

Теперь кстати после превышения кем-то порога значения MaxTokenSize у вас в логах системы будет записываться предупреждение с кодом ID 31. Ранее я говорил, что этот параметр политики решает ваши проблемы с использованием TOKENSZ и других утилит для определения MaxTokenSize — вот как. Если вы изучите подробности события 31 с предупреждением Kerberos-Key-Distribution-Center, вы заметите, что он предоставляет вам всю информацию, необходимую для определения оптимального MaxTokenSize в вашей среде. В следующем примере пользователь barboskin.g является участником более 1000 групп. Когда я пытаюсь войти barboskin.g с помощью команды RUNAS, я сгенерировал ID события 31. В описании события указываются имя участника службы, имя пользователя, размер запрошенного билета и размер порога. Это позволяет объединить все события 31 и определить максимальный размер запрашиваемого билета.

IIS, HTTP 400 — неверный запрос

В прошлом Microsoft указала, что можно увеличить размер MaxTokenSize до 65 535. Это то, что не рекомендуется, потому что некоторые приложения основаны на этом значении. Возьмите пример IIS. Как мы видели в этой статье , клиент использует заголовок   «Авторизация»  для предоставления серверу IIS элементов аутентификации (Ticket Kerberos). Следовательно, размер заголовка увеличивается с увеличением количества групп пользователей. Если заголовок HTTP увеличивается за пределы, установленные на сервере, сервер IIS может отклонить запрос и отправить сообщение об ошибке в качестве ответа (HTTP 400 — неверный запрос).

2 значения в реестре сервера для HTTP.sys позволяют вам контролировать максимальный размер каждого заголовка HTTP-запроса. По умолчанию эти значения отсутствуют, но могут быть созданы по мере необходимости в HKEY_LOCAL_MACHINESystemCurrentControlSet Services HTTPParameters. Запись реестра MaxFieldLength указывает верхний предел общего размера строки запроса и заголовков. Обычно эта запись реестра настраивается с помощью записи реестра MaxRequestBytes. Если значение MaxRequestBytes меньше значения MaxFieldLength, значение MaxFieldLength корректируется.

Даже если его нет в реестре, MaxFieldLength по умолчанию устанавливается с Windows 2012 на 65 534. Из-за кодировки HTTP base64 заголовка HTTP значение MaxTokenSize не должно превышать 48 000 байтов (48 o X 1.333 = приблизительно 64 o). 1.333 представляет базовую кодировку 64, которая механически увеличивает размер заголовка. Вы можете прочитать эту статью, чтобы пойти дальше, расшифровав заголовок авторизации (http://remivernier.com/index.php/2018/09/16/exploration-des-entetes-http-www-authenticate/).

Сжатие SID ресурса KDC

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

Компоненты KDC для Windows Server 2012 помогают уменьшить размер PAC, используя сжатие SID ресурсов. По умолчанию Windows Server 2012 KDC всегда сжимает SID ресурса. Чтобы сжать идентификаторы ресурсов SID, KDC сохраняет SID домена ресурсов, членом которого является целевой ресурс. Затем он вставляет только часть RID каждого SID ресурса в часть ResourceGroupIds данных аутентификации. Сжатие SID ресурса уменьшает размер каждого сохраненного экземпляра SID ресурса, потому что SID домена сохраняется один раз, а не с каждым экземпляром. Без сжатия SID ресурса KDC вставляет все SID, добавленные доменом ресурса, в часть Extra-SIDструктуры PAC, которая является списком SID.

Interoperability

Другие реализации Kerberos могут не понимать сжатие группы ресурсов и поэтому несовместимы. В этих сценариях может потребоваться отключить сжатие группы ресурсов, чтобы обеспечить возможность взаимодействия KDC в Windows Server 2012 со сторонней реализацией Kerberos.

Сжатие SID ресурса включено по умолчанию; однако вы можете отключить его. Вы отключаете сжатие SID ресурса на KDC в Windows Server 2012 с помощью значения реестра DisableResourceGroupsFields в разделе реестра HKLMSoftwareMicrosoftWindowsCurrentVersion PoliciesSystemKdc Parameters. Это значение реестра имеет тип значения реестра DWORD. Вы полностью отключаете сжатие SID ресурса, когда устанавливаете значение реестра равным 1. KDC читает эту конфигурацию при создании заявки на обслуживание. При включенном бите KDC не использует сжатие SID ресурса при создании заявки на обслуживание.

На этом я заканчиваю свою стать про размер буфера MaxTokenSize. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

The kerberos client received a KRB_AP_ERR_MODIFIED error from the server

The article helps you to resolve the issue that the kerberos client received a KRB_AP_ERR_MODIFIED error from the server.

Applies to: В Windows Server 2003
Original KB number: В 558115

Symptoms

During access to NLB virtual IP/NLB Virtual Name, the user may prompt to a username and password, and the following error may add to the local system event log:

«The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/myserver.domain.com. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (domain.com), and the client realm. Please contact your system administrator.»

Cause

During access to the IIS 6 web site that support Windows Integrated Authentication, the following issues may occur:

1. Mismatch DNS name resolution. The issue is common in an NLB environment that uses multiple IPs or network adapters.
2. The user doesn’t have a Local NTFS access permission.
3. The Web Site is using Application Pool with a poor permission setting.

Resolution

To resolve the error issue, consider to implement the following tests:

Verify that the IIS has been set up with correct NTFS settings.

Integrated Windows Authentication (IIS 6.0)

Verify that each cluster node has been set up with correct DNS settings.

Verify that the node has been set up with correct Application Pool settings:

Configuring Application Pool Identity with IIS 6.0 (IIS 6.0)

Verify that internet explorer has been set up with a correct security setting.

More information

Authentication and Access Control Diagnostics 1.0 (x86)

Internet Information Services Diagnostic Tools

Community Solutions Content Disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the suitability, reliability, or accuracy of the information and related graphics contained herein. All such information and related graphics are provided «as is» without warranty of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and conditions with regard to this information and related graphics, including all implied warranties and conditions of merchantability, fitness for a particular purpose, workmanlike effort, title and non-infringement. You specifically agree that in no event shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental, special, consequential damages or any damages whatsoever including, without limitation, damages for loss of use, data or profits, arising out of or in any way connected with the use of or inability to use the information and related graphics contained herein, whether based on contract, tort, negligence, strict liability or otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of damages.

Источник

Клиент kerberos получил KRB_AP_ERR_MODIFIED ошибку с сервера.

Эта статья поможет устранить проблему, из-за которую клиент Kerberos KRB_AP_ERR_MODIFIED ошибку с сервера.

Применяется к: Windows Server 2003
Исходный номер базы знаний: 558115

Симптомы

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

Идентификатор события: 4
Источник: Kerberos
Тип: Ошибка

«Клиент kerberos получил KRB_AP_ERR_MODIFIED с узла сервера/myserver.domain.com. Это означает, что пароль, используемый для шифрования билета службы Kerberos, отличается от пароля на целевом сервере. Как правило, это связано с одинаковыми именованными учетными записями компьютеров в целевой области (domain.com) и клиентской области. Обратитесь к системному администратору».

Причина

Во время доступа к веб-сайту IIS 6, который поддерживает встроенную проверку подлинности Windows, могут возникнуть следующие проблемы:

1. Несоответствие разрешения DNS-имен. Эта проблема распространена в среде балансировки сетевой подсистемы балансировки нагрузки, использующей несколько IP-адресов или сетевых адаптеров.
2. У пользователя нет разрешения на локальный доступ NTFS.
3. Веб-сайт использует пул приложений с неудовлетворительной настройкой разрешений.

Решение

Чтобы устранить ошибку, рассмотрите возможность реализации следующих тестов:

Убедитесь, что службы IIS настроены с правильными параметрами NTFS.

Встроенная проверка подлинности Windows (IIS 6.0)

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

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

Настройка удостоверения пула приложений с помощью IIS 6.0 (IIS 6.0)

Убедитесь, что в Internet Explorer настроен правильный параметр безопасности.

Дополнительные сведения

Проверка подлинности и контроль доступа диагностики 1.0 (x86)

Средства диагностики служб Internet Information Services

Отказ от ответственности за содержимое общедоступных решений

Корпорация Майкрософт и/или ее поставщики не делают никаких заявлений относительно пригодности, надежности или точности сведений и соответствующих изображений, приведенных в настоящем документе. Все эти сведения и соответствующие изображения предоставлены «как есть» без каких-либо гарантий. Корпорация Майкрософт и/или ее поставщики настоящим отказываются от каких-либо гарантийных обязательств и условий в отношении этих сведений и соответствующих изображений, включая все подразумеваемые гарантии и условия товарной пригодности, применимости для конкретных целей, качества исполнения, прав собственности и отсутствия нарушений прав интеллектуальной собственности. В частности, вы подтверждаете свое согласие с тем, что корпорация Майкрософт и/или ее поставщики ни при каких обстоятельствах не несут ответственности за прямой или косвенный ущерб, штрафные санкции, случайные, фактические, косвенные или иные убытки, включая, в частности, убытки от утраты эксплуатационных качеств, от потери данных или прибылей в связи с использованием или невозможностью использовать эти сведения и соответствующие изображения, содержащиеся в настоящем документе, возникшие вследствие соглашения, гражданского правонарушения, халатности, объективной ответственности или иным образом, даже если корпорация Майкрософт или ее поставщики заранее были извещены о возможности такого ущерба.

Источник

Kerberos – KRB_AP_ERR_MODIFIED is not always an SPN problem

TLDR: This can also be caused by a mismatch in security policy “Network Security: Configure encryption types allowed for Kerberos“.

Consider the following scenario:

• You have a web site set up to use Kerberos authentication. It doesn’t matter what kind of site, but we’ll say it’s a SharePoint site, since that’s the theme around here.
• The site is at https://teams.contoso.com and its application pool is running as service account CONTOSOSP_WEB_APP_SVC.
• Kernel Mode authentication is not enabled in IIS Manager.

• Note: It’s possible that some users could have this “access denied” behavior, while others have no trouble accessing the site.

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server SP_WEB_APP_SVC. The target name used was HTTP/teams.contoso.com. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (CONTOSO.COM) is different from the client domain (CONTOSO.COM), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Most commonly, the “KRB_AP_ERR_MODIFIED” error means that you have a Service Principal Name (SPN) issue, specifically, the SPN has been added to the wrong account. You should check those things first.

In our scenario above, we know that the application pool is running as a domain account and Kernel Mode authentication is disabled, which is the typical configuration for a SharePoint web app. In that case, we need an HTTP SPN set for the site host name, and set on the account running the application pool.

We can use SETSPN -l (that’s a lower case L) to see which SPNs have been set on our service account:

Command: setspn -l CONTOSOSP_WEB_APP_SVC

Registered ServicePrincipalNames for CN=SP_WEB_APP_SVC,OU=Service Accounts,DC=contoso,DC=com:

You an also do it the opposite way, where you search for a given SPN to see which account it’s set on. For that you use SETSPN -q

Command: setspn -q HTTP/teams.contoso.com

And you can use SETSPN -x to check if there are any duplicate SPNs, meaning the same SPN set on more than one account. That situation will also cause Kerberos to fail, so if it finds any duplicates, you should probably take care of those.

That all looks good, now what?

Lets say you look through all of this, and it all checks out:

• The application pool is running as the account you expect (CONTOSOSP_WEB_APP_SVC)
• Kernel Mode Authentication is disabled.
• The SPN is in the correct format (HTTP/teams.contoso.com)
• The SPN is set on the application pool account, and only that account.

Now that we’ve gone through the most common reasons for “KRB_AP_ERR_MODIFIED”, we’ll get to a lesser-known problem, which is what spawned this blog post.

All “KRB_AP_ERR_MODIFIED” means is that the encryption key used to encrypt the Kerberos ticket is not the same as the key that the server is trying to use to decrypt it. This can happen if the encryption algorithm is different between client and server, which can be controlled by a Windows security policy called “Network Security: Configure encryption types allowed for Kerberos“. If this setting is configured differently between the client machine and the web server, the result can be a mismatch in encryption types, a failure to decrypt the Kerberos ticket, and the “KRB_AP_ERR_MODIFIED” error, resulting in Access Denied.

You can check this by looking at the Local Security Policy on both client and server.

SecPol.msc > Security Settings > Local Policies > Security Options > Network Security: Configure encryption types allowed for Kerberos

Example:

Lets say that on the problem client machine, the policy is undefined, which would allow the user to get a Kerberos ticket encrypted with the “RC4_HMAC_MD5” algorithm.

However, on the web server side, the “Configure encryption types allowed for Kerberos” policy is defined, and is set to only allow these three:

– Future encryption types

Because the encryption type used by the client machine is not included in the “allowed” list on the server, the server is unable to decrypt the Kerberos ticket, and authentication fails with “KRB_AP_ERR_MODIFIED”.

Resolution:

Use Group Policy to define the same settings for “Network Security: Configure encryption types allowed for Kerberos” and make sure it’s applied consistently to both servers and client machines.

Other Tips:

If you’re wondering which encryption type was used to encrypt a Kerberos ticket, you can run the command “klist” on the client. It will display all of the Kerberos tickets currently assigned to the user. You’re looking for the one that matches the SPN you’re using for the site.

Command: klist

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-9

Ticket Flags 0x40a10000 -> forwardable renewable…

Источник

Kerberos error krb ap err modified

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

since one night i receive the following error message on all member Server in a branch office for a special subent.
Other Member server i a different subnet are not getting these errors. Before those member servers (new setup)
worked fine for about 2-3 Month:

Log Name: System
Source: Microsoft-Windows-Security-Kerberos
Date: 09.10.2013 02:47:27
Event ID: 4
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: server
Description:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server dc01$.
The target name used was cifs/dc01.local. This indicates that the target server
failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN)
is registered on an account other than the account the target service is using. Please ensure that the target SPN
is registered on, and only registered on, the account used by the server. This error can also happen when the target
ervice is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC)
has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password.
If the server name is not fully qualified, and the target domain (domain.local) is different from the client domain (domain.local),
check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

These servers have no routing to the local Domain Controllers, instead they contact the DCs at the main office. So the
KRB_AP_ERR_MODIFIED error is coming from both DCs at the main office, not specific to one pc.

Effects that i have:
— no logon with RDP possible (wrong username or password)
— Service which Relay on Kerberos Auth have Problems

So when i reboot the server in most cases its working again for some time. I also find out, when deleting the cached
Kerberos Tickets with kerbtray its working.

Any ideas what could cause the problem. As mentioned, it happend for all member servers in this subnet starting in the
same night. As always, nothing was changed 😉

Источник

I have two new Domain Controllers on new Forest. Servers have DFS and IIS services installed. Everything seemed to go Ok for a While. After updating servers I got new errors. Now once in hour aditional Domain controller IIS2 is making these errors to event log:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the
server iis2$. The target name used was
E3514235-4B06-11D1-AB04-00C04FC2DCD2/d170f7fc-6f05-4ea5-9dee-a657e3de019b/example.com@example.com.
This indicates that the target server failed to decrypt the ticket
provided by the client. This can occur when the target server
principal name (SPN) is registered on an account other than the
account the target service is using. Ensure that the target SPN is
only registered on the account used by the server. This error can also
happen if the target service account password is different than what
is configured on the Kerberos Key Distribution Center for that target
service. Ensure that the service on the server and the KDC are both
configured to use the same password. If the server name is not fully
qualified, and the target domain (example.com) is different from the
client domain (example.com), check if there are identically named
server accounts in these two domains, or use the fully-qualified name
to identify the server.

What does this really mean? What should I do to fix this problem? How to start…

Those server are new ones, I even tryed to reinstall servers with same roles. Every time same kind of kerberos erros occurs. Previous time it was somemethin to di with Ldap, and now this…