KRB_AP_ERR_MODIFIED is a common Kerberos failure message. This means some encrypted Kerberos authentication data sent by the client did not decrypt properly at the server.
When a Kerberos client requests a ticket for a specific service, the service is actually identified by its SPN. The KDC grants the client a service ticket that is encrypted using service’s secret key. Basically, the AD account password that that matches the SPN requested.
Under some scenarios, KDC may generate a service ticket that encrypted with password of a wrong account (or not expected one). Then, when client provide that ticket to the service for authentication, the service can’t decrypt it and authentication failed with KRB_AP_ERR_MODIFED.
In short, this happens because KDC issued a ticket encrypted using password of account A, but on the service side, it tries to decrypt this using the password of account B.
Common cause for this are duplicated SPN, wrong DNS settings, two computers in different domains have the same name, client requests wrong SPN. And from IIS 7, it may due to the wrong setting of IIS (kernel/user mode authentication).
262177 How to enable Kerberos event logging
By expanding the authenticate field in the HTTP response header returned by IIS, we could locate the reason for Kerberos authentication error.
- Http: Response, HTTP/1.1, Status: Unauthorized, URL: / , Using GSS-API Authentication
StatusCode: 401, Unauthorized
- WWWAuthenticate: Negotiate …
- Authenticate: Negotiate oWwwaqADCgEBomMEYWBfBgkqhkiG9xIBAgIDAH5QME6abcdIBBaEDAgEepBEYDzIwMTExMabcd0MDUxMDE0WqUabcd2mAwIBKakKGwhURVNULkNPTaoXMBWgAwIBAaEOMAwbCmNvbnRvc29zdmM=
- GssAPI: 0x1
- ResponseToken: 0x1
- KerberosToken: 0x1
- InnerContextToken: 0x1
- KerberosToken: 0x1
TokId: Krb5Error (0x300)
- Error: KRB_ERROR (30)
+ ErrorCode: KRB_AP_ERR_MODIFIED (41)
+ Realm: TEST.COM
+ Sname: contososvc
Date: Fri, 14 Oct 2011 05:10:14 GMT
It would be more straightforward using Wireshark.
Log Name: System
Date: 10/13/2011 10:10:05 PM
Event ID: 4
Task Category: None
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server contososvc. The target name used was HTTP/iis01.test.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. 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 service 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 (TEST.COM) is different from the client domain (TEST.COM), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
In this event, the SPN used is HTTP/iis01.test.com, and the account used to decrypt the ticket is contososvc. This happens because the account account used to encrypt the ticket is not contososvc.
In the case of a duplicated SPN, the same SPN was registered on at least two accounts. For example, a SPN was registered on two accounts: A and B. What happens is that KDC will generate a service ticket that may be encrypted with password of account A. Then, when the client sends that ticket to the service during authentication, the service may try to decrypt this using account B.
On Windows 2008 and later, detect duplicated SPN is easier. Since Windows Server 2008, the setspn itself includes a feature to search SPNs.
Besides HTTP/ SPN, please remember to check HOST/ SPN as well. HOST/ SPN will be used as a failover/alternative if HTTP/ SPN does not exist. In case of this scenario, wrong HOST/ SPN will result in Kerberos failure as well.
Here is a sample output of setspn on Windows Server 2008 SP2. For more details about this tool, please reference this document.
For Windows 2003 and XP, we can use another tool named ldifde to search duplicated SPN. Here is a sample query for HTTP/contoso. Please remember, don’t forget HOST/ SPN as well.
Here is an example output of ldifde, for more details about this tool, please reference follow document.
The SPN is forest-wide object, it has to be unique inside the whole domain. For a complex environment, using follow command to search the entire forest, like this:
Ldifde -s GCName -t 3268 -f d:\spn.ldf -d “dc=test, dc=com” –l ServicePrincipleName –r “(ServicePrincipalName=HTTP/contoso)”
In addition, we can use a wild card search like this:
Ldifde -s GCName -t 3268 –f d:\spn.ldf -d “dc=test, dc=com” -l servicePrincipalName -r (servicePrincipalName=*contoso*)
This is a specific scenario which most related to the behavior of client. This problem occurs if the Web site uses a CNAME resource record in the Domain Name System (DNS). For example, the DNS setting looks like this:
Contoso CNAME iis01.test.com
iis01.test.com A 10.0.5.2
When you use Internet Explorer to access the Web site, Internet Explorer uses the host name of the server ((IIS01)) instead of the CNAME resource record(Contoso) to contact the server. The authentication may fail with KRB_AP_ERR_MODIFIED.
HTTP/Contoso.test.com Registered on test\contososvc
HOST/IIS01.test.com Registered on test\iis01(machine account)
+ Ipv4: Src = 10.0.5.3, Dest = 10.0.5.1, Next Protocol = UDP, Packet ID = 9717, Total IP Length = 62
+ Udp: SrcPort = 64506, DstPort = DNS(53), Length = 42
- Dns: QueryId = 0x4BB1, QUERY (Standard query), Query for contoso.test.com of type Host Addr on class Internet
+ Ipv4: Src = 10.0.5.1, Dest = 10.0.5.3, Next Protocol = UDP, Packet ID = 6526, Total IP Length = 98
+ Udp: SrcPort = DNS(53), DstPort = 64506, Length = 78
- Dns: QueryId = 0x4BB1, QUERY (Standard query), Response - Success, 49, 0
QueryIdentifier: 19377 (0x4BB1)
- ARecord: contoso.test.com of type CNAME on class Internet: iis01.test.com
- ARecord: iis01.test.com of type Host Addr on class Internet: 10.0.5.2
+ Ipv4: Src = 10.0.5.3, Dest = 10.0.5.1, Next Protocol = TCP, Packet ID = 9728, Total IP Length = 0
+ Tcp: Flags=...AP..., SrcPort=50044, DstPort=Kerberos(88), PayloadLen=1488, Seq=4106960882 - 4106962370, Ack=354586390, Win=513 (scale factor 0x8) = 131328
- Kerberos: TGS Request Realm: TEST.COM Sname: HTTP/iis01.test.com
Error message in Internet Explorer when you try to access a Web site that requires Kerberos authentication on a Windows XP-based computer: "HTTP Error 401 - Unauthorized: Access is denied due to invalid credentials"
Internet Information Services (IIS) 7.0 enables kernel mode authentication by default. Kernel mode authentication runs under the machine account no matter what account is used to run the application pool. The machine account is used to decrypt the Kerberos ticket.
However, there are some scenarios you need to use a domain service account for authentication process instead of machine account. For example, a web arm scenario.
For this scenario, Instead of disabling kernel mode authentication in IIS, you can configure IIS to use the Web application pool’s identity for authentication (by setting useAppPoolCredentials="true").
For IIS 7+, we have 3 Windows authentication configuration. Different scenario requires register SPN on different accounts. In the scenario of improper SPN and IIS 7 configuration, it may result in authentication failure with KRB_AP_ERR_MODIFIED if the SPN was set to unexpected account.
NOTE: Machine account includes all accounts can represent the machine on network including Network Service, Local System, Local Service and ApplicationPoolIdentity for IIS 7+. Service accounts means a domain account used as the application pool identity.
Here, I listed couple of scenarios which can result in Kerberos authentication failed with KRB_AP_ERR_MODIFIED.
Kernel Mode Authentication
Application Pool Identity
Service Account like (domain\contosoService)
Web Site Binding To
IIS server’s NetBIOS Name. Access like this way:
HTTP/ SPN registered on service account
For this scenario, the Kerberos ticket is encrypted by service account, and is decrypted by IIS server’s computer account.
A customized host header. Access like this way:
For this scenario, the Kerberos ticket is encrypted by service account, and decrypted by IIS server’s computer account.
IIS server’s NetBIOS Name.
Access like this way:
HTTP/ IIS_Server_NetBIOS_Name doesn’t registered on any account
Or, registered on IIS server’s computer account
For this scenario, the Kerberos ticket is encrypted by IIS server’s computer account, and decrypted by service account.
URL used to access web site
No HTTP/ SPN required. By default, the HOST/ IIS_Server_NetBIOS_Name will be used.
If you want, you can register HTTP/ IIS_Server_NetBIOS_Name on the server name.
This is the default scenario for IIS 7+ when using IIS server’s computer name to access the web application.
Need register SPN on IIS server’s computer account, like:
SetSPN -a HTTP/Customer_Host_NAME IIS_SRV_NetBIOS
Some application requires this when they need special
permission for application pool identity.
Need register SPN on service account, like:
SetSPN -a HTTP/Customer_Host_NAME domain\contosoService
SetSPN -a HTTP/IIS_SERVER_FQDN domain\contosoService
You need select this scenario if you want web site binding to IIS server’s computer name and running the site with a domain account.
This is same for IIS 6 scenario.
SetSPN -a HTTP/ IIS_SERVER_NetBIOS_NAME domain\contosoService
This is similar to the default scenario of IIS 6.
See you Next Time,
Wei from APGC DSI Team
An insightful and extremely useful document. Your analysis of the problem and method of examining the possible causes shows an understanding of Kerberos that few other bloggers seem to possess. Thank you for your work - it has been extremely useful!