System stored procedures

Question

Post reply

System stored procedures

hottman

SSC Veteran

Points: 200
More actions
August 14, 2007 at 2:40 pm

#118166

We are trying to install a vendor application and are running into a problem with the default behavior of sp_addlogin in SQL Server 2005. sp_addlogin is written to use the CREATE LOGIN procedure but by default has the CHECK_POLICY variable set to ON (actually, it does not even include this parameter but ON is the default value if not specified). Their installation is not passing in a password for one of the SQL Server Logins it needs to create which adheres to the minimum characteristics for passwords.
The correct solution is, of course, for them to change their install to make this password stronger so that it meets the minimum. I was thinking that as a short term fix, we could alter the sp_addlogin procedure to add the CHECK_POLICY parameter and set the value to OFF. But it seems that Microsoft has the system stored procedures locked down a little tighter in SQL Server 2005. Is there a way around this?
Can anyone help?

Mark

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

MarkusB SSC-Dedicated Points: 37370 More actions · Answer 1

Mark,

why don't you just change the Local Security Policy on the server to accept a weak password?

Once the login has been created you can change it to not enforce the password policy and change back the local policy for the server.

Markus

[font="Verdana"]Markus Bohse[/font]

Steve Jones - SSC Editor SSC Guru Points: 736478 More actions · Answer 2

I like Markus' advice. It's a workaround and will get things moving. The other thing you can try is create the login yourself and then see if you can get the install to bypass the error message.

Or even skip it. Dynamics used to require sa level access because it wanted to create logins for users. However we found we could do it manually and then the program would just pick up the user and it could be assigned security, etc.

hottman SSC Veteran Points: 200 More actions · Answer 3

Good ideas, but we already tried them.

Unfortunately, this is a production server on our enterprise AD domain and corporate policies physically prevent us from changing the setting on the server. Options for this are greyed out even when logged in as an administrator.

We did try pre-creating the login but the vendor install checks for its existance and drops it prior to trying to create it. Nice, huh.

Any other ideas out there?

Changing the system stored procedures is really not an option more?

Mark

Bob Fazio SSChampion Points: 10794 More actions · Answer 4

Talk about being between a rock and a hard place. I would love to say. If you want us to buy, fix this. And tell your domain admins I need this changed for me to do this.... ugggg..

Could you setup a server that is either not bound to the policy, install, then move DB? Is this really the first time this vendor has come across this?

Assuming the worst.

Before you muck with the procedure, I haven't tried to change that one. Try first to create a copy of it. There are some that just won't compile easy because they need "Special Settings" Don't break your installation. I have been in your position and I suspect your ideas are about your only option.