|
I kind of thought the idea of only having
one password policy per domain was that you are theoretically protecting the
domain admin accounts (when enforcing complexity) from an escalation type
attack from a “user” account. Or for that matter, protecting the
whole domain with more complex passwords. What good does it do to have a domain
admin account with a complex password if a user has a 2 letter password that
someone easily guesses, and then runs a DDOS on AD, or obtains some other critical
directory information that would not have been accessible without a simple
domain user account? I am sure there are lot more things that can be done with
a domain user account than you think (or at least more than you think you didn’t
overlook). In my eyes it makes total sense why it is
the way it is. Although I know it all comes back to users not putting their
passwords on their monitor and all that crap (or complex password vs. pass
phrase). I guess it isn’t that simple :)
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of joe 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 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 Douglas M. Long
- RE: [ActiveDir] Password complexity require... joe
- RE: [ActiveDir] Password complexity require... Cothern Jeff D. Team EITC
