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 CONTOSO\SP_WEB_APP_SVC.
- Kernel Mode authentication is not enabled in IIS Manager.
-
Domain users try to access the site and get three authentication prompts and then Access Denied.
- Note: It’s possible that some users could have this “access denied” behavior, while others have no trouble accessing the site.
- You look in the System event log on the web server(s) and find this error:
Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: The present
Time: Doesn’t matter
User: N/A
Computer: WFE1
Description:
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 CONTOSO\SP_WEB_APP_SVC
Example output:
Registered ServicePrincipalNames for CN=SP_WEB_APP_SVC,OU=Service Accounts,DC=contoso,DC=com:
HTTP/teams.contoso.com
HTTP/teams
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
Example output:
Checking domain DC=contoso,DC=com
CN=SP_WEB_APP_SVC,OU=Service Accounts,DC=contoso,DC=com
HTTP/teams.contoso.com
HTTP/teams
Existing SPN found!
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 (CONTOSO\SP_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:
– AES128_HMAC_SHA1
– AES256_HMAC_SHA1
– 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
Example output:
Client: josh @ CONTOSO.COM
Server: HTTP/teams.contoso.com @ CONTOSO.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-9
Ticket Flags 0x40a10000 -> forwardable renewable…
Start Time: 10/12/2020 11:36:54 (local)
End Time: 10/12/2020 21:36:54 (local)
Renew Time: 10/19/2020 11:36:54 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DC01