Mastodawn

@VladDBA @dbatools
> In this case, the solution is to just tell dbatools to trust the server’s certificate

This might be the simple way forward but it isn’t a great thing to do IMO. You wouldn’t recommend people blindly trust expired or invalid certificates whole browsing the internet. Have a talk to your DB admins (if that isn’t yourself) about setting up a proper certificate that is trusted.

@jborean @dbatools
So the key part there being "in this case", meaning on the instance residing on my PC where I'm not going to set up an encrypted connection to SQL Server unless I want to test something specific.

Second, not all shops have encrypted connections configured and enabled for SQL Server.

Another thing is that that's a bit of a forced comparison - connecting to a SQL Server instance in your company's intranet isn't the same thing as browsing some iffy website on the internet.

> So the key part there being "in this case", meaning on the instance residing on my PC where I'm not going to set up an encrypted connection to SQL Server unless I want to test something specific.

Trouble with this advice is that now people read these blogs and think it will be ok to just ignore the certificate problems. If you are going to document it then you should explicitly state why you did and why it's probably not a good idea.

> So the key part there being "in this case", meaning on the instance residing on my PC where I'm not going to set up an encrypted connection to SQL Server unless I want to test something specific.

> Another thing is that that's a bit of a forced comparison - connecting to a SQL Server instance in your company's intranet isn't the same thing as browsing some iffy website on the internet.

I wouldn't say so. By this logic you should say internal sites or intranets inside a companies network don't need HTTPS. It is crucial for services to be able to prove they are who the client thinks it is. Failing to do so opens yourself up to man in the middle attacks.

@jborean @dbatools
Someone MITM-ing a SQL Server instance is very unlikely since it doesn't really work the same way as a site, where you can just log the request containing the credentials.
Even more so if Windows authentication is used, which is the case in most shops using AD/Entra, since you're not sending your username and password, and SQL Server has to validate with the DC that you are you.

An attacker would have an easier time kerberoasting an SPN.

Anyway, I've updated the post.

> Someone MITM-ing a SQL Server instance is very unlikely since it doesn't really work the same way as a site

It works exactly the same way. Being a MITM means the attacker can intercept and modify the requests in any way they want. They can relay the tokens used as well. I would argue being a SQL server would make it a more enticing target due to the sensitive data that can be exchanged.

Kerberos is a useful way to authenticate the server but there are many scenarios in which it cannot be used; SQL credentials, IP address used, misconfigured SPN. Unless you've disabled NTLM auth altogether and only rely on Windows auth then you shouldn't just rely on it solely.

@jborean @dbatools
Your last reply sounds like you might not have understood my reply. But it isn't relevant since I'm not going to continue this back&forth.
Most companies running SQL Server on-prem or on cloud VMs don't yet have encrypted connections configured.
If a DBA wants to use dbatools without having to set up encryption on all of their instances, because management says it isn't a priority yet, they should be able to do so, hence the post.
1/2