Benötigte Berechtigungen
Um Filterausdrücken mit relationalen Vergleichsoperatoren zu verarbeiten, benötigt das verwendeten Benutzerkonto die Programmfunktion ApiServer_SCIM. Ausnahmen davon sind der Test auf Gleichheit (eq) und auf Vorhandensein eines Wertes (pr). Dies gilt sowohl für Filter im URL-Parameter filter als auch für die Verwendung von Path-Filtern in Patch-Operationen.
Soll es bestimmten Benutzern möglich sein, Filterausdrücke zu verarbeiten, können Sie die Berechtigungen über Berechtigungsgruppen an die Benutzer vergeben.
-
Für die nicht-rollenbasierte Anmeldung wird die Berechtigungsgruppe QBM_ApiServer_SCIM bereitgestellt. Diese Gruppe besitzt die Programmfunktion. Nehmen Sie die Systembenutzer in die Berechtigungsgruppe auf. Administrative Systembenutzer erhalten diese Berechtigungsgruppe automatisch.
-
Für die rollenbasierte Anmeldung wird die Berechtigungsgruppe QER_4_ApiServer_SCIM bereitgestellt. Diese Gruppe besitzt die Programmfunktion. Die Berechtigungsgruppe ist mit der Anwendungsrolle Basisrollen | API Server SCIM Filter verbunden. Nehmen Sie die Identitäten in die Anwendungsrolle auf.
Anfragen an die Basis-URL
Die SCIM 2.0 Spezifikation sieht optionale Anfragen an die Basis-URL des SCIM Serviceproviders vor. Diese Anfragen können optional einen Filterausdruck enthalten. Dies dient vorwiegend der Suche nach Objekten, wenn deren Endpunkt nicht genau bekannt ist und somit der Endpunkt-übergreifenden Suche.
Das SCIM Plugin unterstützt diese Anfragen. Im Filter sind nur logische OR-Verknüpfungen und die Vergleichsoperatoren eq, sw, ew sowie co zugelassen, die sich auf die Metainformation Resourcetype beziehen müssen.
Beispiel:
https://<servername>.<domainname>/ApiServer/scim/v2?filter=(meta.Resourcetype eq “Locality”) or (meta.Resourcetype sw “D”)
Das Ergebnis kann eine Liste von Objekten verschiedenen Typs enthalten, wobei die Anzahl der zurückgelieferten Elemente 10.000 aus Last- und Performance-Gründen nicht überschreiten darf. Andernfalls wird eine Fehlermeldung von Typ tooMany zurückgegeben. Die Suchbedingung sollte verfeinert werden und das Ergebnis stärker einschränken.
Anfragen an eine Endpunkt-URL
Die SCIM 2.0 Spezifikation sieht bei Anfragen an die über /ResourceTypes definierten Endpunkte optional die Parameter filter, attributes, count und startIndex vor. Bei Anfragen mit der ID eines konkreten Objektes (die URL enthält die id des Objektes) sind die Parameter excludedAttributes und attributes erlaubt. Das SCIM Plugin unterstützt diese Parameter.
Bei Anfragen an einen Endpunkt wird eine Liste aller Elemente (oder aller Elemente, die dem Filter entsprechen) zurückgegeben. So kann vom SCIM Client ein indexbasiertes Paging mit Angabe der gewünschten Anzahl von Sätzen pro Seite initiiert werden (Parameter count und startIndex).
Beispiel: Anfrage an einen Endpunkt
http://<servername>.<domainname>/ApiServer/scim/v2/Person
Beispiel: Anfrage der ersten 100 Elemente an einen Endpunkt mit Paging
http://<servername>.<domainname>/ApiServer/scim/v2/Person?startindex=1&count=100
Beispiel: Anfrage an einen Endpunkt mit Filter
http://<servername>.<domainname>/ApiServer/scim/v2/Person?filter=InternalName co "Y"
Beispiel: Anfrage an einen Endpunkt mit Filter und Ausgabe von zwei zusätzlichen Eigenschaften
http://<servername>.<domainname>/ApiServer/scim/v2/Person?filter=InternalName co "Y"&attributes=ExitDate,TechnicalEntryDate
Beispiel: Anfrage eines Objektes an einen Endpunkt
http://<servername>.<domainname>/ApiServer/scim/v2/UNSGroupB/94bbe614-0a6e-4659-8fe9-20da94d967c8
Beispiel: Anfrage von konkreten Eigenschaften eines Objektes an einen Endpunkt
http://<servername>.<domainname>/ApiServer/scim/v2/UNSGroupB/94bbe614-0a6e-4659-8fe9-20da94d967c8?attributes=cn,members
Die in die DBQueue eingestellten Aufträge resultieren aus Triggerverarbeitung, Änderungen an Konfigurationsparametern, wie beispielsweise Änderung der Konfigurationsparameter zur Vererbung oder durch die Ausführung zeitgesteuerter Aufträge. Der DBQueue Prozessor verarbeitet die Aufträge aus der DBQueue. Für die parallele Ausführung der Aufträge werden durch den DBQueue Prozessor mehrere Slots verwendet. Die Verarbeitung der internen Aufträge erfolgt durch den Database Agent Service. Stellen Sie sicher, dass der Database Agent Service installiert und konfiguriert ist.
Detaillierte Informationen zum Thema
Über die Staging-Ebene der One Identity Manager-Datenbank legen Sie fest, ob es sich um eine Testdatenbank, Entwicklungsdatenbank oder produktive Datenbank handelt. Über die Staging-Ebene werden einige Datenbankeinstellungen gesteuert.
Wenn Sie die Staging-Ebene der Datenbank ändern, werden die folgenden Einstellungen konfiguriert.
Tabelle 185: Standardeinstellungen für Entwicklungsumgebung, Testumgebung und Produktivumgebung
|
Maximale Laufzeit DBQueue Prozessor |
20 Minuten |
40 Minuten |
120 Minuten |
|
Maximale Anzahl der Slots für DBQueue Prozessor |
5 |
7 |
Maximale Anzahl der Slots laut Hardwarekonfiguration |
Die Standardeinstellungen für den DBQueue Prozessor sind für einen Normalbetrieb ausgelegt und müssen in der Regel nicht angepasst werden.
Wenn mehrere Datenbanken in einer verwalteten Instanz in Azure SQL-Datenbank betrieben werden, können Sie die Anzahl der Slots fest vorgeben. Passen Sie im Designer den folgenden Konfigurationsparameter an.
-
QBM | DBServerAgent | CountSlotAgents: Genaue Anzahl der Slots. Ist der Konfigurationsparameter aktiviert, wird immer die Anzahl der angegebenen Slot eingerichtet. Es erfolgt keine interne Berechnung der Slotanzahl anhand der Hardwarekonfiguration. Die Änderung der Konfiguration des Servers hat keinen Einfluss. Es wird der Wert 15 empfohlen.
HINWEIS: Für den Einsatz einer Datenbank auf einem SQL Server wird der Konfigurationsparameter nicht empfohlen. Für den Einsatz einer Datenbank auf einem SQL Server hat sich die Ermittlung der Slots über die Hardwarekonfiguration bewährt.
Für Testumgebungen und Entwicklungsumgebungen sind die Konfigurationseinstellungen reduziert, da sich mehrere Datenbanken auf einem Server befinden können. Müssen aus Performancegründen die Einstellungen für Testumgebungen und Entwicklungsumgebungen angepasst werden, ändern Sie im Designer die Einstellungen der folgenden Konfigurationsparameter an.
-
QBM | DBQueue | CountSlotsMax: Anzahl der maximal zu verwendenden Slots.
Nutzen Sie den Konfigurationsparameter um die Anzahl der Slots bei Bedarf zu reduzieren. Werte kleiner als 5 sind nicht zulässig.
Ausnahme: Für die Nutzung der maximal verfügbaren Slots laut Hardwarekonfiguration geben Sie den Wert 0 an.
-
QBM | DBQueue | KeepAlive: Maximale Laufzeit des zentralen Dispatchers. Nach Ablauf der Laufzeit werden die Aufträge aktuell verwendeter Slots noch abgearbeitet. Anschließend werden die Slots gestoppt und der zentrale Dispatcher beendet.
Der minimal zulässige Wert für die Laufzeit ist 5 Minuten, der maximal zulässige Wert ist 720 Minuten.
Verwandte Themen
Treten bei der Initialisierung des DBQueue Prozessors Fehler auf, werden die Meldungen im Anwendungsprotokoll protokolliert. Das Anwendungsprotokoll können Sie beispielsweise über die Ereignisanzeige in der Microsoft Management Console anzeigen.
Über den Konfigurationsparameter QBM | DBServerAgent | CreateNotification können Sie konfigurieren, in welchen Fällen Meldungen in das Anwendungsprotokoll geschrieben werden. Passen Sie den Konfigurationsparameter bei Bedarf im Designer an.
Zulässige Werte sind:
-
0: Es erfolgt keine Protokollierung.
-
1: Es werden nur Erfolgsmeldungen protokolliert.
-
2: Es werden nur Fehlermeldungen protokolliert (Standard).
-
3: Es werden alle Meldungen protokolliert.
