none
The sa password must meet SQL Server password policy requirements.

Answers

  • You should contact the ALLDATA database vendor to determine what effects will have on their application if you were to either choose a strong password for the 'sa' account, or to use Windows security and lock out the 'sa' account.

     

    And I'm sure they have encountered this question before and will have some suggestions.

    Saturday, June 30, 2007 7:49 PM
    Moderator

All replies

  • You should contact the ALLDATA database vendor to determine what effects will have on their application if you were to either choose a strong password for the 'sa' account, or to use Windows security and lock out the 'sa' account.

     

    And I'm sure they have encountered this question before and will have some suggestions.

    Saturday, June 30, 2007 7:49 PM
    Moderator
  •  

    Hi Amilcar

     

    I've got the same problem, did you ever find a solution to this?

     

    Thanks, Daniel

    Monday, September 10, 2007 11:20 AM
  • Several simple solution steps:

    1*. Go to Administrative Tools / Domain Security Policy :: Security Settings | Account Policies | Password Policy

    2*. Ensure "Minimum password length" and "Password must meet complexity requirements" set to "Not Defined" state.

    * Skip this steps if you don't have domain controller.

    3. Go to Administrative Tools / Local Security Policy :: Security Settings | Account Policies | Password Policy

    4. Turn "Minimum password length" to zero and "Password must meet complexity requirements" to "Disable"

    5. Go to SQL Installation window and press "Retry".

    6. After installation successfully done, turn changed security settings from steps 1-4 back.

    7. Have fun.

    Monday, December 08, 2008 8:54 AM
  •  

    Amilcar,


    I recently ran into the same problem with a vendor who created a custom install package with their application.

     

    Simplest Answer:

    1st -  Remove the machine from the domain (if not on the domain proceed to step 2 anyways)

    2nd - make sure the local security policy is set to not require complex passwords

    3rd - run your install, then change the application password once complete

    4th - put the machine back on the domain.

     

     

    Cause:

    * Let me first caveate this by saying I thought I had a strong grasp on SQL 2005 (regardless of iteration), but once again a small feature change snuck up and bit me.

    - Microsoft has modified SQL 2005 (and supposedly 2000 was capable with the proper OS, but I never saw the behaviour) to inherit Password policy from the OS. So if the machine is on the domain and you have a password policy requiring complex passwords (as you should do at a very minimum) you will indeed see this problem with an incorrectly setup application.

     

    Specific example:

    the application in my case is "DocuShare Express" from Xerox. It is used by the MultiFunction printers to provide some advanced features. It turns out that the installer does not prompt the user for an SQL password when installing, it then proceeds to install SQL Express and set the password to *null*. Now that I have strong feelings about security, actually I do, if you are going to provide a tool and this tools provides web based access to scanned documents and it secures that access....     WHY then would you use the "SA" account and then even WORSE!!! why would you use a blank password????

     

     

     

    I have to stop here or my Soapbox will be taken away.

     

    I hope this helps you or someone else in your situation.

    Monday, December 08, 2008 5:03 PM
  •  Password Policy integration was first introduced in SQL Server 2005, I am including BOL documentation as well as an article wrote by Laurentiu that should help to explain this feature:

    * Password Policy (http://msdn.microsoft.com/en-us/library/ms161959(SQL.90).aspx)

    * SQL Server: Password Policy FAQ (http://blogs.msdn.com/lcris/archive/2008/02/20/sql-server-password-policy-faq.aspx)

     

      I agree with Zx9hippo regarding the concerns of third party tools that either use null/blank SA passwords and/or rely on SA for the day to day operations; and I would like to encourage anyone who is facing similar problems to contact the affected vendors and ask, as their customers, to follow the least privilege principle and stop dependencies on sysadmin in their software, and that they provide you with the right tools/options to secure your system when installing and using their products (in this case, the embedded SQL Server instances they use).

     

      Thanks a lot,

    -Raul Garcia

      SDE/T

      SQL Server Engine

     

    Monday, December 08, 2008 7:37 PM
    Moderator