RE: [ActiveDir] ou delegation - change password at next logon
For W2K3: To reset user passwords you need the Reset Password extended right on the user object. This is also available through the delegation of control wizard using the common delegated task Reset a user account's password If you want to reset user passwords and force password change at next logon you need the Reset Password extended right on the user object and you need Read/Write permissions on the attribute pwdLastSet. This is also available through the delegation of control wizard using the common delegated task Reset user passwords and force password change at next logon Look at the delegwiz.inf from W2K3 for the Reset user passwords and force password change at next logon and use that in the delegwiz.inf of W2K Cheers, jorge -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Tuesday, March 28, 2006 16:45 To: activedir@mail.activedir.org Subject: [ActiveDir] ou delegation - change password at next logon Dear all, was wondering if someone could give us a view on the delegation of the 'user must change password at next logon' it seems that having applied the delegation (using Windows 2000 delegation wizard on a Windows 2000 domain) that allows 'reset password on user objects' , the delegate can check the box from ADUC, but this does not in fact set the above attribute it would seem that we are going to need to apply a custom delegation, from which it is not immediately obvious how to delegate the setting of this attribute. would anyone be able to offer a 'walkthrough' using the Windows 2000 delegate control wizard ?? Thanks GT List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ 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.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] ou delegation - change password at next logon
Graham, According to the Best Practices for Delegating Active Directory, this is what you need to do: 1. write properties on user object to modify User-Password attribute 2. write properties on user object to modify User-Force-Change-Password extended right Or 1. write properties on user object to modify Pwd-Last-Set attribute Dunno if these are accessible via the delegation wizard. :m:dsm:cci:mvp | marcusoh.blogspot.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Tuesday, March 28, 2006 9:45 AM To: activedir@mail.activedir.org Subject: [ActiveDir] ou delegation - change password at next logon Dear all, was wondering if someone could give us a view on the delegation of the 'user must change password at next logon' it seems that having applied the delegation (using Windows 2000 delegation wizard on a Windows 2000 domain) that allows 'reset password on user objects' , the delegate can check the box from ADUC, but this does not in fact set the above attribute it would seem that we are going to need to apply a custom delegation, from which it is not immediately obvious how to delegate the setting of this attribute. would anyone be able to offer a 'walkthrough' using the Windows 2000 delegate control wizard ?? Thanks GT List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] ou delegation - change password at next logon
If you're an IT Pro mag subscriber, check this out: http://www.windowsitpro.com/Article/ArticleID/41105/41105.html If not, here's a QUICK summary... 1) At the BOTTOM of this message, copy and everything. ON THE MACHINE *FROM* WHICH YOU DO YOUR DELEGATION (i.e. your machine) 2) BACK UP %windir%\inf\delegwiz.inf 3) REPLACE it with the text you copied below. 4) ALSO back up the 'new' file, since a service pack could theoretically stomp back on the old lame file 5) Re-launch ADUC and you'll now see exactly the task you need to delegate in the delegation of control wizard. You need reset password (a 'control right') and specify user must change password at next logon (a permission to change the pwdLastSet attribute of the user account -- setting it to 0 forces change at next logon; and when you check the box in the UI, you're setting it to 0). If by some chance you're coming to Windows Connections in Orlando, I'll be doing this at my delegation session as an example. Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Tuesday, March 28, 2006 7:45 AM To: activedir@mail.activedir.org Subject: [ActiveDir] ou delegation - change password at next logon Dear all, was wondering if someone could give us a view on the delegation of the 'user must change password at next logon' it seems that having applied the delegation (using Windows 2000 delegation wizard on a Windows 2000 domain) that allows 'reset password on user objects' , the delegate can check the box from ADUC, but this does not in fact set the above attribute it would seem that we are going to need to apply a custom delegation, from which it is not immediately obvious how to delegate the setting of this attribute. would anyone be able to offer a 'walkthrough' using the Windows 2000 delegate control wizard ?? Thanks GT List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ =START COPYING BELOW [Version] signature=$CHICAGO$ [DelegationTemplates] Templates = template1, template2, template3, template4, template5, template6, template7, template8, template9, template10, template11, template12, template13, template14, template15, template16, template17, template18, template19, template20, template21, template22, template23,template24, template25, template26, template27, template28, template29, template30, template31, template32, template33,template34, template35, template36, template37, template38, template39, template40, template41, template42, template43,template44, template45, template46, template47, template48, template49, template50, template51, template52, template53,template54, template55, template56, template57, template58, template59, template60, template61, template62, template63,template64, template65, template66, template67, template68, template69, template70 ;- [template1] AppliesToClasses=domainDNS,organizationalUnit,container Description = Create, delete, and manage user accounts ObjectTypes = SCOPE, user [template1.SCOPE] user=CC,DC [template1.user] @=GA ;- ;- [template2] AppliesToClasses=domainDNS,organizationalUnit,container Description = Reset user passwords and force password change at next logon ObjectTypes = user [template2.user] CONTROLRIGHT= Reset Password pwdLastSet=RP,WP ;-- ;-- [template3] AppliesToClasses=domainDNS,organizationalUnit,container Description = Read all user information ObjectTypes = user [template3.user] @=RP ;-- [template4] AppliesToClasses = organizationalUnit,container Description = Create, delete and manage groups ObjectTypes = SCOPE, group [template4.SCOPE] group=CC,DC [template4.group] @=GA ;-- ;-- [template5] AppliesToClasses=domainDNS,organizationalUnit,container Description = Modify the membership of a group ObjectTypes = group [template5.group] member=RP,WP ;-- ;-- [template6] AppliesToClasses = domainDNS Description = Join a computer to the domain ObjectTypes = SCOPE [template6.SCOPE] computer=CC ;-- ;-- [template7] AppliesToClasses = domainDNS,organizationalUnit,site Description = Manage Group Policy links ObjectTypes = SCOPE [template7.SCOPE] gPLink=RP,WP gPOptions=RP,WP
RE: [ActiveDir] OU Delegation
fully agree with Gil. And besides this, people forget that there is a more important "safe haven" that comes natively with the OS, which doesn't at all require the overhead of a separate root = it's the "Safe Mode" feature that you can also use to boot a DC into (don't confuse this with the Directory Services Restore Mode, which is a special option of the Safe Mode). When booted in safe mode, the OS will boot with a minimal set of drivers and services - nice thing when used on a DC is that AD is actually active and special rules apply for the DC in this mode. For example for logon: you will always be able to logon with the default administrator account even if some script or GPO has done damage to your domain (such as the given example oflockdown of all users via GPO), disabling all accounts (incl. the def. administrator, which is possible in Win2003), or adding all accounts to more groups than the normal logon can handle (also called the token bloat attack). It does become critical that the default administrator's password is known - and since this won't typcially be used for everyday administration, it's a good practise to keep it in a safe somewhere offline. As such understanding your options is critical when discussing the need (or not) for a separate root domain. Covering your a__ for (untested) GPO changes should not be one of them. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Donnerstag, 19. Januar 2006 19:58To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation when the GPO guys screwed up on the main account domains. The locked down EVERY single userid to kiosk mode Most people mitigate this sort of risk by technical review, automating the change app lication, and testing in a separate test forest. I can't see creating a separate domain as a "safe haven" for screwups like that. And it doesn't provide a safe haven from lots of other potential screwups like replication topology changes or schema mods. -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, January 19, 2006 11:10 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Exactly. There are good reasons forand against both multiple domains (including empty) and multiple forests. As a safe haven from domain level GPOs or finalQA point for domain level modificationsare things I wouldn't push against. Does it make sense for everyone? Depends on your management structure and concerns - some will see that as an issue that could impact them, others could see it as nothing. As a security barrier to protect hacking of the enterprise/schema admin is one I would pushagainst because it doesn't actually do anything to help that. Organization of the forest is one that could easily go either way, tough to argue it as it really isn't technically based. In larger multidomain environments, I tend to like empty roots because the overhead is usually quite minimal in relation to everything else and it is a great place to deploy new patches, etc. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Thursday, January 19, 2006 9:55 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation candid=on As we've heard before today - do a cost/benefit study. Is it really prudent to build an extra domain with the incurred over heads just in case someone makes a mistake? There are doubtless other mistakes which can only mitigated by building a separate forest. There may be good reasons (and bad ones too) for building a placeholder domain - these reasons need to be weighed against the incurred costs (over at least a 3 year period). candid=off neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky HabeebSent: 19 January 2006 14:37To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation "The biggest thing about an empty forest root is it is a safe haven. Safe haven: A domain where the god rights live and you don't apply any gpo's or other things that can get out of hand and hurt you. This actually saved my a__ once at [deleted] when the GPO guys screwed up on the main account domains. The locked down EVERY single userid to kiosk mode. Fortunately they have no rights in the root domain so couldn't do anything to my IDs so I could log onto my PC with the forest root ID and undo what they did." Verbatim quote fromone of the top [I mean "REALLY TOP] AD guys on this list to me in an offline when I asked him about whether or not I should do an empty root. I did it. RH _ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of joeSent: Wednesday, January 18, 2006 8:13 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegatio
RE: [ActiveDir] OU Delegation
Of course you do. ;o) Once again though let me state that I consider this something else to add to the stack of reasons if already considering the empty root. You don't even have to go through the stuff you mention below if you know what you are doing to break back in. You simply use a machine that isn't in the domain (even a Linux machine will do)and connect to the DCs across the network and manage it that way like by smoking the AD gplinks or whatever. However, I would honestly consider that beyond at least 80% of the AD admins in existence without someone walking them through it.All admin accounts disabled in some way obviously will take some form of direct access. Also again, it isn't necessarily going to be an untested GPO that bites you. Something that could have been tested for 6 months and worked perfectly every time could go assup on application into production (especially if you are using GPOs filtered via ACLing) that could cause very undesirable results. Overall I think the jump from one domain to two to add an empty root is a harder jump than a jump from x (with x1)to x+1 to add an empty root is not as hard a jump. I don't think that an empty root is the end all be all answer but it doesn't bother me much when I see them either unless someone did it entirely because they think it protects the schema and enterprise admins which A LOT of people did do because of a lot of bad advice. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, GuidoSent: Sunday, January 22, 2006 3:01 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation fully agree with Gil. And besides this, people forget that there is a more important "safe haven" that comes natively with the OS, which doesn't at all require the overhead of a separate root = it's the "Safe Mode" feature that you can also use to boot a DC into (don't confuse this with the Directory Services Restore Mode, which is a special option of the Safe Mode). When booted in safe mode, the OS will boot with a minimal set of drivers and services - nice thing when used on a DC is that AD is actually active and special rules apply for the DC in this mode. For example for logon: you will always be able to logon with the default administrator account even if some script or GPO has done damage to your domain (such as the given example oflockdown of all users via GPO), disabling all accounts (incl. the def. administrator, which is possible in Win2003), or adding all accounts to more groups than the normal logon can handle (also called the token bloat attack). It does become critical that the default administrator's password is known - and since this won't typcially be used for everyday administration, it's a good practise to keep it in a safe somewhere offline. As such understanding your options is critical when discussing the need (or not) for a separate root domain. Covering your a__ for (untested) GPO changes should not be one of them. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Donnerstag, 19. Januar 2006 19:58To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation when the GPO guys screwed up on the main account domains. The locked down EVERY single userid to kiosk mode Most people mitigate this sort of risk by technical review, automating the change app lication, and testing in a separate test forest. I can't see creating a separate domain as a "safe haven" for screwups like that. And it doesn't provide a safe haven from lots of other potential screwups like replication topology changes or schema mods. -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, January 19, 2006 11:10 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Exactly. There are good reasons forand against both multiple domains (including empty) and multiple forests. As a safe haven from domain level GPOs or finalQA point for domain level modificationsare things I wouldn't push against. Does it make sense for everyone? Depends on your management structure and concerns - some will see that as an issue that could impact them, others could see it as nothing. As a security barrier to protect hacking of the enterprise/schema admin is one I would pushagainst because it doesn't actually do anything to help that. Organization of the forest is one that could easily go either way, tough to argue it as it really isn't technically based. In larger multidomain environments, I tend to like empty roots because the overhead is usually quite minimal in relation to everything else and it is a great place to deploy new patches, etc. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Thursday, January 19, 2006 9:55 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation candid=
RE: [ActiveDir] OU Delegation
candid=on As we've heard before today - do a cost/benefit study. Is it really prudent to build an extra domain with the incurred over heads just in case someone makes a mistake? There are doubtless other mistakes which can only mitigated by building a separate forest. There may be good reasons (and bad ones too) for building a placeholder domain - these reasons need to be weighed against the incurred costs (over at least a 3 year period). candid=off neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky HabeebSent: 19 January 2006 14:37To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation "The biggest thing about an empty forest root is it is a safe haven. Safe haven: A domain where the god rights live and you don't apply any gpo's or other things that can get out of hand and hurt you. This actually saved my a__ once at [deleted] when the GPO guys screwed up on the main account domains. The locked down EVERY single userid to kiosk mode. Fortunately they have no rights in the root domain so couldn't do anything to my IDs so I could log onto my PC with the forest root ID and undo what they did." Verbatim quote fromone of the top [I mean "REALLY TOP] AD guys on this list to me in an offline when I asked him about whether or not I should do an empty root. I did it. RH _ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of joeSent: Wednesday, January 18, 2006 8:13 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Well I didn't say I don't see the benefit of an empty root. I just don't see it as a generic best practice. Sometimes it makes a ton of sense, sometimes someone needs to be slapped for bringing it up. ;o) joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Wednesday, January 18, 2006 5:11 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Boy, I just had a consultant recommend an empty root as best practice for a divestiture were doing. Like Gil and Joe, I really dont see the benefit (nor could the consultant name anything specifically). We have a single domain and delegate OU rights based basically on an administrative teams need to manage a group of resources, typically computers. Users, groups and Exchange are managed centrally. Moving things around within one domain is a whole lot easier than among domains. AL Al Maurer Service Manager, Naming and Authentication Services IT | Information Technology Agilent Technologies (719) 590-2639; Telnet 590-2639 http://activedirectory.it.agilent.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Thursday, January 12, 2006 10:50 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation As joe says, "it depends". AD architecture is always a cost/benefit discussion, and most people don't really understand 1) the real benefits of multiple domains, and 2) the additional costs of running multiple domains. For instance, "additional security" is often cited as a benefit of an empty root. An empty root maybe provides a little additional security, but not much. The benefit depends on your own risk evaluation. On the other hand, the ongoing operational cost of a two domainforestis considerably higher than a single domain forest. Additional hardware costs, additional diagnostic complexity, and a more complicated DR situation all add to the costs of running multiple domains. My general recommendationis tostick with a single domain if you can, and add additional domains if you need to for password policy or controlling replicationtraffic. And if you find you have to have multiple domains anyway, use an empty root, because the incremental cost of an additional domain if you already have more than one is pretty small. But, "it depends". -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, January 12, 2006 9:32 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Ah good ol best practices. :) What is recommended? Whatever is best for the customer of course. I guess my question is why one domain and one root versus just one domain? What is the purpose of the root? I am not saying this is bad by any stretch, there are good valid reasons for a root with other domains hanging off of it. Just curious what the decision flow was like to do it. Hopefully it wasn't something along the lines of reading "an empty root" is good somewhere and going for it as it is totally context sensitive. I would s
RE: [ActiveDir] OU Delegation
"The biggest thing about an empty forest root is it is a safe haven. Safe haven: A domain where the god rights live and you don't apply any gpo's or other things that can get out of hand and hurt you. This actually saved my a__ once at [deleted] when the GPO guys screwed up on the main account domains. The locked down EVERY single userid to kiosk mode. Fortunately they have no rights in the root domain so couldn't do anything to my IDs so I could log onto my PC with the forest root ID and undo what they did." Verbatim quote fromone of the top [I mean "REALLY TOP] AD guys on this list to me in an offline when I asked him about whether or not I should do an empty root. I did it. RH _ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of joeSent: Wednesday, January 18, 2006 8:13 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Well I didn't say I don't see the benefit of an empty root. I just don't see it as a generic best practice. Sometimes it makes a ton of sense, sometimes someone needs to be slapped for bringing it up. ;o) joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Wednesday, January 18, 2006 5:11 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Boy, I just had a consultant recommend an empty root as best practice for a divestiture were doing. Like Gil and Joe, I really dont see the benefit (nor could the consultant name anything specifically). We have a single domain and delegate OU rights based basically on an administrative teams need to manage a group of resources, typically computers. Users, groups and Exchange are managed centrally. Moving things around within one domain is a whole lot easier than among domains. AL Al Maurer Service Manager, Naming and Authentication Services IT | Information Technology Agilent Technologies (719) 590-2639; Telnet 590-2639 http://activedirectory.it.agilent.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Thursday, January 12, 2006 10:50 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation As joe says, "it depends". AD architecture is always a cost/benefit discussion, and most people don't really understand 1) the real benefits of multiple domains, and 2) the additional costs of running multiple domains. For instance, "additional security" is often cited as a benefit of an empty root. An empty root maybe provides a little additional security, but not much. The benefit depends on your own risk evaluation. On the other hand, the ongoing operational cost of a two domainforestis considerably higher than a single domain forest. Additional hardware costs, additional diagnostic complexity, and a more complicated DR situation all add to the costs of running multiple domains. My general recommendationis tostick with a single domain if you can, and add additional domains if you need to for password policy or controlling replicationtraffic. And if you find you have to have multiple domains anyway, use an empty root, because the incremental cost of an additional domain if you already have more than one is pretty small. But, "it depends". -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, January 12, 2006 9:32 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Ah good ol best practices. :) What is recommended? Whatever is best for the customer of course. I guess my question is why one domain and one root versus just one domain? What is the purpose of the root? I am not saying this is bad by any stretch, there are good valid reasons for a root with other domains hanging off of it. Just curious what the decision flow was like to do it. Hopefully it wasn't something along the lines of reading "an empty root" is good somewhere and going for it as it is totally context sensitive. I would say the overall design goal, especially when Exchange is involved is to use a single domain forest. However, if there is a good reason to add more domains, do it. Usually when someone says they have a domain and a root they mean they have a domain and an EMPTY root and I wonder about how the decision was arrived at. We have had this discussion previously on the list where some people are gung ho empty root and some people are gung ho no-empty root and both pointing at best practices. I am more of the does it make sense in this specific situation kind of person. From: [EMAIL PROTE
RE: [ActiveDir] OU Delegation
Exactly. There are good reasons forand against both multiple domains (including empty) and multiple forests. As a safe haven from domain level GPOs or finalQA point for domain level modificationsare things I wouldn't push against. Does it make sense for everyone? Depends on your management structure and concerns - some will see that as an issue that could impact them, others could see it as nothing. As a security barrier to protect hacking of the enterprise/schema admin is one I would pushagainst because it doesn't actually do anything to help that. Organization of the forest is one that could easily go either way, tough to argue it as it really isn't technically based. In larger multidomain environments, I tend to like empty roots because the overhead is usually quite minimal in relation to everything else and it is a great place to deploy new patches, etc. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Thursday, January 19, 2006 9:55 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation candid=on As we've heard before today - do a cost/benefit study. Is it really prudent to build an extra domain with the incurred over heads just in case someone makes a mistake? There are doubtless other mistakes which can only mitigated by building a separate forest. There may be good reasons (and bad ones too) for building a placeholder domain - these reasons need to be weighed against the incurred costs (over at least a 3 year period). candid=off neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky HabeebSent: 19 January 2006 14:37To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation "The biggest thing about an empty forest root is it is a safe haven. Safe haven: A domain where the god rights live and you don't apply any gpo's or other things that can get out of hand and hurt you. This actually saved my a__ once at [deleted] when the GPO guys screwed up on the main account domains. The locked down EVERY single userid to kiosk mode. Fortunately they have no rights in the root domain so couldn't do anything to my IDs so I could log onto my PC with the forest root ID and undo what they did." Verbatim quote fromone of the top [I mean "REALLY TOP] AD guys on this list to me in an offline when I asked him about whether or not I should do an empty root. I did it. RH _ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of joeSent: Wednesday, January 18, 2006 8:13 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Well I didn't say I don't see the benefit of an empty root. I just don't see it as a generic best practice. Sometimes it makes a ton of sense, sometimes someone needs to be slapped for bringing it up. ;o) joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Wednesday, January 18, 2006 5:11 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Boy, I just had a consultant recommend an empty root as best practice for a divestiture were doing. Like Gil and Joe, I really dont see the benefit (nor could the consultant name anything specifically). We have a single domain and delegate OU rights based basically on an administrative teams need to manage a group of resources, typically computers. Users, groups and Exchange are managed centrally. Moving things around within one domain is a whole lot easier than among domains. AL Al Maurer Service Manager, Naming and Authentication Services IT | Information Technology Agilent Technologies (719) 590-2639; Telnet 590-2639 http://activedirectory.it.agilent.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Thursday, January 12, 2006 10:50 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation As joe says, "it depends". AD architecture is always a cost/benefit discussion, and most people don't really understand 1) the real benefits of multiple domains, and 2) the additional costs of running multiple domains. For instance, "additional security" is often cited as a benefit of an empty root. An empty root maybe provides a little additional security, but not much. The benefit depends on your own risk evaluation. On the other hand, the ongoing operational cost of a two domainforestis considerably higher than a single domain forest. Additional hardware costs, additional diagnostic complexity, and a more complicated DR situation all add to the costs of running multiple domains. My general recommendationis tostick with a single domain if you can, and add additional domains if you need to
RE: [ActiveDir] OU Delegation
when the GPO guys screwed up on the main account domains. The locked down EVERY single userid to kiosk mode Most people mitigate this sort of risk by technical review, automating the change app lication, and testing in a separate test forest. I can't see creating a separate domain as a "safe haven" for screwups like that. And it doesn't provide a safe haven from lots of other potential screwups like replication topology changes or schema mods. -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, January 19, 2006 11:10 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Exactly. There are good reasons forand against both multiple domains (including empty) and multiple forests. As a safe haven from domain level GPOs or finalQA point for domain level modificationsare things I wouldn't push against. Does it make sense for everyone? Depends on your management structure and concerns - some will see that as an issue that could impact them, others could see it as nothing. As a security barrier to protect hacking of the enterprise/schema admin is one I would pushagainst because it doesn't actually do anything to help that. Organization of the forest is one that could easily go either way, tough to argue it as it really isn't technically based. In larger multidomain environments, I tend to like empty roots because the overhead is usually quite minimal in relation to everything else and it is a great place to deploy new patches, etc. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Thursday, January 19, 2006 9:55 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation candid=on As we've heard before today - do a cost/benefit study. Is it really prudent to build an extra domain with the incurred over heads just in case someone makes a mistake? There are doubtless other mistakes which can only mitigated by building a separate forest. There may be good reasons (and bad ones too) for building a placeholder domain - these reasons need to be weighed against the incurred costs (over at least a 3 year period). candid=off neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky HabeebSent: 19 January 2006 14:37To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation "The biggest thing about an empty forest root is it is a safe haven. Safe haven: A domain where the god rights live and you don't apply any gpo's or other things that can get out of hand and hurt you. This actually saved my a__ once at [deleted] when the GPO guys screwed up on the main account domains. The locked down EVERY single userid to kiosk mode. Fortunately they have no rights in the root domain so couldn't do anything to my IDs so I could log onto my PC with the forest root ID and undo what they did." Verbatim quote fromone of the top [I mean "REALLY TOP] AD guys on this list to me in an offline when I asked him about whether or not I should do an empty root. I did it. RH _ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of joeSent: Wednesday, January 18, 2006 8:13 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Well I didn't say I don't see the benefit of an empty root. I just don't see it as a generic best practice. Sometimes it makes a ton of sense, sometimes someone needs to be slapped for bringing it up. ;o) joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Wednesday, January 18, 2006 5:11 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Boy, I just had a consultant recommend an empty root as best practice for a divestiture were doing. Like Gil and Joe, I really dont see the benefit (nor could the consultant name anything specifically). We have a single domain and delegate OU rights based basically on an administrative teams need to manage a group of resources, typically computers. Users, groups and Exchange are managed centrally. Moving things around within one domain is a whole lot easier than among domains. AL Al Maurer Service Manager, Naming and Authentication Services IT | Information Technology Agilent Technologies (719) 590-2639; Telnet 590-2639 http://activedirectory.it.agilent.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Thursday, January 12, 2006 10:50 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation As joe says, "it depends". AD architecture is always a cost/benefit discussion, and most people don't really understand 1) the real benefits of multiple domains, and 2) the additiona
RE: [ActiveDir] OU Delegation
I agree wholeheartedly. GP has lots of potential for causing major headaches across thousands of machines at onceand yet I'm amazed at how few folks I come across practice good change management on them the way they would when rolling out any new application update or patch. In Win2K days it was a bit harder, but with GPMC, RSOPand the myriad of 3rd party tools on the market for change control, the implementation of "accidental"and disruptiveGP changes should be a thing of the past. "Should be" being the operative phrase :). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Thursday, January 19, 2006 10:58 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation when the GPO guys screwed up on the main account domains. The locked down EVERY single userid to kiosk mode Most people mitigate this sort of risk by technical review, automating the change app lication, and testing in a separate test forest. I can't see creating a separate domain as a "safe haven" for screwups like that. And it doesn't provide a safe haven from lots of other potential screwups like replication topology changes or schema mods. -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, January 19, 2006 11:10 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Exactly. There are good reasons forand against both multiple domains (including empty) and multiple forests. As a safe haven from domain level GPOs or finalQA point for domain level modificationsare things I wouldn't push against. Does it make sense for everyone? Depends on your management structure and concerns - some will see that as an issue that could impact them, others could see it as nothing. As a security barrier to protect hacking of the enterprise/schema admin is one I would pushagainst because it doesn't actually do anything to help that. Organization of the forest is one that could easily go either way, tough to argue it as it really isn't technically based. In larger multidomain environments, I tend to like empty roots because the overhead is usually quite minimal in relation to everything else and it is a great place to deploy new patches, etc. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Thursday, January 19, 2006 9:55 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation candid=on As we've heard before today - do a cost/benefit study. Is it really prudent to build an extra domain with the incurred over heads just in case someone makes a mistake? There are doubtless other mistakes which can only mitigated by building a separate forest. There may be good reasons (and bad ones too) for building a placeholder domain - these reasons need to be weighed against the incurred costs (over at least a 3 year period). candid=off neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky HabeebSent: 19 January 2006 14:37To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation "The biggest thing about an empty forest root is it is a safe haven. Safe haven: A domain where the god rights live and you don't apply any gpo's or other things that can get out of hand and hurt you. This actually saved my a__ once at [deleted] when the GPO guys screwed up on the main account domains. The locked down EVERY single userid to kiosk mode. Fortunately they have no rights in the root domain so couldn't do anything to my IDs so I could log onto my PC with the forest root ID and undo what they did." Verbatim quote fromone of the top [I mean "REALLY TOP] AD guys on this list to me in an offline when I asked him about whether or not I should do an empty root. I did it. RH _ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of joeSent: Wednesday, January 18, 2006 8:13 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Well I didn't say I don't see the benefit of an empty root. I just don't see it as a generic best practice. Sometimes it makes a ton of sense, sometimes someone needs to be slapped for bringing it up. ;o) joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Wednesday, January 18, 2006 5:11 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Boy, I just had a consultant recommend an empty root as best practice for a divestiture were doing. Like Gil and Joe, I really dont see the benefit (nor could the consultant name anything specifically). We have a single domain and delegate OU rights based basically on an administrative teams need to manage a group of resources, typically computers. Users, groups and Exchange are m
RE: [ActiveDir] OU Delegation
Even with thorough review and testing things can go still go wrong, say a script or tool that is supposed to lock down an ACL doesn't for some odd reason though it did in test every single time. I wouldn't say that safe haven in and of itself is a reason to have an empty root unless the parties involved felt strongly enough about that particular issue. But it is, IMO,good to add to the list of possible reasons. It is aways a case of balancing the pros and cons and arriving at an answer that fits the specific case. I have been witness to several really evil or bad things or at least things generally considered to be so but acclimating myself to them when you hear all of the details and don't see any other solution. Often permissioning and delegation seems to be a pick the lesser of multiple evils situation, especially when doing things like trying to put in admin separation for separation of duties between things like Exchange and AD ops if the company or management isn't willing to invest in or support acomplete provisioning solution. Completely agree on replication topo changes and schema mods. I came from an environment where getting a schema mod through the system and accomplished in less than 6 months would have been a miracle, and yet, still, there is stuff in that schema that never should have made it in and was never used. Why? Because there are people in every company that have the weight to push things through that properlythinking people wouldn't allow. I recall one cool issue where a new logon script was put into place on all users and the way it was written if there wasn't enough environment space the logon script would delete every file on the C: drive. Hundreds if not thousands of people all over the country were logging help desk tickets because their workstations crashed and burned and everyone thought there was a virus. This was a change that got pushed through even though myself and my manager fought it like they were trying to take away our magic 8-ball (which we made all serious decisions with). We didn't know that would happen but I had a strict rule of don't do complicated things with logon scripts because if it screws up, people will interpret that as a logon issue. In the end, the logon scripts were still used for this type of heavy duty stuff(software installs, etc)which I personally still to this day think is abad idea. People aren't logging on for fun, they are logging on to get work done. If you don't let them do that, tough for them to get the work done. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Thursday, January 19, 2006 1:58 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation when the GPO guys screwed up on the main account domains. The locked down EVERY single userid to kiosk mode Most people mitigate this sort of risk by technical review, automating the change app lication, and testing in a separate test forest. I can't see creating a separate domain as a "safe haven" for screwups like that. And it doesn't provide a safe haven from lots of other potential screwups like replication topology changes or schema mods. -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, January 19, 2006 11:10 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Exactly. There are good reasons forand against both multiple domains (including empty) and multiple forests. As a safe haven from domain level GPOs or finalQA point for domain level modificationsare things I wouldn't push against. Does it make sense for everyone? Depends on your management structure and concerns - some will see that as an issue that could impact them, others could see it as nothing. As a security barrier to protect hacking of the enterprise/schema admin is one I would pushagainst because it doesn't actually do anything to help that. Organization of the forest is one that could easily go either way, tough to argue it as it really isn't technically based. In larger multidomain environments, I tend to like empty roots because the overhead is usually quite minimal in relation to everything else and it is a great place to deploy new patches, etc. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Thursday, January 19, 2006 9:55 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation candid=on As we've heard before today - do a cost/benefit study. Is it really prudent to build an extra domain with the incurred over heads just in case someone makes a mistake? There are doubtless other mistakes which can only mitigated by building a separate forest. There may be good reasons (and bad ones too) for building a placeholder domain - these reasons need to be weighed against the incurred costs (over at least a 3 year period). candid=off neil From: [EMAIL
RE: [ActiveDir] OU Delegation
"Should be" being the operative phrase Exactly. I have a phrase I like to use to describe that "Theory meet Reality." From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-EliaSent: Thursday, January 19, 2006 2:59 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation I agree wholeheartedly. GP has lots of potential for causing major headaches across thousands of machines at onceand yet I'm amazed at how few folks I come across practice good change management on them the way they would when rolling out any new application update or patch. In Win2K days it was a bit harder, but with GPMC, RSOPand the myriad of 3rd party tools on the market for change control, the implementation of "accidental"and disruptiveGP changes should be a thing of the past. "Should be" being the operative phrase :). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Thursday, January 19, 2006 10:58 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation when the GPO guys screwed up on the main account domains. The locked down EVERY single userid to kiosk mode Most people mitigate this sort of risk by technical review, automating the change app lication, and testing in a separate test forest. I can't see creating a separate domain as a "safe haven" for screwups like that. And it doesn't provide a safe haven from lots of other potential screwups like replication topology changes or schema mods. -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, January 19, 2006 11:10 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Exactly. There are good reasons forand against both multiple domains (including empty) and multiple forests. As a safe haven from domain level GPOs or finalQA point for domain level modificationsare things I wouldn't push against. Does it make sense for everyone? Depends on your management structure and concerns - some will see that as an issue that could impact them, others could see it as nothing. As a security barrier to protect hacking of the enterprise/schema admin is one I would pushagainst because it doesn't actually do anything to help that. Organization of the forest is one that could easily go either way, tough to argue it as it really isn't technically based. In larger multidomain environments, I tend to like empty roots because the overhead is usually quite minimal in relation to everything else and it is a great place to deploy new patches, etc. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Thursday, January 19, 2006 9:55 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation candid=on As we've heard before today - do a cost/benefit study. Is it really prudent to build an extra domain with the incurred over heads just in case someone makes a mistake? There are doubtless other mistakes which can only mitigated by building a separate forest. There may be good reasons (and bad ones too) for building a placeholder domain - these reasons need to be weighed against the incurred costs (over at least a 3 year period). candid=off neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky HabeebSent: 19 January 2006 14:37To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation "The biggest thing about an empty forest root is it is a safe haven. Safe haven: A domain where the god rights live and you don't apply any gpo's or other things that can get out of hand and hurt you. This actually saved my a__ once at [deleted] when the GPO guys screwed up on the main account domains. The locked down EVERY single userid to kiosk mode. Fortunately they have no rights in the root domain so couldn't do anything to my IDs so I could log onto my PC with the forest root ID and undo what they did." Verbatim quote fromone of the top [I mean "REALLY TOP] AD guys on this list to me in an offline when I asked him about whether or not I should do an empty root. I did it. RH _ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of joeSent: Wednesday, January 18, 2006 8:13 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Well I didn't say I don't see the benefit of an empty root. I just don't see it as a generic best practice. Sometimes it makes a ton of sense, sometimes someone needs to be slapped for bringing it up. ;o) joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Wednesday, January 18, 2006 5:11 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Boy, I just had a consultant recommend an empt
RE: [ActiveDir] OU Delegation
Boy, I just had a consultant recommend an empty root as best practice for a divestiture were doing. Like Gil and Joe, I really dont see the benefit (nor could the consultant name anything specifically). We have a single domain and delegate OU rights based basically on an administrative teams need to manage a group of resources, typically computers. Users, groups and Exchange are managed centrally. Moving things around within one domain is a whole lot easier than among domains. AL Al Maurer Service Manager, Naming and Authentication Services IT | Information Technology Agilent Technologies (719) 590-2639; Telnet 590-2639 http://activedirectory.it.agilent.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick Sent: Thursday, January 12, 2006 10:50 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation As joe says, it depends. AD architecture is always a cost/benefit discussion, and most people don't really understand 1) the real benefits of multiple domains, and 2) the additional costs of running multiple domains. For instance, additional security is often cited as a benefit of an empty root. An empty root maybe provides a little additional security, but not much. The benefit depends on your own risk evaluation. On the other hand, the ongoing operational cost of a two domainforestis considerably higher than a single domain forest. Additional hardware costs, additional diagnostic complexity, and a more complicated DR situation all add to the costs of running multiple domains. My general recommendationis tostick with a single domain if you can, and add additional domains if you need to for password policy or controlling replicationtraffic. And if you find you have to have multiple domains anyway, use an empty root, because the incremental cost of an additional domain if you already have more than one is pretty small. But, it depends. -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, January 12, 2006 9:32 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation Ah good ol best practices. :) What is recommended? Whatever is best for the customer of course. I guess my question is why one domain and one root versus just one domain? What is the purpose of the root? I am not saying this is bad by any stretch, there are good valid reasons for a root with other domains hanging off of it. Just curious what the decision flow was like to do it. Hopefully it wasn't something along the lines of reading an empty root is good somewhere and going for it as it is totally context sensitive. I would say the overall design goal, especially when Exchange is involved is to use a single domain forest. However, if there is a good reason to add more domains, do it. Usually when someone says they have a domain and a root they mean they have a domain and an EMPTY root and I wonder about how the decision was arrived at. We have had this discussion previously on the list where some people are gung ho empty root and some people are gung ho no-empty root and both pointing at best practices. I am more of the does it make sense in this specific situation kind of person. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, Devon Sent: Thursday, January 12, 2006 11:12 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation Well, I just thought it would be best practice to consolidate multiple domains to one. Whats recommended? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Wednesday, January 11, 2006 7:58 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation You want to look at a couple of main points 1. How do you plan to delegate the permisisons, I.E. the groupings of machines, users, etc. 2. How do you play to do GPOs if at all. 3. How is the administration really going to work. For instance, if you use a provisioning system for managing users (highly recommended) you don't generally want to delegate those to local OU admins but instead keep them in a main OU that the provisioning system only has control to. Why one domain and one root domain? I am not arguing one way or the other, just curious for the reasoning. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, Devon Sent: Wednesday, January 11, 2006 4:24 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] OU Delegation Were in the process of consolidating 21 child domains into just one and one root. We want to separate the divisions (domains) into different OUs. Is there a guide or best practice out there on delegating admin permissions on OUs? Also, weve got Exchange permissions to deal with too. Devon Harding Windows Systems Engineer Southern Wine Spirits - BSG 954-602-2469
RE: [ActiveDir] OU Delegation
Tell him he needs to go to DEC. Its where all the cool AD people go :) -g From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Wednesday, January 18, 2006 3:11 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Boy, I just had a consultant recommend an empty root as best practice for a divestiture were doing. Like Gil and Joe, I really dont see the benefit (nor could the consultant name anything specifically). We have a single domain and delegate OU rights based basically on an administrative teams need to manage a group of resources, typically computers. Users, groups and Exchange are managed centrally. Moving things around within one domain is a whole lot easier than among domains. AL Al Maurer Service Manager, Naming and Authentication Services IT | Information Technology Agilent Technologies (719) 590-2639; Telnet 590-2639 http://activedirectory.it.agilent.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Thursday, January 12, 2006 10:50 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation As joe says, "it depends". AD architecture is always a cost/benefit discussion, and most people don't really understand 1) the real benefits of multiple domains, and 2) the additional costs of running multiple domains. For instance, "additional security" is often cited as a benefit of an empty root. An empty root maybe provides a little additional security, but not much. The benefit depends on your own risk evaluation. On the other hand, the ongoing operational cost of a two domainforestis considerably higher than a single domain forest. Additional hardware costs, additional diagnostic complexity, and a more complicated DR situation all add to the costs of running multiple domains. My general recommendationis tostick with a single domain if you can, and add additional domains if you need to for password policy or controlling replicationtraffic. And if you find you have to have multiple domains anyway, use an empty root, because the incremental cost of an additional domain if you already have more than one is pretty small. But, "it depends". -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, January 12, 2006 9:32 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Ah good ol best practices. :) What is recommended? Whatever is best for the customer of course. I guess my question is why one domain and one root versus just one domain? What is the purpose of the root? I am not saying this is bad by any stretch, there are good valid reasons for a root with other domains hanging off of it. Just curious what the decision flow was like to do it. Hopefully it wasn't something along the lines of reading "an empty root" is good somewhere and going for it as it is totally context sensitive. I would say the overall design goal, especially when Exchange is involved is to use a single domain forest. However, if there is a good reason to add more domains, do it. Usually when someone says they have a domain and a root they mean they have a domain and an EMPTY root and I wonder about how the decision was arrived at. We have had this discussion previously on the list where some people are gung ho empty root and some people are gung ho no-empty root and both pointing at best practices. I am more of the does it make sense in this specific situation kind of person. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, DevonSent: Thursday, January 12, 2006 11:12 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Well, I just thought it would be best practice to consolidate multiple domains to one. Whats recommended? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Wednesday, January 11, 2006 7:58 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation You want to look at a couple of main points 1. How do you plan to delegate the permisisons, I.E. the groupings of machines, users, etc. 2. How do you play to do GPOs if at all. 3. How is the administration really going to work. For instance, if you use a provisioning system for managing users (highly recommended) you don't generally want to delegate those to local OU admins but instead keep them in a main OU that the provisioning system only has control to. Why one domain and one root domain? I am not arguing one way or the other, just curious for the reasoning. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, DevonSent: Wednesday, January 11, 2006 4:24 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] OU Delegation Were in the process of consolidating 21 child domains into just one and one root. We want to separate the divisions (domai
RE: [ActiveDir] OU Delegation
Well, if I were going this time, Id tell you in person which consulting firm he worked for. HINT: its none of the ones weve mentioned in this thread as being AD experts. J Al Maurer Service Manager, Naming and Authentication Services IT | Information Technology Agilent Technologies (719) 590-2639; Telnet 590-2639 http://activedirectory.it.agilent.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick Sent: Wednesday, January 18, 2006 3:56 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation Tell him he needs to go to DEC. Its where all the cool AD people go :) -g From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, January 18, 2006 3:11 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation Boy, I just had a consultant recommend an empty root as best practice for a divestiture were doing. Like Gil and Joe, I really dont see the benefit (nor could the consultant name anything specifically). We have a single domain and delegate OU rights based basically on an administrative teams need to manage a group of resources, typically computers. Users, groups and Exchange are managed centrally. Moving things around within one domain is a whole lot easier than among domains. AL Al Maurer Service Manager, Naming and Authentication Services IT | Information Technology Agilent Technologies (719) 590-2639; Telnet 590-2639 http://activedirectory.it.agilent.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick Sent: Thursday, January 12, 2006 10:50 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation As joe says, it depends. AD architecture is always a cost/benefit discussion, and most people don't really understand 1) the real benefits of multiple domains, and 2) the additional costs of running multiple domains. For instance, additional security is often cited as a benefit of an empty root. An empty root maybe provides a little additional security, but not much. The benefit depends on your own risk evaluation. On the other hand, the ongoing operational cost of a two domainforestis considerably higher than a single domain forest. Additional hardware costs, additional diagnostic complexity, and a more complicated DR situation all add to the costs of running multiple domains. My general recommendationis tostick with a single domain if you can, and add additional domains if you need to for password policy or controlling replicationtraffic. And if you find you have to have multiple domains anyway, use an empty root, because the incremental cost of an additional domain if you already have more than one is pretty small. But, it depends. -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, January 12, 2006 9:32 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation Ah good ol best practices. :) What is recommended? Whatever is best for the customer of course. I guess my question is why one domain and one root versus just one domain? What is the purpose of the root? I am not saying this is bad by any stretch, there are good valid reasons for a root with other domains hanging off of it. Just curious what the decision flow was like to do it. Hopefully it wasn't something along the lines of reading an empty root is good somewhere and going for it as it is totally context sensitive. I would say the overall design goal, especially when Exchange is involved is to use a single domain forest. However, if there is a good reason to add more domains, do it. Usually when someone says they have a domain and a root they mean they have a domain and an EMPTY root and I wonder about how the decision was arrived at. We have had this discussion previously on the list where some people are gung ho empty root and some people are gung ho no-empty root and both pointing at best practices. I am more of the does it make sense in this specific situation kind of person. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, Devon Sent: Thursday, January 12, 2006 11:12 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation Well, I just thought it would be best practice to consolidate multiple domains to one. Whats recommended? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Wednesday, January 11, 2006 7:58 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation You want to look at a couple of main points 1. How do you plan to delegate the permisisons, I.E. the groupings of machines, users, etc. 2. How do you play to do GPOs if at all. 3. How is the administration really going to work. For instance, if you use a provisioning system for managing users (highly recommended) you don't generally want to delegate
RE: [ActiveDir] OU Delegation
I heard you weren't going to make it this year. High suckage factor. -g From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Wednesday, January 18, 2006 4:21 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Well, if I were going this time, Id tell you in person which consulting firm he worked for. HINT: its none of the ones weve mentioned in this thread as being AD experts. J Al Maurer Service Manager, Naming and Authentication Services IT | Information Technology Agilent Technologies (719) 590-2639; Telnet 590-2639 http://activedirectory.it.agilent.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Wednesday, January 18, 2006 3:56 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Tell him he needs to go to DEC. Its where all the cool AD people go :) -g From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Wednesday, January 18, 2006 3:11 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Boy, I just had a consultant recommend an empty root as best practice for a divestiture were doing. Like Gil and Joe, I really dont see the benefit (nor could the consultant name anything specifically). We have a single domain and delegate OU rights based basically on an administrative teams need to manage a group of resources, typically computers. Users, groups and Exchange are managed centrally. Moving things around within one domain is a whole lot easier than among domains. AL Al Maurer Service Manager, Naming and Authentication Services IT | Information Technology Agilent Technologies (719) 590-2639; Telnet 590-2639 http://activedirectory.it.agilent.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Thursday, January 12, 2006 10:50 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation As joe says, "it depends". AD architecture is always a cost/benefit discussion, and most people don't really understand 1) the real benefits of multiple domains, and 2) the additional costs of running multiple domains. For instance, "additional security" is often cited as a benefit of an empty root. An empty root maybe provides a little additional security, but not much. The benefit depends on your own risk evaluation. On the other hand, the ongoing operational cost of a two domainforestis considerably higher than a single domain forest. Additional hardware costs, additional diagnostic complexity, and a more complicated DR situation all add to the costs of running multiple domains. My general recommendationis tostick with a single domain if you can, and add additional domains if you need to for password policy or controlling replicationtraffic. And if you find you have to have multiple domains anyway, use an empty root, because the incremental cost of an additional domain if you already have more than one is pretty small. But, "it depends". -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, January 12, 2006 9:32 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Ah good ol best practices. :) What is recommended? Whatever is best for the customer of course. I guess my question is why one domain and one root versus just one domain? What is the purpose of the root? I am not saying this is bad by any stretch, there are good valid reasons for a root with other domains hanging off of it. Just curious what the decision flow was like to do it. Hopefully it wasn't something along the lines of reading "an empty root" is good somewhere and going for it as it is totally context sensitive. I would say the overall design goal, especially when Exchange is involved is to use a single domain forest. However, if there is a good reason to add more domains, do it. Usually when someone says they have a domain and a root they mean they have a domain and an EMPTY root and I wonder about how the decision was arrived at. We have had this discussion previously on the list where some people are gung ho empty root and some people are gung ho no-empty root and both pointing at best practices. I am more of the does it make sense in this specific situation kind of person. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, DevonSent: Thursday, January 12, 2006 11:12 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Well, I just thought it would be best practice to consolidate multiple domains to one. Whats recommended? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Wednesday, January 11, 2006 7:58 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation You want to look at a couple of main points 1. How do y
RE: [ActiveDir] OU Delegation
Well I didn't say I don't see the benefit of an empty root. I just don't see it as a generic best practice. Sometimes it makes a ton of sense, sometimes someone needs to be slapped for bringing it up. ;o) joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Wednesday, January 18, 2006 5:11 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Boy, I just had a consultant recommend an empty root as best practice for a divestiture were doing. Like Gil and Joe, I really dont see the benefit (nor could the consultant name anything specifically). We have a single domain and delegate OU rights based basically on an administrative teams need to manage a group of resources, typically computers. Users, groups and Exchange are managed centrally. Moving things around within one domain is a whole lot easier than among domains. AL Al Maurer Service Manager, Naming and Authentication Services IT | Information Technology Agilent Technologies (719) 590-2639; Telnet 590-2639 http://activedirectory.it.agilent.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Thursday, January 12, 2006 10:50 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation As joe says, "it depends". AD architecture is always a cost/benefit discussion, and most people don't really understand 1) the real benefits of multiple domains, and 2) the additional costs of running multiple domains. For instance, "additional security" is often cited as a benefit of an empty root. An empty root maybe provides a little additional security, but not much. The benefit depends on your own risk evaluation. On the other hand, the ongoing operational cost of a two domainforestis considerably higher than a single domain forest. Additional hardware costs, additional diagnostic complexity, and a more complicated DR situation all add to the costs of running multiple domains. My general recommendationis tostick with a single domain if you can, and add additional domains if you need to for password policy or controlling replicationtraffic. And if you find you have to have multiple domains anyway, use an empty root, because the incremental cost of an additional domain if you already have more than one is pretty small. But, "it depends". -gil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Thursday, January 12, 2006 9:32 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Ah good ol best practices. :) What is recommended? Whatever is best for the customer of course. I guess my question is why one domain and one root versus just one domain? What is the purpose of the root? I am not saying this is bad by any stretch, there are good valid reasons for a root with other domains hanging off of it. Just curious what the decision flow was like to do it. Hopefully it wasn't something along the lines of reading "an empty root" is good somewhere and going for it as it is totally context sensitive. I would say the overall design goal, especially when Exchange is involved is to use a single domain forest. However, if there is a good reason to add more domains, do it. Usually when someone says they have a domain and a root they mean they have a domain and an EMPTY root and I wonder about how the decision was arrived at. We have had this discussion previously on the list where some people are gung ho empty root and some people are gung ho no-empty root and both pointing at best practices. I am more of the does it make sense in this specific situation kind of person. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, DevonSent: Thursday, January 12, 2006 11:12 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Well, I just thought it would be best practice to consolidate multiple domains to one. Whats recommended? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Wednesday, January 11, 2006 7:58 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation You want to look at a couple of main points 1. How do you plan to delegate the permisisons, I.E. the groupings of machines, users, etc. 2. How do you play to do GPOs if at all. 3. How is the administration really going to work. For instance, if you use a provisioning system for managing users (highly recommended) you don't generally want to delegate those to local OU admins but instead keep them in a main OU that the provisioning system only has control to. Why one domain and one root domain? I am not arguing one way or the other, just curious for the reasoning. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, DevonSent: Wednesday, January 11, 2006 4:24 PMTo: ActiveDir@mail.activedir.orgSubject: [Activ
RE: [ActiveDir] OU Delegation
Well, I just thought it would be best practice to consolidate multiple domains to one. Whats recommended? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Wednesday, January 11, 2006 7:58 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation You want to look at a couple of main points 1. How do you plan to delegate the permisisons, I.E. the groupings of machines, users, etc. 2. How do you play to do GPOs if at all. 3. How is the administration really going to work. For instance, if you use a provisioning system for managing users (highly recommended) you don't generally want to delegate those to local OU admins but instead keep them in a main OU that the provisioning system only has control to. Why one domain and one root domain? I am not arguing one way or the other, just curious for the reasoning. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, Devon Sent: Wednesday, January 11, 2006 4:24 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] OU Delegation Were in the process of consolidating 21 child domains into just one and one root. We want to separate the divisions (domains) into different OUs. Is there a guide or best practice out there on delegating admin permissions on OUs? Also, weve got Exchange permissions to deal with too. Devon Harding Windows Systems Engineer Southern Wine Spirits - BSG 954-602-2469 __ This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use or distribution of the information included in the message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank You.
RE: [ActiveDir] OU Delegation
Ah good ol best practices. :) What is recommended? Whatever is best for the customer of course. I guess my question is why one domain and one root versus just one domain? What is the purpose of the root? I am not saying this is bad by any stretch, there are good valid reasons for a root with other domains hanging off of it. Just curious what the decision flow was like to do it. Hopefully it wasn't something along the lines of reading "an empty root" is good somewhere and going for it as it is totally context sensitive. I would say the overall design goal, especially when Exchange is involved is to use a single domain forest. However, if there is a good reason to add more domains, do it. Usually when someone says they have a domain and a root they mean they have a domain and an EMPTY root and I wonder about how the decision was arrived at. We have had this discussion previously on the list where some people are gung ho empty root and some people are gung ho no-empty root and both pointing at best practices. I am more of the does it make sense in this specific situation kind of person. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, DevonSent: Thursday, January 12, 2006 11:12 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Well, I just thought it would be best practice to consolidate multiple domains to one. Whats recommended? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Wednesday, January 11, 2006 7:58 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation You want to look at a couple of main points 1. How do you plan to delegate the permisisons, I.E. the groupings of machines, users, etc. 2. How do you play to do GPOs if at all. 3. How is the administration really going to work. For instance, if you use a provisioning system for managing users (highly recommended) you don't generally want to delegate those to local OU admins but instead keep them in a main OU that the provisioning system only has control to. Why one domain and one root domain? I am not arguing one way or the other, just curious for the reasoning. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, DevonSent: Wednesday, January 11, 2006 4:24 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] OU Delegation Were in the process of consolidating 21 child domains into just one and one root. We want to separate the divisions (domains) into different OUs. Is there a guide or best practice out there on delegating admin permissions on OUs? Also, weve got Exchange permissions to deal with too. Devon Harding Windows Systems Engineer Southern Wine Spirits - BSG 954-602-2469 __This message and any attachments are solely for the intendedrecipient and may contain confidential or privileged information.If you are not the intended recipient, any disclosure, copying, useor distribution of the information included in the message and anyattachments is prohibited. If you have received this communicationin error, please notify us by reply e-mail and immediately andpermanently delete this message and any attachments. Thank You.
RE: [ActiveDir] OU Delegation
Yes, I would definitely like to see that script. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Desmond Sent: Wednesday, January 11, 2006 4:49 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation Devon- To a certain extent is varies based on your business requirements. There are basic things though: Computers Users Groups Contacts. My standard for OUs is something like this CookieCutter Division --Computes Workstations Laptops Servers --Users Employees Contractors Temporary --Groups --Contacts I let people create OUs under the bottom most OU in each subtree and do whatever to the relevant objects. I provision users centrally so I don't delegate exchange. It's way easier to have some sort of central exchange provisioningysstem or site rather than trying to delegate it. I have a sript I wrote that creates the OU structure, groups, and delegates various rights, you're welcome to a copy if you want it. You'll have to modify it for your organization, but, it's a good start. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] on behalf of Harding, Devon Sent: Wed 1/11/2006 4:24 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] OU Delegation Were in the process of consolidating 21 child domains into just one and one root. We want to separate the divisions (domains) into different OUs. Is there a guide or best practice out there on delegating admin permissions on OUs? Also, weve got Exchange permissions to deal with too. Devon Harding Windows Systems Engineer Southern Wine Spirits - BSG 954-602-2469 __ This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use or distribution of the information included in the message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank You.
RE: [ActiveDir] OU Delegation
There's no end all domain structure best practice. An empty root is fairly well accepted. Beyond that there are a multitude of things you need to look at from an technical perspective. One reason to segment off domains sometimes is geography. You have an AsiaPac domain and a Americas domain so that your AsiaPac Americas traffic is just GC replication rather than DC and sysvol. If you're truly goign to delegate it all out, and things like the above conern don't play in, I'd probably place my ballot on a sinle domain without knowing anything else. In reality you need to get yourself a provisioning ysstem and delegate account management tasks. Trust your provisioning system to do object lifecycle management. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] on behalf of Harding, Devon Sent: Thu 1/12/2006 11:11 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation Well, I just thought it would be best practice to consolidate multiple domains to one. What's recommended? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Wednesday, January 11, 2006 7:58 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OU Delegation You want to look at a couple of main points 1. How do you plan to delegate the permisisons, I.E. the groupings of machines, users, etc. 2. How do you play to do GPOs if at all. 3. How is the administration really going to work. For instance, if you use a provisioning system for managing users (highly recommended) you don't generally want to delegate those to local OU admins but instead keep them in a main OU that the provisioning system only has control to. Why one domain and one root domain? I am not arguing one way or the other, just curious for the reasoning. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, Devon Sent: Wednesday, January 11, 2006 4:24 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] OU Delegation We're in the process of consolidating 21 child domains into just one and one root. We want to separate the divisions (domains) into different OUs. Is there a guide or best practice out there on delegating admin permissions on OUs? Also, we've got Exchange permissions to deal with too. Devon Harding Windows Systems Engineer Southern Wine Spirits - BSG 954-602-2469 __ This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use or distribution of the information included in the message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank You. winmail.dat
RE: [ActiveDir] OU Delegation
Brian, Could you send a copy off list to me as well. [EMAIL PROTECTED] I take it is a _vbscript_. Thanks, Dave From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, DevonSent: Thursday, January 12, 2006 11:30 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Yes, I would definitely like to see that script. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian DesmondSent: Wednesday, January 11, 2006 4:49 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] OU Delegation Devon- To a certain extent is varies based on your business requirements. There are basic things though: Computers Users Groups Contacts. My standard for OUs is something like this CookieCutter Division --Computes Workstations Laptops Servers --Users Employees Contractors Temporary --Groups --Contacts I let people create OUs under the bottom most OU in each subtree and do whatever to the relevant objects. I provision users centrally so I don't delegate exchange. It's way easier to have some sort of central exchange provisioningysstem or site rather than trying to delegate it. I have a sript I wrote that creates the OU structure, groups, and delegates various rights, you're welcome to a copy if you want it. You'll have to modify it for your organization, but, it's a good start. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] on behalf of Harding, DevonSent: Wed 1/11/2006 4:24 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] OU Delegation Were in the process of consolidating 21 child domains into just one and one root. We want to separate the divisions (domains) into different OUs. Is there a guide or best practice out there on delegating admin permissions on OUs? Also, weve got Exchange permissions to deal with too. Devon Harding Windows Systems Engineer Southern Wine Spirits - BSG 954-602-2469 __This message and any attachments are solely for the intendedrecipient and may contain confidential or privileged information.If you are not the intended recipient, any disclosure, copying, useor distribution of the information included in the message and anyattachments is prohibited. If you have received this communicationin error, please notify us by reply e-mail and immediately andpermanently delete this message and any attachments. Thank You. *** Internet Email Confidentiality The information contained in this message (including any attachments) may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that it is strictly prohibited (a) to disseminate, distribute or copy this communication or any of the information contained in it, or (b) to take any action based on the information in it. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. **
RE: [ActiveDir] OU Delegation
Devon- To a certain extent is varies based on your business requirements. There are basic things though: Computers Users Groups Contacts. My standard for OUs is something like this CookieCutter Division --Computes Workstations Laptops Servers --Users Employees Contractors Temporary --Groups --Contacts I let people create OUs under the bottom most OU in each subtree and do whatever to the relevant objects. I provision users centrally so I don't delegate exchange. It's way easier to have some sort of central exchange provisioningysstem or site rather than trying to delegate it. I have a sript I wrote that creates the OU structure, groups, and delegates various rights, you're welcome to a copy if you want it. You'll have to modify it for your organization, but, it's a good start. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] on behalf of Harding, Devon Sent: Wed 1/11/2006 4:24 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] OU Delegation We're in the process of consolidating 21 child domains into just one and one root. We want to separate the divisions (domains) into different OUs. Is there a guide or best practice out there on delegating admin permissions on OUs? Also, we've got Exchange permissions to deal with too. Devon Harding Windows Systems Engineer Southern Wine Spirits - BSG 954-602-2469 __ This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use or distribution of the information included in the message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank You. winmail.dat
Re: [ActiveDir] OU Delegation
It's a bit dated by this point, but I still consider Sanjay Tandon's delegation white paper to be one of the better treatments on the subject: http://www.microsoft.com/downloads/details.aspx?FamilyID=631747a3-79e1-48fa-9730-dae7c0a1d6d3DisplayLang=en - Laura On 1/11/06, Harding, Devon [EMAIL PROTECTED] wrote: We're in the process of consolidating 21 child domains into just one and one root. We want to separate the divisions (domains) into different OUs. Is there a guide or best practice out there on delegating admin permissions on OUs? Also, we've got Exchange permissions to deal with too. Devon Harding Windows Systems Engineer Southern Wine Spirits - BSG 954-602-2469 __ This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use or distribution of the information included in the message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank You. -- --- Laura E. Hunter Microsoft MVP - Windows Server Networking Author: _Active Directory Consultant's Field Guide_ (http://tinyurl.com/7f8ll) List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] OU Delegation
check out the AD Delegation Whitepaper from our friend Sanjay Tandon (who is no longerwith MS, but the document is still very useful): Main Doc http://www.microsoft.com/downloads/details.aspx?FamilyID=631747a3-79e1-48fa-9730-dae7c0a1d6d3DisplayLang=en Appendix http://www.microsoft.com/downloads/details.aspx?FamilyID=29dbae88-a216-45f9-9739-cb1fb22a0642DisplayLang=en I've also done a few detailed presentations on it, but I'm sure you'll find all you need in those docs. In general, you are certainly on the right path to consolidate all those domains into a single one. I might even argue the root but that's a different topic and you might need that one child domain you're keeping for other reasons (but I hope you're not creating a new child domain for the sole purpose of consolidating the others...) /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, DevonSent: Mittwoch, 11. Januar 2006 22:24To: ActiveDir@mail.activedir.orgSubject: [ActiveDir] OU Delegation Were in the process of consolidating 21 child domains into just one and one root. We want to separate the divisions (domains) into different OUs. Is there a guide or best practice out there on delegating admin permissions on OUs? Also, weve got Exchange permissions to deal with too. Devon Harding Windows Systems Engineer Southern Wine Spirits - BSG 954-602-2469 __This message and any attachments are solely for the intendedrecipient and may contain confidential or privileged information.If you are not the intended recipient, any disclosure, copying, useor distribution of the information included in the message and anyattachments is prohibited. If you have received this communicationin error, please notify us by reply e-mail and immediately andpermanently delete this message and any attachments. Thank You.
RE: [ActiveDir] OU Delegation
You want to look at a couple of main points 1. How do you plan to delegate the permisisons, I.E. the groupings of machines, users, etc. 2. How do you play to do GPOs if at all. 3. How is the administration really going to work. For instance, if you use a provisioning system for managing users (highly recommended) you don't generally want to delegate those to local OU admins but instead keep them in a main OU that the provisioning system only has control to. Why one domain and one root domain? I am not arguing one way or the other, just curious for the reasoning. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, DevonSent: Wednesday, January 11, 2006 4:24 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] OU Delegation Were in the process of consolidating 21 child domains into just one and one root. We want to separate the divisions (domains) into different OUs. Is there a guide or best practice out there on delegating admin permissions on OUs? Also, weve got Exchange permissions to deal with too. Devon Harding Windows Systems Engineer Southern Wine Spirits - BSG 954-602-2469 __This message and any attachments are solely for the intendedrecipient and may contain confidential or privileged information.If you are not the intended recipient, any disclosure, copying, useor distribution of the information included in the message and anyattachments is prohibited. If you have received this communicationin error, please notify us by reply e-mail and immediately andpermanently delete this message and any attachments. Thank You.
RE: [ActiveDir] OU Delegation question
Just so we have it straight, once you set the deny permission, they're still able to delete an account but not create one? Is that about it? Is that the last of what you need to accomplish as well? -Original Message- From: Thommes, Michael M. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 3:51 PM To: Active Directory Mailing List (E-mail) Subject: [ActiveDir] OU Delegation question Hi All: At least around here, Robbie's Tuna book has yet to hit the shelves. And Microsoft's whitepaper on delegation is still a month away. Other references on delegation appear scant at best. So here's the problem that I have been tearing my hair out on (and I didn't have much to start with! 8-) ): We would like to delegate *almost* all rights to the various Divisional OUs we have to various OU admin groups. We'll let them do anything they want to *except*: 1) create accounts; 2) delete accounts; 3) rename accounts; and 4) reset passwords. We have other groups for #4. You'd think this is a relatively easy task. So far, my experiences show otherwise. Using the Delegation Wizard, it would see reasonable to give the OU admin groups the following permissions in the respective OU: 1) Full Control, applied to this object and all child objects 2) Create/Delete User Object, applied to this object and all child objectsthen set it to Deny 3) Reset Password, applied to User Objects...then set it to Deny 4) Write Property, Write Logon Name (pre-Windows 2000)...then set it to Deny 5) Write Property, Write Logon Name...then set it to Deny So far, the admin groups cannot create a user account (good!); they cannot reset a user's password (good!); they cannot rename an account (good!); BUT they can *still* delete a user account (very bad!). Any help is certainly appreciated! Thanks. Mike Thommes List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] OU Delegation question
Hi Al (and Joe), Thanks for the responses. Al, that is correct, the OU Admin can still delete the user object. And yes, I think that is the last thing that I want to accomplish. However, Joe's previous reply gives me cause for concern about the Full Control issue. The bottom line is that I don't want to restrict what the OU admins can do in their respective OUs, except I do not want them to create a user account, nor delete an already existing user account, nor rename the user account, nor reset the password. We view our domain accounts as sacred; they are never to be deleted (disabled, yes) and the creation of domain accounts is done through a special process that is done by a single office so that the appropriate business rules are followed. The Delegation Wizard GUI poses a question. If you start getting granular for a particular permission and uncheck the Allow box, it would appear that the ability to do that particular operation then rests on maybe inherited permissions or some other gray area. By explicitly checking the Deny box, it becomes (at least to me) a very black and white issue, since Deny takes precedence. Am I missing a bigger picture here? I really am looking forward to getting my hands on Robbie's book and the MS whitepaper on delegation! Keep the comments coming! Mike Thommes -Original Message- From: Mulnick, Al [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 9:52 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] OU Delegation question Just so we have it straight, once you set the deny permission, they're still able to delete an account but not create one? Is that about it? Is that the last of what you need to accomplish as well? -Original Message- From: Thommes, Michael M. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 3:51 PM To: Active Directory Mailing List (E-mail) Subject: [ActiveDir] OU Delegation question Hi All: At least around here, Robbie's Tuna book has yet to hit the shelves. And Microsoft's whitepaper on delegation is still a month away. Other references on delegation appear scant at best. So here's the problem that I have been tearing my hair out on (and I didn't have much to start with! 8-) ): We would like to delegate *almost* all rights to the various Divisional OUs we have to various OU admin groups. We'll let them do anything they want to *except*: 1) create accounts; 2) delete accounts; 3) rename accounts; and 4) reset passwords. We have other groups for #4. You'd think this is a relatively easy task. So far, my experiences show otherwise. Using the Delegation Wizard, it would see reasonable to give the OU admin groups the following permissions in the respective OU: 1) Full Control, applied to this object and all child objects 2) Create/Delete User Object, applied to this object and all child objectsthen set it to Deny 3) Reset Password, applied to User Objects...then set it to Deny 4) Write Property, Write Logon Name (pre-Windows 2000)...then set it to Deny 5) Write Property, Write Logon Name...then set it to Deny So far, the admin groups cannot create a user account (good!); they cannot reset a user's password (good!); they cannot rename an account (good!); BUT they can *still* delete a user account (very bad!). Any help is certainly appreciated! Thanks. Mike Thommes List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] OU Delegation question
Hi Michael, The reason the OU Admin can still delete the user object is because of the Full Control ACE you added. When deleting an object, the operating system first looks at the object itself to see the caller has the Delete permission. If not, it then goes to its PARENT (in this case an OU) to see if the caller has the Delete Subtree permission. Therefore, if you follow your current model, you can deny permissions to the Delete Subtree permission as well as the Modify Permissions permission to achieve your results. You will also see a similar behavior in NTFS permissions where users can mysteriously delete files that they have as read only. If you look at the parent folder, they will have the Delete Subfolders and Files permission (associated with Full Control). I hope this helps. All the best, Brian Small President == Small Wonders Software [EMAIL PROTECTED] http://www.smallwonders.com == IMPORTANT - This e-mail message (and attachments) may contain information that is confidential to Small Wonders Software. If you are not the intended recipient you cannot use, distribute or copy the message or attachments. In such a case, please notify the sender by return e-mail immediately and erase all copies of the message and attachments. Opinions, conclusions and other information in this message and attachments that do not relate to the official business of Small Wonders Software are neither given nor endorsed by it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thommes, Michael M. Sent: Wednesday, October 08, 2003 11:10 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] OU Delegation question Hi Al (and Joe), Thanks for the responses. Al, that is correct, the OU Admin can still delete the user object. And yes, I think that is the last thing that I want to accomplish. However, Joe's previous reply gives me cause for concern about the Full Control issue. The bottom line is that I don't want to restrict what the OU admins can do in their respective OUs, except I do not want them to create a user account, nor delete an already existing user account, nor rename the user account, nor reset the password. We view our domain accounts as sacred; they are never to be deleted (disabled, yes) and the creation of domain accounts is done through a special process that is done by a single office so that the appropriate business rules are followed. The Delegation Wizard GUI poses a question. If you start getting granular for a particular permission and uncheck the Allow box, it would appear that the ability to do that particular operation then rests on maybe inherited permissions or some other gray area. By explicitly checking the Deny box, it becomes (at least to me) a very black and white issue, since Deny takes precedence. Am I missing a bigger picture here? I really am looking forward to getting my hands on Robbie's book and the MS whitepaper on delegation! Keep the comments coming! Mike Thommes -Original Message- From: Mulnick, Al [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 9:52 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] OU Delegation question Just so we have it straight, once you set the deny permission, they're still able to delete an account but not create one? Is that about it? Is that the last of what you need to accomplish as well? -Original Message- From: Thommes, Michael M. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 3:51 PM To: Active Directory Mailing List (E-mail) Subject: [ActiveDir] OU Delegation question Hi All: At least around here, Robbie's Tuna book has yet to hit the shelves. And Microsoft's whitepaper on delegation is still a month away. Other references on delegation appear scant at best. So here's the problem that I have been tearing my hair out on (and I didn't have much to start with! 8-) ): We would like to delegate *almost* all rights to the various Divisional OUs we have to various OU admin groups. We'll let them do anything they want to *except*: 1) create accounts; 2) delete accounts; 3) rename accounts; and 4) reset passwords. We have other groups for #4. You'd think this is a relatively easy task. So far, my experiences show otherwise. Using the Delegation Wizard, it would see reasonable to give the OU admin groups the following permissions in the respective OU: 1) Full Control, applied to this object and all child objects 2) Create/Delete User Object, applied to this object and all child objectsthen set it to Deny 3) Reset Password, applied to User Objects...then set it to Deny 4) Write Property, Write Logon Name (pre-Windows 2000)...then set it to Deny 5) Write Property, Write Logon Name...then set it to Deny So far, the admin groups cannot create a user account (good!); they cannot reset a user's password (good!); they cannot rename an account (good!); BUT they can *still* delete a user
RE: [ActiveDir] OU Delegation question
Brian, And other such oddities, such as the ability to 'force' down through the structure of NTFS files and folders a new ACE for a Security Principal that has no permissions at all, and in fact - is denied access in other conceivable ways. Yeah, I like that feature in Security Explorer... ;o) Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Small Sent: Wednesday, October 08, 2003 12:11 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] OU Delegation question Hi Michael, The reason the OU Admin can still delete the user object is because of the Full Control ACE you added. When deleting an object, the operating system first looks at the object itself to see the caller has the Delete permission. If not, it then goes to its PARENT (in this case an OU) to see if the caller has the Delete Subtree permission. Therefore, if you follow your current model, you can deny permissions to the Delete Subtree permission as well as the Modify Permissions permission to achieve your results. You will also see a similar behavior in NTFS permissions where users can mysteriously delete files that they have as read only. If you look at the parent folder, they will have the Delete Subfolders and Files permission (associated with Full Control). I hope this helps. All the best, Brian Small President == Small Wonders Software [EMAIL PROTECTED] http://www.smallwonders.com == IMPORTANT - This e-mail message (and attachments) may contain information that is confidential to Small Wonders Software. If you are not the intended recipient you cannot use, distribute or copy the message or attachments. In such a case, please notify the sender by return e-mail immediately and erase all copies of the message and attachments. Opinions, conclusions and other information in this message and attachments that do not relate to the official business of Small Wonders Software are neither given nor endorsed by it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thommes, Michael M. Sent: Wednesday, October 08, 2003 11:10 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] OU Delegation question Hi Al (and Joe), Thanks for the responses. Al, that is correct, the OU Admin can still delete the user object. And yes, I think that is the last thing that I want to accomplish. However, Joe's previous reply gives me cause for concern about the Full Control issue. The bottom line is that I don't want to restrict what the OU admins can do in their respective OUs, except I do not want them to create a user account, nor delete an already existing user account, nor rename the user account, nor reset the password. We view our domain accounts as sacred; they are never to be deleted (disabled, yes) and the creation of domain accounts is done through a special process that is done by a single office so that the appropriate business rules are followed. The Delegation Wizard GUI poses a question. If you start getting granular for a particular permission and uncheck the Allow box, it would appear that the ability to do that particular operation then rests on maybe inherited permissions or some other gray area. By explicitly checking the Deny box, it becomes (at least to me) a very black and white issue, since Deny takes precedence. Am I missing a bigger picture here? I really am looking forward to getting my hands on Robbie's book and the MS whitepaper on delegation! Keep the comments coming! Mike Thommes -Original Message- From: Mulnick, Al [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 9:52 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] OU Delegation question Just so we have it straight, once you set the deny permission, they're still able to delete an account but not create one? Is that about it? Is that the last of what you need to accomplish as well? -Original Message- From: Thommes, Michael M. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 3:51 PM To: Active Directory Mailing List (E-mail) Subject: [ActiveDir] OU Delegation question Hi All: At least around here, Robbie's Tuna book has yet to hit the shelves. And Microsoft's whitepaper on delegation is still a month away. Other references on delegation appear scant at best. So here's the problem that I have been tearing my hair out on (and I didn't have much to start with! 8-) ): We would like to delegate *almost* all rights to the various Divisional OUs we have to various OU admin groups. We'll let them do anything they want to *except*: 1) create accounts; 2) delete accounts; 3) rename accounts; and 4) reset passwords. We have other groups for #4. You'd think this is a relatively easy task. So far, my experiences show otherwise. Using the Delegation Wizard
RE: [ActiveDir] OU Delegation question
Mike, you definitely want to rethink your approach. Joe's comment was very important = don't try to grant 'EVERYTHING *except*' - rather, you should come up with exactly what you want your OU Admins to do in their OU or sub-OUs. You certainly don't want to pass out Full-Control on the level of the OUs = this is like giving them the keys to the kingdom: as soon as you grant someone the permission to manage permissions on their container object (the OU), everything else you do is useless. Not only can they change whatever you've set, but they can also block inheritance of the permissions from the parent OUs - more sooner than later you'll have an ACL mess in AD. I won't even mention GPOs now. Next, don't forget one important thing with your Delegation design: it's much easier to limit what you allow, than to handle deny ACEs (Access Control Entries). You have to understand the priority of permission evaluation: inherited ACEs come after explicit ACEs - i.e. an explicit allow on a level closer to the object will override an inherited deny. So you may THINK that you've still set the deny on your parent OU, while in some child OU the admin might have granted allow permissions to create, manage and delete users etc. So in general, you should preferr to grant permission on the objects that you want managed. E.g. for a Full OU Admin (general): Organizational Units: Allow - Read All Computer: Allow - Full Control, Create, Delete Contact:Allow - Full Control, Create, Delete Group: Allow - Full Control, Create, Delete Printer:Allow - Full Control, Create, Delete Shared Folder: Allow - Full Control, Create, Delete User: Allow - Full Control, Create, Delete In your case, you'll have to think more in detail, what you admins are supposed to be able to do on the User object - as you don't want them to create or delete users, remove these permissions from the list above. Now, instead of Full Control, sounds like you want the admins to be much more restricted on the account - I doubt you want them to do everything except renaming and resetting PW = if your this strict with your accounts, should these admins have the power to expire the account or to disable it, or simply to unlock it if it is locked? Should they be able to check the Store PW using reversible encryption flag?... What is it they're allowed to do - likely to add groups to the user - right? Well this is a group permission (you don't add groups to users, you add users to groups). And how about the address and phone information = all held in the Personal Information property set, could easily be granted as a block. In short, with some additional investigation, you may find you simply need to GRANT a few permissions instead of allowing everything and trying to DENY some. Not sure if you've had the chance to visit MEC US or IT Forum in Europe last year - you should find my session on Delegation of Admin rights quite useful (was SEC400 at MEC and SEC330 at IT forum). It contains a lot of the information which is also covered by MS in the upcoming whitepaper. If you don't have access to it, I can send you the PPT slides offline (and will make you forward it to anyone else who asks ;-) /Guido -Original Message- From: Thommes, Michael M. [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 8. Oktober 2003 17:10 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] OU Delegation question Hi Al (and Joe), Thanks for the responses. Al, that is correct, the OU Admin can still delete the user object. And yes, I think that is the last thing that I want to accomplish. However, Joe's previous reply gives me cause for concern about the Full Control issue. The bottom line is that I don't want to restrict what the OU admins can do in their respective OUs, except I do not want them to create a user account, nor delete an already existing user account, nor rename the user account, nor reset the password. We view our domain accounts as sacred; they are never to be deleted (disabled, yes) and the creation of domain accounts is done through a special process that is done by a single office so that the appropriate business rules are followed. The Delegation Wizard GUI poses a question. If you start getting granular for a particular permission and uncheck the Allow box, it would appear that the ability to do that particular operation then rests on maybe inherited permissions or some other gray area. By explicitly checking the Deny box, it becomes (at least to me) a very black and white issue, since Deny takes precedence. Am I missing a bigger picture here? I really am looking forward to getting my hands on Robbie's book and the MS whitepaper on delegation! Keep the comments coming! Mike Thommes -Original Message- From: Mulnick, Al [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 9:52 AM To: '[EMAIL PROTECTED
