Let me tell you a little story about a useful tool called Microsoft Secure Score and how one of it’s recommendations led to a crisis by killing off authentication for a Azure File Share…

The Story

A customer had been using Azure File Share for quite some time as a replacement for a little local NAS. All was good and well. All of the files lived happily in the cloud and no hardware to worry about. All is good! The few people that need access to this share just run a little script shich in turn stores some authentication details in Windows. This is done via the command “cmdkey”. Nothing special here! It even looks something like this:

cmdkey /add:targetname /user:username /pass:password

And then PowerShell can mount up the share. This might not be the BEST way to do it, but it will get the job done.

With best intentions

Until… a wild recommendation in Microsoft Secure Score appears! This is a score given by Microsoft based on a number of indicators showing your tenants security posture. Low score bad, high score good. The higher the score, the better your security is.

And security sometimes comes with a cost. It’s almost always a tradeoff between high usability with low security, and the other way around. A highly secure system will be less vulnerable and may not be as flexible.

Since I work for an MSP we manage a lot of tenants, and a lot of those customers have services from us where we continually tweak security settings to try our very best to have the high ground IF and WHEN the attackers come. This is an infinite mindset we have adopted.

What happened

So as a part of this we also harden the Windows devices that are managed by Intune. And in Windows we can do a lot of things, as disable stuff like storing credentials so no hackers can get to them and so on. Good, right? Well, what did I tell you about the Azure File Share? Right… we need access to not only store the credentials but also read them. So what happens when we tighten the grip a bit too much? We block them out of the file shares since they no longer can authenticate 🙂

Because we set this little bugger to be enabled by doing this:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"disabledomaincreds"=dword:00000001

This essentially disables the local credential store where the much needed credentials are stored. We logged in on one computer, changed it to (Disable):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"disabledomaincreds"=dword:00000000

And everything were smooth sailing again. PHEW!

What we learned

As it may have good intentions, security settings will at some point affect SOMETHING. Not every recommendation from Microsoft Secure Score is a hit. Sometimes it’s a miss. Not every customer notices the changes, but no customer is like the next one. Of about 50 customers we rolled out this change to, there were like two of them that got some sort of problems. Every change will introduce some kind of risk. And in this day and age, that’s a risk we are willing to take in the name of keeping our customers secure!

Luckily for us this was quite reversible and when we understood the problem, we could quickly deploy a fix because we knew what changes we were pushing.

Have you done something similiar? How did it go? Let me know in the comments 😀