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 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 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 Azure AD 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 kein Datensatz für die Zustimmung des Benutzers oder Administrators vorhanden ist, sendet Azure AD 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 Azure AD nicht hinzugefügt. Führen Sie die Schritte zum Hinzufügen eines benutzerdefinierten Domänennamens zu Azure AD aus, um azure AD eine benutzerdefinierte Domäne hinzuzufügen und sie zu registrieren. 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 Azure AD 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 die Anwendungs-ID des URI in Azure AD 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 der in Azure AD vorgenommenen App-Konfigurationen falsch sind. Um diesen Fehler zu beheben, überprüfen Sie, ob die in Ihrem Code konfigurierten App-Details und das App-Manifest (zuvor als Teams-App-Manifest bezeichnet) mit den Werten in Azure AD übereinstimmen.

Die folgende Abbildung zeigt ein Beispiel für die in Azure AD konfigurierten App-Details.

App-Konfigurationswerte in Azure AD

Überprüfen Sie, ob die folgenden Werte zwischen Azure AD, clientseitigem Code und App-Manifest übereinstimmen:

  • App-ID: Die App-ID, die Sie in Azure AD 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 Azure AD übereinstimmt.

  • Geheimer App-Schlüssel: Der im Back-End Ihrer App konfigurierte App-Schlüssel sollte mit den Clientanmeldeinformationen in Azure AD identisch sein. 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 Azure AD ü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 korrekt ist, wie in Azure AD 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, korrekt und wie in Azure AD definiert ist.
  • Azure AD Version 1.0 oder 2.0 (ver): Überprüfen Sie, ob die Azure AD-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 es 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 Kennworteingabeaufforderung nicht angezeigt, da im Browser eine aktive Azure AD-Sitzung vorhanden ist, die für die Authentifizierung und zum Abrufen eines Tokens verwendet wird. Im Teams-Desktopclient wird die Kennwortaufforderung angezeigt, da der Desktopclient über keine Azure AD-Sitzung verfügt, die freigegeben werden muss und zur Anmeldung aufgefordert wird.

Siehe auch

Bewährte Sicherheitsmethoden für Anwendungseigenschaften in Azure Active Directory