Share via

Service fails to start and logs ERROR_DOWNGRADE_DETECTED in its log, on a Windows Server 2008 R2 based system

  • Article

Microsoft Support is comprised of separate teams, each specialized in a few areas, so our customers get the highest level of support. The moment a case is logged, the process of routing it to the correct team starts. Nonetheless, every so often we get an issue that ,try as hard as we may, eludes our attempts to classify it correctly. And these issues are the ones that make you think out of the proverbial “box”.

In this instance, a Windows Server 2003 SP2 based system was upgraded to Windows Server 2008 R2. The sole purpose of this server was to run an LOB (line-of-business) application installed as a service. Before the upgrade, the service was operating normally, without any errors. However, now, it failed to start and logged these errors in its log file:

ERROR_DOWNGRADE_DETECTED

Unable to get information about file XXXX using FindFirstFile. Operating system error message: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

From the log file, we could also see that this error was being returned by Windows API calls which were made to read the service’s profile information from a file on a UNC path.

Normally, if a third party service fails to start, we would ask the customer to contact the vendor of the application, but in this case, the vendor wasn’t able to offer any assistance. So it was Microsoft Support or Bust.

Our first hint was that the server had been upgraded. The second was in the error message itself. Put both the hints together and it’s fairly easy to deduce that there’s something in the mix that may no longer be supported or enabled on Windows Server 2008 R2. A simultaneous network trace showed that Kerberos preauthentication was required, but not being done:

292 4:46:54 PM 10/25/2010 11.3722179 XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX KerberosV5 KerberosV5:KRB_ERROR - KDC_ERR_PREAUTH_REQUIRED (25) {TCP:26, IPv4:25}

We then turned our attention to the service account under which the third part service was running. Looking at its properties, one particular setting stood out in that I had never seen that enabled on any other Active Directory account previously:

Capture

A quick search located this KB Article. The title itself tells us why the issue is occurring.

The security principals and the services that use only DES encryption for Kerberos authentication are incompatible with the default settings on a computer that is running Windows 7 or Windows Server 2008 R2
https://support.microsoft.com/kb/977321

Based on the third party service requirements, you can either follow the steps in the article to enable DES encryption types on your Windows Server 2008 R2 based systems or simply uncheck the “Use DES encryption types for this account” checkbox on the service account.

We chose to uncheck the setting on the service account and voila! Another issue bites the dust.