Safely Using an Insecure SA Development Account

As a consultant, I’m sometimes a part of projects that do things I wouldn’t choose to do. Welcome to the real world, right? For example, on one project I worked on in the past, the connection string for an project used the “sa” account for sql server. Further, it was in the web.config file and that file was checked into source control. First, I’m not a big fan of connection strings in source control, and have already posted on an easier way. If nothing else, use “Integrated Security=SSPI” in the connection string, and then each developer uses his local windows account to assign permissions.

But I’m a consultant on this project, and I can’t dictate that change. Fine. So I just lived with it for a while. But it bothered me that anyone on the project, or ever on that project, was walking around with the same sa password, and the password policy file unchecked. Until I came up with a simple solution.

Rename sa, and put the password policy back in place. And then create a new user called sa, that only has the necessary privileges on that database. If you don’t have need of your sa account for other reasons, you could just reduce the permissions in this case. But I still wanted a sql login that had permissions to administrate the database. Usually, you would do that kind of management from a domain account, but I don’t run a domain since I’m in so many different locations, and I might need to manage remotely, hence a sql login.

Anyway, here are the steps:

1. Rename the sa user:

alter login sa with name = mynewsystemaccount

2. Restart your sql server

3. Choose a new password for sa, and check the policy is enforced. I did this with management studio, but you can use t-sql if you prefer:

alter login mynewsystemaccount with password='some strong new password here', 
      check_policy = on, check_expiration = off;

4. Create a new sa user with the previously insecure password, and only grant them the necessary permissions on the database for that development application.

“sa” is still an insecure account, and any other developer can run any command they want on that development database, but they can’t administrate your whole server. There are plenty of other ways to solve this, if you have an interesting one, post in the comments below.