July 30, 2014 at 10:48 pm
Comments posted to this topic are about the item Spackle: Making sure you can connect to the DAC
Kenneth FisherI was once offered a wizards hat but it got in the way of my dunce cap.--------------------------------------------------------------------------------For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/[/url]For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/[/url]Link to my Blog Post --> www.SQLStudies.com[/url]
July 31, 2014 at 7:01 am
Would there be any security concerns with allowing remote admin connections? Seems like it would be ok as long as you have your sysadmin logins controlled appropriately.
Be still, and know that I am God - Psalm 46:10
July 31, 2014 at 7:33 am
Really the DAC doesn't really add any security implications. Only sysadmins can connect and if you are a sysadmin you have complete control of the instance anyway. The only thing you can do in the DAC that you can't in a regular connection is view the system tables. This can give you a little bit of extra information (the password hash for a contained user for example) but nothing that is all that big a deal if you are a sysadmin already.
That being said, you still want to make sure your sysadmins are under control 🙂
Kenneth FisherI was once offered a wizards hat but it got in the way of my dunce cap.--------------------------------------------------------------------------------For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/[/url]For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/[/url]Link to my Blog Post --> www.SQLStudies.com[/url]
April 24, 2015 at 8:41 am
Actually there are a couple implications to using DAC that a person may want to consider.
When logging in via DAC, any login trigger you might be using to audit or otherwise control access will be bypassed.
If you have auditing turned on and are using the 'Fail operation on audit failure' feature the DAC may be your only way to get in if your attempt to connect is being rejected due to an audit problem.
These are both reasons to turn it on and reasons to leave it off depending on your situation. If a login trigger fails the login will be denied, even to SA, but since the trigger is bypassed on the DAC you can still get in to fix it. The same goes for problems with server level auditing.
You might have other auditing around use of RDP to access your servers and therefore use of DAC can be indirectly monitored with those controls whereas, if remote DAC is allowed, anyone who relies solely on a login trigger will not see the login. Anyone who relies on instance auditing will always see the login unless there is a problem logging the attempt. Via the DAC the attempt will succeed even if it might otherwise fail using a normal connection.
If your server is so pegged that you can't RDP but remote DAC is enabled, since the DAC has a dedicated thread you can always get in if remote DAC is enabled.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply