Built in accounts are both a help and and a hindrance. Years ago I was working on a SQL Server 4.2 system, where I was an administrator. The database was very unstable, and we were trying to determine if it was something being done by the application or the platform itself. While I was a local administrator, I couldn't access other, remote SQL 4.2 instances at other locations for our company. Since we ran the same code (supposedly), we wanted to test how various parts of the system performed between the two systems.

One late night, while actually reading the manual, I discovered the "probe" account, which was a built in account for early Sybase/SQL Server versions. I used this to query remote instance and compare settings and performance. This helped us narrow down the the problems, though it wasn't the way I would have wanted the system to work.

Any built in account allows some ease of getting an application working, but it also provides a known backdoor to your system if it is not properly secured. The "sa" account is one of those well known accounts for SQL Server that can cause issues. This account has complete control over SQL Server, and even though it can be renamed, simple queries can discover what the new name is and mount attacks. This is one reason why many people like to only enable Windows Authorization, preventing anyone from logging in with this account?

However, is this enough? I don't think so, as a simple administration action could enable mixed mode authentication. I would say that everyone should set a long, random password for "sa" on all instances, but what do most of you think? Do you provide any other protections for the sa account? Let us know today.