Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

K. Brian Kelley - Databases, Infrastructure, and Security

IT Security, MySQL, Perl, SQL Server, and Windows technologies.

Dealing with Auditors: Password Settings

Yet again I've seen an audit request where the auditor wants the DBA to show what SQL Server's settings are for this set of information:

Facepalm pose 

  • Account Lockout settings
  • Password Expiration settings
  • Password Complexity settings

 

If you're dealing with an auditor who is asking for this on your SQL Server, please refer them to:

 

Books Online: Password Policy  (this link goes to the SQL Server 2005 BOL, when such support was introduced)

 

Then show them this quote (emphasis mine):

 

When it is running on Windows Server 2003 or later versions, SQL Server 2005 can use Windows password policy mechanisms.

SQL Server 2005 can apply the same complexity and expiration policies used in Windows Server 2003 to passwords used inside SQL Server. This functionality depends on the NetValidatePasswordPolicy API, which is only available in Windows Server 2003 and later versions.

 

If they aren't familiar with that function, point them here:

 

NetValidatePasswordPolicy function

 

In other words, SQL Server is passing off the password check to the OS. Therefore, the settings are at the OS. This is true of every version since SQL Server 2005. Hit the same topic, regardless of version, and you'll see something similar with regards to the text. The bottom line is that there are no separate settings in SQL Server. Furthermore,if your Windows computer is in an Active Directory domain, then most likely your OS is getting them from the Default Domain Policy, which is stored in Active Directory. In short, the auditors need to look there, not in SQL Server.

 

If they're interested in seeing what SQL-based logins which are enforcing password policy/expiration, that's a different story. Query sys.sql_logins and you'll get that information. But as far as the settings are concerned, they aren't "settable" within SQL Server. They come from the OS. If they still insist on seeing the settings, point them to this article and send them off to your friendly (well, until the auditor shows up at his or her desk) Windows administrator:

 

How to configure password enforcement options for standard SQL Server logins

 

Comments

Posted by kmslogic on 22 June 2013

SQL Policy *can* be set up this way (per your quote), and probably 99% of the time is, but not necessarily.  You should be able to tell an auditor that it is set up to use OS/AD settings and if so to point them in the right direction.

Posted by Nadrek on 24 June 2013

This is nearly completely worthless to an auditor, though it is a useful step to take for newly created accounts.

Proof of statement is below; note that it creates a login with a password that should never pass policy, _then_ it sets the policy on... and that happens without requiring a password change, leaving the old, bad password 100% intact and unchanged, but showing the nifty Policy applied checkbox.

Therefore, the check policy checkbox is only meaningful to changing the password _while_ the checkbox is checked.  Looking at the checkbox on an existing account tells you nothing whatsoever about the existing password.

USE [master]

GO

CREATE LOGIN [testbadpw] WITH PASSWORD=N'bad', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF

GO

ALTER LOGIN [testbadpw] WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english], CHECK_EXPIRATION=ON, CHECK_POLICY=ON

GO

DROP LOGIN [testbadpw]

GO

Posted by Nadrek on 24 June 2013

This is nearly completely worthless to an auditor, though it is a useful step to take for newly created accounts.

Proof of statement is below; note that it creates a login with a password that should never pass policy, _then_ it sets the policy on... and that happens without requiring a password change, leaving the old, bad password 100% intact and unchanged, but showing the nifty Policy applied checkbox.

Therefore, the check policy checkbox is only meaningful to changing the password _while_ the checkbox is checked.  Looking at the checkbox on an existing account tells you nothing whatsoever about the existing password.

USE [master]

GO

CREATE LOGIN [testbadpw] WITH PASSWORD=N'bad', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF

GO

ALTER LOGIN [testbadpw] WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english], CHECK_EXPIRATION=ON, CHECK_POLICY=ON

GO

DROP LOGIN [testbadpw]

GO

Posted by Nadrek on 24 June 2013

This is nearly completely worthless to an auditor, though it is a useful step to take for newly created accounts.

Proof of statement is below; note that it creates a login with a password that should never pass policy, _then_ it sets the policy on... and that happens without requiring a password change, leaving the old, bad password 100% intact and unchanged, but showing the nifty Policy applied checkbox.

Therefore, the check policy checkbox is only meaningful to changing the password _while_ the checkbox is checked.  Looking at the checkbox on an existing account tells you nothing whatsoever about the existing password.

USE [master]

GO

CREATE LOGIN [testbadpw] WITH PASSWORD=N'bad', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF

GO

ALTER LOGIN [testbadpw] WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english], CHECK_EXPIRATION=ON, CHECK_POLICY=ON

GO

DROP LOGIN [testbadpw]

GO

Leave a Comment

Please register or log in to leave a comment.