When a client needs to access a service or resource from a target server, it goes to DC to request a Service Ticket first. Because a target server can provide more than one services, in its request, the client has to include what type of resource/service it wants, this is done by including SPN in the request.
So it's easy to understand that, in an AD environment, servers(namely services providers) have to registered their SPN properly in AD in order to advertise/provide services properly. For example, Exchange server will normally register exchangeAB, exchangeMDB, exchangeRFR, and SMTP SPNs. Likewise, DC will register ldap, ntfrs, etc.
There are a few special SPNs that all servers will register automatically. HOST is one of them, sometimes in the form of cifs.
When the KDC gets a Service Ticket Request from a client, it extracts the SPN from the request, locate the server in its database(in Windows world, it's AD) based on SPN. KDC then prepares the ticket, encrypted it with the resource server's master key or service account's master key, and returns the ticket to client.
Kerberos error KRB_APP_ERR_MODIFIED (in Event ID 4 for AD) will occur if a service ticket was encrypted with one key while to be decrypted with another. This happens when a ticket is sent to a wrong computer, which in turn is often caused by duplicated DNS records, different computers have same name, etc. It can also be caused in the following scenario:
Target server (named DesiredServer)provides a service named "serviceA"; serviceA is running a service account named "ServiceAaccount"
Ideally, SPN 'serviceA\Targetserver' should be registered under DesiredServer's name. However in our example, it was registered under a different server's name, say, "WrongServer". Or same SPN 'serviceA\Targetserver' was registered twice under both "DesiredServer" and "WrongServer"
A client is requesting serviceA, it applies the service ticket from a DC with SPN 'serviceA' specified
DC searches its database based on SPN provided. It gets "WrongServer" as result. DC encrypts the ticket with "WrongServer"'s master key
The ticket is still sent to "DesiredServer" for service, and "DesiredServer" won't be able to decrypted the ticket.
A Kerberos error is logged on "DesiredServer"
Or there are chances that, when a ticket should be encrypted with a service account's key, but instead, it is encrypted with the computer's master key.
Search This Blog
Apr 20, 2007
Apr 19, 2007
Kerberos Event ID 4 - draft
Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 4/18/2007
Time: 2:01:16 AM
User: N/A
Computer: computer1
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/njmail01.corpdomain.com. The target name used was COMPUTER2. 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 (CORPDOMAIN.COM), and the client realm. Please contact your system administrator.
Theory that needs more study to verify:
A client requested service/resource from COMPUTER2, it got ticket that had been encrypted with COMPUTER2's key. But somehow it sent the ticket to COMPUTER1, who couldn't decrypt the ticket because it didn't have correct key.
Cause: 1. DNS or other name resolution error causes the client sending ticket to wrong machine. Check if there is any wrong/duplicate A/PTR records for COMPUTER1 and COMPUTER2
2. Computer2 didn't have one of its SPNs registered. When a request for that service with respective ticket comes in, the ticket then is sent to the local computer account, which has host/SPN(or cifs/SPN) automatically created. In this case, host/SPN isn't the service that is expected, therefore the error generated.
Example: COMPUTER2 is a sql server, it should have had a sql/SPN registered for its service account, but it didn't. When a client asks for sql service from computer2, ideally the ticket should be sent to sql service but since there isn't sql/SPN record in AD, the ticket is sent to local machine account(computer2) instead. The local computer tries to use its automatically generated cifs/SPN(host/SPN) to decrypt the ticket and fails.
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 4/18/2007
Time: 2:01:16 AM
User: N/A
Computer: computer1
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/njmail01.corpdomain.com. The target name used was COMPUTER2. 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 (CORPDOMAIN.COM), and the client realm. Please contact your system administrator.
Theory that needs more study to verify:
A client requested service/resource from COMPUTER2, it got ticket that had been encrypted with COMPUTER2's key. But somehow it sent the ticket to COMPUTER1, who couldn't decrypt the ticket because it didn't have correct key.
Cause: 1. DNS or other name resolution error causes the client sending ticket to wrong machine. Check if there is any wrong/duplicate A/PTR records for COMPUTER1 and COMPUTER2
2. Computer2 didn't have one of its SPNs registered. When a request for that service with respective ticket comes in, the ticket then is sent to the local computer account, which has host/SPN(or cifs/SPN) automatically created. In this case, host/SPN isn't the service that is expected, therefore the error generated.
Example: COMPUTER2 is a sql server, it should have had a sql/SPN registered for its service account, but it didn't. When a client asks for sql service from computer2, ideally the ticket should be sent to sql service but since there isn't sql/SPN record in AD, the ticket is sent to local machine account(computer2) instead. The local computer tries to use its automatically generated cifs/SPN(host/SPN) to decrypt the ticket and fails.
(search on keyword KRB_AP_ERR_MODIFIED)
Subscribe to:
Comments (Atom)