SQL Server Performance

Using the SA Account

Discussion in 'EditorsBlog' started by shanetasker, Sep 26, 2008.

  1. shanetasker New Member

    James Luetkehoelter recently wrote an interesting blog post that was an open letter to vendors pleading them not to use the SQL Server sa account. I agree with James's sentiments that there is no reason for an application to use the sa account. However, I think that until more organisations start to include a clause in their development contracts that stipulates that the application must connect with an account other than sa, vendors will continue to develop applications that rely on the sa account. There are countless third-party applications that not only connect using the sa account but also have a blank password.
    Although vendors continue to follow the practice of using the sa account I don't think they are 100% to blame. If you think of the Windows world, typically system administrators no longer use the administrator account and they ensure that their accounts are no longer a member of domain administrators. However, when I think of the SQL Server world, if I had a dollar for every time that I had heard someone ask what the as password was so they could login, I would be a very rich man. I think that database administrators should lead by example by not using the sa account, only then can we expect that vendors do not use the sa account.
    - Peter Ward
  2. AngryDBA New Member

    I makes me fume that there are applications on sale from major vendors who simply don't know or won't tell DBAs what permissions are actually needed.I can understand it (but not approve it) from small mickey mouse vendors but when you are talking about 6 figure price tags there is no excuse.I work on one system that needs sysadmin privileges to performs certain functions. For the rest of the time it can be locked down to read/write permissions on tables.There are others that need elevated privileges to run obscure and unsupported database commmands. In SQL Server this will be setting trace flags on and off before performing tasks.Lets face it, basic security in SQL Server isn't hard.Set a database role per audience, grant only those permissions necessary to each role, make users or preferably Windows security groups defining the audience members of that role.The comment that sticks out most for me was made by a aging VME programmer. When you buy an expensive system you are simply buying a bigger bug list.

Share This Page