duplicate SPN on domain controller RRS feed

  • Question

  • Hi

    suffering from symptoms in this article -

    I can't login to DC  , setspn.exe -x shows no duplicates as does ldfide

    • please help !


    Thursday, June 2, 2016 9:33 AM


All replies

  • Hi

     Check this similar case,might be helpful;

    And if the isssue persist,you just demote DC from domain and then promote it as DC again.But verify before DC is not fsmo roles holder.(PDC)check with "netdom query fsmo" if yes,just transfer fsmo roles to other dc before process.

    This posting is provided AS IS with no warranties or guarantees,and confers no rights. Best regards Burak Uğur

    Thursday, June 2, 2016 12:33 PM
  • Hi laffeg,

    >>suffering from symptoms in this article -

    For a resolution you can remove the external trust and replace it with a forest trust created between the forest root domains of either forest. You may use selective authentication so still only the users can logon to your system that had the ability to do so before. Alternatively, you can take the following steps

    1. When you inspect the trusted object for the trusted domain in the domain, you will see an attribute TrustType = 1 which sets the trust to NETBIOS name resolution and hence no Kerberos. You can inspect the value in ADSIEDIT.MSC in the System container. The object will be named after the NETBIOS name of the remote domain.
      To solve this problem, re-create the trust using the Trust Wizard for Windows Server. This will create the trust using the DNS names of the domains and then TrustType = 2, thus DNS and Kerberos can be used on the trust.

    2. The network data flow for Kerberos is quite different, and requires port 88 for UDP and TCP to work, and also port 389 in UDP to locate the domain controller. If you are using Windows Vista systems to change the user passwords, you need to open the Kerberos change password port, 464, for both UDP and TCP.
    3. Because the trust is an external trust, the suffix routing options you have with a forest trust are not available, because of this, custom UPN suffixes will not work. will not work when the domain FQDN name is
      In order to log on, you need to use the real fully qualified domain name(FQDN)<samaccountname>@<FQDN> like This is called the implicit user principal name (UPN).

    4. A similar problem with UPN suffixes may also happen with a forest trust. If you have custom UPN suffixes (not matching a domain name in the forest), you need to register it on the forest. The local forest admin also has to enable the suffix, so the suffix can be used on computers in another forest across the forest trust.


    Best Regards,
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact
    Friday, June 3, 2016 2:48 AM