Freigeben über

Fehlerbehebung bei der SSO-Authentifizierung in Teams

  • Artikel

Hier ist eine Liste von Problemen und Fragen zu SSO und wie Sie diese beheben können.

Unterstützung für Microsoft Graph


1. Funktioniert die Graph-API in Postman?
Sie können die Microsoft Graph Postman-Sammlung für den Einstieg in Microsoft Graph-APIs verwenden.

Weitere Informationen finden Sie unter Verwenden von Postman mit einer Microsoft Graph-API.


2. Funktioniert die Graph-API im Microsoft Graph-Explorer?
Ja, die Graph-API funktioniert im Microsoft Graph-Explorer.

Weitere Informationen finden Sie unter Graph-API.


Fehlermeldungen und deren Behandlung


1. Fehler: Zustimmung fehlt.
Wenn Microsoft Entra ID eine Anforderung für den Zugriff auf eine Microsoft Graph-Ressource empfängt, wird überprüft, ob der App-Benutzer oder Mandantenadministrator seine Zustimmung für diese Ressource erteilt hat. Wenn keine Aufzeichnung der Zustimmung des Benutzers oder Administrators vorhanden ist, sendet Microsoft Entra ID eine Fehlermeldung an Ihren Webdienst.

Ihr Code muss dem Client (z. B. im Textkörper einer 403 Forbidden-Antwort) mitteilen, wie der Fehler behandelt werden soll:

  • Wenn die Registerkarten-App Microsoft Graph-Bereiche benötigt, für die nur ein Administrator seine Zustimmung geben kann, sollte ihr Code einen Fehler generieren.
  • Wenn die einzigen Bereiche, die benötigt werden, vom Benutzer zugewiesen werden können, sollte Ihr Code auf ein alternatives System zur Benutzerauthentifizierung zurückgreifen.

2. Fehler: Fehlender Bereich (Berechtigung).
Dieser Fehler wird nur während der Entwicklung angezeigt.

Um diesen Fehler zu behandeln, sollte Ihr serverseitiger Code die Antwort 403 Forbidden an den Client senden. Er sollte den Fehler in der Konsole protokollieren oder in einem Protokoll aufzeichnen.


3. Fehler: Ungültige Zielgruppe im Zugriffstoken für Microsoft Graph.
Der serverseitige Code sollte eine 403 Forbidden-Antwort an den Client senden, um dem Benutzer eine Nachricht anzuzeigen. Es wird empfohlen, den Fehler auch in der Konsole zu protokollieren oder in einem Protokoll aufzuzeichnen.

4. Fehler: Der Hostname darf nicht auf einer bereits im Besitz befindlichen Domäne basieren.
Sie können diesen Fehler in einem der beiden Szenarien erhalten:
  1. Die benutzerdefinierte Domäne wird der Microsoft Entra-ID nicht hinzugefügt. Um eine benutzerdefinierte Domäne zur Microsoft Entra-ID hinzuzufügen und zu registrieren, führen Sie die Schritte zum Hinzufügen eines benutzerdefinierten Domänennamens zu Microsoft Entra ID aus. Führen Sie dann erneut die Schritte unter Konfigurieren des Bereichs für Zugriffstoken aus.
  2. Sie sind nicht mit Administratoranmeldeinformationen im Microsoft 365-Mandanten angemeldet. Melden Sie sich bei Microsoft 365 als Administrator an.

5. Fehler: Der Benutzerprinzipalname (USER Principal Name, UPN) wurde im zurückgegebenen Zugriffstoken nicht empfangen.
Sie können UPN als optionalen Anspruch in Microsoft Entra ID hinzufügen.

Weitere Informationen finden Sie unter Bereitstellen optionaler Ansprüche für Ihre App und Zugriffstoken.


6. Fehler: Teams SDK-Fehler: resourceDisabled.
Um diesen Fehler zu vermeiden, stellen Sie sicher, dass der Anwendungs-ID-URI in der Microsoft Entra-App-Registrierung und in Ihrem Teams-Client ordnungsgemäß konfiguriert ist.

Weitere Informationen zur Anwendungs-ID des URI finden Sie unter So machen Sie eine API verfügbar.


7. Fehler: Generischer Fehler beim Ausführen der Registerkarten-App.
Ein allgemeiner Fehler kann angezeigt werden, wenn eine oder mehrere app-Konfigurationen, die in Microsoft Entra ID erstellt wurden, falsch sind. Um diesen Fehler zu beheben, überprüfen Sie, ob die in Ihrem Code konfigurierten App-Details und das App-Manifest (zuvor teams-App-Manifest genannt) mit den Werten in Microsoft Entra ID übereinstimmen.

Die folgende Abbildung zeigt ein Beispiel für die App-Details, die in Microsoft Entra ID konfiguriert sind.

App-Konfigurationswerte in Microsoft Entra ID

Überprüfen Sie, ob die folgenden Werte zwischen Microsoft Entra ID, clientseitigem Code und App-Manifest übereinstimmen:

  • App-ID: Die App-ID, die Sie in Microsoft Entra ID generiert haben, sollte im Code und in der App-Manifestdatei identisch sein. Überprüfen Sie, ob die App-ID im App-Manifestschema mit der Anwendungs-ID (Client-ID) in Microsoft Entra ID übereinstimmt.

  • App-Geheimnis: Das im Back-End Ihrer App konfigurierte App-Geheimnis sollte mit den Clientanmeldeinformationen in Microsoft Entra ID übereinstimmen. Sie sollten auch überprüfen, ob der geheime Clientschlüssel abgelaufen ist.

  • Anwendungs-ID-URI: Der App-ID-URI im Code und in der App-Manifestdatei sollte mit dem Anwendungs-ID-URI in Microsoft Entra ID übereinstimmen.

  • App-Berechtigungen: Überprüfen Sie, ob die Berechtigungen, die Sie im Bereich definiert haben, Ihren App-Anforderungen entsprechen. Wenn ja, überprüfen Sie, ob sie dem Benutzer im Zugriffstoken gewährt wurden.

  • Administratorzustimmung: Wenn für einen Bereich eine Administratorzustimmung erforderlich ist, überprüfen Sie, ob die Zustimmung für den betreffenden Bereich dem Benutzer erteilt wurde.

Überprüfen Sie außerdem das Zugriffstoken, das an die Registerkarten-App gesendet wurde, um zu überprüfen, ob die folgenden Werte korrekt sind:

  • Zielgruppe (aud): Überprüfen Sie, ob die App-ID im Token richtig ist, wie in Microsoft Entra ID angegeben.
  • Mandanten-ID(tid): Überprüfen Sie, ob der im Token erwähnte Mandant korrekt ist.
  • Benutzeridentität (preferred_username): Überprüfen Sie, ob die Benutzeridentität mit dem Benutzernamen in der Anforderung für das Zugriffstoken für den Bereich übereinstimmt, auf den der aktuelle Benutzer zugreifen möchte.
  • Bereiche (scp): Überprüfen Sie, ob der Bereich, für den das Zugriffstoken angefordert wird, richtig und wie in Microsoft Entra ID definiert ist.
  • Microsoft Entra Version 1.0 oder 2.0 (ver): Überprüfen Sie, ob die Microsoft Entra-Version korrekt ist.

Sie können JWT für die Überprüfung des Tokens verwenden.

Bot-SSO-Tokenfehler


Tokenaustauschfehler.
Wenn beim Token-Austausch ein Fehler auftritt, verwenden Sie den folgenden Code:
{​​ 
    "status": "<response code>", 
    "body": 
    {​​ 
        "id":"<unique Id>", 
        "connectionName": "<connection Name on the bot (from the OAuth card)>", 
        "failureDetail": "<failure reason if status code is not 200, null otherwise>" 
    }​​ 
}​​

Informationen zum Botverhalten, wenn der Tokenaustausch keine Zustimmungsaufforderung auslöst, finden Sie in den folgenden Schritten:

Hinweis

Es ist keine Benutzeraktion erforderlich, da der Bot die Aktionen ausführt, wenn der Token-Austausch fehlschlägt.

  1. Der Client beginnt eine Konversation mit dem Bot, der ein OAuth-Szenario auslöst.

  2. Der Bot sendet eine OAuth-Karte an den Client zurück.

  3. Der Client fängt die OAuth-Karte ab, bevor er sie dem App-Benutzer anzeigt. Sie überprüft, ob sie eine TokenExchangeResource -Eigenschaft enthält.

  4. Wenn die Eigenschaft vorhanden ist, sendet der Client eine TokenExchangeInvokeRequest an den Bot. Der Client muss über ein austauschbares Token für den Benutzer verfügen. Dieses Token muss ein Azure AD v2-Token sein, dessen Zielgruppe mit der -Eigenschaft identisch TokenExchangeResource.Uri sein muss.

  5. Der Client sendet eine Aufrufaktivität mit dem folgenden Code an den Bot:

    {
    "type": "Invoke",
    "name": "signin/tokenExchange",
    "value": 
    {
        "id": "<any unique Id>",
        "connectionName": "<connection Name on the skill bot (from the OAuth card)>",
        "token": "<exchangeable token>"
    }
}

  6. Der Bot verarbeitet die TokenExchangeInvokeRequest und gibt eine TokenExchangeInvokeResponse an den Client zurück. Der Client muss warten, bis er die TokenExchangeInvokeResponse erhält.

    {
    "status": "<response code>",
    "body": 
    {
        "id":"<unique Id>",
        "connectionName": "<connection Name on the skill bot (from the OAuth card)>",
        "failureDetail": "<failure reason if status code is not 200, null otherwise>"
    }
}

  7. Wenn TokenExchangeInvokeResponse eine status von 200 hat, zeigt der Client die OAuth-Karte nicht an. Sehen Sie sich das normale Flussbild an. Für alle anderen status oder wenn TokenExchangeInvokeResponse nicht empfangen wird, zeigt der Client dem Benutzer die OAuth-Karte. Sehen Sie sich das Fallback-Flow-Bild an. Wenn Fehler oder nicht erfüllte Abhängigkeiten wie die Benutzereinwilligung vorliegen, stellt diese Aktivität sicher, dass der SSO-Fluss auf den normalen OAuthCard-Fluss zurückfällt.

    Hinweis

    Im Teams-Webclient wird die Kennwortaufforderung nicht angezeigt, da im Browser eine aktive Microsoft Entra-Sitzung vorhanden ist, die für die Authentifizierung und zum Abrufen eines Tokens verwendet wird. Im Teams-Desktopclient wird die Kennworteingabeaufforderung angezeigt, da der Desktopclient keine Microsoft Entra-Sitzung hat, die freigegeben werden muss und zur Anmeldung aufgefordert wird.

Siehe auch

Bewährte Sicherheitsmethoden für Anwendungseigenschaften in Microsoft Entra ID