A
Anteaus
Guest
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.
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.