Microsoft-365-Integrationen (rA Meetings)
Die rA-Meetings-App läuft in SharePoint und Teams — im Browser Ihrer Beschäftigten, ohne eigenen Server. Damit sie ein beschlossenes Ergebnis nach roleALPHA übertragen oder eine Governance-Frage stellen kann, muss roleALPHA die Anmeldung akzeptieren, die dort ohnehin besteht: die Microsoft-Anmeldung des Menschen, der gerade in der Besprechung sitzt.
Für die Beschäftigten heißt das: keine zweite Anmeldung, kein Freigabedialog, keine Adresseingabe. Der Entwurf erscheint in roleALPHA unter ihrem Namen, mit genau ihren Rechten, im richtigen Mandanten.
Was Sie einrichten
Abschnitt betitelt „Was Sie einrichten“Zwei Felder, einmalig, unter KI-Einstellungen → Microsoft-365-Integrationen:
| Feld | Was hineingehört |
|---|---|
| Verzeichnis-Kennung | Die Directory-(Tenant-)ID Ihres Microsoft-365-Verzeichnisses. Sie finden sie im Entra-Portal unter Übersicht. |
| Erlaubte Adressen | Die Adressen, aus denen zugegriffen werden darf — Ihre SharePoint-Adresse, für Teams zusätzlich https://teams.microsoft.com. Eine je Zeile. |
Voraussetzung ist der Schalter Externe KI-Anwendungen darüber. Ist er aus, ist auch diese Verbindung aus.
Leeres Feld = abgeschaltet. Ohne Verzeichnis-Kennung lehnt roleALPHA jede Anfrage ab, gleichgültig wie gültig das vorgelegte Microsoft-Token ist.
Dazu gehört ein Schritt auf der Microsoft-Seite, den Ihre Microsoft-365-Administration macht: die Genehmigung der Berechtigung für roleALPHA (API access im SharePoint-Admin-Center). Die Anleitung dazu liefert rA Meetings mit.
Die Werte für rA Meetings
Abschnitt betitelt „Die Werte für rA Meetings“Sobald die Verzeichnis-Kennung im Feld steht, erscheint darunter ein Block mit vier Werten. Genau diese vier fragt der Einrichtungsassistent von rA Meetings in Schritt 4 („Verbindungen einrichten”) ab. Sie stehen nirgends sonst — vorher musste man sie erfragen.
| Feld in rA Meetings | Was es ist |
|---|---|
| MCP-Adresse von roleALPHA | Die Adresse, mit der die App spricht. |
| Ressource (Anwendungs-ID-URI des Dienstes) | Womit sich roleALPHA gegenüber Microsoft als API ausweist. Gilt für die ganze Installation und wird von der Plattform-Administration gepflegt, nicht von Ihnen. |
| Delegierte Berechtigung (Scope) | Der Bereich, den das Microsoft-Token tragen muss — üblicherweise access_as_user. |
| roleALPHA-Tenant-ID | Ihr Mandant in roleALPHA. Nicht zu verwechseln mit der Verzeichnis-Kennung oben: die gehört Microsoft, diese roleALPHA. Beide sehen gleich aus. |
Die MCP-Adresse ist die zentrale Anmeldeadresse — auch dann, wenn Sie roleALPHA sonst über Ihre eigene Firmendomain benutzen. Das ist kein Versehen: das Microsoft-Token wird auf der Anmeldedomain getauscht, und das Ergebnis gilt zeichengenau für die dort genannte Adresse. Tragen Sie Ihre Firmendomain ein, wird jede Anfrage abgewiesen — mit einer Meldung, die die Adresse nicht nennt. Übernehmen Sie die Adresse deshalb aus dem Block, statt sie zu tippen.
Unter den Werten steht eine kurze Liste „Was außerdem stimmen muss”. Sie zeigt für jeden Punkt, ob er erledigt ist: der Schalter für externe Anwendungen, die gespeicherte Verzeichnis-Kennung, mindestens eine erlaubte Adresse, die Anwendungs-ID-URI und die zentrale Anmeldedomain. Die letzten beiden kann nur die Plattform-Administration setzen; steht dort etwas offen, ist die Anbindung unabhängig von Ihren Eingaben aus.
Eine Bedingung lässt sich dort nicht anzeigen, und sie ist trotzdem die häufigste Ursache: jede Person muss sich einmal über Microsoft bei roleALPHA angemeldet haben (siehe unten).
Wie die Anmeldung technisch abläuft
Abschnitt betitelt „Wie die Anmeldung technisch abläuft“Wissenswert ist daran vor allem, was nicht passiert: das Microsoft-Token wird von roleALPHA nicht als Eintrittskarte weitergereicht. Es wird geprüft und gegen ein eigenes, kurzlebiges roleALPHA-Token getauscht.
- Die App hält das Microsoft-Token des angemeldeten Menschen.
- Sie tauscht es bei roleALPHA gegen ein roleALPHA-Token (gültig eine Stunde).
- Mit diesem Token spricht sie den roleALPHA-Endpunkt an.
Beim Tausch prüft roleALPHA fünf Dinge, und jedes kann die Anfrage beenden:
- Die Unterschrift stammt wirklich von Microsoft — aus Ihrem Verzeichnis.
- Das Token ist für roleALPHA ausgestellt, nicht für irgendeine andere Anwendung.
- Es ist ein Token für einen Menschen. Token, die eine Anwendung ohne Menschen holt („Dienstkonto”), werden abgelehnt.
- Der Mensch ist in roleALPHA bekannt (siehe unten).
- Der Mandant hat die Funktion eingeschaltet.
Die Rechte kommen nie aus dem Microsoft-Token. roleALPHA schlägt sie frisch nach, genau wie bei einer Anmeldung über die Web-Oberfläche. Wer in roleALPHA etwas nicht sehen oder ändern darf, kann es auch über die App nicht.
Warum ein Mensch sich einmal bei roleALPHA über Microsoft anmelden muss
Abschnitt betitelt „Warum ein Mensch sich einmal bei roleALPHA über Microsoft anmelden muss“Zugeordnet wird über die Objekt-Kennung aus Ihrem Verzeichnis — nicht über die E-Mail-Adresse. Diese Kennung merkt sich roleALPHA beim Anmelden über Microsoft. Solange sie fehlt, antwortet der Tausch mit dem Hinweis, sich einmal über Microsoft bei roleALPHA anzumelden; danach funktioniert die App dauerhaft.
Der Umweg hat einen Grund: eine E-Mail-Adresse ändert sich, die Objekt-Kennung nicht. Siehe Single Sign-On (SSO).
Was Sie wissen sollten, bevor Sie es einschalten
Abschnitt betitelt „Was Sie wissen sollten, bevor Sie es einschalten“Die Genehmigung gilt Ihrem ganzen Verzeichnis, nicht nur rA Meetings. Microsoft erteilt SharePoint-Erweiterungen ihre Berechtigungen über einen gemeinsamen Zugang des Mandanten. Technisch kann deshalb jede SharePoint-Erweiterung in Ihrem Verzeichnis diese Verbindung benutzen — begrenzt durch die Rechte des jeweiligen Menschen in roleALPHA, aber nicht auf eine einzelne App. Wer das nicht möchte, schränkt die Verteilung der Erweiterungen in SharePoint ein.
Keine Platzhalter bei den Adressen. https://*.sharepoint.com würde jeder SharePoint-Seite
jedes Microsoft-Kunden Zugriff geben. Das Feld weist solche Eingaben deshalb ab.
Gastkonten aus fremden Verzeichnissen werden nicht zugeordnet, solange sie in roleALPHA kein eigenes Konto haben.
Wenn es nicht funktioniert
Abschnitt betitelt „Wenn es nicht funktioniert“| Meldung oder Symptom | Ursache |
|---|---|
| „Für diesen Mandanten ist kein Entra-Verzeichnis hinterlegt” | Verzeichnis-Kennung fehlt. |
| „Externe Anwendungen sind … nicht freigeschaltet” | Der Schalter darüber ist aus. |
| „Dieses Konto ist … nicht mit dem Verzeichnis verknüpft” | Die Person hat sich noch nie über Microsoft bei roleALPHA angemeldet. |
| „Das vorgelegte Token wurde nicht angenommen” | Falsches Verzeichnis, fehlende Genehmigung in Entra, oder ein Token ohne Menschen. Der genaue Grund steht im Protokoll. |
| Die App meldet einen Netzwerkfehler, ohne dass roleALPHA etwas protokolliert | Die Adresse der App steht nicht unter Erlaubte Adressen. |
| Der Block mit den vier Werten erscheint nicht | Im Feld Verzeichnis-Kennung steht nichts oder keine gültige GUID. |
| Im Block steht „Die Anwendungs-ID-URI ist … nicht hinterlegt” | Eine Einstellung der Plattform, nicht Ihres Mandanten. Solange sie fehlt, wird jedes Microsoft-Token abgelehnt — bitte an die Plattform-Administration wenden. |
| Alle vier Werte sind eingetragen, und es funktioniert trotzdem nicht | Meist die MCP-Adresse: eine eigene Firmendomain funktioniert dort nicht (siehe oben). |
Zugänge sehen und beenden
Abschnitt betitelt „Zugänge sehen und beenden“Jede Verbindung erscheint unter Verbundene Anwendungen — je Mensch eine Zeile. Sie lässt sich dort einzeln beenden; wer beendet wurde, bekommt keinen neuen Zugang mehr, bis die Verbindung für den Mandanten neu eingerichtet wird.
Der schnellste Weg, alles zu beenden, ist die Verzeichnis-Kennung zu leeren oder den Schalter für externe Anwendungen auszuschalten. Beides wirkt sofort und beendet auch laufende Sitzungen.
Verwandt
Abschnitt betitelt „Verwandt“- Single Sign-On (SSO) — die Anmeldung über Microsoft, die die Zuordnung erst möglich macht
- Anmeldeverfahren — welche Anmeldewege ein Mandant zulässt