I would like to know can the 'sa' username rename or disable it?
if disable or rename it what problem will cause it?
I have clients request on the below tasks, would like to know more info on this.
where i can download or get the info.
*This post is locked for comments
The 'sa' account is the system administrator account for SQL and cannot be deleted or renamed. The average user should not even be told it exists and it password needs to be strong and known by only a few people in your organization.
ok. thanks! where i can download or get the info if rename sa what problem will caused?
what about the sa password can be change? will caused any problem after changed?
I stand corrected. Apparently you can change the 'sa' account. This is useful for situations where SQL is installed in a mixed mode environment which will always be the case with GP installations. You can read these articles if you find it necessary to change the sa name. The changing of the name comes into play if you create any connections or write code where you have hard-coded in the sql credentials. The DSN for GP will also be affected if you do rename the sa account. Any time you log in where it would have been 'sa' now has to be the new name. SQL Services are started with domain account so 'sa' is not used there. If you do rename the 'sa account just lock down the new name to only a feew select people within your organization.
Be careful disbaling or renaming the sa user as there are still some parts of Microsoft Dynamics GP which require the user to be 'sa'.
Gents,
I have worked with many auditing firms in IT audits mainly with big four considers the "sa" user a security thread as it is well known to all developers and will make the hacking process easier! PWC and EY considers this a high risk finding and will be reported in the findings report.
I have done this before for many customers, just switch the DYNSA to SYSADMIN at the SQL level to be your administrator and rename the "sa" user to anything else like "System Administrator" or something like that.
For GP in specific, everything will work fine until start using the PSTL, which cannot be used by any user other than the "sa".
sa is required for some maintenance activities such as restoring a database from within GP, installing Payroll updates (so I'm lead to believe but I've not done this as GP Payroll doesn't apply to the UK) and also by a number of third party add-ons to GP which are hardcoded to be used only by the sa user (although typically only during the install/update process)
You'd probably get away with disabling it and re-enabling when you have an update to do but I would recommend not renaming it.
Let me give you some information from Microsoft's side on this issue. You NEVER EVER want to delete SA as it is very difficult to get it back sometimes. From the GP side you can simply disable SA and turn DYNSA into SA as Mohammad mentioned. Take a look at page 37 and down in the Secuity Planning PDF file. This will tell you how to configure DYNSA or other users to be able to do the tasks that SA can be default.
I will agree with Jonathan on NEVER NEVER EVER delete the SA account. Disabling it is the best option if absolutely necessary. Just make certain that at least one Active Directory account has sysadmin rights to the SQL Server instance to re-enable it. Something that was not mentioned above is that Dynamics Utilities will only accept the SA login, so you would not be able to create new companies or upgrade or update GP when necessary.
@Richard, the SQL DSN will not be affected, and will not break if SA changes - that password you enter to set SQL DSN parameters is never cached for security reasons. If anyone is concerned with the password residing on a PC, you can set one up by naming it, choosing SQL authentication, unchecking the login box, unchecking all the ANSI flags and save (without test, because you did not log in). It will still work when the end user logs in, and you did not ever enter the sa password.
Share
Report
All responses (
Answers (
