After migrating service accounts or computer accounts in the intra-forest environment, the target user can no longer authenticate to the source servers like MS SQL etc. when using Kerberos authentication. EventID 11 is found in the Event Log on Domain Controllers:
There are multiple accounts with name MSSQLSvc/ComputerName.DomainName.SysName.Company.Local:1433 of type DS_SERVICE_PRINCIPAL_NAME.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp .
NTLM authentication continues to function.
This is due to the fact that duplicate SPNs cannot exist in the same forest. SPNs are unique identifiers for the services running on the servers. Each service that uses Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network. It is registered in Active Directory attribute servicePrincipalName under a service account or computer account if service runs under the Local System Account. Any service or user can look up the SPN for another service. When they want to authenticate to such service, SPN is used to differentiate it from other services running in AD.
1. Please skip servicePrincipalName attribute when doing intra-forest service accounts or computer accounts migration with migration session or directory synchronization.
2. Follow this Microsoft KB Article ID: 321044 to set proper SPNs for the migrated computer or service accounts:
"Event ID 11 in the System log of domain controllers"
http://support.microsoft.com/kb/321044
OR
"Service Logons Fail Due to Incorrectly Set SPNs"
http://technet.microsoft.com/en-us/library/cc772897.aspx
According to Microsoft:
"Kerberos uses SPNs extensively. When a Kerberos client uses its TGT to request a service ticket for a specific service, the service is actually identified by its SPN. The KDC will grant the client a service ticket that is encrypted in part with a shared secret that the service account as identified by the AD account that matches the SPN has (basically the account password). In the case of a duplicate SPN, what can happen is that the KDC will generate a service ticket that may be created based on the shared secret of the wrong account. Then, when the client provides that ticket to the service during authentication, the service itself cannot decrypt it and the auth fails. The server will typically log an "AP Modified" error and the client will see a "wrong principal" error code.
So, duplicate SPNs are very bad, much in the same way that duplicate UPNs are bad. Both can cause Kerb auth to break and Windows uses Kerb for auth
everywhere it can."
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center