Reference article: https://technet.microsoft.com/en-us/library/cc759300(v=ws.10).aspx
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.
To identify duplicated accounts:
you can use the command: setspn -q <service/server:port> ; to find SPN duplicate on the forest
orusing setspn -L <computername> ; to list the SPN associated to a computer AD object
or by looking Event ID 11, source KDC on Domain controllers event log
