Blank password works for user account - all other passwords don't!

Hi Group (and thanks for any help given):

I am new to SQL 2005 and have an issue with passwords. I set the password on a user account and tried to access my program (Time Matters.) I received an error message that the application was unable to connect to the system database. When I set the password to blank (no password), the application was able to connect to the SQL db and everything worked just fine.

I've tried several different passwords. Any password besides blank does not work. Blank always does. Obviously I don't want to use a blank password. But where in SQL Server is the setting or could a copy of the original password be "stuck"?

Thanks for your help.

Jeff

Hi,

if you are running on a WIndows 2003 Server you might have the password policy enabled. You can disabled that by navigating to the appropiate user in the Managment Studio and disable the Enforce password policy checkox. YOu can also disable that at server level (not if it is overwritten by a domain policy). Open the group policy snapin for this and navigate to the security option for the password policy.

Which error (number are you getting) ?

HTH, jens Suessmeyer.

http://www.sqlserver2005.de

|||what client application are you using to connect. is it the management studio|||

Thanks for the reply.

It is a Windows 2003 Server and on one of my two users I can turn off the Enforce password policy checkbox (I still cannot connect with any password but a blank one, however.) On the other user, I get the error message 15128 (The CHECK_POLICY and CHECK_EXPIRATION options cannot be turned OFF when MUST_CHANGE is ON.)

Due to security concerns on the server, I cannot turn off the Password Policy enabled setting on the Windows 2003 Server itself.

Any ideas?

Thanks,

Jeff

|||

Yes, I am using the MS SQL Server Management Studio. The application I am trying to connect to its MS SQL Server databases is Time Matters. It creates two different database schemas in SQL Server (one for the "real" database, one for the "training" database.) For each of the databases, it creates a login that is used for workstations to exchange data with SQL Server.

Both logins will only work when the passwords are blank. Both worked earlier, before the server was physically moved (and, I think, some other, security-based changes were made.) It seems like a blank password is equivalent to not having the password checked, but any password entered is verified against some earlier password and deemed as out-of-date, and therefore access is denied.

(By the way, I have set the password(s) back to every password that has ever been used--the only one that works is a blank password.

Thanks for any advice.

Jeff

|||

If "Must Change" is checked, the user has to change the password before they can log in successfully.

If you are enforcing the domain's password policy, any domain password complexity policy (repeated characters, presence of special characters, etc.) must be met as well. Make sure the passwords are sufficiently complex.

Have you tried creating a long, complex password for the login (e.g. "SqlS3rVr{pw") and unchecking the Must Change check box in the login dialog?

Thanks,
Steve

|||

Hello...

I had similar problems. My solution: (i write this while i am actually doing it. the values do work on a standard windows 2003 server, fully updated)
Steps:
create an account: TestMe,
select SQL server authentication, (notice that "enforce", "expiration" and "must change" get enabled.)
Type the password: anypassword (euhm... yep do that twice :-) otherwise...)
deselect: [ ] User must change the password at next logon
close/save the user by clicking OK

open it again (notice that must change is greyed out)
deselect the remaining two options and your done. save and reopen: You can set the password to any you like.

I haven't had no time to test what exactly happens when you turn back on the "enforce password policy" but it would not surprise me if the domain policy is taking over. When using the SQL server authentication it is possible to "bypass" the domain security policy.