The kerberos client received a krb ap err modified error from the server

Hi,

   We are getting this error from some servers in our environment when trying to connect to a SQL Server, but not from all (so, we do have some that are able to connect fine to it)

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server <SQLServiceAccount>. The target name used was MSSQLSvc/<SQLServerName-FQDN>:1433. 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 (<Domain>) is different from the client domain (<Domain>), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Details:

We are trying to test using an UDL File, and when Kerberos Logging is enabled, we are seeing this (Source: Security-Kerberos, Event 3):

A Kerberos error message was received:
on logon session
Client Time:
Server Time: 15:0:15.0000 1/8/2019 Z
Error Code: 0x29 KRB_AP_ERR_MODIFIED
Extended Error:
Client Realm:
Client Name:
Server Realm: <Domain>
Server Name: <SQLServiceAccount>
Target Name:
Error Text:
File: 3
Line: 587
Error Data is in record data.

SPNs look ok when checking with the Kerberos Configuration Troubleshooting tool (and the fact that other servers in the same environment are working (there are multiple working, and multiple failing)… All are in the same domain (single domain environment)..
and all of them are able to talk to other SQL Servers that coexist with the problematic one.

Any ideas/suggestions, on what I can look at next to troubleshoot this?

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 😉

Источник

При попытке ручной репликации данных между контроллерами домена 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 согласно этого гайда.

 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.