Fixing KDC Authentication Problems when upgrading your domain and forest functional level from 2003 to 2008 R2

We recently upgraded our Domain and Forest Functional Level from 2003 to 2008 R2, after a day or so I started having problems connecting to a number of 2008 R2 Hyper-V Virtual Machines. When attempting to connect I would receive the following error:
An Authentication Error Has Occurred. The Encryption Type Requested Is not supported by the KDC
At around the same time we also had one of our Exchange 2010 Transport Servers stop servicing clients, when I attempted to open the Exchange management console on the local server console ended with a HTTP server error status 500 and “Kerberos” authentication failed. So I decided to take a look through the event viewer to see what was up.

As part of Exchange there is an Active Directory Topology Service which will scan your environment for Active Directory Servers every 15 minutes or so, all of the exchange services rely on this service (if you ever have to restart all exchange services, simply restart the AD Topology Service). In the application event log I noticed the following error message:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=xxxx). Topology discovery failed, error 0×80040952 (LDAP_LOCAL_ERROR (Client-side internal error or bad LDAP message))….
There were also issues with the Exchange STORE service with the following two events:
Process STORE.EXE (PID=xxxx). All Global Catalog Servers in forest DC=xxx,DC=xx,DC=xx are not responding.
Process STORE.EXE (PID=xxxx). All Domain Controller Servers in use are not responding

The rather simple resolution to all this trouble is simply to restart the KERBEROS DISTRIBUTION KEY or KDC service on all Domain controllers. While simply restarting the Service will solve the problem, you’re probably better off just doing a proper restart after upgrading your functional levels, only from 2003 to 2008 / 2008 R2.

10 thoughts on “Fixing KDC Authentication Problems when upgrading your domain and forest functional level from 2003 to 2008 R2

  1. ITInfra says:

    We are in the process of migrating to exchange 2013. On of the step is to ensure that the domain functional level is at least windows 2003. However our present functional level is Windows 2000. We have already changed out all our Windows 2000 DCs to Windows 2008 DCs. Should there be any concerns? What are the best steps?

    • John says:

      You will probably just want check replication is healthy before proceeding and then restart your DCs after the raising of functional levels, apart from that should be painless.

  2. Hans says:

    thanks you very much for this information!
    We just changed the level a day ago and today people couldn’t connect to our remote apps…
    Restarting the service helped and saved me lots of troubleshooting!
    Thanks again!


  3. rod says:


    thanks for providing this information. Read this before raising the domain functional level. About 6 hours after raising I run into that issue and was able to solve it very fast by just restarting the KDC- Service on both GC servers Our Exchange server corresponding to.

    Our enviroment:
    2 DCs in First site 2008 R2
    4 Exchange server 2010 sp2
    Raise was from 2003 to 2008 R2

    The issue happens first on our Exchange CAS- Server.

    Br, rod

  4. jeff says:

    Thanks for this !, one question ?
    If I restart the KDC right after raising the domain functional level ( I raised the forest level first hope that was correct ?)
    will it prevent the issues ? or do I have to wait to get them the restart the services ?

    • John says:

      Give it a few minutes for DCs to replicate and become aware that the DFL has been raised then restart the service on all of your DCs.

  5. BobbyT says:

    After we upgraded the DFL from 2003 to 2008R2, it broke TACACS+ authentication and proxy authentication, both which go through the Cisco ACS server using PAP_ASCII protocol. It also broke our Tivoli Endpoint Manager (TEM) authentication to the AD (You install user accounts in the TEM and it proxies the authentication to AD via a service account). The ASA, which used RADIUS to authenticate to the AD used MS-CHAPv2 authentication – it did not have a problem. To solve the TEM problem, we deleted and readded the users accounts in the TEM. To solve the TACACS problem, we recycled the ACS service on the ACS server.

Leave a Reply