...you know a few Longhorn bugs filed on this might help
(hint hint)
Grillenmeier, Guido wrote:
;-) thanks for the feedback anyways Eric – it gives us an idea that we
shouldn’t build our hopes too high for the multiple-password-policies
feature at this stage in the LH development phase. But I’ll keep
hoping anyways.
/Guido
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Eric Fleischman
*Sent:* Saturday, September 02, 2006 6:25 PM
*To:* ActiveDir@mail.activedir.org
*Subject:* RE: [ActiveDir] Seperate Administrator password policy
Is this a serious question? I have no idea. If I knew, not only would
I do this, but I’d run out and buy a lotto ticket immediately. <g>
This isn’t about NDA or not. We can’t see in to the future like this.
We do our best to build as much as we can. At some point, the gates
close. What makes it in is quazi-predictable, but not to the level
you’re asking for.
~Eric
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of
*Grillenmeier, Guido
*Sent:* Saturday, September 02, 2006 2:15 AM
*To:* ActiveDir@mail.activedir.org
*Subject:* RE: [ActiveDir] Seperate Administrator password policy
Eric,
can you already state publicly, what the chance of this feature is to
make it into Longhorn, if at all? Or is this still NDA?
Thanks,
Guido
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Eric Fleischman
*Sent:* Saturday, September 02, 2006 6:32 AM
*To:* ActiveDir@mail.activedir.org
*Subject:* RE: [ActiveDir] Seperate Administrator password policy
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]>
[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
<mailto: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
