Solution:

If you are seeing this error, go to ALL of you Domain Controllers and restart the KERBEROS DISTRIBUTION KEY (KDC) service.  I have done this on live DC’s without any errors or disruption in service.

 

Details:

I found the An Authentication Error Has Occured.  The Encryption Type Requested Is not Supported by the KDC, intermittantly when trying to RDP to various Server 2008 and R2 servers.

Last week, I moved the Forest and Domain functional level to 2008 (from 2003) and a few days later I started seeing problems with my Exchange 2007 SP2 Server (on Hyper-V Server 2008 R1 on a 2008 R1 host).  Specifically users were not able to connect to Exchange via Outlook, ActiveSync or BBerry Ent. Server 5 (which is on the same VM).  I spent MANY hours chasing DNS, GPolicy, NIC and other settings but found that the problem went away after a reboot… that was on Friday.

The next day (Saturday), I had the same problem with Exchange.  I found that if I ran GPUPDATE, it would error out and the event viewer would record:

error code 82 windows could not authenticate to the active directory service on a domain controller (LDAP Bind function call failed)

I also found that I could not get Exchange’s TRANSPORT SERVICE to restart.  It would stop but fail to start.

Most of the articles I read said this related to DNS problems, but I am confident in my DNS config:

– all 4 DC’s point to themselves for DNS and one other DC for secondary DNS
– I can resolve host names throughout the network, including all of the DC’s and the server in question
– REPADMIN /SHOWREPL <DC-HOSTNAME> shows expected results
– DCDIAG and DCDIAG /FIX provide expected results
– I can use \\host-name\ of each DC and see the SYSVOL folder
– The Exchange 2007 Server 2008 problem server is NOT a DC; just a member server.
– there is only ONE subnet and one physical location/site.

After a while I was able to get GPUPDATE to function without error and after restarting all of the Exchange and Blackberry services, all appeared well.  I made several small changes, but believe none of them resolved the issue, I think it was simply time that resolved this.

I ran Windows Updates on this Exchange 2007 Server 2008 R1 VM and rebooted without problem but the RDP issue remains.

When I Remote Desktop (RDP) to the server (from Win 7, or Server 2008 or even RDP from the host Server 2008 r2 server) but I can still log into the Exchange server via the Hyper-V console.

On the off chance this DC was a problem, I set the Exchange Server 08 VM in question to use DNS from two other DC’s, but that did not resolve the issue.

 

For more simple information on this KDC error, you find these references useful:

http://blogs.technet.com/b/ad/archive/2007/11/02/server-2008-and-windows-vista-encryption-better-together.aspx

http://blogs.msdn.com/b/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx

 


20 Comments

Randy Spangler · August 25, 2015 at 9:05 pm

We have two 2012R2 Hyper-V hosts replicating from one to the other. Today I inadvertently violated the cardinal rule: “Never make more than one change at a time.”

I had to replace a UPS in my NOC, so I shut down four servers, one of which was my Hyper-V replication target. One of the servers kicked into that “Applying 1 of 98 updates” and it literally took 5 hours to finish. During that time, I raised the Domain Function Level on the main DC from 2003 to 2008R2 (I guess I was bored.)

After I brought the rack back up (after swapping the UPS), I noticed that replication had broken. I searched a number of event log errors, but none worked until I found this page.

My replica target had the following 29212 Event ID “Hyper-V failed to authenticate the primary server using Kerberos authentication. Error: The I/O operation has been aborted because of either a thread exit or an application request. (0x800703E3)”

I promptly opened both of my DCs and restarted the KDC service on each. BAM! That was all it took.

Thanks a million!

Randy

Greg · July 24, 2015 at 2:57 pm

Thank you this resolved the problem after a recent AD functional level raise.

Leave a Reply to Greg Cancel reply

Avatar placeholder

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