Security on Andy M Mallon - AM²

How to revoke SA permissions that seem to be "stuck" to a login?

Wed, 02 Feb 2022 13:29:23 -0500

Question

Apologies in advance if I don't use some terminology correctly here. I'm not a DBA but I've been temporarily forced into the role.

I've inherited an application that runs on SQL Server 2016 Enterprise - one instance for PROD and another for TEST. These instances are set up in an "always on" configuration, so I have one Availability Group for PROD and one for TEST. Each Availability Group has two servers in it. Each instance has multiple databases in it, but only one DB in each instance is actually used by the application - the others look to have been created for testing purposes. I'm only mentioning that there are other DBs just in case it might be relevant in some way that I'm not aware of.

Can changing database owner affect permissions or role memberships?

Mon, 30 Mar 2020 21:23:49 -0400

Question

A couple years ago we ran into a situation where we were changing the database owner from a DBA's login to sa, and immediately thereafter we received a complaint that the service login (which was NOT the DBA's login) no longer had access to the database. On checking, the service login had indeed lost it's role memberships.

What the heck is the dbcreator role?

Thu, 19 Dec 2019 07:30:14 -0500

Microsoft docs defines the dbcreator role as:

Members of the dbcreator fixed server role can create, alter, drop, and restore any database.

But what specific permissions are actually included in that role? If we scroll down in the docs just a little, we’ll see a diagram that tells us that dbcreator grants two permissions:

Testing as another user...without their password

Wed, 18 Dec 2019 11:50:35 -0500

This guy doesn't have Elvis's password and is still able to impersonate him. As a DBA or SQL Developer, you've surely encountered a scenario where something worked for you, but not for another user. DBAs usually are part of the sysadmin role, or have a collection of powerful permissions. If I run code as myself, I will *never* have permissions problems because my account is sysadmin. If I want to ensure permissions are correct, I need to run the code as the less-privileged account.

Can you try now?

I honestly don’t think there is a more frustrating experience than getting into the feedback loop of making a permission change, and asking the user if it works, and when it doesn’t work, you try another change, and ask them to try again, and when it doesn’t work, you try another change, and ask them to try again, and when it doesn’t work, you try another change, and ask them to try again, and when it doesn’t work, you try another change, and ask them to try again…

Why Best Practices Exist: Learning from others' mistakes

Wed, 28 Jun 2017 20:00:11 -0400

The latest malware to make the headlines is really interesting to me. It’s a ransomware worm called Petya. Ransomware is particularly interesting to me as a DBA, because DBAs are responsible for keeping data safe, and ransomware is specifically designed to destroy your data. I’m not a security expert, and I don’t even pretend I am–but security is something we should all be interested in.

Big security loophole with SQL Logins

Thu, 30 Apr 2015 16:46:00 -0400

Aaron Bertrand (twitter|blog) recently blogged asking for help to fix a big security loophole. I read the post then, but it was only this morning that I finally got around to REALLY looking at it, thinking about it, and testing it out for myself.

Aaron can do a much better job at describing the issue than I can, so I urge you to read his blog post on the topic, or his Stack Exchange answer on the topic. Then, go up-vote the Connect item he filed.

I’ll do my best to give a quick summary of the issue here, if you don’t want to read Aaron’s full version:

Microsoft’s documentation explains that sys.logins.is_policy_checked means “Password policy is checked.” Bill Clinton was right, “It depends upon what the meaning of the word ‘is’ is."
This use of “is” in this terse definition could have two meanings:

As a descriptor of what has happened: “The password policy has been checked for this login."
As an instruction of what SQL Server should do in the future: “The password policy will be checked for this login."

(If you aren’t already hung-up thinking about Bill Clinton, I probably just gave you a flashback to a grammar school teacher grilling you on conjugations of the verb “to be.”)

As it turns out, the correct meaning of this column is actually #2: “The password policy will be checked for this login.” Most people (myself included) wrongly expect this column to have the other meaning.

Further, there is no DMV that describes #1: “The password policy has been checked for this login.” If an auditor asks you to prove that all SQL logins meet your password policy, there is no way to prove that.

Yes, I can use processes to manage my own environment to a point where I am confident that the passwords are strong. However, if I were an auditor, I would demand proof the DBA wasn’t skirting the rules by altering the flag before an audit (and flipping it back later).

So, I join in Aaron’s call-to-action. Go up-vote the Connect item and get this security loophole fixed.