OU structure design, name standards, and depth

  • 59 Views
  • Last Post 16 June 2017
BrianB posted this 15 June 2017

All:   I have been tasked with writing policy and redesigning the OU structure for our environment. As such, my leadership wants to gain control back of our OU structure. Currently, OU’s are created based upon various criteria, such as Department, Division, Application groups, College, Location, etc. In some cases, they are simple 3 letter OU names, and then others are multiple word names. Some OU’s are up to a hundred+ deep and a few are up to 7 levels deep.

  I am curious if anyone on this mail list has controls or standards in place for their OU structure and what those might be? Would you be willing to share? Do you have a written security policy for AD and how it may be used and how the structure and delegations are granted?

  ·         Moving forward in a new forest, my leadership wants to standardize on the following; ·         naming convention ·         Default structure ·         Only Delegated Admin’s can create OU’s ·         Vetting process for creating a new OU or additional OU’s outside of the default ·         Limiting the number of layers   ·         Technical controls will limit the OU creation to delegated Admins.

·         Naming conventions will be enforced by the delegated admins. ·         Vetting for new or additional OU’s will be around the necessity to apply same or different policy or admin controls more granularly.

·         Minimizing the layers will be enforced by the delegated Admins.

  You responses are very much appreciated,   Brian Britt  

       

       

Order By: Standard | Newest | Votes
g4ugm posted this 15 June 2017

Brian,  I would add some criteria about maintaining the created structure. So in unlikely event of a business restructure (http://www.anvari.org/fun/Job/Administratum:AChemicalAnalysis.html) who is going to fund the re-organization of Active Directory.Dave 

show

kebabfest posted this 15 June 2017

Hi Brian,
I haven't got a written policy per as, but I have designed a few different structures for different companies.The best advice I can give is try and think of it from somebody who has just joined the company in IT and a business user.The OU structure works best when it reflects the business functionality structure. However the ou names should make sense. 3 letters and 100 resource access groups Are great for the guy who has worked in the company for 20 years, but if a new it guy can't get a feel for the structure quickly then it isn't much good.Keep it as simple as you can. An ou structure of 100 deep sounds like granularity that is excessive.Delegated rights are the way to go . Getting support staff away from bring  domain admins will reduce a lot of headaches A Good Ad structure should help the support staff understand the business better. The better you understand your business the better support you can provide. Oh and keep your naming conventions as simple as possible.E.g. <server location>-<type of server>-<environment>-number e.g an ad dev server in Minnesota would be MIN-ADS-DEV-01.
If you make the ok structure or server naming conventions overly complicated people will continuly get them wrong. 


show

pawan posted this 16 June 2017

Hi Brian,
OU structure should not be so deep or beyond the 10 layers to manage easily.
You can have ou structure like:
Org OU>Servers OUWorkstation OuUsers OUGroups OuAny Special Ou
Beneath of these ou you can create country Wise OU in each categoryLike: UK, US
If you also want to create OU site wise in each country, you can create but don't create till you need to apply other GPO than Country OU.
If you want to isolate any group of server,users,workstation ou you can create the sub ou and block inheritance.
Here you can restrict to admins to create changes only for their respective location through delegate control.
For Naming convention:
User name: max 8 character first+last name or vice versa
Workstation: country code+site code+device type+digitLike: UKLNWD01. Windows desktop in UK site London(you can ignore site name if not much necessary)
Server: Country code+Server Type+ Function type+numberUKWSAD01 -windows server with AD role
Group: cn+site+ function+org/deptGroups naming convention depends upon purpose.
Regards,Pwnkmr
On Jun 16, 2017 4:54 AM, "Eoin Hamdam" <ehamdam@xxxxxxxxxxxxxxxx> wrote:
Hi Brian,
I haven't got a written policy per as, but I have designed a few different structures for different companies.The best advice I can give is try and think of it from somebody who has just joined the company in IT and a business user.The OU structure works best when it reflects the business functionality structure. However the ou names should make sense. 3 letters and 100 resource access groups Are great for the guy who has worked in the company for 20 years, but if a new it guy can't get a feel for the structure quickly then it isn't much good.Keep it as simple as you can. An ou structure of 100 deep sounds like granularity that is excessive.Delegated rights are the way to go . Getting support staff away from bring  domain admins will reduce a lot of headaches A Good Ad structure should help the support staff understand the business better. The better you understand your business the better support you can provide. Oh and keep your naming conventions as simple as possible.E.g. <server location>-<type of server>-<environment>-number e.g an ad dev server in Minnesota would be MIN-ADS-DEV-01.
If you make the ok structure or server naming conventions overly complicated people will continuly get them wrong. 


show

BrianB posted this 16 June 2017

Thanks for the info, but I am fairly well versed on OU architecture and the “How”, I am more concerned on written policy controls for default OU and limiting

the org to a set of standards and controls. Does anyone have these type of written policies in place and would they be willing to share your standards and polices?



 

Architecture-wise, I understand OU design.



 

Thank you for answering,

 

Brian Britt

 

show

barkills posted this 16 June 2017

I’ve got a ton of documentation, linked from a starting place of

https://itconnect.uw.edu/wares/msinf/ous/.



 

https://itconnect.uw.edu/wares/msinf/design/policy/ou-practices/ covers some of

the topics you’ve mentioned like who can authorize, naming, and policies. We tie the delegated OU name to a variety of other things like delegation role group names, expected group policy names (and objects associated with GPOs like IPSec policies), DFS namespaces,

a default computer namespace reservation,  and groups which enable capabilities (e.g. we automatically create a group which has all the computers in a given delegated OU as a replacement for ‘Domain Computers’). Because the OU name has that relationship, we

don’t allow customers to change it without our assistance, so we can ensure that all the associated items are also updated. One key policy is requiring more than one OU admin—and that’s to ensure there is someone other than the domain admins who can help a

given organization.

 

We don’t get entangled with what folks do with their delegated OU after it has been created. The permissions granted have been carefully chosen to prevent them

from breaking things, but give them as broad a set of capability as they need. For example, they don’t get the ability to set permissions. They also don’t get the ability to create users or groups, because those abilities come via our integrated institutional

solutions. If they want to create deep OU structures—more power to them—it’s their mess to support. I can say that with about 150 delegated OUs across about 10 years, we haven’t gotten called to help clean up any crazy stuff in a delegated OU. I can’t say

the same for other Windows domains—we’ve gotten called in to help with those about a dozen times over that same 10 year period.

 

I can answer specific questions about anything you find under the set of documentation that links from that first URL.

J

 

Brian

 

show

BrianB posted this 16 June 2017

Brian,

 

Thanks for that info. I appreciate your willingness to share that. If you done mind, I may borrow some ideas.

 

Brian Britt

 

show

Close