Zurück zu Wissen
Active Directory – oder sein Cloud-Nachfolger Microsoft Entra ID – verwaltet Identitäten zentral. Verbindest du dieses Verzeichnis per SAML oder SCIM mit deinen SaaS-Tools, übernimmt es automatisch das Anlegen und Entfernen von Konten und erzwingt Sicherheitsregeln in allen Tools gleichzeitig. Wie das konkret eingerichtet wird und wo die Grenzen liegen, zeigt dieser Leitfaden.
Das Wichtigste in Kürze
- Klassisches on-premises Active Directory spricht die Protokolle moderner SaaS-Tools nicht; für cloud-basierte Umgebungen brauchst du einen cloud-fähigen Identity Provider wie Microsoft Entra ID, Okta oder Google Workspace.
- SAML 2.0 und OIDC regeln das Single Sign-On: Zugangsdaten bleiben beim Identity Provider, SaaS-Tools erhalten nur eine signierte Bestätigung der erfolgreichen Anmeldung.
- SCIM 2.0 automatisiert das Anlegen, Aktualisieren und Deaktivieren von Konten in allen verbundenen Tools, sobald du Änderungen im Verzeichnis vornimmst.
- ActiveCampaign unterstützt SAML-basiertes SSO im Enterprise-Plan; Benutzerrollen lassen sich über Gruppen im Identity Provider automatisch zuweisen.
- Eine zentrale Identity-Integration lohnt sich erst ab einer gewissen Tool-Dichte und Teamgröße; für sehr kleine Teams überwiegt der Einrichtungsaufwand den Nutzen oft noch.
Was klassisches Active Directory von cloud-fähigen Identity Providern unterscheidet
Active Directory wurde ursprünglich für Windows-Domänennetze entwickelt. Es arbeitet mit Kerberos und NTLM – Protokollen, die voraussetzen, dass Clients im gleichen Netzwerk sitzen. Im Büronetz funktioniert das zuverlässig: Anmeldung an der Windows-Arbeitsstation, Zugriff auf Dateiserver, Exchange-Verbindung – alles läuft über das domäneninterne Ticket-System, ohne dass Passwörter über das Netz übertragen werden.
SaaS-Tools sind über das öffentliche Internet erreichbar und sprechen andere Protokolle. Sie erwarten SAML, OIDC oder SCIM – keine Kerberos-Tickets. Klassisches AD allein kann deshalb keine direkte SSO-Verbindung zu Slack, ActiveCampaign, Asana oder Salesforce herstellen. Die Brücke baut entweder ein Sync-Dienst wie Microsoft Entra Connect, der on-premises Identitäten in die Cloud spiegelt, oder du verzichtest auf das lokale AD als alleinige Quelle und verwaltest Identitäten primär in einem cloud-nativen Identity Provider.
Die wichtigsten Identity Provider für DACH-Unternehmen
Microsoft Entra ID – früher als Azure Active Directory bekannt – ist der naheliegende Einstieg, wenn dein Team bereits Microsoft 365 nutzt. Datenspeicherung lässt sich auf europäische Rechenzentren beschränken, was für DSGVO-Überlegungen relevant ist. Die Integration in Teams, SharePoint und Exchange funktioniert ohne zusätzliche Konnektoren, und die SAML- sowie SCIM-Unterstützung für externe SaaS-Tools ist umfassend dokumentiert.
Okta ist Provider-agnostisch und bietet eine sehr breite Auswahl an vorgefertigten App-Integrationen. Es ist besonders dann stark, wenn deine Tool-Landschaft bunt gemischt ist und du keinen Microsoft-zentrierten Ansatz verfolgst. Google Workspace hat seinen eigenen eingebetteten Identity Provider – sinnvoll, wenn das Team ohnehin Google-zentriert arbeitet und Google als Verzeichnis bereits genutzt wird. JumpCloud richtet sich an gemischte Umgebungen mit macOS, Linux und Windows und bietet ebenfalls SAML- und SCIM-Unterstützung ohne Abhängigkeit von einem der großen Cloud-Anbieter.
Die Entscheidung zwischen diesen Providern hängt davon ab, welche Plattform in deinem Unternehmen schon dominiert. Ein Team, das vollständig in Microsoft 365 lebt, gewinnt mit Microsoft Entra ID am meisten – der Aufwand für eine weitere Instanz entfällt. Wer bereits Okta im Einsatz hat, muss keinen Wechsel vornehmen; der Aufwand liegt dann allein darin, weitere Tools anzubinden.
SSO mit SAML und OIDC: Was beim Login tatsächlich passiert
Single Sign-On bedeutet nicht, dass Passwörter zwischen Tools geteilt werden. Stattdessen kommunizieren Identity Provider und SaaS-Tool über ein gesichertes Nachrichtenformat, das belegt: Diese Person hat sich erfolgreich authentifiziert. Das Passwort verlässt den Identity Provider nie – das ist der entscheidende Sicherheitsvorteil gegenüber Passwortwiederverwendung über Tools hinweg.
Der SAML-Ablauf Schritt für Schritt
Wenn du dich bei einem SSO-fähigen Tool wie ActiveCampaign anmeldest, läuft im Hintergrund Folgendes ab. Du rufst die Anmeldeseite auf und klickst auf "Mit SSO anmelden". Das Tool (der Service Provider, kurz SP) leitet dich an den konfigurierten Identity Provider weiter. Dort authentifizierst du dich einmalig – mit Benutzername, Passwort und sofern aktiviert einem zweiten Faktor. Der Identity Provider erstellt eine signierte XML-Nachricht, die sogenannte SAML-Assertion, die deine Identität und ggf. Gruppeninformationen enthält, und schickt sie an das Tool zurück. Das Tool prüft die Signatur gegen das hinterlegte Zertifikat des Identity Providers und gewährt dir Zugang.
OIDC (OpenID Connect) folgt dem gleichen Grundprinzip, ist aber JSON-basiert und baut auf OAuth 2.0 auf. Es ist leichter zu implementieren und daher in modernen Web-Apps und mobilen Anwendungen weiter verbreitet. Für Enterprise-SaaS mit IT-Abteilung ist SAML der ältere und weitverbreitetere Standard; viele Tools unterstützen inzwischen beide. Welchen Standard ein konkretes Tool unterstützt, steht in dessen Dokumentation unter SSO oder Enterprise Authentication.
SP-initiiertes und IdP-initiiertes SSO
Beim SP-initiierten SSO startet der Nutzer beim Tool – er ruft die Anmeldeseite auf und wird zum Identity Provider weitergeleitet. Das ist die häufigere Variante und funktioniert auch, wenn ein Nutzer einen direkten Bookmark auf das Tool hat. Beim IdP-initiierten SSO startet der Nutzer im Portal des Identity Providers – etwa einem Okta-Dashboard oder dem Microsoft-Meine-Apps-Portal – und öffnet das Tool von dort aus. Beide Wege enden am gleichen Ziel; welcher sinnvoller ist, hängt davon ab, ob dein Team von einem zentralen App-Portal aus arbeitet oder direkte URLs bevorzugt.
JIT-Provisionierung: Konten beim ersten Login anlegen
Bei Just-in-Time-Provisionierung (JIT) entsteht das Benutzerkonto im SaaS-Tool automatisch beim allerersten Login via SSO. Das ist bequem, weil kein vorheriges Anlegen im Tool nötig ist. Es hat aber einen Haken: Berechtigungen müssen vorab konfiguriert sein, damit der neue Account beim Anlegen sofort die richtigen Rechte erhält. Außerdem taucht der User erst nach dem ersten Login im System auf, was bedeutet, dass eine Zuweisung von Kontakten, Deals oder Kampagnen-Zugriffen vor dem Login nicht möglich ist. SCIM löst dieses Problem, weil Konten unabhängig vom Login-Zeitpunkt angelegt werden können.
Wie SCIM Konten automatisch anlegt, aktualisiert und deaktiviert
SCIM 2.0 (System for Cross-domain Identity Management) ist ein offener Standard, der in den RFCs 7642 bis 7644 definiert ist. Er beschreibt eine REST-API, über die ein Identity Provider mit einem SaaS-Tool kommuniziert. Der Identity Provider übernimmt dabei die Rolle der führenden Quelle: Er kennt alle Nutzer, ihre Attribute und ihre Gruppenzugehörigkeit. Ändert sich dort etwas, propagiert SCIM diese Änderung an alle angebundenen Tools.
Die drei Kernoperationen und wann sie ausgelöst werden
Das Anlegen eines Kontos (CREATE) erfolgt, sobald ein Nutzer der Gruppe zugewiesen wird, die Zugriff auf das jeweilige Tool hat. Das Aktualisieren (UPDATE) greift bei Namensänderungen, Abteilungswechseln oder Rollenwechseln – das Attribut-Mapping legt fest, welche Verzeichnis-Felder auf welche Tool-Felder übertragen werden. Die Deaktivierung (DEACTIVATE) ist der wohl wichtigste Vorgang: Sobald ein Mitarbeiterkonto im Verzeichnis gesperrt wird, verliert er in allen per SCIM verbundenen Tools den Zugang – innerhalb des nächsten Synchronisierungszyklus, typischerweise innerhalb weniger Minuten bis zu einer Stunde je nach Konfiguration.
Ohne SCIM bleibt die Deaktivierung ein manueller Schritt, den IT-Administratoren für jedes Tool einzeln erledigen müssen. In der Praxis führt das dazu, dass ausgeschiedene Mitarbeiter noch Tage oder Wochen nach ihrem letzten Arbeitstag technisch Zugang zu Systemen haben. Das ist ein Risiko, das Informationssicherheit und DSGVO-Pflichten gleichzeitig berührt. Den Zusammenhang zwischen Datenzugriff und datenschutzrechtlichen Anforderungen im E-Mail-Marketing-Kontext erklärt der Leitfaden zu DSGVO-konformem E-Mail-Marketing mit ActiveCampaign ausführlicher.
Gruppen-basierte Provisionierung
Statt einzelne Nutzer direkt zuzuweisen, funktioniert praxistaugliche SCIM-Integration über Gruppen. Du legst im Identity Provider Gruppen an, die den Rollen in deinen Tools entsprechen – etwa "Marketing-Automation", "Sales-CRM" oder "Analytics-Readonly". Diesen Gruppen werden Tools zugewiesen; wer in die Gruppe eintritt, bekommt automatisch Zugang zum Tool mit der definierten Rolle. Das macht Onboarding zum reinen Gruppenmanagement: neuen Mitarbeiter in die richtigen Gruppen aufnehmen, und alle Zugänge entstehen daraus automatisch.
Das Attribut-Mapping entscheidet, welche Verzeichnis-Felder in welche Tool-Felder übernommen werden. Mindestens E-Mail-Adresse, Vorname und Nachname müssen abgebildet sein; für die automatische Rollenzuweisung in ActiveCampaign kommt das Gruppen-Attribut hinzu. Falsch konfiguriertes Attribut-Mapping ist die häufigste Ursache dafür, dass SCIM technisch synchronisiert, aber Nutzer im Tool trotzdem falsche oder fehlende Rechte haben.
So verbindest du ActiveCampaign mit einem Identity Provider
ActiveCampaign unterstützt SAML-basiertes Single Sign-On im Enterprise-Plan. Das Setup besteht aus zwei parallelen Konfigurationsschritten: Im Identity Provider legst du eine neue Anwendung an, in ActiveCampaign hinterlegst du die SAML-Parameter des Identity Providers. Beide Seiten müssen übereinstimmen, bevor der erste Test-Login funktioniert.
- In ActiveCampaign die SSO-Einstellungen öffnen: Einstellungen aufrufen und den Bereich für Single Sign-On suchen. Dort findest du die ACS-URL (Assertion Consumer Service URL) und die Entity-ID – beide Werte brauchst du für den Identity Provider.
- Im Identity Provider eine neue Unternehmensapp für ActiveCampaign anlegen. Bei Microsoft Entra ID gibt es in der App-Galerie eine vorgefertigte Vorlage; bei Okta ist ActiveCampaign im Integrationskatalog gelistet. ACS-URL und Entity-ID aus dem ersten Schritt dort eintragen.
- Attribut-Mapping konfigurieren: Der Identity Provider muss wissen, welches Verzeichnis-Attribut auf welches SAML-Attribut abgebildet wird. Mindestens E-Mail-Adresse, Vorname und Nachname müssen übertragen werden. Für automatische Rollenzuweisungen zusätzlich die Gruppenzugehörigkeit als Attribut konfigurieren.
- SAML-Metadaten vom Identity Provider – entweder als Metadaten-URL oder als XML-Datei – in ActiveCampaign hinterlegen. Damit weiß ActiveCampaign, welches Zertifikat zur Prüfung der Assertions genutzt wird und wo der Identity Provider erreichbar ist.
- Den vollständigen Login-Fluss mit einem dedizierten Testkonto durchlaufen: vom leeren Browser-Tab über die Weiterleitung zum Identity Provider bis zum erfolgreichen Zugang in ActiveCampaign mit den korrekten Berechtigungen. Erst wenn das reibungslos funktioniert, die Umstellung für alle weiteren Nutzer aktivieren.
Welche Rollen innerhalb von ActiveCampaign welche Aktionen erlauben und wie Gruppen sinnvoll abgegrenzt werden, erklärt der Beitrag zu ActiveCampaign Benutzerrechten und Gruppen im Detail.
Typische Fehler bei der Rollenvergabe und wie du sie vermeidest
Die häufigste Fehlerquelle bei der Einrichtung einer Identity-Integration ist nicht die Technik, sondern die Berechtigungsstruktur. Gruppen werden vage definiert, Rollen zu großzügig vergeben, Fallback-Zugänge fehlen. Wer diese Fehler kennt, spart sich spätere Überarbeitungen.
Admin-Rechte als Provisorium werden zum Dauerzustand
Beim ersten Setup vergeben viele Teams Admin-Rechte an alle, damit das System erst einmal läuft. Das Provisorium bleibt. In einer strukturierten Berechtigungsarchitektur bekommt jeder Nutzer nur die Rechte, die er für seine tägliche Arbeit braucht – das Prinzip der minimalen Berechtigung. In ActiveCampaign bedeutet das konkret: Marketing-Mitarbeiter erhalten Zugriff auf Kampagnen und Automationen, aber keine Konto-Einstellungen. Sales-Mitarbeiter sehen CRM und Deals, erstellen aber keine E-Mail-Kampagnen. Administratoren sind wenige, namentlich bekannte Personen. Wer diese Trennung von Anfang an in der Gruppenstruktur abbildet, muss sie später nicht mühsam nachträglich bereinigen.
Individuelle Einzelzuweisungen statt Gruppenstruktur
Wenn Zugriffsrechte direkt an Einzelpersonen vergeben werden statt über Gruppen, entsteht bei jedem neuen Mitarbeiter manueller Aufwand. Gleichzeitig wächst die Gefahr, dass beim Offboarding einzelne Zugriffsrechte übersehen werden, weil kein zentrales Bild existiert, wer worauf Zugriff hat. Gruppen machen den Zustand des Systems ablesbar: Eine Liste der Gruppen und ihrer Mitglieder zeigt sofort, wer Zugang zu welchem Tool mit welcher Rolle hat.
Kein Fallback-Zugang bei Ausfall des Identity Providers
Wenn alle Nutzer ausschließlich per SSO einloggen und der Identity Provider nicht erreichbar ist – wegen Wartungsfenster, Netzwerkproblem oder Fehlkonfiguration nach einem Update – sind sämtliche betroffenen Tools unzugänglich. Für geschäftskritische Tools sollte mindestens ein lokaler Admin-Account existieren, der nicht über den Identity Provider läuft. Dieser Account sollte nie für den Alltag genutzt werden, damit er als sauberer Fallback erhalten bleibt, und sicher verwahrt sein – im Passwort-Manager des Unternehmens, zugänglich für mehr als eine Person.
Deprovisioning-Prozess ohne klare Zuständigkeit
SCIM-Deprovisioning funktioniert nur so schnell und zuverlässig wie der vorgelagerte Prozess im Verzeichnis. Wenn die HR- oder IT-Abteilung das Konto im Identity Provider nicht zeitnah deaktiviert, läuft SCIM ins Leere. Das Deaktivieren im Verzeichnis muss deshalb fest in den Offboarding-Ablauf integriert sein – nicht als optionaler letzter Schritt, sondern als erster technischer Schritt am oder vor dem letzten Arbeitstag.
Wann eine AD-Integration noch nicht der richtige Schritt ist
Eine zentrale Identitätsverwaltung ist kein Allheilmittel und rechnet sich nicht in jeder Situation. Wer die Grenzen kennt, trifft die Entscheidung nüchterner.
Sehr kleine Teams mit wenigen Tools
Für ein Team von vier bis fünf Personen, das drei SaaS-Tools nutzt, überwiegt der Einrichtungsaufwand den Nutzen deutlich. Der Zeitgewinn durch zentrales Zugriffsmanagement ist real, aber gering; das Risiko nicht gelöschter Konten ist bei dieser Teamgröße überschaubar. Sinnvoller ist hier ein Passwort-Manager mit Freigabe-Funktion, der geteilte Konten sichtbar und verwaltbar macht, ohne die Komplexität eines eigenen Identity Providers.
Tools ohne SAML- oder SCIM-Unterstützung
Nicht alle SaaS-Tools unterstützen SAML oder SCIM. Ältere oder nischenspezifische Anwendungen haben oft ausschließlich Benutzername-Passwort-Login. Für diese Tools bringt ein Identity Provider keinen Vorteil bei der Anmeldung und keine Automatisierung beim Onboarding oder Offboarding – du musst Konten dort weiterhin manuell verwalten. Prüfe deshalb vor dem Setup, welche deiner tatsächlich genutzten Tools die nötigen Protokolle unterstützen und ob das für den Großteil der Arbeitslast der Fall ist.
Temporäre Gastkonten und externe Projektzuarbeit
Für externe Berater, Freelancer oder Projektteilnehmer, die temporären Zugang zu einem einzelnen Tool brauchen, ist SCIM-Provisionierung unnötig komplex. Solche Gastkonten lassen sich direkt im jeweiligen Tool anlegen und nach Projektende entfernen. Einen externen Nutzer als vollwertiges Verzeichniskonto anzulegen, nur um ihn per SCIM zu provisionieren, erzeugt mehr Verwaltungsaufwand als es spart. Sinnvoll ist SCIM für Gastkonten erst dann, wenn Externe regelmäßig auf mehrere Tools gleichzeitig zugreifen müssen und deren Zugänge zentral gesteuert werden sollen.
Häufige Fragen
Muss ich für SSO in ActiveCampaign zwingend den Enterprise-Plan buchen?
SAML-basiertes Single Sign-On ist in ActiveCampaign ausschließlich im Enterprise-Plan verfügbar. Das bedeutet, dass du den Plan entsprechend wählen oder wechseln musst, bevor eine IdP-Integration überhaupt möglich ist. Teams, die ActiveCampaign auf einem niedrigeren Plan nutzen und zentrale Authentifizierung wollen, können als Zwischenlösung einen Passwort-Manager mit Team-Sharing einsetzen, bis der Wechsel auf Enterprise sinnvoll wird.
Was passiert, wenn der Identity Provider nicht erreichbar ist?
Sind alle Logins ausschließlich per SSO konfiguriert und fällt der Identity Provider aus, können sich Nutzer nicht mehr anmelden. Die Lösung ist ein lokaler Admin-Account je kritischem Tool, der unabhängig vom Identity Provider existiert. Dieser Account darf nicht für den Alltag genutzt werden, damit er als sauberer Fallback erhalten bleibt. Zugang zum Fallback-Passwort sollte mehr als eine Person im Unternehmen haben.
Wie unterscheidet sich JIT-Provisionierung von SCIM?
JIT legt ein Konto im SaaS-Tool an, wenn ein Nutzer sich das erste Mal über SSO anmeldet – das Konto entsteht also ereignisgesteuert durch den Login. SCIM ist unabhängig davon: Der Identity Provider sendet eine Nachricht an das Tool, sobald ein Nutzer einer Gruppe zugewiesen oder entzogen wird. SCIM ermöglicht damit auch aktive Deaktivierung, während JIT beim Ausscheiden eines Mitarbeiters keine Deprovisioning-Nachricht auslöst.
Unterstützt ActiveCampaign auch OIDC, oder nur SAML?
Stand 2026 dokumentiert ActiveCampaign SSO über SAML 2.0. OIDC ist in der offiziellen Dokumentation für die Enterprise-SSO-Integration nicht aufgeführt. Wenn du einen Identity Provider nutzt, der SAML unterstützt – was bei Microsoft Entra ID, Okta und Google Workspace der Fall ist – ist das für die Anbindung an ActiveCampaign ausreichend. Prüfe die aktuellen Versionshinweise in der ActiveCampaign-Dokumentation, da sich Funktionsumfänge weiterentwickeln.
Wie weise ich in ActiveCampaign automatisch unterschiedliche Rollen per Gruppe zu?
Das funktioniert über das Attribut-Mapping in der SAML-Konfiguration. Im Identity Provider legst du fest, welches Gruppen-Attribut in der SAML-Assertion übermittelt wird. In ActiveCampaign wird dieses Attribut dann einer internen Rolle zugeordnet. Mitglieder der Gruppe "Marketing-Automation" erhalten beim Login automatisch die Rolle "Marketing Manager" in ActiveCampaign – ohne manuellen Eingriff, solange das Mapping korrekt konfiguriert ist.
Wer Microsoft Entra ID oder einen anderen cloud-nativen Identity Provider als zentrales Verzeichnis für seine SaaS-Landschaft einrichtet, legt eine Grundlage, auf der sich jedes neue Tool mit wenig zusätzlichem Aufwand anbinden lässt. Der kritischste Teil ist nicht das technische Setup, sondern eine sauber durchdachte Gruppenstruktur: Wer hat Zugriff worauf, und wer ist für die Pflege dieser Gruppen verantwortlich. Einmal aufgesetzt, macht diese Struktur jeden späteren Onboarding- und Offboarding-Vorgang zum reinen Gruppenmanagement im Verzeichnis.
