Restrict the usage of a SQL Server Authenticated Application Id

Kenneth Fisher, 2017-12-18 (first published: 2017-12-06)

SQL Server login ids may not be the most secure thing in the world but they are likely to be around for quite a while and one of the more common uses of them is as an application id. An application uses a SQL Server id to connect to SQL and then controls its own security internally. The problem comes in when developers decide “Hey, I have the password to the app id, it has way more permissions in the database than I do. I’ll just use it.” So why is that a problem? Well, here are a few examples:

  • Clear text passwords. There are ways to send an encrypted password to SQL but if the developer is doing something like this they probably aren’t using them.
  • Lack of clear accountability. There is no way to know for certain who is using the id. It could be anyone.
  • Permissions are controlled for a reason. This developer is using permissions not properly granted to them, possibly causing a data breach through a lack of understanding of why these procedures are in place. Heck, they could be the data breach themselves. It wouldn’t be the first time an employee has stolen data.
  • Avoiding being accused of stealing data. Guess what, if you have access to this account and data is stolen using it, you are a suspect. No one want’s that unless it’s unavoidable right?
  • Not to mention that SQL Authentication is just less secure to begin with.


Anyone of these would cause you to fail a security audit. All of them together? Not good.

So how do we fix it? Well, the best possible method is to not give your developers the password. Use config files containing an encrypted copy of the password and you can dramatically limit knowledge of the password. However, that isn’t necessarily a quick or easy solution (modifying the app to use a config file at all for example). So what to do in the meantime?

The simplest thing to do is to create a logon trigger to control where this account can come from. Before we start if you are going to use a logon trigger make sure you know how to log in and disable it if there are any mistakes.

USE master
CREATE TRIGGER [Control_AppLogin] 
	DECLARE @error nvarchar(150);
	-- Check for the app login name.
	IF ORIGINAL_LOGIN() = 'test_app_login'
        AND (
			-- Check that the application is Management Studio.
			APP_NAME() = 'Microsoft SQL Server Management Studio - Query'
			-- Make sure that the connection is coming from the application server
			OR HOST_NAME() <> 'ApplicationServerName'
		SET @error = HOST_NAME() + N' attempted to login in using ' + ORIGINAL_LOGIN() + ' from Management Studio.' ;
		RAISERROR (@error, 25, 1) WITH LOG;

Note: The same trigger could hit several app ids at once, multiple applications etc. Here I’m hitting one login and I’m being pretty specific about the application name (although it does appear the object explorer uses the same name). I’m also saying that all connections have to come from a specific machine (the application server).

The downside here is that you can fairly easily pretend you are coming in through a different application or even a different machine. Heck, the way things are set up you could just use Excel from the application machine to access the data. The upside is that most people wouldn’t bother even if they did know how. The problem is, this comes under the heading of “security by obscurity” which really isn’t. It’s going to help prevent accidental issues but not necessarily intentional ones. Which is why the top two methods are Use Windows Authentication and if for some reason that isn’t possible Minimize the number of people who have access to the password.





Related content

Database Mirroring FAQ: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup?

Question: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? This question was sent to me via email. My reply follows. Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? Databases to be mirrored are currently running on 2005 SQL instances but will be upgraded to 2008 SQL in the near future.

Robert Davis


1,567 reads

Networking – Part 4

You may want to read Part 1 , Part 2 , and Part 3 before continuing. This time around I’d like to talk about social networking. We’ll start with social networking. Facebook, MySpace, and Twitter are all good examples of using technology to let…

Andy Warren


1,530 reads

Speaking at Community Events – More Thoughts

Last week I posted Speaking at Community Events – Time to Raise the Bar?, a first cut at talking about to what degree we should require experience for speakers at events like SQLSaturday as well as when it might be appropriate to add additional focus/limitations on the presentations that are accepted. I’ve got a few more thoughts on the topic this week, and I look forward to your comments.

Andy Warren


360 reads