Re: Password is "too recent to change"

Thanks Geoff. You are correct and I happily appologize to MSFT for jumping
to conclusions :)

I looked into Check_Policy. It's a a new parm and isn't supported in the
older DMO (which is how this routine was written). However, it was easy to
modify the function using TSQL and it worked perfectly.

Thanks again for that help. Hope this helps someone else moving to Vista.

--
Maz


"Geoff N. Hiten" wrote:

Hold on. Microsoft had to fix a lot of the default open security holes.
While that can cause problems, they also gave us the tools to deal with the
issue.

Run this T-SQL command

ALTER LOGIN <yourloginname> WITH CHECK_POLICY = OFF

and it will stop checking the OS or domain password policy for SQL Server.
I woud recommend setting it back on after making all the changes.

--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP




"Spicy Mikey" <Maz@xxxxxxxxxxxxxxxxx> wrote in message
news:912129B0-B3BC-4986-905B-2A6031EEA9DF@xxxxxxxxxxxxxxxx
I agree with that assessment. The question, unfortunately, still stands;
how
do we change it? More specifically, how do we change it programatically?
These are turn key setups. The customer will have no expertise in this
matter. We need to do this from our application wizard.

Since these are policy settings, I'm concerned it cannot be changed
through
any software interface. Also, this is a SQL Server login and password not
a
Windows password. Not sure why SQL is enforcing that OS rule.

Regardless, here's the dilema. Our wizard initially installs SQL Server
with a generic SA password using a command line install. After that step
completes, the password and other security settings are altered and this
instance is taken over by the applications setup wizard. We do a two
step
process because sometimes there are problems getting SQL installed and
manual
intervention is required. It is good to have the option of giving someone
the "install" SA password without needing to reveal the final operational
SA
password which is a secret and embedded in the app.

Does anyone know how to change this policy back to zero programatically OR
any thought on how to do this install without risking exposing the SA
password?

My gut feeling is we're screwed by another somewhat arbitrary change
implemented by MSFT without consideration of the impacts to it's software
partners. Someone prove me wrong please? I'd love to be able to
appologize
for jumping to that conclusion.

--
Maz


"Laurentiu Cristofor [MSFT]" wrote:

The password policy that generates this message is called Minimum
password
age - x days - you cannot change the password within x days from last
change. The default value on Vista probably differs from the one on your
previous OS.

Thanks

--
Laurentiu Cristofor [MSFT]
Software Development Engineer
SQL Server Engine
http://blogs.msdn.com/lcris/

This posting is provided "AS IS" with no warranties, and confers no
rights.

"Spicy Mikey" <Maz@xxxxxxxxxxxxxxxxx> wrote in message
news:A921C953-A780-4C94-9497-94993579BB31@xxxxxxxxxxxxxxxx
We have a "wizard" that deploys and configures a SQL 2005 instance for
our
application. Among other things, it resets the SA password to a strong
password that is unknown to the client.

It works fine except now with installations on Vista. When the
password
is
set by the script it gets an error stating "Password Validation Failed.
The
password for the user is too recent to change."

I've never had this problem before. We need to get around it but I see
no
settings in SQL to adjust that. I also don't see any settings in Local
Policies for Vista that require a password exists for a certain amount
of
time.

Anyone run into this yet and/or have a suggestion to solve it?
--
Maz





.