Bekannte Probleme und Lösungen bei der Einhaltung des SCIM 2.0-Protokolls des Microsoft Entra-Benutzerbereitstellungsdiensts
Über Microsoft Entra ID können Benutzer*innen und Gruppen automatisch für alle Anwendungen oder Systeme bereitgestellt werden, denen ein Webdienst mit der in der SCIM 2.0-Protokollspezifikation definierten Schnittstelle vorgelagert ist.
Die Microsoft Entra Unterstützung für das SCIM 2.0-Protokoll wird unter Automatisches Bereitstellen von Benutzer*innen und Gruppen aus Microsoft Entra ID für Anwendungen mit SCIM (System for Cross-Domain Identity Management) beschrieben. Dort werden auch die einzelnen Teile des Protokolls aufgeführt, die implementiert werden, um Benutzer*innen und Gruppen aus Microsoft Entra ID für Anwendungen, die SCIM 2.0 unterstützen, automatisch bereitzustellen.
In diesem Artikel werden aktuelle und ehemalige Probleme mit dem Bereitstellungsdienst für Microsoft Entra-Benutzer*innen im Zusammenhang mit der Einhaltung des SCIM 2.0-Protokolls und Möglichkeiten zur Umgehung dieser Probleme beschrieben.
Grundlegendes zum Bereitstellungsauftrag
Vom Bereitstellungsdienst wird das Konzept eines Auftrags verwendet, um Vorgänge für eine Anwendung auszuführen. Die Auftrags-ID (jobID) ist in der Statusanzeige angegeben. Alle neuen Bereitstellungsanwendungen werden mit einer Auftrags-ID erstellt, die mit „scim“ beginnt. Der SCIM-Auftrag stellt den aktuellen Zustand des Diensts dar. Ältere Aufträge haben die ID „customappsso“. Dieser Auftrag stellt den Zustand des Diensts im Jahr 2018 dar.
Bei Verwendung einer Kataloganwendung enthält der Auftrag in der Regel den Namen der App (beispielsweise „zoom snowFlake“ oder „dataBricks“). Wenn Sie eine Kataloganwendung verwenden, können Sie diese Dokumentation überspringen. Die Informationen gelten hauptsächlich für katalogfremde Anwendungen mit der Auftrags-ID „SCIM“ oder „customAppSSO“.
SCIM 2.0-Konformitätsprobleme und Status
Bei Elementen, die in der folgenden Tabelle als korrigiert markiert sind, weist der SCIM-Auftrag das korrekte Verhalten auf. Bei den vorgenommenen Änderungen haben wir uns zwar um Abwärtskompatibilität bemüht. Das neue Verhalten sollte für alle neuen Implementierungen sowie bei der Aktualisierung bereits vorhandener Implementierungen verwendet werden. Beachten Sie, dass das Verhalten von customappSSO, das vor Dezember 2018 Standard war, nicht mehr unterstützt wird.
Hinweis
Für die 2018 vorgenommenen Änderungen können Sie das customappsso-Verhalten wiederherstellen. Für die seit 2018 vorgenommenen Änderungen können Sie die URLs verwenden, um das ältere Verhalten wiederherzustellen. Bei den vorgenommenen Änderungen haben wir uns um Abwärtskompatibilität bemüht: Sie können entweder zur alten Auftrags-ID zurückkehren oder ein Flag verwenden. Es empfiehlt sich jedoch wie bereits erwähnt nicht, das alte Verhalten zu implementieren, da es nicht mehr unterstützt wird. Das neue Verhalten sollte für alle neuen Implementierungen sowie bei der Aktualisierung bereits vorhandener Implementierungen verwendet werden.
| SCIM 2.0-Konformitätsproblem | Korrigiert? | Korrekturdatum | Abwärtskompatibilität |
|---|---|---|---|
| Microsoft Entra ID erfordert „/scim“ im Stamm der SCIM-Endpunkt-URL der Anwendung | Ja | 18. Dezember 2018 | Downgrade zu „customappSSO“ |
| Erweiterungsattribute verwenden vor Attributnamen die Punktnotation „.“ anstelle der Doppelpunktnotation „:“. | Ja | 18. Dezember 2018 | Downgrade zu „customappSSO“ |
| Patchanforderungen für mehrwertige Attribute enthalten eine ungültige Syntax für Pfadfilter | Ja | 18. Dezember 2018 | Downgrade zu „customappSSO“ |
| Anforderungen zur Erstellung von Gruppen enthalten einen ungültigen Schema-URI | Ja | 18. Dezember 2018 | Downgrade zu „customappSSO“ |
| Aktualisieren des PATCH-Verhaltens zum Sicherstellen der Konformität (z. B. aktiv als boolescher Wert und ordnungsgemäßes Entfernen von Gruppenmitgliedschaften) | No | TBD | Verwenden eines Featureflags |
Flags zum Ändern des SCIM-Verhaltens
Verwenden Sie die weiter unten angegebenen Flags in der Mandanten-URL Ihrer Anwendung, um das Standardverhalten des SCIM-Clients zu ändern.
Verwenden Sie die folgende URL, um das PATCH-Verhalten zu aktualisieren und SCIM-Konformität sicherzustellen. Das Flag ändert die folgenden Verhalten:
- Anforderungen zum Deaktivieren von Benutzern
- Anforderungen zum Hinzufügen eines Zeichenfolgenattributs mit einem einzelnen Wert
- Anforderungen zum Ersetzen mehrerer Attribute
- Anforderungen zum Entfernen eines Gruppenmitglieds
Dieses Verhalten ist derzeit nur verfügbar, wenn Sie das Flag verwenden, wird jedoch in den nächsten Monaten zum Standardverhalten. Beachten Sie, dass dieses Featureflag bei bedarfsgesteuerter Bereitstellung nicht funktioniert.
- URL (SCIM-konform): aadOptscim062020
- SCIM-RFC-Verweise:
Im Folgenden finden Sie Beispielanforderungen, die darlegen sollen, was die Synchronisierungs-Engine derzeit sendet, im Vergleich zu den Anforderungen, die gesendet werden, nachdem das Featureflag aktiviert wurde.
Anforderungen zum Deaktivieren von Benutzern:
Ohne Featureflag
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "Replace",
"path": "active",
"value": "False"
}
]
}
Mit Featureflag
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "replace",
"path": "active",
"value": false
}
]
}
Anforderungen zum Hinzufügen eines Zeichenfolgenattributs mit einem einzelnen Wert:
Ohne Featureflag
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "Add",
"path": "nickName",
"value": "Babs"
}
]
}
Mit Featureflag
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "add",
"path": "nickName",
"value": "Babs"
}
]
}
Anforderungen zum Ersetzen mehrerer Attribute:
Ohne Featureflag
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "Replace",
"path": "displayName",
"value": "Pvlo"
},
{
"op": "Replace",
"path": "emails[type eq \"work\"].value",
"value": "TestBcwqnm@test.microsoft.com"
},
{
"op": "Replace",
"path": "name.givenName",
"value": "Gtfd"
},
{
"op": "Replace",
"path": "name.familyName",
"value": "Pkqf"
},
{
"op": "Replace",
"path": "externalId",
"value": "Eqpj"
},
{
"op": "Replace",
"path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumber",
"value": "Eqpj"
}
]
}
Mit Featureflag
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "replace",
"path": "emails[type eq \"work\"].value",
"value": "TestMhvaes@test.microsoft.com"
},
{
"op": "replace",
"value": {
"displayName": "Bjfe",
"name.givenName": "Kkom",
"name.familyName": "Unua",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumber": "Aklq"
}
}
]
}
Anforderungen zum Entfernen eines Gruppenmitglieds:
Ohne Featureflag
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "Remove",
"path": "members",
"value": [
{
"value": "u1091"
}
]
}
]
}
Mit Featureflag
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "remove",
"path": "members[value eq \"7f4bc1a3-285e-48ae-8202-5accb43efb0e\"]"
}
]
}
- Downgrade-URL: Sobald das neue SCIM-konforme Verhalten bei nicht im Katalog enthaltenen Anwendungen zum Standardverhalten wird, können Sie mit der folgenden URL ein Rollback auf das alte, nicht SCIM-konforme Verhalten durchführen: AzureAdScimPatch2017
Upgraden vom älteren customappsso-Auftrag zum SCIM-Auftrag
Durch die folgenden Schritte wird Ihr vorhandener customappsso-Auftrag gelöscht und ein neuer SCIM-Auftrag erstellt.
Melden Sie sich beim Microsoft Entra Admin Center mindestens mit der Rolle Anwendungsadministrator an.
Browsen Sie zu Identität>Anwendungen>Unternehmensanwendungen.
Suchen Sie nach Ihrer vorhandenen SCIM-Anwendung, und wählen Sie sie aus.
Kopieren Sie im Abschnitt Eigenschaften Ihrer SCIM-App die Objekt-ID.
Wechseln Sie in einem neuen Webbrowserfenster zu https://developer.microsoft.com/graph/graph-explorer, und melden Sie sich als Administrator*in für den Microsoft Entra-Mandanten an, unter dem Ihre App hinzugefügt wurde.
Führen Sie im Graph-Tester den unten stehenden Befehl aus, um die ID Ihres Bereitstellungsauftrags zu suchen. Ersetzen Sie „[object-id]“ durch die Dienstprinzipal-ID (Objekt-ID), die Sie im dritten Schritt kopiert haben.
GET https://graph.microsoft.com/beta/servicePrincipals/[object-id]/synchronization/jobs
Kopieren Sie in den Ergebnissen die vollständige „ID“-Zeichenfolge, die mit „customappsso“ oder mit „scim“ beginnt.
Führen Sie den folgenden Befehl aus, um die Konfiguration für die Attributzuordnung abzurufen, damit Sie eine Sicherung erstellen können. Verwenden Sie dieselbe [object-id] wie zuvor, und ersetzen Sie die [job-id] durch die ID des Bereitstellungsauftrags, die Sie im letzten Schritt kopiert haben.
GET https://graph.microsoft.com/beta/servicePrincipals/[object-id]/synchronization/jobs/[job-id]/schemaKopieren Sie die JSON-Ausgabe aus dem letzten Schritt, und speichern Sie sie in einer Textdatei. Der JSON-Code enthält alle benutzerdefinierten Attributzuordnungen, die Sie in Ihrer alten App hinzugefügt haben, und sollte einige Tausend Zeilen mit JSON-Code umfassen.
Führen Sie den folgenden Befehl aus, um den Bereitstellungsauftrag zu löschen:
DELETE https://graph.microsoft.com/beta/servicePrincipals/[object-id]/synchronization/jobs/[job-id]Führen Sie den folgenden Befehl aus, um einen neuen Bereitstellungsauftrag zu erstellen, der über die neuesten Fehlerbehebungen für den Dienst verfügt.
POST https://graph.microsoft.com/beta/servicePrincipals/[object-id]/synchronization/jobs
{ "templateId": "scim" }
- Kopieren Sie in den Ergebnissen des letzten Schritts die vollständige „ID“-Zeichenfolge, die mit „scim“ beginnt. Sie können optional auch Ihre alten Attributzuordnungen erneut anwenden. Führen Sie dazu den Befehl unten aus, und ersetzen Sie „[new-job-id]“ durch die neue Auftrags-ID, die Sie kopiert haben. Geben Sie außerdem die JSON-Ausgabe aus Schritt 7 als Anforderungstext ein.
PUT https://graph.microsoft.com/beta/servicePrincipals/[object-id]/synchronization/jobs/[new-job-id]/schema
{ <your-schema-json-here> }
- Wechseln Sie wieder zurück zum ersten Webbrowserfenster, und wählen Sie die Registerkarte Bereitstellung für Ihre Anwendung aus.
- Überprüfen Sie Ihre Konfiguration, und starten Sie anschließend den Bereitstellungsauftrag.
Downgraden vom SCIM-Auftrag zum customappsso-Auftrag (nicht empfohlen)
Das alte Verhalten kann zwar mithilfe eines Downgrades wiederhergestellt werden, dies wird jedoch nicht empfohlen, da einige der von uns vorgenommenen Aktualisierungen nicht für customappsso zur Verfügung stehen und customappsso möglicherweise irgendwann nicht mehr unterstützt wird.
Melden Sie sich beim Microsoft Entra Admin Center mindestens mit der Rolle Anwendungsadministrator an.
Browsen Sie zu Identität>Anwendungen>Unternehmensanwendungen.
Erstellen Sie im Abschnitt Anwendung erstellen eine neue Nicht-Kataloganwendung.
Kopieren Sie im Abschnitt Eigenschaften der neuen benutzerdefinierten App die Objekt-ID.
Wechseln Sie in einem neuen Webbrowserfenster zu https://developer.microsoft.com/graph/graph-explorer, und melden Sie sich als Administrator*in für den Microsoft Entra-Mandanten an, unter dem Ihre App hinzugefügt wurde.
Führen Sie im Graph-Tester den folgenden Befehl aus, um die Konfiguration der Bereitstellung für Ihre App zu initialisieren. Ersetzen Sie „[object-id]“ durch die Dienstprinzipal-ID (Objekt-ID), die Sie im dritten Schritt kopiert haben.
POST https://graph.microsoft.com/beta/servicePrincipals/[object-id]/synchronization/jobs{ templateId: "customappsso" }Wechseln Sie wieder zurück zum ersten Webbrowserfenster, und wählen Sie die Registerkarte Bereitstellung für Ihre Anwendung aus.
Schließen Sie die Konfiguration der Benutzerbereitstellung wie gewohnt ab.
Nächste Schritte
Erfahren Sie mehr über die Bereitstellung und Bereitstellungsaufhebung für SaaS-Anwendungen.