Erstellen einer Outlook-Integration in Microsoft Entra ID

Bitte melden Sie sich zunächst in Ihrem Microsoft Azure Portal https://azure.microsoft.com an. Anschlißend legen Sie einen Evalea-Dienstbenutzer in Microsoft Entra ID an (dieser Benutzer muss Zugriff auf einen eigenen Kalender haben und in der Lage sein, Termine zu erstellen und Personen einzuladen).
Als nächstes gehen Sie zur Microsoft Entra ID und wählen dort “App-registrations”. Auf der nächsten Seite wählen Sie dann “New registrations”.

Dies führt Sie zur Ansicht “Register an application”.

Tragen Sie an dieser Stelle den Namen der App ein, wählen Sie die Option “Single tenant” und führen Sie die Registrierung durch. Die Namensgebung steht Ihnen frei.

Anschließend werden Sie zur Übersichtsseite der Anwendung weitergeleitet.

In der Anwendungsübersicht sind bereits die Client-ID sowie die Mandanten-ID (Tenant-ID) eingetragen. Bitte übernehmen Sie beide Angaben in das Microsoft SSO-Add-On innerhalb von Evalea. 

Ein Client Secret können Sie durch Auswahl der Option “Add a certificate or secret” erstellen.

Auf dieser Seite ist die Option “New client secret” zu wählen. Vergeben Sie eine aussagekräftige Beschreibung und legen Sie eine Gültigkeitsdauer von 24 Monaten fest.

Der daraufhin generierte Wert stellt das Client Secret dar. Dieser ist unverzüglich zu sichern, da er nach Verlassen der Seite nicht mehr eingesehen werden kann.

Das Client Secret muss in das Microsoft Outlook Add-On in Evalea kopiert werden.

Anschließend kehren Sie zurück zur Anwendungsübersicht.

Hier fügen Sie die Option “Delegated permissions” zum Lesen und Schreiben des Kalenders des Dienstbenutzers hinzu.

Im nächsten Schritt gehen sie zurück zu “Application overview"  und dann ”Authentication".

An dieser Stelle ist eine Redirect-URI hinzuzufügen. Hier fügen sie die Option “Add a plattform” → “Web” hinzu. 

Dann geben Sie die Redirect URI ein, die Sie im Microsoft Outlook Add-On in Evalea sehen können. Die Redirect URI sieht wie folgt aus: https://evalea.de/tool/settings/outlook

Einrichtung im Add-On

Fügen Sie nun im Add-On selbst die (1) Client ID, das (2) Client Secret und die (3) Tenant ID hinzu. Anschließend speichern Sie ihre Eintragungen und melden sich mit dem Dienstkonto (Dienstbenutzer) an. Somit ist ihr Zugang eingerichtet.

FAQs

• Was sind “Scopes” und warum brauchen wir sie? 
  • "Delegated permissions", auch "Scopes" genannt, sind Berechtigungen, die es der Anwendung erlauben, im Namen eines angemeldeten Benutzers zu handeln.  Die Anwendung kann jedoch niemals auf etwas zugreifen, auf das der angemeldete Benutzer nicht zugreifen könnte. In einem delegierten Szenario kann eine Applikation nur im Namen eines Benutzers handeln, wenn sie die entsprechenden Microsoft Graph-Berechtigungen besitzt. Zusätzlich hängt die tatsächliche Zugriffsebene der Applikation auch von den Berechtigungen des Benutzers selbst ab.

• Warum muss eine Azure-App registriert werden? 
  • Microsoft Graph ist eine RESTful-Web-API, über die Sie auf Microsoft Cloud-Dienste zugreifen können. Nach der Registrierung Ihrer App können Sie Authentifizierungstoken für einen Benutzer oder Dienst abrufen und Anfragen an die Microsoft Graph API senden.Die App ermöglicht es Nutzern, sich mit persönlichen Microsoft-Konten (wie Outlook.com), Geschäfts-, Schul- oder Unikonten anzumelden – oder sogar beiden Kontotypen, sofern zugelassen. Dabei kann die App nur auf Ressourcen und APIs zugreifen, für die der jeweilige Benutzer auch Berechtigungen besitzt.

Häufige Fehler

Auf der Add-On-Seite können folgende Fehler auftreten, wenn die Einstellungen nicht korrekt sind oder Sie das Add-On mit einem Dienstkonto aktivieren und anmelden.

1. AADSTS900971: Keine Antwort-URL angegeben
Dieser Fehler tritt normalerweise auf, wenn die in der Authentifizierung verwendete Redirect-URL ungültig ist oder nicht in Microsoft Entra ID registriert wurde.

Lösung:
Registrieren Sie eine gültige Redirect-URL in Ihrer Entra ID-Anwendung. Die Redirect-URL finden Sie im Microsoft Outlook Add-On in Evalea.

2. AADSTS700016: UnauthorizedClient_DoesNotMatchRequest – Die Anwendung wurde im Verzeichnis/Mandanten nicht gefunden
Dies kann passieren, wenn

• Die Anwendung nicht vom Administrator des Mandanten installiert wurde.
• Oder kein Benutzer im Mandanten die Zustimmung erteilt hat.
  Mögliche Ursachen sind auch eine falsch konfigurierte Anwendungs-ID oder eine Authentifizierungsanfrage, die an den falschen Mandanten gesendet wurde.

Lösung:
Überprüfen Sie die App-Konfiguration. Häufig liegt der Fehler vor, wenn die Secret-ID statt des eigentlichen Secret-Werts kopiert wurde.

3. AADSTS7000222: InvalidClientSecretExpiredKeysProvided – Der angegebene Client Secret-Schlüssel ist abgelaufen
Der verwendete Client Secret ist nicht mehr gültig.

Lösung:

Erstellen Sie einen neuen Client Secret.

Alternativ können Sie sicherere Zertifikatsanmeldeinformationen verwenden: https://aka.ms/certCreds