Die Berechnung der durch die Vererbung zugeordneten Objekte erfolgt durch den DBQueue Prozessor. Durch Trigger werden bei vererbungsrelevanten Zuordnungen Aufträge in die DBQueue eingestellt. Diese Aufträge werden durch den DBQueue Prozessor verarbeitet und resultieren in weiteren Folgeaufträgen für die DBQueue oder in Prozessen für die Prozesskomponente HandleObjectComponent in der Jobqueue. Durch die Prozessverarbeitung werden die resultierenden Zuordnungen von Berechtigungen zu Benutzerkonten in den Zielsystem-Umgebungen eingefügt, geändert oder gelöscht.
Abbildung 10: Überblick über die Berechnung der Vererbung
Identitäten, Geräte und Arbeitsplätze können nur Mitglieder in Rollen werden, die auf der Tabelle BaseTree aufbauen. Diese Rollen werden in Sichten (Views) abgebildet, die jeweils einen bestimmten Teilausschnitt der Tabelle BaseTree repräsentieren.
Tabelle 3: Sichten auf die Tabelle BaseTree
|
Org |
Abbildung von Geschäftsrollen |
HINWEIS: Da die Sichten Teilausschnitte der Tabelle BaseTree sind, gelten alle nachfolgend beschriebenen Vererbungsmechanismen ebenso für die Sichten.
Vererbungen gehen von der Tabelle BaseTree aus. Die Tabelle BaseTree kann über die Beziehung UID_Org - UID_ParentOrg beliebig viele Rollenhierarchien abbilden. Diese werden in der Tabelle BaseTreeCollection abgelegt. Dabei werden alle Rollen aufgezählt, von denen die angegebene Rolle erbt. Entsprechend ihrer Teilausschnitte aus der Tabelle BaseTree gibt es für jede Sicht eine entsprechend benannte *Collection-Tabelle mit dem Teilausschnitt der Rollenhierarchie.
In der Tabelle BaseTreeCollection gilt folgende Beziehung:
-
UID_Org ist die Rolle, die erbt.
-
UID_ParentOrg ist die Rolle, die vererbt.
Dieses Prinzip gilt auch bei Bottom-Up-Bäumen, die von unten nach oben vererben, auch wenn scheinbar die Eltern-Beziehung aus der BaseTree-Tabelle umgekehrt wird.
Jede Rolle erbt auch von sich selbst.
Jede Rolle einer Rollenhierarchie muss einen Bezug zur Tabelle OrgRoot (Rollenklassen) haben. OrgRoot ist die Klammer für Rollenhierarchien. Eine Rollenhierarchie wird immer nur für eine Rollenklasse gebildet. Rollen aus verschiedenen Rollenklassen dürfen nicht in ein und derselben Rollenhierarchie vorkommen oder per Eltern-Kind-Beziehung aufeinander verweisen.
Abbildung 11: Darstellung einer hierarchischen Rollenstruktur am Beispiel einer OrgCollection
Eine Rolle erbt alles, was ihren Eltern in der Rollenhierarchie zugewiesen wurde, einschließlich dem, was ihr selbst zugewiesen wurde. Ändert sich die Menge der Rollen, von denen eine Rolle etwas erbt, so wird für alle Mitglieder dieser Rolle eine Neuberechnung der zugeordneten Objekte veranlasst. Ändert sich die Menge von zugeordneten Objekten eines Objekttyps zu einer Rolle, so wird für alle Mitglieder der Rolle eine Neuberechnung der zugeordneten Objekte dieses Objekttyps veranlasst. Wird also beispielsweise Software an eine übergeordnete Rolle zugewiesen, werden die Mitglieder der Tabelle BaseTreeHasApp neu berechnet.
Die Mitglieder einer Rolle erben nach definierten Regeln alle Zuweisungen über die primären und sekundären Rollenstrukturen, denen Sie laut der Tabelle BaseTree angehören sowie den Vorgängerstrukturen laut der Tabelle BaseTreeCollection.
Bei der Berechnung der Vererbung erfolgt für jede Zuweisung ein Eintrag in die entsprechende Zuweisungstabelle. Jede Tabelle, in der Zuweisungen abgebildet werden, hat eine Spalte XOrigin. In dieser Spalte wird die Herkunft einer Zuweisung als Verknüpfung von Bit-Positionen abgelegt. Bei jedem Eintrag in die Zuweisungstabelle erfolgt entsprechend der Zuweisungsart eine Änderung der Bit-Positionen. Jede Zuweisungsart ändert dabei nur die für sie vorgesehene Bit-Position.
Es bedeuten:
-
Bit 0: Die Zuweisung wurde direkt vorgenommen.
-
Bit 1: Die Zuweisung wurde indirekt vorgenommen, jedoch nicht über eine dynamischen Rolle.
-
Bit 2: Die Zuweisung erfolgte über eine dynamische Rolle.
-
Bit 3: Die Zuweisung erfolgte über eine Zuweisungsbestellung.
-
Bit 4: Das Bit wird modulspezifisch unterschiedlich verwendet. Ausführliche Informationen finden Sie in den Administrationshandbüchern der Module, in denen das Bit genutzt wird.
Tabelle 4: Mögliche Werte der Spalte XOrigin
|
0 |
0 |
0 |
1 |
1 |
Nur direkt zugewiesen. |
|
0 |
0 |
1 |
0 |
2 |
Nur indirekt zugewiesen. |
|
0 |
0 |
1 |
1 |
3 |
Direkt und indirekt zugewiesen. |
|
0 |
1 |
0 |
0 |
4 |
Über dynamische Rolle zugewiesen. |
|
0 |
1 |
0 |
1 |
5 |
Über dynamische Rolle und direkt zugewiesen. |
|
0 |
1 |
1 |
0 |
6 |
Über dynamische Rolle und indirekt zugewiesen. |
|
0 |
1 |
1 |
1 |
7 |
Über dynamische Rolle, direkt und indirekt zugewiesen. |
|
1 |
0 |
0 |
0 |
8 |
Zuweisungsbestellung. |
|
1 |
0 |
0 |
1 |
9 |
Zuweisungsbestellung und direkt zugewiesen. |
|
1 |
0 |
1 |
0 |
10 |
Zuweisungsbestellung und indirekt zugewiesen. |
|
1 |
0 |
1 |
1 |
11 |
Zuweisungsbestellung, direkt und indirekt zugewiesen. |
|
1 |
1 |
0 |
0 |
12 |
Zuweisungsbestellung und über dynamische Rolle zugewiesen. |
|
1 |
1 |
0 |
1 |
13 |
Zuweisungsbestellung, direkt und über dynamische Rolle zugewiesen. |
|
1 |
1 |
1 |
0 |
14 |
Zuweisungsbestellung, indirekt und über dynamische Rolle zugewiesen. |
|
1 |
1 |
1 |
1 |
15 |
Zuweisungsbestellung, direkt, indirekt und über dynamische Rolle zugewiesen. |
Besonderheiten bei Vererbung von Zuweisungen über Rollenhierarchie
HINWEIS: Wenn eine Zuweisung über die Rollenhierarchie vererbt wird, wird an der geerbten Zuweisung das Bit 1 gesetzt. Geerbte Zuweisungen sind folglich immer indirekt zugewiesen, auch wenn sie ursprünglich direkt, über eine dynamische Rolle oder eine Zuweisungsbestellung entstanden sind.
Beispiel:
Für die Geschäftsrolle "Sales" wurde die Zuweisung einer Active Directory Gruppe bestellt. Die untergeordnete Geschäftsrolle "Sales EMEA" erbt diese Zuweisung. In der Tabelle OrgHasADSGroup ist XOrigin folgendermaßen gesetzt:
- Geschäftsrolle "Sales": XOrigin='8' (Zuweisungsbestellung)
- Geschäftsrolle "Sales EMEA": XOrigin='2' (indirekt zugewiesen)
Wirksamkeit von Zuweisungen
Ob eine Zuweisung wirksam ist, wird über die Spalte XIsInEffect abgebildet. Ist beispielsweise eine Identität deaktiviert, zum Löschen markiert oder als sicherheitsgefährdend eingestuft, so kann für diese Identität die Vererbung der Unternehmensressourcen unterbunden werden. Die Zuweisung der Unternehmensressourcen bleibt erhalten, diese Zuweisung wird jedoch nicht wirksam.
Der DBQueue Prozessor überwacht die Änderung der Spalte XOrigin. Bei Änderung des Wertes in XOrigin wird die Spalte XIsInEffect neu berechnet.
Folgende Einstellungen sollten Sie vor der Zuweisung von Unternehmensressourcen prüfen und gegebenenfalls anpassen:
-
Legen Sie fest, ob und wie Identitäten, Geräte und Arbeitsplätze und Unternehmensressourcen an Rollen zugewiesen werden dürfen.
-
Legen Sie die Vererbungsrichtung innerhalb der Hierarchie fest.
-
Schränken Sie bei Bedarf die Vererbung für bestimmte Rollen ein.
Sie können für einzelne Rollen oder einzelne Identitäten, Geräte oder Arbeitsplätze festlegen, ob die Vererbung von Unternehmensressourcen verhindert werden soll.
-
Definieren Sie bei Bedarf Rollen, die sich gegenseitig ausschließen.
Über die Festlegung sogenannter widersprechende Rollen verhindern Sie, dass Identitäten, Geräte oder Arbeitsplätze in Rollen aufgenommen werden, die sich ausschließende Unternehmensressourcen enthalten.
Detaillierte Informationen zum Thema
