Contained User syntax does not support bypassing password policy by aaronbertrand

Don, these details are listed further down in the Connect item. Did you expand the "Details" node? I'll repeat for you here. First, set up a machine that has a password policy in place and active. I can't write a T-SQL script for that. Then, on an instance that resides on the machine with the password policy in place:

USE [master];
GO

-- works:
CREATE LOGIN blat_login WITH PASSWORD = 'splunge', CHECK_POLICY = OFF;
GO

-- fails:
CREATE LOGIN splung_login WITH PASSWORD = 'splunge';
GO

/*
Msg 15116, Level 16, State 1, Line 1
Password validation failed. The password does not meet Windows policy requirements because it is too short.
*/

-- now set up a contained database:

EXEC sp_configure 'contained database authentication', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
CREATE DATABASE Contained;
GO
ALTER DATABASE Contained SET CONTAINMENT = PARTIAL;
GO
USE Contained;
GO

-- fails:

CREATE USER blat_user WITH PASSWORD = 'splunge';
GO

/*
Msg 15116, Level 16, State 1, Line 1
Password validation failed. The password does not meet Windows policy requirements because it is too short.
*/

There is no way to make this succeed, as there is no way to use CREATE USER syntax that does NOT go through the windows password policy checks. These checks are not the basic password validation policy you're talking about, they're coming from Windows. If you still can't see the problem here (I can make a server-level login with a weak password, but I need a strong password for a much more restricted contained user), can you please have Isaac Kunen take a look at this issue?

Hi Aaron,

Thank you for your feedback!

We have some really basic password validation policy in place if we don't go through windows password policy checks -

Rules:
------
1.    Cannot be null
2.    Cannot be same as the login name
3.    Cannot be same as the machine name
4.    Cannot be any of the fixed names such as -{"password", "admin", "administrator", "sa", "sysadmin"};

If you can provide me with the T-SQL script, I'll be more than happy to investigate this issue further for you.

Thank you and regards,
Don Pinto
SQL Server Engine Security

Don, I can only guess you didn't try the repro, because your explanation does not match my experience. Can you please explain how I can set CHECK_POLICY off for a contained database user? This user is not associated with a login, and CHECK_POLICY is not an option for CREATE USER.

Hi Aaron,

Thanks for your feedback on the product!

After taking a deeper look into the design, we only do simple password validation checks and don't enforce the policy if CHECK_POLICY is set to OFF.

Thank you and regards,
Don Pinto
SQL Server Engine Security

Quite agree Aaron. I'd also suggest that contained users will be the most likely ones that will need the ability to turn off policy checking as they'll often be used for application databases where apps connect with fixed credentials.

Regards,

Greg