Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server <computer name>$. 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 name>), and the client realm. Please contact your system administrator.
|English: This information is only available to subscribers. An example of English, please!|
|Concepts to understand:|
What is Kerberos?
In my case the issue was due to scavenging not enabled in reverse DNS zones. On the direct zone it was correct, but the records on the reverse zones were in some cases 5 years old. The issue solved enabling scavenging on all reverse zones and purging old records.
In my case, running dfsutil /purgemupcache fixed the problem. See T736784 for information about dfsutil.
EV100482 (Fixing the Security-Kerberos / 4 error) provides information on the troubleshooting steps taken to fix this event on a Microsoft System Center 2012 R2 Server.
In our case, Symantec Backup Exec 2012 was attempting to discover servers that are not being backed up causing these Kerberos errors on our backup server event logs. The solution was to go into the Backup Exec settings and disable discover data to back up. Restart Backup Exec services to commit the change. See EV100437 (Symantec TECH207085).
We had this error while accessing a MS Windows Server 2012 file cluster from XP clients. Access using the IP was working but by host name not. The hotfix described in ME2838669 fixed the problem.
In our case, this error began after we changed the ip address of Windows 2003 domain controller and added a new Windows 2008 R2 domain controller on the older DC's IP address. To resolve the problem, we removed the host file entries that were hard coded in the old DC's hosts files (to the old IP). Lesson of this was to not only check DNS for duplicate/stale dns entries but to also check the local hosts file as well.
I recently was able to make this go away with the assistance of Microsoft PSS. The situation occured on each node of our Exchange 2007 CCR mailbox cluster with some regularity.
Create the following REG_DWORD value and set to 1 in the registry: This value was not present previously. Do this on each node in the CCR Cluster:
This error is about identically named accounts - and appears to be quite popular. My fix was this:
Check in DNS for any A records that have identical IP addresses.
If you find some, identify which is the current correct A record and IP. Delete the other.
Check ADUC for the identical A record machine names, for example if you see ComputerA and ComputerB both on 192.168.1.10 - one of these is out of date, and could be caused by one of the machines no longer existing on your network.
Verify if one of the machines no longer exists. Remove the account from ADUC. - Note the error mentions both the DC and a client - this error relates to two clients sharing the same IP and both having valid accounts in AD.
One you have done this - i would reccomend to enable DNS Ageing and Scavenging, and to scavenge stale resources records. I would also reccomend to configure your DHCP to dynamically update records, you will need to provide credentials to do this.
This should solve your issues.
I had reinstalled a server but forgot to delete it from AD. When i deleted it from AD the error was gone.
Peter Van Gils
A client was using a DNS CNAME to point traffic to host2 after host1 was decomissioned. This is similar to the problems I had posted for a different environment. Removing the CNAME would have resolved the issue but was not a possible solution in this particluar case.
I was experiencing issues with NETLOGON, SPN records, Kerberos, NLTEST, and connections beetwen servers and domain controllers.
Randomly we were losing connection with DC and only re-joining in domain solved this issue. There were also communication problems with Kerberos, SPN (even though the SPN was set correctly in schema) recprds, and NLTEST was always unsuccessful. Renaming and rejoining the domain did not help, neither re-promoting of DCs.
I fixed this by:
1. Removing another gateways from the network configuration
2. Inserting only primary and secondary DNS system into network settings of servers
3. Removing DNS systems which were not domain members from NAME Servers settings on domain DNS systems
I would recommend that first, install all the patches and hotfixes for the affected systems. I have also implemented the recommendations found at ME948496 and ME244474.
A client computer may receive the following event when the computer tries to connect to a clustered network name that has Kerberos enabled. See ME913327 to see under what conditions this event is received.
This problem occurs because two or more computer accounts have the same service principal name (SPN) registered. See ME321044 to solve this problem.
See ME558115 for additional information about this event.
In our case it was an entry in the etc/hosts file. After renaming a server and setting up a new one with the same name the host-entry was not updated and so the new server pointed to the IP address of the old one.
In my case, after setting up a cluster, I could not add a public store to the virtual node. There was a pre-existing Exchange server that I needed to replicate from but kept getting this error each time I attempted to bring the cluster public folder store online. WINS was ok, however, reverse DNS had several entries for not only the mail virtual server on the cluster, but the other nodes as well due to previous setting of DHCP on the adapters. I removed all duplicate DNS settings and rebooted. All mailbox stores came up afterwards.
I had a problem with the hosts file being incorrectly configured (wrong ip address). When the misconfiguration was corrected, the error went away.
In my case, I was receiving this error on a domain controller. Reseting the Machine Account Password by following the instructions in Microsoft's article ME260575 solved the problem.
When we have reinstalled a machine with a different name but the same IP address, we saw this error on client machines when they tried to connect to the reinstalled machine. Deleting the old machine account from AD resolved the problem.
We had this problem when updating the SPN value of the computer account in AD for our EMC storage. It appears that the EMC computer account needed to be re-registered in the domain to avoid the situation in which a client was not able to connect to the storage via its NetBIOS name.
The cause of this problem turned out to be two DCs sharing the same IP address, one of which was offline. This occurred because of a mistake during a branch rollout. Pinging both hosts listed in the event text should be a good place to start troubleshooting this error.
This event can occur if you setup multiple NETBIOS names for the same computer.
I disabled the computer account, cleared the WINS/DNS information on the computer account, and finally, enabled it back. In my case, that solved the problem.
This problem can be caused by an incorrect PTR entry for the offending workstation or server in Reverse Lookup Zones under DNS. To correct the situation, delete the incorrect PTR entry in DNS, and then have the offending computer re-register itself in DNS using “ipconfig /registerdns” or by rebooting the client computer. Also, check to ensure that member computers can properly update PTR records.
This issue was affecting two of my domain controllers in the same domain. I resolved this problem by setting the DNS zone for the domain to Primary instead of Active Directory integrated. I then ran a “netdiag /fix” from the Windows 2003 support tools. A new DNS zone was then created on the second DC using the zone file from the first DC after the “netdiag /fix”. This immediately resolved the issue and had the extra benefit of also resolving some replication issues.
We had this problem on a newly installed DC that also acts as DHCP Server and was not properly configured. We configured all our DHCP servers to register clients, using a common domain account. This new DC/DHCP server was not configured with these DHCP credentials, so all the other DHCP servers could not update A records that this new DHCP server had registered. This caused several A records to have the same IP address registered, causing Event ID 4 when the KDC did not know which client was the right one.
As per Microsoft: "Kerberos cannot authenticate the Web program user because the server cannot verify the Kerberos authentication request sent by the client. This usually happens when there is an account in the target domain with the same name as the server in the client's domain. If so, the ticket is issued for the server in the client's domain and it cannot be decrypted by the recipient server in the target domain". See MSW2KDB and the link to "Troubleshooting Kerberos Errors" for more details.
From a newsgroup post:
- Upgrade to the latest SP. There were some Kerberos caching issues fixed in WinXP SP1.
- The log might indicate an account name collision in your domain. Look for multiple accounts in the domain with the name SRV1. Possibly even a user account.
This problem occurred when a user was logged into multiple workstations. He changed password on one of the workstations while one of the others was locked. When the user went to unlock the machine with the old password immediately following the password change, this error was generated from the locked workstation. The user was unable to log on. The user then logged in using the updated password and the ticket was updated using the new password.
I received this error on a Windows 2003 SBS server concerning a Windows XP Professional workstation. The SBS server was the only DC in the domain. I corrected this problem after realizing that the workstation’s clock was 15 minutes behind the DC. I ran net time to update the workstation against the DC. I later replaced the workstation’s BIOS battery to permanently fix the error and added the net time command to all login scripts across the domain.
This event will occur if you present a service ticket to a principal (target computer) which cannot decrypt it. Normally the service ticket is encrypted using the shared secret of the machine account's password as a basis for the encryption used to encrypt the service ticket. Only the KDC (Domain Controllers) and the target machine know the password. The client presents encrypted session ticket it received from the KDC to the target server. If the server can decrypt the ticket, the server then knows that it was encrypted by a trusted source (the DC) and the presenter (the client) is also trusted. If the target server has a different password than the DC, the session ticket cannot be decrypted and the failure occurs.
Here is an example of how this can happen with two identically named machine accounts in separate forests. Suppose there are 2 machine accounts named FOO in DomainA, and DomainB, but the server really lives in DomainB, then users in domain A would get the error. Given the short name FOO, users in DomainA would acquire a service ticket to DomainA\FOO, and then present it to the DomainB\FOO server.
DomainB\FOO does not have the same password as DomainA\FOO, so it cannot decrypt the service ticket. There are two fixes for this scenario:
1. Access the server by the FQDN (e.g. FOO.DomainB.Com).
2. Delete the potentially unused server account (e.g. delete DomainA\Foo).
Other problems can cause this error:
1) WINS/DNS bad configuration. The name of the target server is mistakenly resolved to a different machine. To fix verify the resolved IP address actually matches the target machine's IP address.
2) Service bad configuration (server is actually running as DomainB\SomeOtherAccount, but the service transport, RPC, CIFS, ..., is trying to authenticate to the service DomainB\Foo).
3) Service is running on a cluster, which is not configured to use Kerberos. The same as 2, where you're trying to authenticate to the cluster, but you're actually authenticating to a node in the cluster, resulting in the above error.
To fix this problem, the first step is to identify all machines listed in the error above. Attempt to locate the machines and determine their domain affiliation and current IP address. If the machine is not in same domain as the client reporting the error, verify that a duplicate computer does not exist in the local domain with the same name as one listed in the error.
Next, verify that the client reporting the error can correctly resolve the right IP address for the client in question. Attempt a net use then check the NetBIOS cache (nbstat -c) and the DNS cache (ipconfig /displaydns).
You can use the following method to determine of there are any duplicate machine names registered in the same forest. Run the following command specifying the name of a GC as “GCName”.
ldifde -f SPNdump.ldf -s GCName -t 3268 -d dc=forest, dc=root –r "(objectclass=computer)" -l servicePrincipalName.
Note that the above is one line wrapped for readability. Open the file and search for all occurrences of the name list in the error 4 (omitting the $). This will catch duplicates in the same forest. However, it will not catch duplicates in different forests. You will need rerun in all forest and search the output from each.
To resolve the problem I removed the offending system completely from the Domain, removed it's entry in AD, and renamed the machine to a different name before joining it back into the domain. The errors are now permanently gone.
This problem has occurred after bringing up a new machine to replace an old one that failed, without first removing the old computer account from the domain. Remove the computer from the domain, delete the account if not done automatically and re-join the domain.
I have found the resolution to this issue. Download a copy of the IIS 6.0 resource kit. Then look at Part 2, Chapter 5, Managing a Secure IIS Solution. Read the section marked: "Kerberos Authentication Requires SPNs for Multiple Worker Processes".
We have seen this event when building new workstations into two separate sites within an Enterprise level AD. A workstaton was named the same in two sites, causing the second machine (when it had finished our automated build) to be tombstoned from the domain (no-one could logon to the station, and attempts to access it from a server via \\stationname\c$ failed with Access Denied). The Kerberos/4 error message was noted on a working station following the attempt to connect to the tombstoned station again using \\stationname\c$.
|Private comment: Subscribers only. See example of private comment|
|Links: IIS 6.0 Resource Kit, Troubleshooting Kerberos Errors|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
|Custom search for *****: Google - Bing - Microsoft - Yahoo|
Send comments or solutions
- Notify me when updated