KDC Authentication problems with 2003 to 2008 domain functional level

Recently I have had problems connecting to the console on a number of 2008 R2 Hyper-v guest virtual machines.  The error was “An Authentication Error Has Occurred.  The Encryption Type Requested Is not supported by the KDC” while I have also had a single Exchange 2010 server fail with the following event IDs: 2102, 2103, 2114, 9106 all reporting LDAP problems, non-responding domain controllers and global catalogs:

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1696). Topology discovery failed, error 0×80040952 (LDAP_LOCAL_ERROR (Client-side internal error or bad LDAP message)). Look up the Lightweight Directory Access Protocol (LDAP) error code specified in the event description. To do this, use Microsoft Knowledge Base article 218185, “Microsoft LDAP Error Codes.” Use the information in that article to learn more about the cause and resolution to this error. Use the Ping or PathPing command-line tools to test network connectivity to local domain controllers.

Process STORE.EXE (PID=4084). All Global Catalog Servers in forest DC=xxx,DC=xx,DC=xx are not responding:

Process STORE.EXE (PID=4084). All Domain Controller Servers in use are not responding:

Attempting to open the Exchange management console on the local server console ended with a  HTTP server error status 500 and “Kerberos” authentication failed.

The Exchange server was able to ping and resolve all DNS names correctly and the problem went away on restarting only to re-occur in 24 hours or so.

The rather simple resolution in the end turned out to be restarting the “KERBEROS DISTRIBUTION KEY (KDC) service” on all Domain controllers.  While Restarting all Domain controllers in their entirety is also a good idea it isn’t always possible (or desirable) on a live production environment.

27 Replies to “KDC Authentication problems with 2003 to 2008 domain functional level”

  1. THANK YOU! I just ran into this problem when I bumped our Domain Functional Level from 2003 to 2008 R2. One of our Exchange Servers starting having the LDAP errors and bombed out, just like you mentioned. I restarted the Box, only to have the problem come back in about 10 hours. Your solution worked great! I didn’t even have to restart Exchange, it just came right back up. I noticed you had just posted this entry, is your system still functional? I’m hoping this is the last of this issue. 🙂

  2. Just to be clear, you experienced this issue right after you raised the domain functional level to 2008? And since you didn’t reboot the dc (or all the DC’s) the KDC service wasn’t serving out Kerberos information.

    Did you have any other issues with ‘legacy’ applications using Kerberos authentication?

    We experienced the same issue a few days ago when the Domain functional level was upgraded to 2008 r2. We had issues with a reporting software we use that uses Kerberos authentication as well.

    As a side note/question, had the domain in use ever had an authorative restore done on it? I know this does something to the krbtgt service account…and our domain had years ago. I don’t know if this made the issue more rare than above or if people just automatically reboot their DC’s after a domain level upgrade.

  3. Hi Nick, The issue didn’t occur instantly after the domain functional level was raised, maybe 10-12 hours after.

    We had a few issues with Mac computers occasionally failing to authenticate which was also resolved when the KDC service was restarted.

    As far as I am aware there has not been an authoritative restore on this domain, but I can’t be 100% on that.

  4. For me, the issue occured literaly within about 30 minutes of changing the Functional Level. It only affected one of our Exchange servers, the one with Mailboxes on it. The HUB/CAS server didn’t seem to have any issues, except for the fact that it wasn’t able to talk to the MB server properly anymore. I have not had the issue re-occur once the KDC services were restarted. I’ve never had to do an Authoritative Restore on our Domain before either.

  5. I’ve also seen this, thanks to a colleague who found this posting. If the affected Exchange server is a DAG member, it may log a DCOM error in the System log trying to access the witness server, if one is configured.

  6. This issue plagued us for a week after raising the Domain Functional level from 2003 to 2008R2: Exch2010 server logged events that no DC’s were available (even though all 6 DC’s were pingable); Exch client connections failed, and EMC errored out; RDP connections failed w/Kerberos errors. Rebooting the DC’s didn’t help, but restarting the Kerberos service seems to have done the trick: 24 hours now of solid, stable Exchange. Crossing my fingers that this “fix” is permanent… thanks, Robin!

  7. Hi, I just had the exact same issue happen… this article saved me alot of grief. Thank you!

    We just raised our domain function level from 2003 to 2008R2 two days ago and everything seemed ok for awhile. After about a day, I had the same type of log entries happening on our exchange transport server and eventually, the exchange address book and exchange transport service went offline and wouldn’t start back up. After restarting all of our domain controller Kerberos Key Distribution Services, those log entries stopped and everything returned to normal and those stopped services started just fine.

  8. This comments section is becoming my go to place for good solid info. If any of you guys want to help, I’m a moderator over at EF (click my name if you like) and I am always telling the admins about this place and the caliber of support knowledge just hanging around. I think you guys would be a great fit over there as well whenever you have time. Thanks, and hope to see you there some time.

  9. Hello, I am having this issue every time that I restart my servers on a VMware VSphere 5 environment. I haven’t raised domain function level or made any change on Exchange 2010. Exchange was working fine for a year. If I restart the KDC service and the MS Exchange Topology service it works fine until I restart the server again and I have to do the same procedure. What could be the problem? Any ideas on how to fix it for good?
    Thank you

  10. After we added 2008R2 DC to 2003 domain (without rising functional level to 2008)our oracle-based applications with SSO stoped working on 2008DC. They worked only on 2003 DCs. One of the solutions is reset password for proxy account for oracle application on 2008DC. Its necessary because 2008 don’t understand DES cryptographic algorithms on accounts from 2003. Afterd we did it, oracle SSO stopped working even on 2003DCs. To reverse this error change password once again but on 2003 DC!!! generate new keytab for proxy user on 2008 (change it in oracle configuracion )and it will work only on 2008DC.

  11. Thank you!! I bumped our domain functional level from 2003 to 2008 and everything was fine….at first.

    24 hours later we noticed webmail (Exchange 2007) stopped working, the HUB server was throwing errors that it couldn’t find a Global Catalogue server. I restarted the “Kerberos Key Distribution Center” on all 4 Domain Controllers and everything came up almost right away.


  12. Exact same issue after raising our functional level from 2003 to 2008R2. It took a few days to manifest, but the logs on the Exchange server did start having errors shortly have the change. Exchange could not find ANY Global Catalog servers in it’s site, yet I could connect to and search GC’s from the Exchange server. None of the DC’s reported any errors from DCDiag. DNS was fine, ping was fine. I rebooted the DC’s, the problem was resolved.

  13. Same issue, same symptoms, same solution.

    Interestingly, I had an MS tech help me with this…and he linked to this article. Not an MS article…this one.

  14. I’m about to raise mine from 2003 to 2012. I’m hoping if I preemptively restart the service instantly I will not see any issues. I have an exchange 2013 DAG running, and with all the cumulative updates and quirks it has shown i do not want my clients to experience any more issues.

  15. Thanks a bunch for this. I raised our function level from 2003 to 2008 and about 24 hours later our CRM system started to behave wierd, some could log on and others couldnt, same errors as the rest of you all in the event viewer, We have a total of 8 DCs. I restarted Kerberos Key service on all of them. Here’s hoping for a calm day at the office tomorrow when I can sit back, relax and enjoy my coffee.

  16. Thanks a bunch for this!! Our problems started happening about 2-3 days after the functional level was raised. We started seeing issues with our Oracle/SAP servers not being able to authenticate via Kerberos. Restart the boxes and 24 hours later the issue was back.

    Then the issue started to plague our exchange boxes(Hub/CAS/MB) and even moved on to our Lync servers. Randomly throughout the day systems would just go down with Kerberos / AD issues.

    Restarted the KDC service on both..BOOM! problems disappeared without any further action.

  17. Hi,

    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

  18. So will restarting the “KERBEROS DISTRIBUTION KEY (KDC) service” right after raising the funcitional on all Domain controllers Prevent the Issue from occurring at all ?

  19. Once again very useful indeed!
    The domain functional level was raised several months ago in our scenario but restarting the KDC on all DC’s and the Exchange System Attendant resolved the issue

  20. Raising from domain/forest functional level 2003 to 2008 R2 took down the SSO setup we had with SAP – no one could log into SAP (ERP/CRM). Restarting the KDC service fixed it instantly. Thank you!

  21. After raising domain and forest functional levels from 2003 to Server 2008 R2 we started to get a few Event ID 15 on the domain controllers for a couple of service accounts. Restarted KDC service on all the domain controllers and still had a couple of Event ID 15’s come through. To be safe, we restarted all the domain controllers since we were in a maintenance window. No more Event ID 15’s yet, but still monitoring as it’s only been one hour so far. Appreciate this article and the comments posted too.

  22. Thank you for posting this article — it’s refreshing to find a solid answer to an unusual issue. After raising domain and forest functional levels from 2003 to 2008 R2, the first symptom we encountered, after about 30 hours was the inability to form a Remote Desktop connection to a couple of servers, one running Windows Server 2012 Standard and another running Windows Storage Server 2012 R2 Standard. From Windows 8.1, the error received after providing credentials for the Remote Desktop connection was ““An authentication error has occurred (Code 0x80004005)”. From Windows Server 2008 R2, however, the error was “An authentication error has occurred. The encryption type requested is not supported by the KDC”.

    Restarting the “Kerberos Key Distribution Center” service on all Domain Controllers instantly resolved the issue with Remote Desktop, and probably averted issues in the near future with Microsoft Exchange.

  23. Dears,

    one of our exchange server System attendant service is not happening in windows 2003 functional level after introduced 2008 R2 DC in our environment, Please help we are in hectic position now, past 30 hours our exchange our is not happening.

  24. THANK YOU for this article!!!
    We raised the FFL this morning and I am glad I found this article before throwing the switch. A few minutes after the upgrade, I restarted the KDC service on all DC’s in the MSX site as well as remote sites. I didn’t want to wait for trouble.
    I have checked the MSX logs and can see they are all logging Event ID 2080 and listing the in-site and out-of-site DC’s/GC’s as being online. Presumably this means they will continue working as expected.
    Thanks again!!! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.