Setting Password complexity requirements

  • Thread starter Thread starter Keith
  • Start date Start date
K

Keith

Our organization wants to set a password complexity standard through AD.
We are running Windows Server 2000 mixed mode. I'm new to AD and need to
now how to initiate the standards we require. I understand that this
option must be enabled at the domain level. Our standard is to have
passwords set to be greater than 6 characters and contain at least 1
number. Do I need an additional plug-in to configure this?
 
Go to ADUC - right click on your domain name and select properties - group
policy - edit the default domain policy. Expand Computer config - Windows
settings - Security settings - Account policies.


hth
DDS W 2k MVP MCSE
 
Keith said:
Our organization wants to set a password complexity standard through AD.
We are running Windows Server 2000 mixed mode. I'm new to AD and need to
now how to initiate the standards we require. I understand that this
option must be enabled at the domain level. Our standard is to have
passwords set to be greater than 6 characters and contain at least 1
number. Do I need an additional plug-in to configure this?
Click to expand...

Yes (because this is NOT the definition Microsoft
uses for their own complexity setting. See below...)

[And the above is extremely insecure -- so bad in
fact as to not be worth the trouble to make it a standard.]

The "complexity" setting requires at least "3 of UPPER/lower
case, numbers, special characters".

If however you choose to use the Microsoft "complexity"
setting, you can do this trivially in a Group Policy.

6 is a ridiculously low number for minimum characters. 7
at least, but even that is breakable fairly quickly.

In fact, I will no longer use anything less than 15 characters
with complexity.

(There is a site on the net that will break a 14 character
password with 'semi-complexity', i.e., UPPER/lower case
and numbers, in under 20 seconds of processing time.)
 
ptwilliams said:
and numbers, in under 20 seconds of processing time.)

What's it called?!?
Click to expand...

I am embarrassed to admit that I cannot remember.

It was some (mainframe?) computer somewhere (at a University?)
which would queue them up -- actually clock time was a quite a
bit more since you had to wait for the request to bubble to the
top of the queue WHEN processing time was available.

But once run, the time was like 12 seconds.
I'd love to see the code they use to do this. I bet it's trivial...
Click to expand...

I don't believe the code was published (at that time).

I do believe it depended on the LanMan hash which is one
of the reasons that I use MORE THAN 14 characters since
doing this defeats the legacy hash (even if the domain generally
supports it.)
 
Keith,

When you set password complexity requirements, the domain refers to
passfilt.dll as its source for the complexity rules. If you are of the
programming ilk, you can create your own password filter and determine rules
that meet your needs.

You can find additional information on doing this at:
http://msdn.microsoft.com/library/d...assword_filter_programming_considerations.asp

While I agree that the complexity requirements you have listed are not
secure, sometimes these things are outside of our control and handed down by
administrative fiat. I would suggest following Herb's recommendations on
administrator passwords. Of course, you can't make this a requirement of
administrators without having a separate management domain in place -- your
best bet, then, might be to have a strong psychological grip on your other
admins <G>.
 
administrator passwords. Of course, you can't make this a requirement of
administrators without having a separate management domain in place -- your
best bet, then, might be to have a strong psychological grip on your other
admins <G>.
Click to expand...

User education is a necessity for strong password
security in any case.

Such education starts with those most powerful 'users',
admins and assistants, who must not only understand
the security requirements but BELIEVE in them to be
able to both follow them personally AND to teach the
"regular" users to do so safely.

For instance, if people don't believe in security, they
will write down their password (think little sticky yellow
notes) or tell their password to their friends or anyone
who they think "needs" it.

If admins don't believe in security, they will use
their admin privileges to avoid the requirements,
and they will never be able to explain it to users
honestly AND effectively.

At least half of good security practices is the education
of your user base.
 
Back
Top