With this one, it wouldn't. This is one of the most commonly requested things in AD history. No one needs to be reminded, it's all about schedule now.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Saturday, September 02, 2006 12:43 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Seperate Administrator password policy ...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 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
