Security kerberos ошибка 4 - Исправление ошибок и поиск оптимальных решений проблем

Remove From My Forums

Вопрос
На некоторых серверах Windows Server 2012 (а также и на Windows Server 2008) стал замечать, что регистрируется такая ошибка.

Источник: Security-Kerberos

ID: 4

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера pc-mak1$. Использовалось конечное имя cifs/PC-DRIVERS3.sfh.local. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может
быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой
сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что
и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (SFH.LOCAL) отличен от домена клиента (SFH.LOCAL), проверьте, нет ли серверных учетных записей с таким же
именем в этих двух доменах, или используйте полное имя для идентификации сервера.

Ошибка регистрируется на сервере, который сам не образается ни к pc-makl1, ни к pc-drivers3.

В чем может быть проблема?

Ответы

Для резервного копирования используется Veritas Backup Exec 15.0.3.

А ответ на команды setspn (запускал на контроллере домена) такой:

C:UsersAdministrator>setspn -L pc-mak1.sfh.local
FindDomainForAccount: ошибка вызова DsGetDcNameWithAccountW с возвращаемым значе
нием 0x00000525
Не удалось найти учетную запись pc-mak1.sfh.local

C:UsersAdministrator>setspn -L pc-drivers3.sfh.local
FindDomainForAccount: ошибка вызова DsGetDcNameWithAccountW с возвращаемым значе
нием 0x00000525
Не удалось найти учетную запись pc-drivers3.sfh.local

Setspn принимает в качестве параметра имя компьютера, а не его FQDN. Поэтому команда должна быть:

setspn -L pc-mak1

и т.п.

BackupExec ЕМНИП может быть настроен так, чтобы искать в сети компьютеры, куда он бы поставил своего агента. Подробностей сейчас не помню — давно им не пользовался.

Слава России!
- Изменено
  
  17 марта 2016 г. 12:10
- Помечено в качестве ответа
  MikAndr
  23 марта 2016 г. 8:13

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):

Text

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.

1 found this helpful
thumb_up
thumb_down

Источник

Recently it came to my attention that our SCCM servers were bringing up the following error for many of our workstations,

Log Name: System
Source: Security-Kerberos
Event ID: 4
Level: Error
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server computer1$. The target name used was cifs/computer2.domain.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 (domain.com) is different from the client domain (domain.com), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

I did find the following posts online,
Event ID 4 — Kerberos Client Configuration which suggests deleting the offending computer object and recreating a new one (to summarise). Very good advice but did not resolve my issue.

Kerberos and SPN problems which suggested to install SPN records for the SQL server and follow up posts that this did not work and that it is a DNS reverse look up issue.

This post got me thinking. I checked my DNS reverse look up zones and they were all there from what I could see. Next I thought, I wonder what computer1 and computer2 resolved to in DNS. Bingo both of these machines responded on the same IP address meaning that when SCCM does its reverse look up for the computer1 it returns with the name of computer2 (I still have no idea why SCCM is doing this reverse lookup). The cause of this issue is not that we have two computers with the same IP address out there but there are two records in DNS for the same IP on with two different names. This was due to our DHCP lease times being much shorter than our DNS scavenging times. To resolve the issue we increased out DHCP leases to 8 days and our scavenging to 5-10 days.

If you want to see some instructions on setting up a reverse lookup zone in DNS check out this guide from Tom’s Hardware Create Reverse Primary DNS Zone in Windows Server 2012

If you want to see some instructions on setting up DNS scavenging settings check out this guide Don’t be afraid of DNS Scavenging. Just be patient.

If you want to see some instructions on where to change DHCP lease time check out these very basic instructions (sorry best I could find without being too wordy) How do I change the DHCP address lease time in Windows 2000?

Источник

Вопрос

Ответы