|
Oh I am not saying don't have complex passwords for users.
If you can pull it off in a secure way, go for it. One issue you have to keep in
mind is that the more complex/long your passwords are that you require, the more
likely someone is going to document it in some other localtion with the most
likely candidate being the postit on the side of the monitor and for the
"secure" business users on a postit in the bottom drawer.
However, as complex as your normal user IDs are, it would
be handy to have even more complex or require more freqent changing for high
power IDs like those associated with services or admins. I know some people are
looking at that going, change service passwords, what is he mad!!!! Yes, mad
that there is even an option to have non-expiring passwords, that is such a huge
bad security issue it isn't even funny. You change passwords so people can't
guess them or so people who learned them somehow can't always use it. So what do
you do, take some of your most critical and potent IDs and make it so you don't
have to change their passwords.... As my young English friend would say...
brilliant.
Having access to a normal userid doesn't necessarily
make an AD more insecure or less resilent to DOS, but obviously, the less info a
hacker has about an environment the better. Unfortunately, a good portion of the
hacks that do occur are by inside people so you always want multiple levels of
security, don't have the complex password for a user as the single
bastion in place. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas M. Long Sent: Friday, April 15, 2005 10:45 AM To: [email protected] Subject: RE: [ActiveDir] Password complexity requirements 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
