Password validation failed
-
Hello Everyone,
I just installed SQL Server Yukon. I tried, via the new SQL Server Workbench to create a SQL Server login but I received this error:
TITLE: Sql Workbench
----------------------------------------
An exception occurred while executing a SQL statement : Batch or statement execution failure : Password validation failed. The password does not meet policy requirements because it is not complex enough. (Microsoft.SqlServer.Smo)
----------------------------------------
ADDITIONAL INFORMATION:
Batch or statement execution failure : Password validation failed. The password does not meet policy requirements because it is not complex enough. (Microsoft.SqlServer.ConnectionInfo)
----------------------------------------
Password validation failed. The password does not meet policy requirements because it is not complex enough. (.Net SqlClient Data Provider)
----------------------------------------
BUTTONS:
OK
----------------------------------------
For sure it's because the password I gave to this login is exactly the same as the login name. But in my case it is what I want.
Is there a way to put this validation to OFF?
Will it be the same on the non beta version?
Thank's
Carl
-
Hey Carl,
After playing around for a while, I discovered that this is a new cool feature to Yukon. At first I tried to create a SQL Server login user: admin, password: admin. And grant the sysadmin to master database. Everything worked just fine. After looking to the Local Security Policy, I found out that the key in Password Policy "Password Must Meet Complexity Requirments" was disable. After enabling the feature, I no longer was able to create a user with not "complex" password. Even trying to grand the user access to non-system databases, would give out the same error you got. If you disable the feature, everything works fine again.
I won't, however, recommend to disable the password validation, or if you do, you should never grant access to system databases. But if you have that special situation, then go ahead and do so.
Good Luck,
Kostil
-
Hello Chris,
is it a setting of SQL Server or a setting of the OS?
I don't find something called "LocalSecurity policy" in BOL.
Thank's
Carl
-
In Windows 2000, go to Control Panel, then Administrative Tools, then Local Security Policy.
Then click on Account Policies, then Password Policies.
You'll see the item "Passwords must meet complexity requirements".
Doubleclick it and set it to "Disabled"
Mike
-
It is already set to disabled.
So it seem that my problem is not related to this setting.
Carl
-
Domain-level policy settings override local policy settings. Perhaps your complex passwords are set at the domain level.
-
Is is not defined at the domain level nor it is at the O.U. for the servers (active directory).
The proof is that I can see that, for this setting the Local Setting is "Disabled" and the Effective setting is also "Disabled".
By the way, why it is the os that is in control of the way I manage SQL Server logins?
I don't speak of windows authentication here, I use SQL Server logins.
Regards,
Carl
-
Carl,
I am also talking about SQL Server logins. In this case SQL Server is communicating with OS and asking if the password follows the complexity rules. As someone said earlier, Domain Security Policy Overrides the Local one, you should check one more time if the "Password Must Meet Complexity Requirments" Is disabled. I test it on my Windows 2003 machine last night. Although, my machine is not a part of the domain, I am sure that the same settings will apply to server in domain. Is machine that running your SQL Server is also your Domain Controller?
Chris
-
Hello Chris,
The machine is not our domain controller.
Since I see that the Effective Setting for the "Passwords must meet complexity requirements" is set to Disabled, it is because it inherit from the higher levels. No?
If it is not the case why I see this status?
Thank's
Carl
-
Hey Carl,
By default when the machine is logged in the domain, Local Group Policy is processed, then domain policy. If any disagreements found in both, domain policy takes over the machine. I would try this: If the machine is a member of OU, then you could go to Active Directory Users and Computers, click OU you want to apply changes and click to "Block Policy Inheritence". I would not advice it, since you have more troble on administering the OU. And Second, check the Default Domain policy, on the domain controller, Since it is the top policy for the domain, and OU inherit from it.
One more thing, if the setting on the machine says Disable, it doesn't mean that this is the final setting, in case of the machine in domain controller. Inheritence is taking place in this case.
This article might be helpful to you. http://support.microsoft.com/default.aspx?scid=kb%3B%5BLN%5D%3B269236, and there are a lot more about policies and inheritence in the domain structure.
Chris
-
Hi again Chris,
To be sure, I put the server out of the domain (even if we are sure that it is set to NOT DEFINED for the OU and it is set to DISABLED on the domain controller).
The result is the same: I cannot create a SQL Server login having the same password as the login name.
Are you sure that it is related to this setting?
Thank's again Chris,
Carl
-
Carl,
I am sure that this feature has to do with Security Policy. When I come back home tonight, I will run this same test again, and will post it here. this will be around 9 pm eastern. I also described the problem to Microsoft SQL Server Discussions and will check tonight if I got any answer on it.
Be back,
Chris
-
Thank's Chris,
this is not a hurry but I appreciate all you are doing to clarify this topic.
Carl
-
Okay...
I made a couple of calls and find out some things that might help, even though the situation is not completely clear. There could have been a lot of factors causing the problem: did you install the SQL server on the machine within the domain; did you take this machine off the domain after installation; have you rebooted the system after taking machine off the domain;
When SQL Server 2000 is installed on the server within domain, taking the machine off will create some problems in the operation of SQL Server, because of the fact that it doesn't know that it is no longer the part of domain forest. As i was told, some setting are changed whenever this situation arises. Maybe even some registry settings. Yukon might have the same problems when it's done this way.
I have also tested it again on my machine, and I am sure it has to do with Security policy. When I enabled it, the error would come up, and would go away only after disabling the password complexity!
Here what I would do:
1) Reboot the machine
. Operation of taking the computer off the domain forest always requires machine reboot. 2) Open the SQL Server Workbench. Right-click the server you having problems with and choose Properties. Select the security setting from the listbox to the left, and change the authentication mode from mixed to windows. Restart the SQL Server or better yet, follow step 1 and restart the machine
. After restart, go there again, login with windows mode, change the settings back to mixed mode. Restart again. 3) If the above two won't work, and since there is not enough articles and documentaries on Yukon yet, backup all the databases. Reinstall the server to the machine not in the domain (as I understand you want the machine off the domain anyway) and restore all the databases. Now try to add the user with weak account, but make sure the Local Security Setting regarding the complexity of passwords is disable.
Please notify me if you fixed the problem. If not, I will have no choice, but setting up the domain, since I am interested myself. However, I am sure that reinstalling the Yukon will make this problem disappear.
Chris
-
Hello Chris,
Just to make it clear my goal is not to have this machine out off the domain.
Yesterday I put it out of the domain for test pupose only (to proove that the setting was not inherit from the domain). But right after that test, I put it back in the domain and rebooted (twice).
1) It still not work after having rebooted this machine in the domain.
2) It still not work after having done what you said in point 2.
3) I will re-install Yukon, but I don't know when.
I will post here my results when it is done,
Thank's again,
Carl
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply