When we are deploying Identity Management (IDM) solution in organization, we are facing a number of questions. One of them is how to map organization structure scheme (first picture below) to target system so we can facilitate and clarify the work of administrators to manage access and privileges tied to organization structure (OS). Let me show you how we solved this issue for one of our clients in the case of Active Directory (AD).
AD supports several object types. Relevant for the IDM solutions are the following: User, Group, and Organizational Unit (OU). It would be straightforward to map organization structure scheme directly to AD OU, but it is not always practical. OUs in AD have several limitations. The main ones that limit us are:
- User can be assigned to only one AD OU at once,
- when people are working in several departments and when we set up one to one access to OU and they should be assigned to several OUs, we have a problem – the solution is to use Groups instead of OU for department membership in AD
OU is mainly used for administration delegation, for example when certain computers are managed by a small group of administrators (e.g. admins of one locality manage only computers in their locality)
- a practice in AD when accounts are synchronized from HR (or other source system/s) is to have one AD OU (for example People) and all users assign in it
there is limit to display maximum number of items per OU. To avoid that, when we have a lot of users, we can speed up user listing when we create sub OUs with first letter of his name (or first two letters if necessary)
However based on the OU limitations, how to design access when we want to maintain information about the organizational structure and leverage it, although it will not have the structure of AD OUs?
The solution could be to use “group in the group” scheme approach.
Let us consider the following organizational structure:
We have mapped this OS to AD Groups as follows:
We have created a new root OU as a separate tree (INT), in INT we have created OU for People where Users are kept. In OU Departments we have created Groups with the organizational unit names. Development group is a member of Information Technologies, which is a member of the Operations. This configuration allows us to create permissions at the lowest level departments (leaves of the tree, for example: Development – access to the Git repository) and also at higher levels as well when certain departments have same characteristics (e.g. access to WiFi let be set up for each employee, level: Departments or just set it to IT people at Information Technologies level).
In addition to organization unit groups, it is a good practice to create group(s) for applications (OU: Applications) and put specific permission needs to individual applications (e.g. shared folder read access,) and combined with business groups (OU: Groups) which then form approaches for the mass of people (eg. employee, external, agreement), which will contain basic application and organizational groups.
Described groups design associated with the organization structure is transparent, flexible and easy to use for most IDM deployments. When it is appropriately combined with naming conventions, it significantly improves the transparency of identity management in the organization and the best thing about it is that even this can be created an updated with MidPoint