The future of old apps with Windows 10

  • [アーティクル]

The past is hard to let go of, let's be honest. In the IT world, there is a lot of truth to some of the old tools are also some of the best. You SCCM (or dare I still say SMS) guys should know this, for those who still use things like ccmclean instead of ccmsetup /uninstall still or SMS Installer.

One thing Windows has been great at over the years is keeping backwards compatibility with older applications, but those days are coming to an end, and quickly. For example, a moment of silence to any 16-bit app running on Windows 10 x64. You really don't want a single application (or small handful) holding you hostage from going to the next version of Windows, either.

So, to the problem statement: A customer was using a application suite they built in-house using 2 different compilers, in Visual Basic 6 and Visual Studio .NET 2008. When they ran the application making a call to the same SQL database, the VB6 app failed, but the VS.NET 2008 app worked. For those wondering or maybe not old enough to remember, Visual Basic 6 was released in January of 1999. I remember receiving my copy on my desk at work and had a giant smile from ear to ear that morning.

The failure they were experiencing was that all too familiar "Logon failed for NT AUTHORITY\ANONYMOUS LOGON". Well, this is easy, mysery solved - it's SPN entries in AD. Wrong, and not so fast.

Some items of note here: VB6 has been out of support for about a decade now, and although the VS.NET 2008 product is still supported, is soon slated for retirement. But, it is still supported for now. That would be as simple as moving the code to a newer version of Visual Studio. VB6, not so easy as the upgrading from VB6 to the newer Visual Studio isn't a "Load/Compile/Distribute scenario".

This "Anonymous Logon" issue is not a new by any means, and is caused when Service Principle Names (SPNs) are incorrectly configured in the environment due to a term called KCD or “Kerberos Constrained Delegation”. To further complicate troubleshooting, the older compiler was making a COM+ call to the database server. I was able to work around this issue by selecting “Trust this computer for delegation to specified services only” and “Use any authentication protocol”.

I found that by switching to this method (of any authentication protocol) allowed clients to connect to the server and authenticate, making the application work. There was another application that worked fine with using Kerberos only, therefore proving the SPNs were properly set. I also saw that through SQL Management Studio all connections made to the SQL server with the option of using any authentication protocol were using Kerberos, but without KCD.

What’s the difference, Kerberos is Kerberos, right?
When KCD is configured to use Kerberos only, the system performing the delegation (“SQLServer”) must possess a Kerberos service ticket from the delegated user (“ConnectingClient”) as evidence that it is acting on behalf of that user. By changing settings to the “use any authentication protocol”, Kerberos is still being used, but the security is lessened that the service ticket used from what is called Kerberos Services4User, or SFU. SFU provides protocol transition. In simpler terms: A client authenticates with a protocol other than Kerberos and then transitions to Kerberos, but does not use constrained delegation and is less secure.

The main impact to security in this method is that the delegating service is able to delegate an account without the direct involvement of the account owner. What this means is that on no certain terms are any promises or guarantees made to security of this account.

There are a few concerns with this workaround:

  • The workaround does work, however security is reduced.
  • If you are looking to replace or modernize an app to newer code (newer compiler like VB6 to VB.NET), then this may be acceptable solution if you are willing to take the security risks for now.
  • The only other way to fix this issue is to disable Credential Guard, which isn't recommended.
  • One thing to always keep in mind is to test future Windows 10 builds. In the future, this workaround as well as other security changes may prohibit old apps from working.

About Windows 10 and Security

Windows 10 was built with security in mind. I’ve seen many customers want to see a more secure and stable platform, and there have been many improvements made to Windows 10 to accommodate this, among the highlights:

  • Windows Defender SmartScreen helps prevent malicious applications from being downloaded
  • Credential Guard helps keep attackers from gaining access through Pass-the-Hash or Pass-the-Ticket attacks
  • Enterprise certificate pinning helps prevent man-in-the-middle attacks that leverage PKI
  • Device Guard helps keep a device from running malware or other untrusted apps
  • Windows Defender Antivirus, which helps keep devices free of viruses and other malware
  • Blocking of untrusted fonts helps prevent fonts from being used in elevation-of-privilege attacks
  • Memory protections help prevent malware from using memory manipulation techniques such as buffer overruns
  • UEFI Secure Boot helps protect the platform from bootkits and rootkits
  • Early Launch Antimalware (ELAM) helps protect the platform from rootkits disguised as drivers
  • Device Health Attestation helps prevent compromised devices from accessing an organization’s assets

With advancements to the security model in Windows come changes to how applications are developed and behave. Windows 10 really does change how applications are delivered in the sense that I warn software developers and those who distribute software and Windows to “expect something to break”. It’s not because of bad code or any intention to just make everything “not work”, but often security requirements in the OS leaves older coding techniques behind.

For every enterprise or organization, I suggest always keeping a small amount of testers from each department running the “next” version of your OS build to provide feedback on new applications and report things that may not work.

About Windows 10 and Credential Guard

The purpose of Credential Guard is to use virtualization based security to protect domain account Kerberos and NTLM credentials from theft by malicious software, and to isolate these secrets so that only privileged system software can access them. Credential Guard also protects logon session and Credential Manager credentials.

With Credential Guard enabled, it is no longer allowed to use Kerberos unconstrained delegation as it can allow attackers to extract Kerberos keys from the isolated Local Security Authority (LSA) process. Microsoft recommends using KCD instead.

The conclusion and ending...

I would encourage all developers to apply the concept of ”always looking ahead” when writing new code. You should look into having a newer build of Windows available to you in order to test functionality for the next release of the image, so you can have more assurance your apps are safe.

Keep in mind for testing you can use some of the newer features in Gen2 Hyper-V machines on Server 2016 and Windows 10 1607 and later. These include more modern security features such as Virtual TPM and Secure Boot. This will allow testing of features like Credential Guard and Bitlocker in a more contained environment.

A moment of silence to Visual Basic 6 as well. I became a MCSD in VB6 and wrote many apps with it. But, as much as it hurts, deploying anything that pre-dates Active Directory going forward is a bad idea.

— Easy link to my blog: https://aka.ms/leesteve —
If you like my blogs, please share it on social media and/or leave a comment.

Comments

  • Anonymous
    December 10, 2017
    Great in-depth article. Thanks!