Susan,
Your point about lots of admins coming and going, with transient access to
hundreds or thousands of machines, is an important and separate one from
the multiple password policies question that this thread started out with.
I think trying to revoke all the admin creds that a given person had
access to in the last N days (N could be very large) is a hard problem,
and may be unnecessary. If you change all those admin passwords
frequently (e.g., every 24 hrs), then you can rest assured that the
person who just left the org won't have access to anything sensitive
tomorrow. That's good enough in most cases.
Of course, changing every admin cred every 24 hours creates a completely
new problem: how do you do that, in a manner that still makes the admin
creds reliably accessible to the people who need them, and only the people
who need them, only when they need them, and (heck, while we're at it)
with an audit log that shows which person looked up which cred.
Problems like this usually cause products to be written. E-mail me if
you want to get the advertising pitch for our particular solution. :-)
L8r,
--
Idan Shoham
Chief Technology Officer
M-Tech Information Technology, Inc.
[EMAIL PROTECTED]
http://mtechIT.com
On Fri, 1 Sep 2006, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote:
While you guys are skinning that cat (or is it buttering it?) let me
throw out the var/vap world of admin passwords... You have a bunch of
managed clients... you have employees that regularly have admin rights to
those servers. An employee leaves. You need to revoke rights to that
DC.
How is the easy and painless revokation of admin rights done quickly and
easily without going through all the third party crud that needs an admin
password to run on that server? Even having a secondary administrative
rights account and using that for all those third party things means that
the tech (or techo as they say in AU) probably knows that one as well.
(and in SBSland we stupidly still have releases and SP's that require the
built in admin account to install -- SBS sp1 and R2 both need the "500"
account otherwise they barf)
So while you guys are determining how to set password policies for
admins....what's the best way in the transitory world of vars/vaps to
revoke access? Smartcards? SecureID? Other ideas to quickly disallow
access with minimal disruption and maximum effects?
As far as thousands of password policies.. I was chatting last weekend
that you can usually tell a firm that has a old LOB app or backend NT
domain when you find a web site that puts a max number of password
characters of 8. As to the rest of us with modern networks.. we're doing
the best we can pushing to get them half way decent and getting
pushback. (personally I like the web sites these days that have the gui
indicator of how sucky your password is)
The first time I set a password policy I sat down with the person and
explained the process of selecting a good password and then had them
pretend to pick one....
The resulting password of "Adorable" (no quotes) meant that I obviously
didn't get my message across.
For the record:
http://en.wikipedia.org/wiki/Buttered_cat_paradox
Eric Fleischman wrote:
A few comments, in no particular order...
> I can visualize mechanisms to pull this off in the existing
GPOs or to do it outside of the GPOs
Well sure...it doesn't take a visionary to see how this could
be done. ;) See LDAP policies for one such example (though by
no means the only choice...in fact, not how I would do it). I
would point out that if you pulled out password policy, it
would make sense to pull out all policy dependencies in AD
itself so as to fully separate the relationship...that is, AD
and associated components (SAM, Kerberos, etc.) do not depend
on policy application for anything.
> If you leave the world of the GPO I think you get more
flexible as you could then implement it in such a way
that these password
> policies could be applied to users within containers and
even specific individual users which would be great for say
service IDs
> or admin IDs
Well, yea. I mean, this is the DCR that we've been asked for
over and over for like 5 years. While there are many ways to
achieve it (group memberships, direct links from the user &
parent containers, etc.) the net net is the same.
> From the standpoint of speed/perf, I am not sure if it
makes sense to have an assemble the final policy on the
fly mechanism here
<efleis snip of the rest of the paragraph, but I'm commenting
on it all>
The reality is that I don't think most orgs will have
thousands of password policies, so the merging is likely not
all that bad. And the # of settings is low.
That said, I'm still against this as it seems uber
inconsistent to me and very error prone.
> Using groups could be troublesome, what is the override
mechanism, which group is more important if there are
policies on 10
> groups you are in?
This is a trivially solvable problem, I'm not worried about
this.
On the larger point of the right way to skin this cat, I
actually disagree. I am for groups for the same reason I'm
for them in the RODC PRP scenario. Again, there are a great
many orgs where you have OUs separated by many things, say
geographical location, and now want to make an OU-separated
set of lower-priv admins have some special password policy
(imagine the "regional admins" scenario for a customer who
has OUs separated by location). I really think the argument
is very much the same as RODC PRP use of groups...we don't
want to push an OU model here. I'm typically against building
features in such a way that they dictate a specific OU model
to use them as that could fly directly in the face of the
logic you used for your existing OU model.
> It confuses me somewhat why DCs insist on pulling this from
DDP instead of just assembling the policy, like any other,
from all
> applicable GPOs. I assume it was done to avoid a situation
where two DCs could have different policies applied to them
and
> depending on what DC handled your password change, you
would be subject to different rules.
Yes, that's why. In fact, there were some way early win2k
bugs that yielded just this (like pre-SP1 if I remember
right, or maybe even as late as SP1, I'm not sure).
> If that's the case, I can't say I'm a big fan of illogical
hacks to help out less-cluefull admins.
I love this sentence. J
~E
________________________________________________________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Friday, September 01, 2006 2:57 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Seperate Administrator password
policy
I can visualize mechanisms to pull this off in the existing GPOs or
to do it outside of the GPOs. Having thought about this quite a bit
in the past, my personal preference would be to handle this outside
of the GPOs for several reasons. Some of the reasons off the top of
my head:
o I never really liked policy items that simply made changes in
AD and then the changes to the policy were simultaneously moving
through AD replication and GPO replication. It is illogical. Either
prevent the attributes from replicating in AD or don't replicate
them through group policy, pick one. Preferably, IMO, get them out
of the group policy and use a standard LDAP attribute on the
required objects.
o If you leave the world of the GPO I think you get more flexible
as you could then implement it in such a way that these password
policies could be applied to users within containers and
even specific individual users which would be great for say service
IDs or admin IDs.
o It removes you from the complexity and confusion between the
member password policies and domain password policies which even
now is still a huge topic for questions in the newsgroups and
here.
o You don't get people trying to apply different password policies
to different domain controllers. I would like this executed for all
domain/domain controller security settings in general actually.
From the standpoint of speed/perf, I am not sure if it makes sense
to have an assemble the final policy on the fly mechanism here.
>From a perf standpoint I don't think you want to be having to do
the logic to combine multiple password policies into one policy for
every password change (which would be the case if you go to the
user granularity level) and instead would just have an override
mechanism. You can do this with regular GPOs because the clients
individually are processing them, not the DCs. So for this, you
would want to use the closest policy to the user as the one
applied. The alternative here is if there was a builtin inheritance
flowdown model like there is for ACLing where you can simply look
at the one object and know exactly what the password policy
is whether the settings were higher up or directly on the object
just like you can with ACLs. Either way, you need to be able to do
a very simple query and very simply processing and get the decision
for what the policy should be for the user. This isn't a good place
in the code to be just hanging out trying to figure out what to do
for a while.
Using groups could be troublesome, what is the override mechanism,
which group is more important if there are policies on 10 groups
you are in?
Whatever ends up getting done for password policy would be nice to
see on kerberos and lockout policy as well. You shouldn't hopefully
need to do it much with the former but there are times where I wish
I had it available because the only other option was to open the
policy for the entire domain regardless of the stupidity of the
idea from a security standpoint.
This has been a discussion point inside of MSFT for quite a long
time now and I can assure you that anything that gets
implemented/released went through considerable discussion by the
developers inside of MSFT and to people outside outside of MSFT.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
________________________________________________________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Crawford,
Scott
Sent: Friday, September 01, 2006 4:08 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Seperate Administrator password policy
Ø of plans to allow setting password policies at the OU level
What would be the direction they'd go to implement this? Since the
setting is in the computer section of the GPO, it seems to offer
all the functionality one should expect. And in fact, it is
applicable at the OU level and it applies to computers [1]. It
seems that the major reason people want to be able to set the
policy at the OU level is so that it applies to users. The issue
is that it's a computer setting, not a user setting. IMHO, the
only way to allow different password policies for different users,
is to move the settings to the user section of the GPO.
[1] It confuses me somewhat why DCs insist on pulling this from DDP
instead of just assembling the policy, like any other, from all
applicable GPOs. I assume it was done to avoid a situation where
two DCs could have different policies applied to them and depending
on what DC handled your password change, you would be subject to
different rules. If that's the case, I can't say I'm a big fan of
illogical hacks to help out less-cluefull admins.
________________________________________________________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Grillenmeier, Guido
Sent: Thursday, August 31, 2006 7:58 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Seperate Administrator password policy
Agree, a separate domain is certainly a very high price to pay -
it'll cause ongoing headaches with very little benefit. Other
companies add requirements for smartcard logons for Admins or also
solve it via organizational rules as mentioned by ZV.
I've heard of plans to allow setting password policies at the OU
level for Longhorn AD, which is due out mid next year. This could
be wishful thinking (has been a request for quite some time), but I
hope they make it.
/Guido
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Za Vue
Sent: Thursday, August 31, 2006 2:39 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Seperate Administrator password policy
Would it be easier just to ask them to use 15 characters? Run a
small script to check on the numbers of characters after the
passwords have been changed. If under 15 than ask them to change it
again.
-Z.V.
Almeida Pinto, Jorge de wrote:
third party software could be an option
for example: http://www.anixis.com/products/ppe/default.htm
jorge
________________________________________________________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Bahta, Nathaniel V CTR USAF NASIC/SCNA
Sent: Thursday, August 31, 2006 14:15
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Seperate Administrator password
policy
Just wanted to field this to see if it makes any sense
to any of you guys.
We are going to implement a mandatory 15 character password
policy for all of our administrator accounts. The only way
that makes sense is a subdomain with a separate password
policy, since there is only one per domain. I also know that
I have to edit the minPwdLength attribute and the uASCompat
attribute to make this work on the subdomain. Can anyone
think of another method of doing this?
Thanks,
Nate Bahta
This e-mail and any attachment is for authorised use by the
intended recipient(s) only. It may contain proprietary material,
confidential information and/or be subject to legal privilege. It
should not be copied, disclosed to, retained or used by, any other
party. If you are not an intended recipient then please promptly
delete this e-mail and any attachment and all copies and inform the
sender. Thank you.
List info : http://www.activedir.org/List.aspx List FAQ :
http://www.activedir.org/ListFAQ.aspx List archive:
http://www.activedir.org/ml/threads.aspx
