Seit ich die ersten Copilot-Piloten begleite, taucht ein Thema immer wieder auf: Wie lassen sich externe Wissensquellen wie ServiceNow, Confluence oder klassische File Shares ordentlich an die Microsoft-365-Suche und vor allem an Copilot anbinden? Microsoft nennt die Lösung inzwischen Copilot Connectors, früher hießen sie Microsoft Graph Connectors. In vielen Tenants, die ich betreue, kommt spätestens nach dem Copilot-Rollout die Frage auf, wie man Oversharing und unsaubere Berechtigungen vermeidet, sobald externe Datenquellen in Copilot landen.

Copilot Connectors machen externe Inhalte in Suche und Copilot verfügbar

Über Copilot Connectors gelangen Inhalte aus Drittanwendungen oder Dateisystemen in Microsoft Search und Copilot. Eingerichtet werden sie im Microsoft 365 Admin Center unter Copilot → Connectors. Dort gibt es zahlreiche fertige Connectors, unter anderem für ServiceNow, Atlassian Confluence, Salesforce oder einfache Dateifreigaben. Die technischen Grundlagen beschreibt Microsoft in der offiziellen Connector-Übersicht. Mit der Indexierung allein ist es allerdings nicht getan. Viel wichtiger ist, wie die Zugriffsrechte (ACLs) abgebildet und die Identitäten gemappt werden. Copilot zeigt den Usern nämlich exakt das an, was im Index liegt und wofür sie laut ACL berechtigt sind.

Das ACL-Mapping entscheidet über die Sicherheit externer Quellen

In der Praxis hakt es am häufigsten bei der Umsetzung der Access Control Lists. Viele Connectors indexieren Inhalte technisch einwandfrei, übernehmen die Berechtigungen der Quellsysteme aber nicht immer korrekt. Richtig heikel wird es, wenn ein Connector alles als „für alle sichtbar“ indexiert. Dann kann auf einmal jeder im Unternehmen Inhalte lesen, die bisher einem kleinen Nutzerkreis vorbehalten waren. Leider erlebe ich genau das viel zu oft, besonders in Pilotphasen, in denen Connectors „mal schnell“ ausprobiert werden. Bei Quellen ohne Entra-ID-Benutzer, etwa File Shares mit lokalen AD-Accounts oder Confluence mit eigenem User Store, ist eine saubere Identitätszuordnung unverzichtbar. Der Identity Mapping Wizard im Connector-Setup ist dafür Pflicht, erklärt sich aber nicht immer von selbst. Ein einziger Fehler reicht, und im Suchindex herrscht Wildwuchs.

Praxistipp: Testet nach jedem Connector-Setup mit Pilot-Usern, was sie über die Microsoft-365-Suche und Copilot tatsächlich zu sehen bekommen, am besten mit Testaccounts aus unterschiedlichen Rollenbereichen. So fallen Fehler beim ACL-Mapping oder zu breit indexierte Inhalte am schnellsten auf.

Indexierungsgrenzen und Sichtbarkeit lassen sich nur durch Tests prüfen

Technisch gibt es ebenfalls Grenzen. Wie viele Objekte sich indexieren lassen, wie groß einzelne Dateien sein dürfen und wie oft aktualisiert wird, ist je nach Connector unterschiedlich begrenzt (laut aktueller Ankündigung, siehe Microsoft-Dokumentation). Bei Quellen mit großen Datenmengen landet unter Umständen nur ein Teil der Inhalte im Index, und das bemerkt man meist nicht sofort. Den Indexierungsstatus und die Fehlermeldungen im Admin Center sollte man deshalb regelmäßig kontrollieren. Wer genau wissen möchte, welche Dokumente oder Tickets ein bestimmter User über Copilot findet, braucht einen Testaccount oder gezielte Suchabfragen.

Das folgende Diagramm zeigt den Datenfluss eines Connectors im Überblick:

flowchart TD
    ExternalSource["Externe Quelle (z.B. ServiceNow)"] --> ConnectorService["Connector-Service"]
    ConnectorService --> Indexing["Indexierung & ACL-Mapping"]
    Indexing --> M365Search["Microsoft Search-Index"]
    M365Search --> CopilotUser["Copilot-Anfrage User"]
    CopilotUser --> Ergebnis["Suchergebnis (ACL-gefiltert)"]

Abbildung: Mit Copilot Connectors gelangen externe Daten in die Suche, wobei bei jedem Schritt die ACL geprüft wird.

Beim Identitätsmapping von Non-Entra-IDs lauern die meisten Stolperfallen

Der eigentliche Aufwand der Integration steckt oft in der Zuordnung externer User-IDs zu Entra-ID-Konten. Je nach Quellplattform läuft das Mapping über die E-Mail-Adresse, den UserPrincipalName oder sogar über benutzerdefinierte Attribute. Bei File Shares mit alten AD-Accounts oder Cloud-Tools ohne SSO wird es schnell knifflig. Automatische Mappings klappen nur, wenn die Identitäten gepflegt und eindeutig sind. Wer größere Altbestände an Benutzern aus mehreren Systemen zusammenführen will, exportiert vorab am besten eine kleine Mapping-Tabelle und prüft, ob die Zuordnung tatsächlich passt. Im Zweifel beginnt man mit einer kleinen Usergruppe und rollt erst dann auf alle produktiven User aus, wenn die Sichtbarkeit bestätigt ist.

Ein entfernter Connector verlangt gründliches Aufräumen

Wurde zu breit indexiert oder ein Connector nur zum Testen aktiviert, muss auch der Rückbau sorgfältig ablaufen. Wer einen Connector löscht, entfernt damit nicht immer sofort alle indexierten Inhalte aus dem Suchindex. Häufig bleiben sie noch einige Stunden oder Tage sichtbar (laut aktueller Ankündigung). Besser ist es, den Connector im Admin Center zuerst zu deaktivieren, dann den Index zu leeren und den Status regelmäßig zu prüfen. Auch die Gruppen, die Zugriff auf bestimmte Connectors hatten, gehören anschließend auf den Prüfstand. Sind versehentlich sensible Inhalte im Index gelandet, sollte man sicherheitshalber die Suchaktivitäten der letzten Tage auswerten, etwa mit der Audit-Log-Suche in Purview, sofern lizenziert.

In meinen Projekten hat sich ein festes Vorgehen bewährt

Ich starte grundsätzlich mit einer Testgruppe und eigens dafür angelegten Testdaten. Jeden Connector prüfe ich zunächst in einer isolierten Umgebung oder mit möglichst wenigen Usern auf Sichtbarkeit, bevor er produktiv ausgerollt wird. Das ACL-Mapping übernehme ich nie „blind“, sondern teste die User-Mappings und Sichtbarkeiten jedes Mal durch. Nach jedem Testlauf entferne ich den Connector sauber, leere den Index und gehe erst danach in den Produktivbetrieb. Wer sich an diese Grundregeln hält, bekommt Copilot Connectors stabil und sicher zum Laufen.

Zum Weiterlesen: Microsoft-Graph-Connectors – Identität, ACL und Best Practices