Intranet-Integrationen: SSO, HR-Systeme und Microsoft 365

Mitarbeitende sollten dieselben Kontaktdaten nicht in mehreren Systemen aktualisieren oder verschiedene Anwendungen durchsuchen müssen, nur um ein Dokument zu finden. Gut geplante Intranet-Integrationen reduzieren diese wiederkehrenden Schritte. Zugriffsentscheidungen und Datensätze verbleiben dabei in den jeweils zuständigen Systemen.

Open Intranet, von Droptica auf Basis von Drupal entwickelt, kann als Einstiegspunkt in die Arbeitswerkzeuge dienen, ohne Ihren Identitätsanbieter, Ihr HR-System oder Ihre Dokumentenplattform zu ersetzen. Die Herausforderung bei der Umsetzung besteht darin, festzulegen, was angebunden wird, welche Daten kopiert werden und wo Berechtigungen geprüft werden müssen.

Dieser Leitfaden erläutert Integrationsmuster, die Sie prüfen sollten. Er unterscheidet zwischen Drupal-Konfiguration, Community-Modulen und individuell entwickelten Konnektoren und benennt Funktionen, deren Verfügbarkeit in Ihrer Installation zunächst überprüft werden muss.

In diesem Artikel:

• Wie sollten Sie die Integrationsschicht gestalten?
• Wie binden Sie SSO an und verwalten den Kontozugriff?
• Wie kann Open Directory Mitarbeiterprofile, Abteilungen und Rollen aktuell halten?
• Wie sollten Microsoft-365-Inhalte in Open Intranet erscheinen?
• Wie binden Sie Google Workspace an, ohne private Inhalte offenzulegen?
• Wie integrieren Sie Tickets, ohne einen zweiten Service Desk aufzubauen?
• Wie bleiben Dokumentberechtigungen bei einer DMS-Anbindung erhalten?
• Wie testen und warten Sie Intranet-Integrationen?

Wie sollten Sie die Integrationsschicht gestalten?

Beginnen Sie mit den Aufgaben der Mitarbeitenden, nicht mit einer Liste von APIs. „Die aktuelle Abteilung einer Kollegin finden“ ist eine überprüfbare Anforderung. „HR integrieren“ ist es nicht.

Bestimmen Sie für die erste Version die kürzesten sinnvollen Nutzerabläufe:

• Mit einem bestehenden Unternehmenskonto anmelden.
• Eine Kollegin oder einen Kollegen samt aktuellen Kontaktdaten finden.
• Ein Dokument öffnen, für das eine Leseberechtigung besteht.
• Eine Supportanfrage einreichen und ihren Status prüfen.

Erstellen Sie anschließend ein Integrationsverzeichnis. Jede Verbindung braucht eine festgelegte maßgebliche Datenquelle, eine verantwortliche Stelle, ein Authentifizierungsverfahren, eine Lese- und Schreibrichtung sowie eine Aktualisierungsfrequenz.

Dies sind Planungsbeispiele, kein Katalog sofort einsatzbereiter Konnektoren.

Wählen Sie die einfachste Verbindung, die die Aufgabe erfüllt. Ein Link zu Teams kann ausreichen. Teams-Inhalte ins Intranet zu kopieren, verursacht zusätzlichen Aufwand für Berechtigungen, Speicherung und Wartung, ohne den Mitarbeitenden zwangsläufig zu helfen.

Eine Referenzarchitektur trennt drei Zuständigkeiten:

1. Identitätsanbieter: authentifiziert Mitarbeitende.
2. Open Directory: ordnet vereinbarte Benutzerdaten zu und synchronisiert sie.
3. Weitere Konnektoren: tauschen Daten mit Produktivitäts-, Ticket- und Dokumentensystemen aus.

Platzieren Sie die Konnektorlogik in Drupal-Services und gegebenenfalls in Hintergrundprozessen, statt externe API-Aufrufe direkt in Seitentemplates einzubauen.

Prüfen Sie vor der Aufwandsschätzung die installierte Drupal-Version, unterstützte APIs, Mandantenbeschränkungen, Lizenzen und aktiv gepflegte Module. Unterscheiden Sie zwischen der Konfiguration vorhandener Funktionen, der Installation von Community-Modulen und individueller Entwicklung. Drupals Open-Source-Basis ermöglicht Erweiterungen, stellt aber nicht jede externe Anbindung sofort bereit.

Wie binden Sie SSO an und verwalten den Kontozugriff?

Single Sign-on reduziert den Aufwand rund um Passwörter und ermöglicht dem Identity-Team, zentrale Zugriffsrichtlinien durchzusetzen. Microsoft Entra ID, Okta und Keycloak sind je nach Infrastruktur und Protokollanforderungen Ihrer Organisation mögliche Optionen.

Für die Anmeldung an Webanwendungen kommen typischerweise infrage:

• OpenID Connect: häufig für moderne Identitätsplattformen geeignet; arbeitet mit Identitätsattributen und Tokens.
• SAML: verbreitet in Unternehmensumgebungen mit bestehenden Föderationskonfigurationen.

Wählen Sie ein gepflegtes Drupal-Authentifizierungsmodul, das Ihre installierte Drupal-Version und die erforderliche Kontoverknüpfung unterstützt. Prüfen Sie vor der Entscheidung die Versorgung mit Sicherheitsupdates, die Release-Aktivität, die Unterstützung der Abmeldung und den Konfigurationsexport.

Eine typische Einrichtung umfasst folgende Schritte:

1. Registrieren Sie Open Intranet als Anwendung beim Identitätsanbieter.
2. Konfigurieren Sie die exakten Redirect-URLs für OpenID Connect beziehungsweise die Assertion-Consumer-Service-URLs für SAML.
3. Tauschen Sie die erforderlichen Metadaten, Zertifikate oder Client-Zugangsdaten aus.
4. Konfigurieren Sie die Prüfung des erwarteten Ausstellers, der Zielgruppe, der Signaturen und der protokollspezifischen Schutzmechanismen.
5. Ordnen Sie verifizierte Identitätsattribute lokalen Konten zu.
6. Testen Sie mit berechtigten und nicht berechtigten Benutzern.

Verwenden Sie einen stabilen Identitätsschlüssel für die Kontoverknüpfung bei der Authentifizierung. Bei OpenID Connect ist die Kombination aus Issuer und Subject das übliche Identitätspaar, sofern die Implementierung es unterstützt. E-Mail-Adressen können sich ändern oder neu vergeben werden und sollten deshalb nicht automatisch als dauerhafte Authentifizierungskennung dienen.

Davon zu unterscheiden ist die Verwendung einer vertrauenswürdigen Unternehmens-E-Mail-Adresse zum Abgleich von Profilen während der Synchronisierung.

Auch Authentifizierung, Kontobereitstellung und Profilaktualisierung sind getrennte Aufgaben. Eine erfolgreiche Unternehmensanmeldung belegt nicht, dass Abteilung, Führungskraft oder Intranet-Rolle aktuell sind. Entscheiden Sie, ob Konten vor der ersten Anmeldung, bei der ersten Anmeldung oder in einem anderen freigegebenen Verfahren angelegt werden.

Zugriffsregeln sollten ausdrücklich festlegen:

• Welche Gruppen beim Identitätsanbieter auf das Intranet zugreifen dürfen.
• Welche freigegebenen Gruppen welchen lokalen Drupal-Rollen entsprechen.
• Welche MFA-Richtlinien der Identitätsanbieter anwendet.
• Wie lange lokale Sitzungen gültig bleiben.
• Wie deaktivierte Konten ihren bestehenden Intranet-Zugriff verlieren.

Gehen Sie nicht davon aus, dass die Deaktivierung eines Kontos beim Identitätsanbieter sofort jede lokale Drupal-Sitzung beendet. Definieren und testen Sie die Ungültigmachung von Sitzungen, die Kontosperrung und ein eventuell verbleibendes Zugriffszeitfenster.

Testen Sie das Abmeldeverhalten, deaktivierte Benutzer, abgelaufene Zertifikate und Ausfälle des Identitätsanbieters. Falls ein lokaler Notfallzugang für Administratoren erhalten bleibt, beschränken Sie ihn, schützen Sie seine Zugangsdaten gesondert und überwachen Sie jede Nutzung.

Wie kann Open Directory Mitarbeiterprofile, Abteilungen und Rollen aktuell halten?

Open Directory kann Benutzerinformationen in Open Intranet aus einer externen Quelle zuordnen und aktuell halten. Dazu zählen Active Directory, Keycloak oder eine andere Benutzerdatenquelle, sofern die erforderliche Verbindung eingerichtet ist.

Der Nutzen im Alltag ist einfach: Ein Abteilungswechsel oder eine neue Telefonnummer kann ins Intranet übernommen werden, ohne dass dieselbe Information zweimal eingegeben werden muss.

Wenn das HRIS die Mitarbeiterdatensätze verwaltet, entscheiden Sie, ob Open Directory sie direkt oder über ein freigegebenes Verzeichnis erhalten soll, das bereits HR-Aktualisierungen übernimmt. Vermeiden Sie zwei konkurrierende Datenzuflüsse für dasselbe Feld.

Der Ablauf ist:

1. Die vertrauenswürdige Benutzerdatenquelle anbinden.
2. Festlegen, wie Quelldatensätze Intranet-Konten zugeordnet werden.
3. Die benötigten Felder und freigegebenen Rollen zuordnen.
4. Regeln für Überschreiben, Entfernen und Ausnahmen vereinbaren.
5. Die Synchronisierung mit einer kleinen Mitarbeitergruppe testen.
6. Laufende Aktualisierungen über die Mechanismen aktivieren, die die installierte Implementierung unterstützt.

Die folgende Tabelle veranschaulicht Zuordnungsentscheidungen. Sie schreibt keine konkreten Feldnamen im Quellsystem vor.

Beim E-Mail-basierten Abgleich findet der Prozess das Intranet-Konto mit der passenden vertrauenswürdigen Unternehmensadresse und aktualisiert dessen zugeordnete Profilfelder. Mehrdeutige Treffer müssen gemeldet werden; das System darf nicht raten.

Bewahren Sie nach Möglichkeit eine stabile Quellkennung für den weiteren Abgleich auf, damit eine geänderte E-Mail-Adresse kein zweites Konto erzeugt. Vereinbaren Sie außerdem, wie eine später einer anderen Person zugewiesene Adresse behandelt wird.

Trennen Sie Stellenbezeichnungen von Rollen, die Berechtigungen vergeben. „Operations Manager“ kann eine Profilinformation sein, während „Content Editor“ Fähigkeiten in Drupal freischaltet. Wandeln Sie beliebigen Quelltext nicht in Berechtigungen um und vergeben Sie keine Administratorrechte anhand eines ungeprüften Gruppenwerts.

Dokumentieren Sie für jedes zugeordnete Feld:

• Welches System den Wert bestimmt.
• Ob Mitarbeitende ihn lokal bearbeiten dürfen.
• Ob die Synchronisierung lokale Änderungen überschreibt.
• Ob ein leerer Quellwert das Zielfeld leert.
• Was geschieht, wenn eine referenzierte Abteilung oder Führungskraft fehlt.

Beispielsweise wechselt eine Person vom Vertrieb in den operativen Bereich. Die nächste erfolgreiche Synchronisierung aktualisiert ihre Abteilung und führt ausschließlich ausdrücklich konfigurierte Rollenzuweisungen und Rollenentzüge aus. Andere Profilfelder bleiben unverändert.

Prüfen Sie die unterstützten Aktualisierungsauslöser oder Zeitpläne der installierten Open-Directory-Implementierung, bevor Sie Konfigurationsanleitungen schreiben oder Echtzeitaktualisierungen zusagen. Weitere Benutzerdatenquellen können einen Adapter oder zusätzliche Integrationsarbeit erfordern.

Testen Sie Neueintritte, Abteilungswechsel, E-Mail-Änderungen, Rollenentzug, fehlende Datensätze und Austritte. Eine fehlgeschlagene oder unvollständige Quellantwort darf keine massenhafte Kontodeaktivierung auslösen. Gestalten Sie die Behandlung von Austritten als ausdrücklichen Prozess, getrennt von der normalen Profilaktualisierung.

Schließen Sie Gehaltsdaten, medizinische Angaben und andere nicht benötigte sensible Felder aus. Beschränken Sie den Konnektorzugriff auf die erforderlichen Datensätze und Attribute und halten Sie sensible Werte aus den Protokollen heraus.

Wie sollten Microsoft-365-Inhalte in Open Intranet erscheinen?

Beginnen Sie mit der Aufgabe der Mitarbeitenden und wählen Sie anschließend die passende Microsoft-365-Anbindung.

Microsoft-365-SSO und die Autorisierung für Microsoft Graph müssen getrennt konfiguriert werden, selbst wenn sie denselben Identitätsmandanten nutzen. Eine Anmeldung bei Open Intranet berechtigt das System nicht automatisch zum Lesen von Kalendern oder Dokumenten.

Unterscheiden Sie beim Graph-Zugriff:

• Delegierte Berechtigungen: Anfragen laufen im Kontext eines angemeldeten Benutzers, begrenzt durch die erteilten Scopes und dessen Zugriffsrechte.
• Anwendungsberechtigungen: Freigegebene Hintergrundaufgaben laufen ohne angemeldeten Benutzer. Sie können einen größeren Datenbestand zugänglich machen und erfordern eine strengere Prüfung.

Verwenden Sie für mitarbeiterspezifische Komponenten delegierten Zugriff, sofern der jeweilige Dienst ihn unterstützt. Setzen Sie Anwendungsberechtigungen nur ein, wenn eine Hintergrundaufgabe sie rechtfertigt, und beschränken Sie die Ressourcen, soweit dies unterstützt wird. Eine Antwort im reinen Anwendungskontext beweist nicht, dass der aktuelle Intranet-Besucher deren Inhalt sehen darf.

Die Umsetzung umfasst üblicherweise die Anwendungsregistrierung, minimale API-Berechtigungen, erforderliche Zustimmungen, geschützte serverseitige Speicherung von Tokens und Zugangsdaten sowie einen Prozess zur Token-Erneuerung. Behandeln Sie widerrufene Zustimmungen und abgelaufene Zugangsdaten als erwartbare Fehlerfälle.

Prüfen Sie für jeden Dienst die unterstützte Einbettungsmethode. SharePoint-Seiten, Office-Dokumente und andere Microsoft-365-Ressourcen verhalten sich in Frames nicht identisch. Mandanteneinstellungen, Frame-Richtlinien, Cookie-Beschränkungen des Browsers und das aktive Microsoft-Konto können das Ergebnis beeinflussen.

Personalisierte Inhalte benötigen außerdem berechtigungsbewusstes Caching. Konfigurieren Sie in Drupal Cache-Kontexte, Tags und maximale Speicherzeiten so, dass Kalender oder Dokumentlisten einer Person nicht einer anderen angezeigt werden. Lässt sich keine sichere Trennung der Cache-Varianten gewährleisten, darf die Antwort nicht Teil gemeinsam genutzter zwischengespeicherter Seiteninhalte sein.

Beachten Sie die Vorgaben zur API-Drosselung einschließlich mitgeteilter Wartezeiten vor einem erneuten Versuch. Laden Sie optionale Komponenten unabhängig, damit ein Kalenderausfall die Startseite nicht verzögert. Bieten Sie einen klaren Ausweichlink zur Quellanwendung an.

Prüfen Sie Lizenzen, unterstützte Endpunkte, Zustimmungen und Zugriffe mit repräsentativen Mitarbeiterkonten, bevor Sie eine Funktion verbindlich zusagen.

Wie binden Sie Google Workspace an, ohne private Inhalte offenzulegen?

Für Google Workspace gilt dasselbe Prinzip: Zeigen Sie Mitarbeitenden nur Inhalte, auf die sie zugreifen dürfen, ohne den Empfängerkreis der Ressource zu erweitern.

Nutzen Sie Drive-Links, wenn lediglich eine Datei geöffnet werden soll. Prüfen Sie unterstützte Docs- oder Calendar-Einbettungen für Ansichten innerhalb einer Seite. API-basierte Komponenten eignen sich für gefilterte Listen oder andere kontextbezogene Interaktionen.

Die Anmeldung mit einer Google-Identität und die OAuth-Autorisierung für Workspace-Daten sind getrennte Vorgänge. Eine über Google authentifizierte Person hat Open Intranet nicht zwangsläufig berechtigt, ihre Drive-Dateien oder ihren Kalender zu lesen.

Vor der Umsetzung:

• Fordern Sie nur die für die Funktion erforderlichen Scopes an.
• Prüfen Sie Administratoreinstellungen und Beschränkungen externer Anwendungen.
• Klären Sie Zustimmungen und mögliche Verifizierungsanforderungen.
• Testen Sie mit privaten Ressourcen und Benutzern mit unterschiedlichen Freigaberechten.
• Prüfen Sie, welches Konto der Browser für eingebettete Inhalte verwendet.

Veröffentlichen Sie private Dokumente oder Kalender nicht öffentlich, nur damit eine Einbettung geladen wird. Damit verändern Sie Zugriffsgrenzen, statt die Integration zu reparieren.

Dienstkonten und domainweite Delegierung sind separate Architekturentscheidungen mit weitreichenden Berechtigungen. Für benutzerspezifische Ansichten sind sie nicht die Standardlösung. Falls domainweite Delegierung erforderlich ist, dokumentieren Sie Scopes, Regeln für das Handeln im Namen von Benutzern, zuständige Administratoren und das Widerrufsverfahren.

Wenn Browserbeschränkungen oder der Kontokontext das Laden einer Einbettung verhindern, zeigen Sie einen Link „In Google Workspace öffnen“ an. Ein zuverlässiger Weg zur Quelle ist nützlicher als eine leere Komponente oder eine unsichere Freigabe als Behelfslösung.

Wie integrieren Sie Tickets, ohne einen zweiten Service Desk aufzubauen?

Ein Intranet kann den Zugang zum Support erleichtern, während die operative Bearbeitung auf der Ticketplattform verbleibt.

Priorisieren Sie bei Jira Service Management, ServiceNow oder einem kompatiblen internen Service Desk:

• Ein Formular zum Einreichen von Anfragen.
• Eine persönliche Liste der eigenen Anfragen.
• Statusübersichten und Links zum ursprünglichen Ticket.

Belassen Sie Workflow-Verantwortung, Zuweisungsregeln, Eskalationen und Serviceziele in der Serviceplattform. Ordnen Sie nur die Felder zu, die für die Intranet-Nutzung benötigt werden, etwa Anfragetyp, Beschreibung, anfragende Person und zulässige Anhänge.

Verwenden Sie unterstützte APIs zum Einreichen. Empfangen Sie Statusänderungen über unterstützte Webhooks oder fragen Sie den Status in vereinbarten Intervallen ab, wenn keine Webhooks verfügbar sind.

Ordnen Sie den angemeldeten Mitarbeiter serverseitig der richtigen Anfragenden-Identität zu. Vertrauen Sie niemals ohne Prüfung einer vom Browser gelieferten Kennung der anfragenden Person. Prüfen Sie die Berechtigung vor der Anzeige von Ticketdetails oder Anhängen — auch bei Anfragen, deren Sichtbarkeit sich seit der Einreichung geändert hat.

Wiederholungsversuche benötigen Schutz vor Duplikaten. Erzeugen Sie eine stabile Einreichungskennung und nutzen Sie die Idempotenz-Unterstützung der Plattform, soweit vorhanden. Andernfalls müssen Deduplizierung und Abgleich im Konnektor sorgfältig gestaltet werden. Läuft eine Anfrage in ein Timeout, obwohl die Plattform sie bereits angenommen haben könnte, klären Sie zunächst das Ergebnis, statt sie blind erneut einzureichen.

Zeigen Sie eindeutige Zustände an:

• Ausstehend: Die Annahme der Anfrage wurde noch nicht bestätigt.
• Eingereicht: Die Serviceplattform hat eine bestätigte Referenz zurückgegeben.
• Fehlgeschlagen: Die Anfrage konnte nicht abgeschlossen werden und erfordert einen festgelegten nächsten Schritt.

Authentifizieren Sie Webhook-Ereignisse mit dem von der Plattform unterstützten Mechanismus, weisen Sie wiederholt eingespielte Ereignisse nach Möglichkeit zurück und verarbeiten Sie Duplikate sicher. Allgemeine Intranet-Benachrichtigungen sollten lediglich über eine Änderung der Anfrage informieren, statt sensible Ticketinhalte einem größeren Personenkreis offenzulegen.

Wie bleiben Dokumentberechtigungen bei einer DMS-Anbindung erhalten?

Das Dokumentenmanagementsystem bleibt maßgeblich für Versionen, Aufbewahrung und Freigabestatus. Das Intranet soll Mitarbeitenden helfen, Dokumente zu finden und zu öffnen, statt unbemerkt unverwaltete Kopien zu erzeugen.

Wählen Sie die Darstellungsform bewusst:

Verwenden Sie stabile Dokumentkennungen, sofern das DMS sie unterstützt. Pfade und Dateinamen können sich ändern. Definieren Sie, wie der Konnektor verschobene Dateien auflöst, gelöschte Datensätze behandelt und auf geänderte Freigaberechte reagiert.

Die Suchindexierung erfordert ein eigenes Sicherheitskonzept. Legen Sie fest:

1. Welche Metadaten oder Inhalte in den Index gelangen.
2. Wie Dokumentzugriffsregeln abgebildet werden.
3. Wie Benutzer- und Gruppenmitgliedschaften ermittelt werden.
4. Wie schnell Berechtigungsänderungen übernommen werden.
5. Was geschieht, solange Zugriffsinformationen veraltet oder nicht verfügbar sind.

Verlassen Sie sich nicht darauf, dass der endgültige Dokumentlink die gesamte Sicherheit gewährleistet. Ein geschützter Titel oder Suchausschnitt kann schon vor dem Klick Informationen verraten.

Definieren Sie eine akzeptable Verzögerung beim Entzug von Berechtigungen. Lassen sich Zugriffsregeln im Index nicht zuverlässig nachbilden, prüfen Sie eine Autorisierung zur Abfragezeit oder eine enger begrenzte Integration. Wenn die Berechtigung nicht feststellbar ist, muss der Zugriff verweigert werden.

Schützen Sie Vorschau- und Download-Caches genauso sorgfältig wie die Originaldokumente. Verlinken Sie die aktuelle Quellversion, statt eine unbemerkte Intranet-Kopie zu pflegen, die spätere Änderungen oder Aufbewahrungsmaßnahmen womöglich nicht berücksichtigt.

Wie testen und warten Sie Intranet-Integrationen?

Ein Konnektor ist nicht fertig, sobald seine erste Anfrage erfolgreich war. Er ist einsatzbereit, wenn das Team Fehler erkennen, ihre Auswirkungen begrenzen und den Betrieb ohne Rätselraten wiederherstellen kann.

Trennen Sie die Konnektorlogik von den Darstellungskomponenten. Dokumentieren Sie API-Versionen, Feldzuordnungen, Authentifizierungsabläufe, erforderliche Berechtigungen, Modulabhängigkeiten und Speicherorte der Zugangsdaten. Speichern Sie Geheimnisse in einem freigegebenen Secret Store, nicht in exportierter Drupal-Konfiguration oder der Versionsverwaltung.

Verwenden Sie separate Testumgebungen und Dienstidentitäten. Gewähren Sie nur die nötigen Berechtigungen und legen Sie Verfahren zur Rotation von Zugangsdaten, Tokens und Zertifikaten fest.

Erstellen Sie eine Testmatrix für Fehlerfälle und Zugriffsgrenzen:

Testen Sie für Open Directory insbesondere den E-Mail-Abgleich, geänderte Adressen, umbenannte Abteilungen, die Zuweisung und Entfernung freigegebener Rollen sowie fehlende Beziehungen zu Führungskräften. Prüfen Sie nach einem Quellausfall, ob eine erfolgreiche Aktualisierung den erwarteten Zustand wiederherstellt, ohne doppelte Konten anzulegen.

Verwenden Sie Zeitlimits und eine begrenzte Anzahl von Wiederholungsversuchen. Wiederholen Sie vorübergehend fehlgeschlagene Anfragen mit zunehmenden Abständen, aber nicht endlos bei Autorisierungs- oder Validierungsfehlern. Überführen Sie wiederholt scheiternde Queue-Einträge in einen überprüfbaren Fehlerzustand mit einem dokumentierten Verfahren zur erneuten Verarbeitung.

Optionale externe Komponenten benötigen unabhängiges Laden und ein eigenes Ausweichverhalten. Ein einzelner nicht verfügbarer Dienst darf die Intranet-Startseite nicht blockieren.

Überwachen Sie Betriebskennzahlen, ohne sensible Anfrage- oder Antwortinhalte zu speichern:

• Authentifizierungsfehler.
• Zeit seit der letzten erfolgreichen Synchronisierung.
• Fehlgeschlagene oder übersprungene Datensätze.
• Rückstau in der Warteschlange.
• Fehler und Drosselung der vorgelagerten API.
• Zertifikate und Zugangsdaten kurz vor ihrem Ablauf.

Nützliche Kennzahlen zum Start sind erfolgreiche Anmeldungen, Aktualisierungsverzug im Verzeichnis, bestätigte Einreichungen und erfolgreiches Öffnen von Dokumenten. Ermitteln Sie während des Piloten einen Ausgangswert und vereinbaren Sie Alarmschwellen mit den Teams, die darauf reagieren werden.

Planen Sie Drupal- und Konnektorupdates zusammen mit API-Abkündigungen, Zertifikatserneuerungen und Änderungen der Mandantenrichtlinien. Individueller Code benötigt Regressionstests, ebenso wie Community-Module auf Kompatibilität und Sicherheit geprüft werden müssen.

Bestätigen Sie vor dem Start diese Grundlagen:

• Berechtigungstests: weisen nach, dass nicht berechtigte Benutzer geschützte Inhalte und Metadaten nicht sehen können.
• Datenabgleich: vergleicht Quell- und Zieldatensätze, um verpasste Aktualisierungen zu erkennen.
• Alarme: leiten Fehler an Personen weiter, die handeln können.
• Benannte Verantwortliche: jede Verbindung hat eine technische und eine fachliche Verantwortung für die Daten.
• Wiederherstellungsanleitungen: erklären, wie Abläufe sicher angehalten, wiederholt, erneut verarbeitet oder Datenbestände neu aufgebaut werden.

Wie geht es weiter?

Bringen Sie Droptica eine Übersicht Ihres Identitätsanbieters, Ihrer Benutzerdatenquelle, Ihres HRIS, Ihres Microsoft-365- oder Google-Workspace-Mandanten, Ihrer Ticketplattform und Ihres DMS mit.

Ergänzen Sie Beispiele für Mitarbeiterfelder, Abteilungsstruktur und Rollenzuordnungen, die Open Directory pflegen soll — möglichst anhand anonymisierter Datensätze. Beschreiben Sie die Aufgaben der Mitarbeitenden, die Sie unterstützen möchten, sowie Einschränkungen bei Lizenzen, Hosting oder Zugriff.

Sprechen Sie mit Droptica über die Prüfung von Verbindungsmethoden, Zugriffsgrenzen und Umsetzungsaufwand für Open Intranet. Der nächste Schritt ist zu klären, was die Konfiguration abdeckt, welche gepflegten Module passen und wo individuelle Konnektorentwicklung nötig ist.