none
Building Organisation Hierarchy with Active Directory

    Question

  • Hello,

    Our client is an government agency with around 5000 staff members. Currently, all details of departments and units are stored within oracle database. For so many reasons, we would like to move the hierarchy to Active Directory (Windows 2012). Example of how we will use the hierarchy: Access to a certain system for users in a certain unit. Internal eServices portal where a request goes to the person manager or VP for approval, then goes up in the hierarchy. etc..

    The hierarchy has multiple levels (seven at max) . 

    We have the current situations:

    - There is a case where one person manages 2 or more different departments at the same time

    - The details of each unit must include who's the manager of that unit

    The Question: 

    What is the best way to implement that hierarchy?

    Thanks a lot :)

    Sunday, June 9, 2013 11:59 PM

Answers

  • The best in my opinion and how many modern directorys are buillt today - I would stay away as long as possible to represent an organizational hierarchy in Active Directory by expressing it by diffrent levels of containers/organizational units (those serves the ability to group objects into a logical view for administration, if administration are done by the built-in administartive tools that comes with the product, they can also be used for delegation) - I would rather use a IdM (Identity Management System) to featch the information from another source (prehaps the oracel db you're talking about) - to put users into roles, those roles can represent organizational units/departements, rights, managers, locations - this would in active directory be groups, but also attributes - there is a lot of attributes that you can use for location and departement etc - then build up dynamic roles, where you can for example give access or send an e-mail to everyone in Building 4, every one located in Sweden, every one that has the Manager Jimmy etc.

    As you say - often one or more users have to share more than one role within the organization, and an object can only be part of one container/organizational unit at a time in AD (we don't have the concept of aliases in AD) - But a user can be member of more than one role (e.g a group)

    I've designed ADs with 200.000 users - all within the same organizational unit - but beloging to diffrent roles truh groups and having objects quality == a set of base attributes that contain up-to-date information.

    Importent to note is that: If you are going to use this approch you need a mangement tool/view that can create a logical view for you from the information stored on the objects, let's say you want to perform a password reset of all users in the HR departement in the New York office - You need a tool that can show you just that logical view, instead if going truh 500 users in a single OU. (The big win out if this, that I see too many admins spending pretty serious amonunt of time on, is to move objects back and forth btween containers/organzational units cause thier company/organization just decied to re-org thier hierarchy (collapse/add/remove/rename departements etc.)

    Enfo Zipper
    Christoffer Andersson – Principal Advisor
    http://blogs.chrisse.se - Directory Services Blog

    Monday, June 10, 2013 2:41 AM
  • That's good advice from Christoffer.  I fully agree that trying to create an organisational hierarchy using the OU structure of AD is going to lead to problems.  Good reasons for creating OUs are:

    - Delegation of administration

    - Application of Group Policy

    - Improving visibility (although this is less valid with the more recent tools)

    Another issue with using AD to source the hierarchy is that it doesn't handle empty positions very well.  For example, all users in the Logistics department currently report to the head of Logistics, which is currently a vacant position. 

    Tony


    Tony www.activedir.org blog:www.open-a-socket.com

    Monday, June 10, 2013 2:53 AM

All replies

  • The best in my opinion and how many modern directorys are buillt today - I would stay away as long as possible to represent an organizational hierarchy in Active Directory by expressing it by diffrent levels of containers/organizational units (those serves the ability to group objects into a logical view for administration, if administration are done by the built-in administartive tools that comes with the product, they can also be used for delegation) - I would rather use a IdM (Identity Management System) to featch the information from another source (prehaps the oracel db you're talking about) - to put users into roles, those roles can represent organizational units/departements, rights, managers, locations - this would in active directory be groups, but also attributes - there is a lot of attributes that you can use for location and departement etc - then build up dynamic roles, where you can for example give access or send an e-mail to everyone in Building 4, every one located in Sweden, every one that has the Manager Jimmy etc.

    As you say - often one or more users have to share more than one role within the organization, and an object can only be part of one container/organizational unit at a time in AD (we don't have the concept of aliases in AD) - But a user can be member of more than one role (e.g a group)

    I've designed ADs with 200.000 users - all within the same organizational unit - but beloging to diffrent roles truh groups and having objects quality == a set of base attributes that contain up-to-date information.

    Importent to note is that: If you are going to use this approch you need a mangement tool/view that can create a logical view for you from the information stored on the objects, let's say you want to perform a password reset of all users in the HR departement in the New York office - You need a tool that can show you just that logical view, instead if going truh 500 users in a single OU. (The big win out if this, that I see too many admins spending pretty serious amonunt of time on, is to move objects back and forth btween containers/organzational units cause thier company/organization just decied to re-org thier hierarchy (collapse/add/remove/rename departements etc.)

    Enfo Zipper
    Christoffer Andersson – Principal Advisor
    http://blogs.chrisse.se - Directory Services Blog

    Monday, June 10, 2013 2:41 AM
  • That's good advice from Christoffer.  I fully agree that trying to create an organisational hierarchy using the OU structure of AD is going to lead to problems.  Good reasons for creating OUs are:

    - Delegation of administration

    - Application of Group Policy

    - Improving visibility (although this is less valid with the more recent tools)

    Another issue with using AD to source the hierarchy is that it doesn't handle empty positions very well.  For example, all users in the Logistics department currently report to the head of Logistics, which is currently a vacant position. 

    Tony


    Tony www.activedir.org blog:www.open-a-socket.com

    Monday, June 10, 2013 2:53 AM
  • Apologies for the late reply..

    Thanks Chris,

    That was quite a detailed answer!

    I think I'll follow that role-group format!

    Thanks again..

    Sunday, June 16, 2013 6:35 AM
  • Thanks Tony.. It is quite clear that OU is not the answer for our needs..

    Sunday, June 16, 2013 6:36 AM
  • I agree with NOT using the OUs as a means of modeling the organizational hierarchy. But one mechanism that could be used and that I am about to implement as a proof of concept would be to create an object hierarchy in active directory or ADLDS using subclasses of the existing AD schema classes. For instance, company class could be subclassed to permit its inclusion in other companies, the list of allowable attributes for this new subclassed company could include physical address, a POC (userDN), and a host of other interesting attributes.. This AD object hierarchy is already used in the manger attribute of the user object -- which would be a good starting point. Modifying the schema of AD will give most Domain Admins apoplexy - but it's a database the is intended to be the single authoritative source of information that is used across all aspects of the enterprise..  You can set up and test an instance of ADLDS - be sure to get a new OID block before creating new subclasses or attributes. Follow the MSFT guidelines on modifying the schema.. You'll also need to wire up the new pieces into the UI but it's not an impossible task.. Full blog post to follow..


    All science is either physics or stamp collecting

    Thursday, August 14, 2014 12:54 PM