Server 2008 Bug: Default Policy forces null-password accounts.

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



Just a quick note about a flaw in default policies which I've discovered:

If used in the standalone-server role with no AD, Windows Server 2008 sets a
default password policy enforcing complexity-rules, but NOT requiring a
minimum length. This is an unsafe combination, and should be changed.

Where useraccounts are created by way of a batchfile or script, this
condition may lead to some or all accounts having null passwords. This fact
may not be realised by the operator, but even if it is, it may then prove
difficult to correct the situation.

Example commands:

C:\> net user fred /add

Creates a new account with a null password. This should not be possible if
password-policies are in force and working correcly, but in fact it is.

C:\> net user fred averylongandreasonablysecurepassword

This should password-protect the account, but the attempt NOW fails on
complexity rules, leaving the account with a null password. In literal terms
this is an application of the policy... but an insane one!

Since the complexity-policy contains wildcard elements, an account-creation
script could never be certain of meeting it, no matter how complex the
generated password. This makes scripted account-creation an unreliable
process.

Mitigating factors:

The problem only arises when account and password are created in two
separate steps. This is quite common scripting practice, however.

Adding the Domain-controller role resolves this, since this adds a
minimum-length requirement to the policy. However it may not correct the
problem of null-password accounts existing which were created before DC
promotion.

Workaround: The default policy should be changed to EITHER require a minimum
password length AND complexity, or to NOT require complexity. It is the
default condition of requiring complexity but not requiring a minimum length
which creates the unsafe situation.

Resolution: This problem seems to have arisen owing to changes in policy
behaviour from 2003 Server. These changes need to be reviewed.

.



Relevant Pages

  • Re: Local Group Policy - User Logoff Scripts
    ... I looked at the policy for the command prompt and configured as you indicated ... As for the permissions on ... this box and cannot gain access to user account settings on the DC). ... Upon logging off, the script ran perfectly. ...
    (microsoft.public.windows.server.general)
  • Re: Local Group Policy - User Logoff Scripts
    ... >> users are given the Apply Group Policy right. ... > A few more notes on our configuration and testing: ... > this box and cannot gain access to user account settings on the DC). ... Upon logging off, the script ran perfectly. ...
    (microsoft.public.windows.server.general)
  • Re: Administrator resetting password
    ... Check your domain password policy in the Domain Security Policy or if you have more ... than one GPO for the domain check the highest GPO in the domain in the list. ... than complexity. ... You do not want any undefined settings in you account policies. ...
    (microsoft.public.win2000.security)
  • Re: Group Policy
    ... but somehow that policy doesn't take effect on those computers although ... I set the policy setting to "DISABLED" for the policy named "Password must ... meet complexity requirements". ... In a domain -- there can be only one password (account) policy and this ...
    (microsoft.public.windows.server.security)
  • Re: Group Policy to Disbale Users
    ... Schedule a script on a dc that runs every x time. ... disable all account found in your OU "Disabled Users" ... inwhich when I move a user to that OU the policy will automatcially disable that user? ...
    (microsoft.public.win2000.group_policy)