Windows Server


Explanation of Kerberos error KRB_AP_ERR_MODIFIED    



Explanation of Kerberos error KRB_AP_ERR_MODIFIED


Problem Operating System: Windows Server 2003 Enterprise [2003]


Problem Description

The following error is repeated in the event log. The target server name may reference more than one server.


XP Message


Event Type: Error

Event Source: Kerberos

Event Category: None

Event ID: 4

User: N/A

Computer: <Kerberos Client>


The kerberos client received a KRB_AP_ERR_MODIFIED error from the server <target

server>$. 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.


Windows 2003 Message


Event Type: Error

Event Source: Kerberos

Event Category: None

Event ID: 4

User: N/A

Computer: <Kerberos Client>


The kerberos client received a KRB_AP_ERR_MODIFIED error from the server <target

computer>. The target name used was <service type >/< instance 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 (realm name), and the client realm.

Please contact your system administrator.


For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.




Event Message



The event error posted above will appear on the Kerberos client, not the target

server, or the KDC. The field <target server>$ is the name of the server that was

contacted by the local client and is not the SPN or target server name the client

used to request a ticket. In the Windows 2003 message, the SPN used by the client

is listed in sentence "The target name used was <SPN>


For instance, if a client attempts to connect to <\\foobar> and the IP address for

foobar actually resolves to <\\someserver>, the client will get a ticket for foobar

and present it to <\\someserver>. Someserver will be the principle that gets the

ticket which cannot be decrypted and will report an access denied to the client.

Someserver will be the target server name listed in the event even though the user

never attempted to connect to the name someserver. A network trace is required to

determine which IP address was returned by DNS or WINS as well as to determine

which target server name was originally requested by the client. The target server

name can be found in the TGS request/Request Body/Server Name/Principle name



If the TGS request is for the same name as listed in the event, then the computer names were correct but the machine account password known by the KDC and the target server do not match. See below for more information.





The Kerberos Error 4 error "KRB_AP_ERR_MODIFIED" was added in XP and Windows 2003

in response to customer issues around Kerberos failures seen in the field.

Previous to this error, Kerberos may fail silently in the background requiring a

network trace for analysis.


In summary, this error indicates that the ticket was encrypted with a password

which is different than the password currently on the target server.


Explanation of the Error


This event will occur if you present a service ticket to a principal (target

computer) which cannot be decrypted by the target. The service ticket is encrypted

using the shared secret of the machine account's password as a seed for the

resulting encryption used on the service ticket. This ensures that only the KDCs

(DCs) and the target principle can decrypt the ticket. The client presents

encrypted 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 shared secret (machine

account password) used to encrypt the ticket is different between the KDC and the

target machine, the ticket cannot be decrypted and the failure occurs.


Here's 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 DomainA

would get the below error. Given a short name of FOO, users in DomainA would

acquire a service ticket to DomainA\FOO, and then present it to the DomainB\FOO



DomainB\FOO doesn't have the same password as DomainA\FOO, so it can't decrypt the

service ticket.


There are 2 fixes for this scenario:


1) Access the server by the FQDN (e.g. FOO.DomainB.Com)

2) Delete the potentially unused computer account (e.g. delete DomainA\Foo).


Other cases can cause this error:



1) WINS / DNS misconfiguration: 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 misconfiguration (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 isn't configured to use kerberos -

Basically 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






The first step is to identify all machines listed in the error above. Attempt to

locate the machines and determine their domain and forest affiliation as well as

the current IP address. If the machine is not in same forest as the client

reporting the error, verify that a duplicate computer account as well as duplicate

SPN does not exist within the local forest with the same name as one listed in the



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)


Customer Scenarios



The following is some customer scenarios that will result in the error 4


1) Machine moved to different domain - A user moved their machine account to a

trusted domain. The computer account in the source domain was left in place and

used to construct the service ticket which was not valid on the target machine in

its new domain

2) WINS Replication Failing - A user connected over VPN registered with WINS for

machineA, then disconnected. The same IP address was later given to a different

computer, machine B. The computer reporting the Kerberos error attempted to

connect to machineA but sent the ticket to machine B who cannot decrypted it

3) SPN Registration issues - A customer registered the SPN for MachineA under the

machine account for machineB. MachineA exists and is a valid machine account. The

client attempts to get a ticket for machineA and gets a ticket encrypted with

Machine B’s password. Decryption fails.


Altered Ticket


The other possible cause of this issue is that the ticket was alternated either

maliciously during an attach or unintentional by a hardware device such as a NAT or

router. At this time. this is remote and not likely the cause of these errors.


Duplicate Computer Accounts (Same forest)



NOTE: The error KRB_AP_ERR_MODIFIED will NOT occur as a result of duplicate

computer accounts in the SAME forest. The section added for completeness as well

to help separate these common issues from the KRB_AP_ERR_MODIFIED errors. In this

scenario, the KDC has knowledge of all SPNs in the forest via a global catalog

server. The attribute servicePrincipleName is included in the partial attribute

set and shared on all GCs. When the KDC attempts to resolve the requested SPN to a

security principle and it finds that the requested SPN exists on more than one

security principle, then two things happen:


1) In response to the TGS request, the KDC returns the Kerberos error, Server Not

found in Database. The KDC returns this error even though the real result is that

the server was found more than once in the database. When a Windows client

receives this error from the KDC, it will fall back to NTLM. In this way, the

duplicate SPN doesn’t cause a disruption in authentication as long as the Kerberos

is not required.


2) A KDC event ID 11 is listed in the KDC’s system event log listing the SPN that

was found to exist on more than one security principle. Note that this error is

only logged when a client request results in a duplicate being found and is not

performed proactively by the KDC.



Use the following method to determine if there are any duplicate SPNs registered in

the same forest. Run the following command specifying the name of a GC as



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 KDC event ID 11 (omitting text prior to

the / as well as the $). This will catch duplicates in the same forest. However it will not catch duplicates in different forests.


Updated 4-23-2007


No TrackBacks

TrackBack URL: http://www.skar.us/site/mt-tb.cgi/3356

Leave a comment


Author Bio          ★★★★★

Author Name:         administrator
Author Location:    India
Author Rank:          Writer
Author Status:        
The Green leave stands!!



  • eBooks
  • Games
  • Softwares
  • Tools
  • Tweaks
  • Wallpapers
  • Warez
  • Games
  • Tools
  • Wallpapers
    System Administration
  • dll Center
  • Scripts
  • Tools
  • .extensions database
  • Write-up
  • Download Database
  • Jobs
  • Lists
  • Polls
  • Glossary

01000011 01110010 01100001 01100011 01101011 01111010 01101000 01100001 01100011 01101011