Skip to main content
Skip table of contents

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_Radio1

A_Radio1_Admin

A_Radio1_OnAir

DS_BCS_Radio2

A_Radio2_Admin

A_Radio2_OnAir

DS_Tables_Read_Radio1

A_Radio1_Admin

A_Radio1_OnAir

A_Radio1_Production

DS_Tables_Write_Radio1

A_Radio1_Admin

A_Radio1_Production

DS_Tables_Read_Radio2

A_Radio2_Admin

A_Radio2_OnAir

A_Radio2_Production

DS_Tables_Write_Radio2

A_Radio2_Admin

A_Radio2_Production

Access Group

Member in...

A_Radio1_Production

DS_Tables_Read_Radio1

DS_Tables_Write_Radio1

A_Radio2_Production

DS_Tables_Read_Radio2

DS_Tables_Write_Radio2

A_Radio1_OnAir

DS_Tables_Read_Radio1

DS_BCS_Radio1

A_Radio2_OnAir

DS_Tables_Read_Radio2

DS_BCS_Radio2

A_Radio1_Admin

DS_Tables_Read_Radio1

DS_Tables_Write_Radio1

DS_BCS_Radio1

A_Radio2_Admin

DS_Tables_Read_Radio2

DS_Tables_Write_Radio2

DS_BCS_Radio2

User

Member in...

UADMIN

A_Radio1_Admin

A_Radio2_Admin

UR1ADMIN

A_Radio1_Admin

UR1CONTENT

A_Radio1_Production

UR1PLANNER

A_Radio1_OnAir

UR2ADMIN

A_Radio2_Admin

UR2CONTENT

A_Radio2_Production

UR2PLANNER

A_Radio2_OnAir

DigaSystem View

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.