Always sa

James Anderson rails on inappropriate sa account usage:

I can already hear managers saying:

If you don’t trust your employees, why employ them in the first place?

Well there is the whole accidental damage thing. I guess you could cover that by having a good backup\restore process (if your RTO and RPO permitted the downtime) but don’t expect to pass any security audits coming your way. Hint: your clients wont like this.

Plus, supposing everybody knows the sa account, there’s no way to know who accidentally(?) dropped the customer database.

Related Posts

TempDB Encryption With TDE

Arun Sirpal points out an oddity in sys.databases: If you query sys.databases, such as: SELECT is_encrypted,name,user_access_desc FROM sys.databases WHERE database_id = 2 OR database_id = 7 It “might” throw you off. Would you not expect to see is_encrypted set to 1 for TempDB? I thought I remembered earlier editions of SQL Server showing is_encrypted = […]

Read More

Linked Servers And The Kerberos Double-Hop Problem

Jana Sattainathan shows how to set up Kerberos pass-through when dealing with linked servers: Let us say you have SQLServer1 and you want to setup a linked server to SQLServer2 using “pass-through authentication”, a double-hop happens as explain in the article below. Basically, the first hop is when the user authenticates to SQLServer1 and the […]

Read More

Categories

March 2017
MTWTFSS
« Feb Apr »
 12345
6789101112
13141516171819
20212223242526
2728293031