Great Plains SA Choices
November 5, 2000
Someone Actually Thought This Through
I wrote a rant on the "sa" password a couple weeks ago and got quite a bit of feedback. One of the items was a response from Great Plains Software, which was mentioned in the article as having poorly designed their software to use the "sa" account. What follows is the response that I was sent from Ross Hillier at Great Plains.
Great Plains Explanation of It's Use of the "sa" Account
Thank you for your efforts to make our Dynamics and Enterprise products better. However, I do believe that your criticisms are founded on some incorrect information. I would like to take an opportunity to correct this inaccuracy. If this information was incorrectly communicated to you by other members of our Great Plains' team, then I would like to apologize on their behalf.
Great Plains has two products which utilize Microsoft SQL Server: Great Plains Dynamics for SQL Server and Great Plains eEnterprise. Contrary to your assertion, neither of these products requires access to the sa login for adding users to the accounting system. (Note the usage of "requires". Both of our products have the option of using the sa account to simplify the process of adding users, but neither product "requires" usage of sa).
Great Plains has over five thousand businesses using our two SQL Server based products. As you might imagine, these customers have a vast range of skills. Some of these users are sophisticated and knowledgeable experts on SQL Server like yourself. However, some of our customers' knowledge is focused more along accounting lines, and sometimes their detailed knowledge of SQL Server is not at your level.
To meet the needs of all our customers, we actually support two methods for adding users to the system. One method is targeted at sophisticated users like yourself (which does not require use of the sa account), and the other method is targeted at less SQL Server-savvy users. This second method does utilize the sa account.
Use of the System Administrator account.
For those customers who have a more advanced knowledge of SQL Server, they have the option of "unchecking" these two options within eEnterprise setup. When these options are unchecked the process of adding users is now a two-step process:
1) The SQL DBA adds the new login and grants SQL permissions.
This method does not require the Dynamics or eEnterprise user to have access to the sa account.
For less sophisticated users (who may not even have a DBA), we recommend leaving the two setup options "checked". When the setup options are checked, Dynamics and eEnterprise will automatically add the necessary users and logins to SQL Server when a new user is created inside the accounting system. While this method does require that the accounting administrator have access to the sa account, our user feedback indicates that this a more popular choice for our smaller and less sophisticated users than the alternative two-step process. For our smaller users, the "DBA" and the "Accounting Administrator" are almost always the same person. In that case, access to the sa account is not an issue.
By using the sa account, we can get closer to the goal of eliminating the need of having a user to touch the SQL back end during the installation and configuration process. Other than installation and configuration, there are no other processes within the system that require the sa account.
Dedicated SQL Server.
With this in mind, our general corporate recommendation is to load our product in a dedicated server. We feel this best protects our customer's vital need to have a stable and high performing line of business application. It would be foolish for Great Plains to imply that it's OK in all cases to load any number of other applications and utilize the same SQL Server and computer infrastructure that is in place to maintain critical financial business information.
Of course, our recommendation to use a dedicated server is simply our blanket starting point of reference for customers. There are cases where customers have the technical background and skills to properly predict loading on their system using tools like performance monitor or SQL profiler. These customers can then make their own informed decision to configure their hardware in any fashion they desire. However, we still believe our customers interests are best served by starting with a more conservative position and consolidating only after a thoughtful and thorough analysis has been performed.
Enterprise Manager, Query Analyzer or any administrative interface with SQL Server.
The original article is located here:sarant
I happen to like this approach for software development. I just wish that this information was more widely disseminated to Great Plains technical support and VARs. Given this response I am confident that Great Plains will see this gets done. My opinion of this approach to using the "sa" account is valid since in many cases, there will be no DBA in smaller companies that use this software.
As far as the dedicated server section. I understand the position taken and it does make sense. Given the option of using "sa", this is fine with me. If there is no option, then I think it is rather short-sighted of any software company to deliver a SQL Server solution without considering that another application may reside on the same server.