Tuesday, May 15, 2018

Windows 10, Credential Guard and Linked Servers

Currently we are looking into upgrading the user desktops and laptops to Windows 10. During testing we ran into an issue using Linked Servers. Any time you attempted to run a query against a linked server you would get a Anonymous Logon error

On the machine we were attempting to run the query against there would be a similar error in the log:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Could not find a login matching the name provided.

Normally when I see the Anonymous logon error I immediately think SPN issue, but this error message is different than the one I normally see due to the addition of the "Could not find a login matching the name provided". Also, we were not having any issue running the same Linked server query from a windows 7 machine.

Credential Guard and Linked Servers

Credential Guard is new in Windows 10 and is a feature that aims to "isolate and harden key system and user secrets against compromise". Here are a few links to some Microsoft documentation if you want to read up on it

The third link gave us the information we needed to figure out what was happening in our environment. According to the article, Credential Guard will break applications if they require Kerberos unconstrained delegation. This means if you enable delegation for a service account and do not set it to use specified services only, then your linked server connections will fail when you are not connecting directly from the server (this is the classic double hop scenario).

If we look at the delegation page of a service account in active directory we can see the difference between constrained and unconstrained delegation. In our environment, we choose "Trust this user for delegation to any service". This is unconstrained delegation, the service account can act on behalf of another user to any server in our environment.

To change this to constrained delegation you select the radio button for "Trust this user for delegation to specified services only" but then you must create an entry for every host and service that the account can connect to.

This might be a valid solution if you run a shop with only a few servers and rarely add linked servers. If you are constantly building new servers and adding linked servers to the environment this becomes unmanageable. Especially if you are in an environment where the people who create linked servers and the people who are in charge of creating SPNs and configuring delegation are not part of the same team.

Solutions?

So how do we get around this? I mentioned using constrained delegation which might be suitable for some people but even on the MSDN post that I mentioned at the beginning of the article, the poster was only able to get that to work on 9 out of his 12 servers. I also read that this solution might not work properly with availability group listener names, cluster names or CNAMES but I have not had the opportunity to test these out.

There was also mention, in the MSDN post, of setting up a priviledged access workstation or PAW (see this link), but users are not going to want to have to connect to a secondary workstation every time they want to use SSMS.

Another option is to disable Credential Guard (see this link). This is probably the work around that most people will start with but you will have to work with your Security team to see if they are willing to disable this built-in protection long term.

I was surprised to only find a few posts in internet forums dealing with this as windows 10 has been out for a few years and while linked servers are generally frowned on they are being used elsewhere.

Has anyone else run into this issue? Post in the comments if you have any additional solutions.