Wie ein Administrator die EntraId-Anmeldung konfiguriert

Zusammenfassung

Die Verwendung von EntraId für den Login ermöglicht es Nutzern, sich automatisch mit ihrem EntraId (M365) in der STP Cloud anzumelden.
Dieses Dokument beschreibt, wie das EntraId des Kunden als externer Identitätsanbieter für den Mandanten in der STP Cloud konfiguriert wird.

Voraussetzungen

• Der Kunde verfügt über ein Azure Active Directory-Konto
• Zugriffsrechte in AAD, um eine App-Registrierung zu erstellen
• Ein Mandant in der STP Cloud ist vorhanden
• Admin-Zugriff auf diesen Mandanten

1) Lizenzierung für EntraId als eIDP

Folgende Lizenz muss dem Mandanten hinzugefügt werden.

Benötigte Lizenz für die Nutzung von EntraId

Info: Diese Lizenzen können über den STP Support angefordert werden.

2) In Azure Active Directory

2.1) App-Registrierung hinzufügen

Fügen Sie eine App-Registrierung für den STP-Cloud-Login hinzu. Dabei muss auch ein Client-Secret angegeben werden.

Info: Eine App-Registrierung kann hier vorgenommen werden: App-Registrierung in M365

App-Registrierung in M365 hinzufügen

2.2) Redirect-URL angeben

Für die STP-Login-App muss eine Redirect-URL mit der mandantenspezifischen Subdomain angegeben werden, z. B. https://meinedomain.stp-cloud.de/identity/signin-microsoft .

Redirect-URL zur App-Registrierung hinzufügen

2.3) Client-Secret für die App hinzufügen

Es muss ein Secret zur App hinzugefügt werden, um die Identität bei Token-Anfragen zu bestätigen.

Client-Secret zur App-Registrierung hinzufügen

Wichtig: Speichern Sie diese Client-ID und das Secret an einem sicheren Ort, da sie später nicht mehr angezeigt werden und noch benötigt werden!

2.4) API-Berechtigungen für die STP-Login-App konfigurieren

Die Standardberechtigungen und -bereiche sind ausreichend.

Berechtigungen für die App

2.5) Die Endpunkte

Sehen Sie sich die Endpunkte der App an. Der „OAuth 2.0-Autorisierungsendpunkt (v2)“ und der „OAuth 2.0-Token-Endpunkt (v2)“ werden für die weitere Konfiguration benötigt.

Die Endpunkte der App

3) Identity Admin in der STP Cloud

Der Identity Admin

3.1) Externen Identitätsanbieter hinzufügen

Fügen Sie Azure Active Directory als Identitätsanbieter mit den oben genannten Werten hinzu.

Identitätsanbieter konfigurieren

Wichtig: Es kann bis zu einer Stunde dauern, bis die Änderungen wirksam werden. Danach sollte der Login-Bildschirm wie folgt aussehen:

STP Cloud Login-Bildschirm mit „Microsoft 365“-Login-Button

3.2) Individuelle Kontoverknüpfung

Beim Klick auf „Login mit Microsoft 365“ erscheint zunächst eine Fehlermeldung:

Externer Login-Fehler „Unbekannter Benutzer“

Das STP Cloud-Konto muss zuerst mit dem M365-Konto verbunden werden:

3.3) Benutzerkonto verbinden

Um Ihr STP-Benutzerkonto mit dem Azure Active Directory-Konto zu verbinden, melden Sie sich zunächst mit dem lokalen Login in der STP Cloud an.
Nach dem Login gehen Sie zu https://<tenantname>.stp-cloud.de/identity/ (z. B. https://meinedomain.stp-cloud.de/identity/)

Identität verbinden-Seite

Während Sie angemeldet sind, klicken Sie unter „Weitere Identitäten verbinden“ auf „Microsoft 365“. Der Browser leitet Sie zu Azure Active Directory weiter, wo Sie sich mit M365 anmelden können. Danach muss der STP-Cloud Zugriff auf das Microsoft 365-Benutzerprofil gewährt werden.

Zugriff für STP-Cloud gewähren

Nach der Rückleitung ist das Microsoft 365-Konto nun mit dem STP-Cloud-Konto verbunden.

Info: Alternativ kann ein Administrator im Bereich API-Berechtigungen der App-Registrierung in Azure Active Directory die Zustimmung für alle Nutzer erteilen.

3.4) Verbundenes Konto testen

Um das verbundene Konto zu testen, melden Sie sich von der STP-Cloud ab und klicken Sie auf „Microsoft 365“, während Sie nicht angemeldet sind. Sie werden dann automatisch als derselbe Nutzer des verbundenen Microsoft 365-Kontos angemeldet.

3.5) Automatische Verknüpfung per E-Mail-Claim

Statt dass Nutzer ihr M365-Konto einzeln mit ihrem STP-Cloud-Konto verbinden, kann der Admin die automatische Verknüpfung per E-Mail-Claim aktivieren.
Ist diese Option aktiviert, wird das M365-Konto automatisch mit dem STP-Cloud-Konto verbunden, das dieselbe E-Mail-Adresse verwendet.

Automatische Benutzerverknüpfung konfigurieren

3.6) Lokalen Login verhindern

In manchen Fällen soll der Login ausschließlich über einen externen IDP wie AAD erfolgen. Der „Lokale Login“ per E-Mail und Passwort soll dann nicht mehr möglich sein.
In diesem Fall kann der IDP so eingerichtet werden, dass der lokale Login verhindert wird.

Lokalen Login verhindern

Wichtig:

• Wenn dieser IDP der einzige aktive IDP ist, wird der externe Login automatisch versucht.
• Wenn die externe Identität noch nicht verbunden ist und „Automatische Verknüpfung per E-Mail-Claim“ deaktiviert ist, können sich neue Nutzer nicht anmelden.
• Wenn die Konfiguration beim externen IDP widerrufen, abgelaufen oder anderweitig gestört ist, ist ein Login in die STP Cloud nicht mehr möglich.
• In diesem Fall muss ein STP Support-Mitarbeiter die Einstellung „Lokalen Login verhindern“ manuell zurücksetzen.
• Resource Owner Password Grant-Logins sind davon ausgenommen. Sie funktionieren weiterhin mit Benutzername und Passwort, um die Agenten-Konnektivität zu erhalten (z. B. DMS Mobile DESK, Mobile Time).

4) Bekannte Einschränkung

Wenn der externe IDP in IdentityAdmin geändert wird, um gegen einen anderen IDP zu authentifizieren, werden alle externen Identitäten dieses Mandanten ungültig, da sie im anderen IDP eine andere externe ID haben.
Da jeder Nutzer nur eine externe ID pro externem IDP verbinden kann, müssen sie ihre externe ID manuell entfernen und die neue verbinden.

Wichtig: Ist „Lokalen Login verhindern“ aktiviert, können Nutzer ihre alte externe ID nicht entfernen und sich nicht mehr anmelden.

Lösung

Statt den externen IDP zu ändern, entfernen Sie ihn und legen Sie einen neuen an.

Dadurch werden alle verbundenen externen IDs automatisch entfernt.
Die Nutzer können dann ihre externe ID manuell verbinden oder sie wird automatisch verbunden, wenn „Automatische Verknüpfung“ aktiviert ist.

Info: Der Login unter common.stp-cloud.de funktioniert nicht mit Single-Sign-On. Die gemeinsame Subdomain wird z. B. für den STP.Marketplace oder die neuen Office Addins (STP.Documents.Outlook) verwendet. Wird ein Login auf der gemeinsamen Subdomain für einen Mandanten versucht, bei dem lokale Logins verhindert werden, wird der Browser auf die spezifische Mandanten-Subdomain umgeleitet, wo der Login mit dem externen IDP abgeschlossen werden kann. Anschließend wird der Browser zurück zum authentifizierenden Dienst geleitet (aber nur, wenn diese Redirect-URI in Identity Admin auf der Allowlist steht). Dieser Dienst erhält einen Auth-Code, um ihn gegen ein Access-Token einzutauschen. Allerdings wurde das Session-Cookie des Nutzers auf die spezifische Mandanten-Subdomain gesetzt, nicht auf die gemeinsame Subdomain. Der Nutzer gilt daher auf der gemeinsamen Subdomain nicht als angemeldet.