Okta/Microsoft Entra ID Provisioning für Multi-SaaS-Kunden automatisieren

Kunden mit vielen Software-as-a-Service-Anwendungen brauchen ein zentrales Identity Provisioning, um die Einarbeitungszeit zu verkürzen, Einheitlichkeit durchzusetzen und die Zugriffssteuerung im Griff zu behalten. Okta und Entra ID (früher Azure AD) unterstützen SCIM- und API-basiertes Provisioning, um das Lebenszyklus-Management von Benutzer:innen über Cloud-Anwendungen hinweg zu automatisieren. Die Automatisierung dieses Prozesses reduziert manuelle Fehler, beschleunigt das Provisioning und setzt Zugriffsrichtlinien vom ersten Tag an durch.

Dieser Leitfaden erklärt Schritt für Schritt, wie Sie automatisiertes User Provisioning in Entra ID und Okta umsetzen.

Lieber als Video? Sehen Sie sich unser Video-Tutorial „So automatisieren Sie das Provisioning in Okta/Microsoft Entra ID für Multi-SaaS-Kunden“ an, um mehr über das Thema zu erfahren.

Klicken Sie, um eine Methode zu wählen	💻 Am besten für einzelne Benutzer:innen	💻💻💻 Am besten für Unternehmen
Phase 1: Ein rollenbasiertes Provisioning-Modell entwickeln		✓
Phase 2 (PROVISIONING): Methode A – Provisioning von Benutzer:innen und Gruppen in Entra ID automatisieren		✓
Phase 2 (PROVISIONING): Methode B – Okta-Provisioning mit Workflows und SCIM automatisieren		✓
Phase 3 (ÜBERWACHUNG & VALIDIERUNG): Option A – Provisioning-Status über Registry und lokale Protokolle nachverfolgen		✓
Phase 3 (ÜBERWACHUNG & VALIDIERUNG): Option B – Lokale Agent-Aktivität mit Eingabeaufforderung und Ereignisprotokollen prüfen		✓
Phase 4: Provisioning-Richtlinie über Gruppenrichtlinien oder Intune durchsetzen		✓

Phasen und Methoden, um das User Provisioning für Multi-SaaS-Kunden zu automatisieren

Für MSPs beseitigt automatisiertes User Provisioning das manuelle, anwendungsspezifische Anlegen von Benutzer:innen, senkt das Risiko menschlicher Fehler und Verzögerungen und sorgt für einheitliche, rollenbasierte Zugriffe über alle Systeme hinweg. So automatisieren Sie das Provisioning in Okta/Entra ID:

Phase 1: Ein rollenbasiertes Provisioning-Modell entwickeln

In dieser Phase definieren Sie eine standardisierte Struktur, in der Benutzer:innen Rollen wie Vertrieb, HR oder IT zugewiesen werden. Die Rolle bestimmt, welche SaaS-Anwendungen, Berechtigungen und Ressourcen sie erhalten.

📌 Voraussetzungen:

• Vordefinierte Benutzerrollen und Richtlinien für die Anwendungszuweisung
• Admin-Anmeldeinformationen für die Mandantenumgebungen von Entra ID und/oder Okta
• Gruppenbasierte Zugriffssteuerung ist in Okta/Entra ID aktiviert

Standardisieren Sie vor der Automatisierung die Zugriffsanforderungen nach Rolle oder Abteilung:

1. Benutzerrollen definieren: Listen Sie die wichtigsten Rollen im Unternehmen auf.

Beispiele:

• • HR
  • Vertrieb
  • Finanzen
  • IT

2. Rollen den SaaS-Anwendungen zuordnen: Legen Sie fest, welche Anwendungen und Berechtigungen pro Rolle nötig sind.

Beispiele:

• • Vertrieb → Salesforce + Teams
  • HR → BambooHR + Outlook

3. Zugriffsstruktur dokumentieren:

• • Namenskonventionen definieren.
  • Gruppenmitgliedschaften zuweisen.
  • Regeln für die Lizenzzuweisung festlegen.

Nutzen Sie diese Struktur als Grundlage für die automatisierte Provisioning-Logik in Entra ID oder Okta.

Phase 2: Provisioning automatisieren

In dieser Phase richten Sie automatisierte Provisioning-Workflows ein, die Benutzer:innen anlegen, Lizenzen zuweisen und rollenbasierte Zugriffe auf Anwendungen vergeben.

📌 Anwendungsfall: Neue Mitarbeiter:innen automatisiert einarbeiten und ihnen Zugriff auf SaaS-Anwendungen bereitstellen.

Methode A: Provisioning von Benutzer:innen und Gruppen in Entra ID automatisieren

Diese Methode nutzt Entra ID und PowerShell, um das Anlegen von Benutzer:innen, die Lizenzzuweisung und Gruppenmitgliedschaften zu automatisieren, die den Anwendungszugriff steuern.

📌 Voraussetzungen:

• Entra ID Premium P1 oder P2
• Admin-Zugriff auf Entra ID und die SaaS-Anwendungen
• PowerShell 7+ (empfohlen)
• Microsoft Graph PowerShell SDK

Schritt für Schritt:

1. Drücken Sie Win + S, suchen Sie nach PowerShell, klicken Sie mit der rechten Maustaste darauf und wählen Sie Als Administrator ausführen. (Lesen Sie Punkt 1 unter ⚠️ Worauf Sie achten sollten.)
2. Verbindung zu Entra ID herstellen:

Connect-AzAccount

Dieser Befehl authentifiziert Ihre Sitzung gegenüber der Entra-ID-Umgebung.

3. Verbindung zu Microsoft Graph herstellen:

Connect-MgGraph -Scopes "User.ReadWrite.All","Organization.Read.All","Group.ReadWrite.All"

💡 Geben Sie beim Verbinden mit Microsoft Graph die erforderlichen Scopes an, damit die späteren Schritte reibungslos laufen. Ohne diese Scopes können Aufgaben wie das Zuweisen von Lizenzen oder das Hinzufügen von Benutzer:innen zu Gruppen mit Autorisierungsfehlern fehlschlagen.

4. Benutzer:in in Entra ID anlegen:

Stellen Sie vor dem Ausführen des Befehls sicher, dass das Modul Az.Resources installiert und importiert ist.

💡 Das Cmdlet New-AzADUser gehört zum Modul Az.Resources. Ist es nicht importiert, schlägt der Schritt mit dem Fehler CommandNotFoundException fehl.

Install-Module Az.Resources -Scope CurrentUser -Force
Import-Module Az.Resources

Legen Sie dann eine neue Benutzer:in an:

New-AzADUser -DisplayName "Jane Smith" -UserPrincipalName "[email protected]" -Password "P@ssw0rd123" -MailNickname "janesmith" -AccountEnabled $true

Dieser Befehl erstellt ein neues Benutzerobjekt mit Anmeldeinformationen in Entra ID.

💡 Hinweis: Das ist die Grundlage des Provisionings.

5. Microsoft-365-Lizenz zuweisen: (Lesen Sie Punkt 3 unter ⚠️ Worauf Sie achten sollten.)

Stellen Sie nach dem Anlegen der neuen Benutzer:in und vor der Lizenzzuweisung sicher, dass die Eigenschaft UsageLocation gesetzt ist. Zum Beispiel:

Set-MgUser -UserId "[email protected]" -UsageLocation "US"

Weisen Sie anschließend die Lizenz zu:

$SkuId = (Get-MgSubscribedSku -All | Where-Object SkuPartNumber -eq 'ENTERPRISEPACK').SkuId

Set-MgUserLicense -UserId "[email protected]" -AddLicenses @{SkuId = $SkuId} -RemoveLicenses @()/code>

⚠️ Wichtig: Ersetzen Sie die Beispielwerte (z. B. „US“, [email protected]) durch die tatsächlichen Werte Ihres Mandanten.

6. Benutzer:in zu einer Sicherheitsgruppe hinzufügen (für die dynamische Anwendungszuweisung): (Lesen Sie Punkt 2 unter ⚠️ Worauf Sie achten sollten.)

Add-AzADGroupMember -GroupObjectId $groupId -MemberObjectId $userId

Dieser Befehl fügt Benutzer:innen einer Gruppe hinzu, die mit Provisioning-Regeln oder Anwendungszuweisungen verknüpft ist.

Planen Sie das Provisioning über PowerShell-Skripte und Webhook-Trigger aus den HR-Systemen oder PSA-Plattformen Ihrer Kunden.

Methode B: Okta-Provisioning mit Workflows und SCIM automatisieren

Diese Methode automatisiert das Provisioning über SaaS-Anwendungen hinweg mit Okta Lifecycle Management, SCIM-Integrationen und der Okta-Workflows-Engine.

📌 Voraussetzungen:

• Okta Universal Directory
• Admin-Zugriff auf die Okta Admin Console
• Unterstützte SaaS-Anwendungen mit SCIM- oder API-Konnektoren

Option 1: GUI-basierte Automatisierung mit Okta Workflows

Wählen Sie diese Option, wenn Sie ein logikbasiertes Provisioning ohne Code bevorzugen.

1. Trigger: Neue Benutzer:in in Okta angelegt
2. Aktionen:
   • Benutzer:in Gruppen zuweisen (Lesen Sie Punkt 2 unter ⚠️ Worauf Sie achten sollten.)
   • Profilattribute setzen (Lesen Sie Punkt 3 unter ⚠️ Worauf Sie achten sollten.)
   • Benutzer:in an SCIM-fähige Anwendungen übertragen (z. B. Zoom, Slack, Box)

Option 2: Programmatisches Provisioning über Okta-API und Befehlszeilenschnittstelle

Wählen Sie diese Option für DevOps-artige oder skriptgesteuerte Provisioning-Abläufe.

1. Benutzer:in per API anlegen:

curl -X POST "https://client.okta.com/api/v1/users?activate=true" \
-H "Authorization: SSWS yourApiToken" \
-H "Content-Type: application/json" \
-d '{
"profile": {
"firstName": "Jane",
"lastName": "Smith",
"email": "[email protected]",
 "login": "[email protected]"
},
"credentials": {
"password" : { "value": "P@ssword123" }
}
}'

⚠️ Wichtig: Ersetzen Sie die Platzhalterwerte (client.okta.com, yourApiToken, Jane Smith, [email protected], P@ssword123) durch die tatsächliche Okta-Domain, das API-Token, die Benutzerdaten und ein sicheres Passwort Ihres Unternehmens.

Nutzen Sie anschließend das SCIM-Provisioning von Okta, um die Benutzer:in automatisiert in die zugewiesenen Anwendungen und Rollen zu übertragen.

Phase 3: Überwachung und Validierung

Prüfen Sie nach der Provisioning-Phase, ob die Provisioning-Skripte oder Agents korrekt und fehlerfrei durchgelaufen sind.

Option A: Provisioning-Status über Registry und lokale Protokolle nachverfolgen

Diese Option nutzt die lokale Registry und .log-Dateien, um zu prüfen, ob Skripte erfolgreich abgeschlossen wurden.

📌 Voraussetzungen:

• Lokale Administratorrechte
• Optional: RMM-Tool (z. B. NinjaOne) für Prüfungen aus der Ferne

Schritt für Schritt:

1. Drücken Sie Win + R, geben Sie regedit ein und drücken Sie die Eingabetaste, um den Registrierungs-Editor zu öffnen.
2. Navigieren Sie zu:

HKEY_LOCAL_MACHINE\SOFTWARE\Org\Provisioning

3. Prüfen Sie die von Ihrem Skript geschriebenen benutzerdefinierten Schlüssel:
   • LastUserProvisioned (String) = „[email protected]„
   • LastProvisioningRun (String) = „2025-07-01T12:00Z“
   • AzureStatus (String) = „Success“
   • OktaStatus (String) = „Pending“

⚠️ Wichtig: Diese Werte sind nur Beispiele. Ersetzen Sie sie durch die tatsächliche Benutzer:in, den Zeitstempel und den Provisioning-Status aus Ihrer Umgebung.

4. Fragen Sie die Werte aus der Ferne über RMM oder NinjaOne ab, um den Abschluss der Aufgabe zu bestätigen und Fehler zu beheben.

Option B: Lokale Agent-Aktivität mit Eingabeaufforderung und Ereignisprotokollen prüfen

Diese Option nutzt Befehlszeilen-Tools und die Ereignisanzeige, um lokale Provisioning-Aktivitäten zu überprüfen.

📌 Voraussetzungen:

• Administratorzugriff auf die Eingabeaufforderung und die Ereignisanzeige
• Protokolldateien oder Audit-Logs aus den Skripten

Schritt für Schritt:

1. Drücken Sie Win + S, geben Sie cmd ein, klicken Sie mit der rechten Maustaste auf Eingabeaufforderung und wählen Sie Als Administrator ausführen.
2. Aktive Sitzungen auflisten:

query user

3. Erfolg des Provisioning-Skripts anhand der Protokolle prüfen:

type C:\Logs\Provisioning\janesmith.log

⚠️ Wichtig: Pfad und Dateiname hier sind Beispiele. Ersetzen Sie sie durch den tatsächlichen Pfad zur Protokolldatei und den Benutzernamen aus Ihrer Umgebung.

Dieser Befehl gibt den Inhalt der lokalen Protokolldatei in der Konsole aus, sodass Sie prüfen können, ob jeder Provisioning-Schritt erfolgreich abgeschlossen wurde.

4. Prüfen Sie das Windows-Ereignisprotokoll auf kürzliche Kontoänderungen:

wevtutil qe Security "/q:*[System[(EventID=4720)]]" /f:text /c:5

Damit werden die fünf jüngsten Ereignisse zur Erstellung von Benutzerkonten angezeigt.

Diese Schritte helfen Ihnen zu bestätigen, dass lokale Provisioning-Aktionen (z. B. Profilvorbereitung, Desktop-Konfiguration) tatsächlich ausgeführt wurden.

Phase 4: Provisioning über Gruppenrichtlinien oder Intune durchsetzen

Diese Phase stellt sicher, dass neue Benutzer:innen eine einheitliche und sichere Desktop-Umgebung erhalten.

📌 Anwendungsfälle:

• MFA– und Passwortrichtlinien auf alle neuen Benutzer:innen anwenden
• Lokale Administratorrechte einschränken
• Laufwerke und Drucker automatisiert verbinden und die Teams-Anmeldung konfigurieren
• Single-Sign-On-Konfigurationen (SSO) und Listen vertrauenswürdiger Anwendungen durchsetzen

📌 Voraussetzungen:

• In AD oder Entra ID eingebundene Geräte
• Admin-Zugriff auf die Gruppenrichtlinien-Verwaltungskonsole (GPMC) oder Microsoft Intune

Schritt für Schritt:

Option A: Gruppenrichtlinie (GPO)

1. Drücken Sie Win + R, geben Sie gpmc.msc ein und drücken Sie die Eingabetaste, um die GPMC zu öffnen.
2. Erstellen Sie ein neues GPO und verknüpfen Sie es mit der passenden Organisationseinheit (OU). (Lesen Sie Punkt 4 unter ⚠️ Worauf Sie achten sollten.)
3. Konfigurieren Sie:
   • Passwort- und Kontosperrungsrichtlinien
     • Navigieren Sie zu: Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Kontorichtlinien
     • Legen Sie Passwortkomplexität, Mindestlänge und Sperrschwellen fest.
   • Lokale Administratorrechte verweigern
     • Navigieren Sie zu: Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Eingeschränkte Gruppen
     • Fügen Sie die Gruppe Administratoren hinzu und entfernen Sie nicht autorisierte Benutzer:innen explizit.
   • Startskripte und Laufwerkszuordnungen
     • Navigieren Sie zu: Computerkonfiguration > Richtlinien > Windows-Einstellungen > Skripts (Anmelden/Abmelden), um Anmeldeskripte hinzuzufügen.
     • Alternativ navigieren Sie zu: Benutzerkonfiguration > Einstellungen > Windows-Einstellungen > Laufwerkzuordnungen, um Zuordnungen für freigegebene Laufwerke zu konfigurieren.
4. Aktualisierung erzwingen: gpupdate /force

Option B: Microsoft Intune

1. Rufen Sie endpoint.microsoft.com auf.
2. Melden Sie sich mit einem Administratorkonto an.
3. Navigieren Sie zu Geräte > Konfiguration > Erstellen > Neue Richtlinie.
   • Plattform: Windows 10/11
   • Profiltyp: Einstellungskatalog
4. Konfigurieren Sie:
   • Authentifizierung, Passwörter
   • Teams, Outlook, SSO, Geräteeinschränkungen
5. Weisen Sie die Entra-ID-Gruppe zu und stellen Sie die Richtlinie bereit. (Lesen Sie Punkt 4 unter ⚠️ Worauf Sie achten sollten.)

So erhalten neu bereitgestellte Benutzer:innen automatisiert die für sie vorgesehene Desktop-Umgebung.

⚠️ Worauf Sie achten sollten

Risiken	Mögliche Folgen	Gegenmaßnahmen
1. PowerShell-Skripte ohne Administratorrechte ausführen.	Skripte können unbemerkt fehlschlagen und Registry-Schlüssel werden womöglich nicht geschrieben.	Führen Sie das Skript erneut als Administrator aus. Entfernen Sie teilweise angelegte Benutzer:innen manuell.
2. Benutzer:innen der falschen Gruppe zuweisen.	Benutzer:innen erhalten womöglich falsche Anwendungen oder Berechtigungen.	Entfernen Sie die Benutzer:innen aus den falschen Gruppen. Weisen Sie sie der richtigen Gruppe zu und prüfen Sie den Zugriff.
3. Unvollständige Benutzerattribute übertragen.	SaaS-Anwendungen erhalten möglicherweise ungültige oder unvollständige Benutzerdatensätze.	Korrigieren Sie die Attribute in Azure/Okta. Lösen Sie das Provisioning erneut aus oder synchronisieren Sie das Benutzerprofil neu.
4. Falscher Geltungsbereich für GPO- oder Intune-Richtlinien.	Richtlinien greifen für die falschen Geräte oder Benutzer:innen.	Prüfen Sie die Zuweisungen und weisen Sie die Richtlinien den richtigen Entra-ID-Gruppen oder Organisationseinheiten zu.

Weitere Überlegungen

Berücksichtigen Sie Folgendes, wenn Sie das Provisioning in Okta/Entra für Multi-SaaS-Kunden automatisieren:

Lizenzbestand prüfen

Prüfen Sie per Skript vor dem Provisioning, ob Lizenzen verfügbar sind. Das verhindert Fehler bei der Einarbeitung und hilft Ihnen, innerhalb Ihrer Lizenzgrenzen zu bleiben. Nutzen Sie dafür PowerShell mit Microsoft Graph für Entra oder Okta Workflows für Okta-Umgebungen.

Deprovisioning

Automatisieren Sie das Offboarding. Entziehen Sie Zugriffe, deaktivieren Sie Konten und entfernen Sie Lizenzen auf allen verbundenen Plattformen. Nutzen Sie dafür Okta Lifecycle Hooks oder Workflows. Für Entra ID eignen sich PowerShell-Skripte oder die Graph-API.

Audit-Protokollierung

Protokollieren Sie jede Provisioning-Aktion (Anlegen, Aktualisieren, Löschen). Erfassen Sie Zeitstempel, Aktionstyp, Admin-Identität und betroffene Benutzer:in. Bewahren Sie die Protokolle sicher und zugänglich auf. Das unterstützt die Compliance und hilft bei Audits und der Fehlersuche.

Segmentierung über Mandanten hinweg

Verwenden Sie einheitliche Namens- und Tagging-Konventionen. Das vereinfacht die Verwaltung im großen Maßstab und verbessert Automatisierung und Berichterstattung.

Häufige Probleme beim automatisierten User Provisioning beheben

Hier sind typische Provisioning-Probleme und wie Sie sie lösen:

Verzögertes Provisioning

Wenn Benutzerkonten nach dem Anlegen nicht erscheinen, prüfen Sie Ihre SCIM-Konfiguration und die Anwendungszuweisungen. Das können Sie tun:

• SCIM-Konfiguration prüfen:
  1. Navigieren Sie zu Okta Admin Console > Applications > [App-Name] > Provisioning.
  2. Bestätigen Sie, dass das SCIM-Provisioning aktiviert ist.
  3. Prüfen Sie, ob Push New Users und Push Profile Updates aktiviert sind.
• Anwendungszuweisungen bestätigen:
  1. Navigieren Sie zu Applications > [App-Name] > Assignments.
  2. Prüfen Sie, ob die Benutzer:in direkt oder über eine Gruppe zugewiesen ist.
  3. Navigieren Sie zu Directory > Group Rules und stellen Sie sicher, dass die Benutzer:in die Regelbedingungen erfüllt.

PowerShell-Fehler

Ein Skript kann wegen eines falschen Moduls oder eines abgelaufenen Tokens fehlschlagen. Das sollten Sie tun:

• Modulversion bestätigen mit:

Get-InstalledModule

• Erneut authentifizieren mit:

Connect-MgGraph -Scopes "User.ReadWrite.All", "Group.ReadWrite.All"

• Ablauf des Tokens prüfen:

(Get-MgContext).ExpirationTime

Fehlende Registry-Werte

Fehlen die erwarteten Registry-Schlüssel, prüfen Sie, ob das Skript mit Administratorrechten ausgeführt wurde. Vergewissern Sie sich außerdem, dass der Registry-Pfad korrekt ist:

HKEY_LOCAL_MACHINE\SOFTWARE\Org\Provisioning

Gruppe wird nicht angewendet

Ist die Benutzer:in nicht der richtigen Gruppe zugewiesen, prüfen Sie Ihre Mitgliedschaftsregeln und die Zuweisungslogik. So gehen Sie vor:

• In Entra ID:
  1. Navigieren Sie im Entra ID Admin Center zu > Groups > [Gruppenname] > Dynamic Membership Rules.
  2. Klicken Sie auf Validate Rules.
  3. Testen Sie die Benutzer:in und bestätigen Sie, dass ihre Attribute die Regel erfüllen.
• In Okta:
  1. Navigieren Sie zu Directory > Group Rules.
  2. Prüfen Sie, ob die Regelbedingungen zum Profil der Benutzer:in passen.
  3. Sehen Sie sich die Protokolle auf fehlgeschlagene Gruppenzuweisungen an.

NinjaOne-Services für das Provisioning

NinjaOne verbessert Workflows für das Identity Provisioning durch:

Funktion	Was NinjaOne ermöglicht
Bereitstellung von Provisioning-Skripten	Provisioning-Skripte in Kundenumgebungen bereitstellen
Überwachung von Registry und Protokollen	Registry und Provisioning-Protokolle auf den Abschlussstatus überwachen
Automatisierungs-Trigger bei der Einarbeitung	Automatisierung auslösen, wenn Geräte zu Onboarding-Tags oder -Gruppen hinzugefügt werden
Alarmierungen bei Fehlern und Ausnahmen	Alarmierung bei Skriptfehlern oder fehlenden Benutzer- bzw. Gruppenzuweisungen
Provisioning-Berichte über Mandanten hinweg	Berichte zu aktuellen Provisioning-Ereignissen über Mandanten hinweg erstellen

Mit NinjaOne können MSPs einheitliche Provisioning-Workflows durchsetzen und deren Erfolg über alle Umgebungen hinweg mit konsistenter, skriptfähiger Logik überprüfen.

Provisioning in Okta und Entra ID für skalierbare Benutzerverwaltung automatisieren

Wer das User Provisioning in Okta und Entra ID automatisiert, verkürzt als MSP die Einarbeitung, setzt die Zugriffssteuerung durch und senkt den Betriebsaufwand bei der Betreuung von Multi-SaaS-Kunden.

Dieser Leitfaden hat einen vollständigen Automatisierungs-Workflow beschrieben. Er umfasste die Einrichtung rollenbasierter Zugriffe, das Ausführen von Provisioning-Skripten, die Erfolgskontrolle über Registry-Protokolle und das Anwenden von Richtlinien per Gruppenrichtlinie und Intune. Zum Schluss hat er gezeigt, wie NinjaOne Bereitstellung, Nachverfolgung und Berichterstattung über alle Umgebungen hinweg unterstützt, damit das Provisioning einheitlich und zentral verwaltet wird.

Verwandte Themen:

• Geräte-Provisioning
• SSO- und SCIM-Integration
• Was ist Zero Touch Provisioning (ZTP)?