|
The way the policy is implemented now is a direct
descendent of the policy as it existed on NT4. There was no hierarchical layout
for users, it was a flat space. When coming to 2K, it was easiest, least
troubleprone, and less confusing to implement the same system. Basically it
is the concept of the shared SAM/Policy realm within a domain that was there
before. Had they just arbitrarily changed that they could have impacted
many customers with programs that read the single domain policy and make
judgements based on that info. Say for instance apps that manage their own
password, etc. They could have added the functionality and tied it to a
functionality level say W2K Native but again, that is a lot of work for
something customers can already handle on their own if they so
choose.
So anyway, as others have mentioned, the policy is a
computer policy that applies to domain controllers, the domain controllers write
the policy settings to the NC head of AD and the domain controllers read from
that to determine how to enforce rules. If you apply the policies at lower
levels of OU hierarchy you will impact the password policies on the member
machines in those levels. This will not allow you to put a weaker password on a
domain account based on what member machine you use to change your password.
If you flip it around, if you applied the policy to users
there would be no way to apply global policies to local machine users since they
don't exist in Active Directory.
Finally, as ASB pointed out, there are mechanisms out there
to help you do what you want to do. They generally cost a decent amount of
money. It uses a built in functionality to allow you to create your own
complexity filters for passwords. If you are a GREAT C++ programmer, look at the
info in MSDN on password change filters. If you aren't a great c++ programmer,
don't even both as you are playing with key aspects of your security and
stability. If you are a VB programmer err I mean coder - no soup for you.
Another way this can be implemented by a lesser programmer
is to set up a web site that you require people to go through for password
changes. You simply take everyone's permission away to change their own
password and set up a delegated ID used by the website to do all password
changes. Of course lots of room for security issues here as
well.
Will this change in
the default OS at some point in the future, possibly, there certainly are a lot
of requests for it, but it depends on the prioritization of other
functions/features people want as well. Anything that I can pull off on my own
through native interfaces I have a lower priority for having MS change than
things I can't work with at all. For instance, I would much rather see DCs being
able to auth users from multiple domains way before I see built in support for
multiple password policies within a single domain. Ditto the removal of IE and
the GUI from servers. There is no way for me to implement those items I mention
as priority for me but the password issues I can pretty easily
handle.
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kurt Hill Sent: Thursday, April 14, 2005 5:09 PM To: [email protected] Subject: RE: [ActiveDir] Password complexity requirements Yes – that makes sense
– At least I understand why my OU-level GPO’s seemed to be ignoring the password
requirements. I still don’t understand why Microsoft chose to make
password requirements a feature of the DC and not the user, however. The
only solution is to have multiple sites!! Thanks, Kurt From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of
[EMAIL PROTECTED]
|
- RE: [ActiveDir] Password complexity requirements joe
- RE: [ActiveDir] Password complexity require... Douglas M. Long
- RE: [ActiveDir] Password complexity require... Cothern Jeff D. Team EITC
