Active Directory Mapping

Organizing users and groups in Active Direcotry

Microsoft recommends to organize users and groups in the following way.

  • Security groups that hold permissions (and normally have no users as members)
  • Access groups that are members of security groups and have users as members (in theory access groups can be nested but it is not recommended)
  • Users gain permissions indirectly; they are member of access groups which are members of security groups

Note: Security and access groups are not technical properties but describe the usage of groups

Mapping Active Directory (AD) to DigaSystem (DS)

The only groups that have to be synchronized to DigaSystem are security groups. But not all security groups are holding DigaSystem permissions.

To identify DigaSystem-relevant security groups you specify an organizational unit (OU) in Active Directory which will be the root for all sync operations:

  • Groups in the AdSync root OU will be synced
  • Users in the AdSync root OU will be synced
  • Users that are directly or indirectly in groups of the AdSync root OU will be synced
  • In DigaSystem memberships of users are inherited to the top-level security group

The LDAP path specified in the ADSync configuration is used as synchronization root. Only users and groups referenced in this OU (organizational unit) are synchronized to the DigaSystem.


Configuration example in AdSync:

Synchronization Root

ADSync supports LDAP (and GC-style path specifications). A path starting with "LDAP://" (or no prefix) references a domain controller, a path starting with "GC://" references a global catalog server (this is kind of an index of AD content): Not all information available in a domain controller is available in a global catalog, e.g. local group information is not synchronized to a global catalog.

Example AD tree:

Because of LDAP restrictions, the following rules will be applied to the AD-tree:

  • Only containers on 1st level will be synced to DigaSystem groups ("group1" and "ou1" on the picture above).
  • Containers of 2nd and deeper levels are only used to overcome LDAP restrictions and are not created on the DigaSystem side during synchronization process. However, all user from these containers are synchronized recursively and are linked to the related 1st level ancestor.
  • Users can be member of more than one group.

Resulting DigaSystem tree:



Examples

Active Directory View

Membership

Security Group

Contains Access Groups...



DS_BCS_Radio1A_Radio1_AdminA_Radio1_OnAir
DS_BCS_Radio2A_Radio2_AdminA_Radio2_OnAir
DS_Tables_Read_Radio1A_Radio1_AdminA_Radio1_OnAirA_Radio1_Production
DS_Tables_Write_Radio1A_Radio1_Admin
A_Radio1_Production
DS_Tables_Read_Radio2A_Radio2_AdminA_Radio2_OnAirA_Radio2_Production
DS_Tables_Write_Radio2A_Radio2_Admin
A_Radio2_Production

Access Group

Member in...



A_Radio1_ProductionDS_Tables_Read_Radio1DS_Tables_Write_Radio1
A_Radio2_ProductionDS_Tables_Read_Radio2DS_Tables_Write_Radio2
A_Radio1_OnAirDS_Tables_Read_Radio1
DS_BCS_Radio1
A_Radio2_OnAirDS_Tables_Read_Radio2
DS_BCS_Radio2
A_Radio1_AdminDS_Tables_Read_Radio1DS_Tables_Write_Radio1DS_BCS_Radio1
A_Radio2_AdminDS_Tables_Read_Radio2DS_Tables_Write_Radio2DS_BCS_Radio2

User

Member in...




UADMINA_Radio1_AdminA_Radio2_Admin

UR1ADMINA_Radio1_Admin


UR1CONTENT

A_Radio1_Production
UR1PLANNER


A_Radio1_OnAir
UR2ADMIN
A_Radio2_Admin

UR2CONTENT

A_Radio2_Production
UR2PLANNER


A_Radio2_OnAir

DigaSystem View