Kurz gefasst
Wer ein Active Directory an ein IAM anbinden will, scheitert selten an der Technik — und fast immer an gewachsenen Gruppenstrukturen, die niemand mehr überblickt. Das IAM-System erwartet klare, dokumentierte Rechte. Das Active Directory liefert stattdessen eine Verschachtelung, die über Jahre entstanden ist. An dieser Lücke entscheidet sich, ob ein Berechtigungsprojekt trägt oder im ersten Anlauf stecken bleibt.
Weil beide Systeme unterschiedlichen Regeln folgen. Ein IAM-System arbeitet mit einem klaren Modell: Welche Gruppe steht für welches Recht, und wer verantwortet es? Auf dieser Grundlage vergibt, entzieht und rezertifiziert es Zugriffe. Ein Active Directory kennt diese Disziplin nicht von sich aus. Es lässt zu, dass Gruppen in Gruppen liegen — und über Jahre nutzt man das auch aus. Beim Anbindungsprojekt treffen dann eine strenge und eine gewachsene Logik aufeinander.
Gruppenverschachtelung im Active Directory bedeutet: Eine Gruppe ist Mitglied einer anderen Gruppe, diese wiederum Mitglied einer weiteren — über viele Ebenen. Praktisch im Betrieb, aber schwer aufzulösen, sobald ein System jede Berechtigung eindeutig zurückverfolgen muss.
In einem Mandat für eine international agierende Bank ging es genau darum: Active-Directory-Gruppen an ein IAM-System anbinden, um Berechtigungen künftig kontrolliert und nachvollziehbar zu vergeben. Die Ausgangslage in Zahlen: rund 70.000 Gruppen und etwa 10.000 Benutzer in einer einzigen Domäne.
Diese Größenordnung ist der Punkt. Bei 70.000 Gruppen ist keine Struktur mehr „mal eben“ von Hand zu prüfen. Was fehlte, war nicht Technik, sondern Überblick.
Weil das IAM-System keine verschachtelten Gruppen unterstützte. Es erwartete, dass eine Gruppe ein Recht abbildet — direkt, ohne Umweg über weitere Gruppen. Das Active Directory dagegen war massiv verschachtelt: Gruppen lagen in Gruppen, diese wieder in Gruppen, über viele Ebenen.
An einzelnen Stellen war die Verschachtelung sogar zirkulär. Gruppen enthielten sich über mehrere Ebenen am Ende wieder selbst. Für den täglichen Betrieb fiel das nie auf. Für ein System, das jede Berechtigung eindeutig auflösen muss, ist es ein Fehler mit Ansage.
Dazu kam das eigentliche Kernproblem: Es gab keine Dokumentation. Niemand konnte verlässlich sagen, wo eine bestimmte Gruppe tatsächlich berechtigt war — auf welchen Dateiablagen, in welchen Anwendungen, für welche Funktion. Über die Jahre hatten viele Hände viele Gruppen angelegt, verschachtelt und weitergereicht. Das Wissen darüber war mit den Menschen gegangen, die es hatten.
Weil ein IAM-System Rechte verwaltet, keine Container. Eine Gruppe ohne dokumentiertes Recht ist für das IAM wertlos: Sie lässt sich nicht rezertifizieren, nicht auf einen Verantwortlichen zurückführen und nicht sauber vergeben.
Würde man die verschachtelten Gruppen unverändert anbinden, verlagert man den Wildwuchs nur in ein neues System. Die alten Probleme wären dann im IAM abgebildet — mit dem Anspruch, dass es sie eigentlich lösen sollte. Wer Active Directory an ein IAM anbindet, ohne die Berechtigungs-Logik vorher zu klären, baut den Wildwuchs im neuen System nach. Ein sauberes IAM- und IDM-Konzept setzt genau an dieser Stelle an.
Solche Projekte werden nicht an der Schnittstelle gewonnen, sondern in der Analyse davor. Bewährt hat sich ein Vorgehen in drei Schritten:
1. Ist-Aufnahme und Verschachtelung auflösen. Die Gruppenstruktur wird vollständig ausgelesen und Ebene für Ebene aufgelöst. Zirkuläre Ketten werden gezielt gesucht und aufgebrochen, weil sie jede saubere Auswertung verhindern.
2. Rechte je Gruppe klären. Das ist Detailarbeit an den Zugriffen selbst — an Dateiablagen, Anwendungen und Systemen — und im Gespräch mit den Fachbereichen, die die Rechte fachlich verantworten. Aus verschachtelten, undokumentierten Gruppen werden flache, benannte und einem Verantwortlichen zugeordnete Berechtigungen.
3. In Wellen anbinden. Erst diese aufgeräumten Gruppen gehen an das IAM — abschnittsweise, nicht in einem Schritt. So bleibt jede Anbindung überprüfbar, und Fehler zeigen sich in einem abgegrenzten Bereich, nicht im ganzen Verzeichnis.
Die Anbindung von Active Directory an ein IAM ist selten ein technisches Schnittstellenthema. Sie ist ein Aufräumthema. Die Technik steht bereit — die Frage ist, ob die Berechtigungen so beschrieben sind, dass ein IAM-System überhaupt etwas mit ihnen anfangen kann.
Wer vor einem solchen Projekt steht, sollte die ehrliche Frage zuerst stellen: Wissen wir eigentlich, was unsere Gruppen berechtigen? Fällt die Antwort unsicher aus, liegt genau dort der erste Arbeitsschritt — vor jeder Anbindung.
Nicht zwangsläufig. Viele IAM-Systeme erwarten, dass eine Gruppe genau ein Recht abbildet, und lösen verschachtelte Mitgliedschaften nicht auf. Vor der Anbindung muss die Verschachtelung deshalb aufgelöst werden.
Eine Kette von Gruppenmitgliedschaften, die über mehrere Ebenen wieder bei der Ausgangsgruppe endet. Im Betrieb bleibt das oft unbemerkt, für die eindeutige Auflösung von Berechtigungen ist es ein blockierender Fehler.
Über eine Analyse der tatsächlichen Zugriffe auf Dateiablagen, Anwendungen und Systeme — kombiniert mit den Fachbereichen, die die Rechte fachlich verantworten. Ohne diesen Schritt bleibt eine Gruppe für ein IAM ein undokumentierter Container.
Ja. Wer ungeklärte, verschachtelte Gruppen anbindet, bildet den Wildwuchs im IAM nur neu ab. Erst flache, benannte und einem Verantwortlichen zugeordnete Gruppen lassen sich sauber vergeben und rezertifizieren.
Verwandt: Active Directory zu Entra ID: Drei Stolperfallen im Hybrid-Betrieb — wie sich Gruppen und Berechtigungen im Hybrid-Betrieb zwischen beiden Welten verhalten.
Über den Autor: Stefan Gröne berät seit 1998 Konzerne und Banken zu Active Directory, Microsoft Entra ID und Identitäts- und Berechtigungsmanagement. cosoweb betreut unter anderem seit 2018 ein Banking-Mandat im IAM-Umfeld.
Sie planen die Anbindung Ihres Active Directory an ein IAM oder stehen vor einer Berechtigungs-Restrukturierung? Schreiben Sie uns an sgroene@cosoweb.de — wir schauen uns Ihre Ausgangslage an.
← Vorheriger Beitrag: Active Directory zu Entra ID: Drei Stolperfallen im Hybrid-Betrieb
Zurück zur Wissen-Übersicht
Nächster Beitrag: Conditional Access einführen: Warum Report-only zuerst kommt →
Kurz gefasst
- Eine führende Quelle je Datenart — Artikelstamm, Preise und Bestände kommen aus der Warenwirtschaft, Bestellungen aus dem Shop.
- B2B-Regeln abbilden — kundenindividuelle Preise, Staffelungen, Freigabe-Prozesse und Kauf auf Rechnung.
- Fehlertolerante Schnittstellen — protokollieren, wiederholen und melden statt Fehler stillschweigend zu verschlucken.
Was ist eine Warenwirtschafts-Schnittstelle? Eine Warenwirtschafts- oder ERP-Schnittstelle verbindet den Online-Shop mit dem führenden System für Artikel, Preise und Bestände. Sie synchronisiert Daten in definierter Richtung, sodass jede Information nur an einer Stelle gepflegt wird und im Shop automatisch aktuell ist.
Weil sich sonst beide Systeme gegenseitig überschreiben. Der erste Schritt ist keine Technik, sondern eine Festlegung: Welches System ist für welche Information führend? In der Regel kommen Artikelstamm, Preise und Bestände aus der Warenwirtschaft, während der Shop Bestellungen zurückliefert. Ist das nicht eindeutig geklärt, überschreiben sich beide Seiten gegenseitig — und niemand weiß mehr, welcher Preis stimmt.
Weil B2B eigene Regeln hat, die den Standard-Shop-Gedanken sprengen. Kundenindividuelle Preise, Staffelungen, Freigabe-Prozesse, Zahlung auf Rechnung: WooCommerce bildet das ab, braucht dafür aber eine bewusst konzipierte Anbindung statt eines Standard-Konnektors von der Stange.
Fehlertoleranz. Schnittstellen fallen aus — der Server der Warenwirtschaft ist im Wartungsfenster, eine Datei kommt unvollständig an. Eine belastbare Anbindung protokolliert, wiederholt und meldet Fehler, statt sie stillschweigend zu verschlucken. Diese Robustheit ist der Unterschied zwischen einem Shop, dem man traut, und einem, den man täglich kontrolliert.
In der Regel die Warenwirtschaft: Sie führt Artikelstamm, Preise und Bestände, während der Shop Bestellungen zurückmeldet. Entscheidend ist, je Datenart genau eine führende Quelle festzulegen, damit sich beide Seiten nicht gegenseitig überschreiben.
Für einfache Kataloge oft ja, für echte B2B-Anforderungen selten. Kundenindividuelle Preise, Staffelungen und Freigabeprozesse erfordern meist eine bewusst konzipierte Anbindung statt eines Konnektors von der Stange, der nur Standardfälle kennt.
Bei einer robusten Anbindung nichts Dramatisches: Sie protokolliert den Fehler, wiederholt die Übertragung und meldet den Ausfall, statt Daten stillschweigend zu verlieren. Genau diese Fehlertoleranz unterscheidet eine belastbare Schnittstelle von einer, die man täglich kontrollieren muss.
Ja. WooCommerce lässt sich um kundengruppenspezifische Preise, Mengenstaffeln, Rechnungskauf und Freigabeprozesse erweitern. Voraussetzung ist eine saubere Konzeption der Datenflüsse und der Schnittstelle zur Warenwirtschaft, nicht nur die Installation eines Plugins.
Über den Autor: cosoweb entwickelt und betreibt Webservices für den Mittelstand — Webentwicklung, WooCommerce und Systemanbindungen aus einer Hand. Wer erreichbar bleiben will, arbeitet direkt mit den Inhabern, nicht mit einem Account-Layer.
Wie cosoweb B2B-Shops mit WooCommerce umsetzt, steht auf der Seite E-Commerce und Online-Shops.
Sie planen einen B2B-Shop mit ERP-Anbindung? Lassen Sie uns über die Schnittstellen sprechen.
← Vorheriger Beitrag: Individuelles WordPress-Template: wann es günstiger ist
Zurück zur Wissen-Übersicht →
Kurz gefasst
- Struktur — klare Informationsarchitektur, saubere interne Verlinkung und eindeutige Seitentitel.
- Ladezeit — schnelle Seiten ranken besser und halten Besucher, bevor der Inhalt sichtbar wird.
- Messbarkeit — ohne sauberes Tracking bleibt SEO Bauchgefühl.
Was ist technisches SEO? Technisches SEO umfasst alle Maßnahmen an der technischen Grundlage einer Website — Struktur, Ladezeit, Indexierbarkeit, strukturierte Daten und interne Verlinkung —, die darüber entscheiden, ob Suchmaschinen die Inhalte überhaupt erfassen und einordnen können. Es ist die Voraussetzung dafür, dass gute Inhalte gefunden werden.
Struktur. Eine Suchmaschine bewertet, was sie versteht. Eine klare Informationsarchitektur, saubere interne Verlinkung und eindeutige Seitentitel wirken stärker als jede Keyword-Dichte. Wer seine Leistungen thematisch bündelt und untereinander verlinkt, gibt Google die Landkarte, die es braucht — genau nach diesem Prinzip ist auch dieser Wissensbereich aufgebaut.
Weil sie doppelt wirkt — auf Ranking und Conversion. Langsame Seiten ranken schlechter und verlieren zusätzlich Besucher, bevor der Inhalt überhaupt sichtbar wird. Bildoptimierung, sauberes Caching und der Verzicht auf überladene Page-Builder zahlen doppelt ein: auf das Ranking und auf die Conversion. Warum schwere Themes hier bremsen, steht im Beitrag zum individuellen WordPress-Template.
Weil ohne Datengrundlage jede Maßnahme Bauchgefühl bleibt. Ein korrekt eingerichtetes Tracking und die regelmäßige Auswertung von Suchanfragen zeigen, welche Themen tatsächlich Nachfrage haben — und wo sich ein Beitrag lohnt. Erst auf dieser Basis wird aus Aufwand Wirkung.
Beides greift ineinander, aber die Technik ist die Voraussetzung. Solange Struktur, Ladezeit und Indexierbarkeit nicht stimmen, verpuffen auch gut recherchierte Keywords. Im Mittelstand liegt die Ursache mangelnder Sichtbarkeit deshalb häufiger in der technischen Grundlage als im Text.
Ja. Google bewertet Ladezeit und Nutzererlebnis über die Core Web Vitals, und langsame Seiten verlieren zusätzlich Besucher, bevor der Inhalt erscheint. Ladezeit wirkt damit doppelt — auf das Ranking und auf die Conversion.
Generative Antworten in Google AI Overviews, ChatGPT oder Perplexity zitieren bevorzugt Inhalte, die klar strukturiert, eindeutig formuliert und aktuell sind. Wer Fragen direkt beantwortet, Fachbegriffe sauber definiert und Inhalte gut gliedert, verbessert damit zugleich das klassische Ranking und die Sichtbarkeit in KI-Antworten. Die technische Grundlage bleibt dieselbe.
Über ein korrekt eingerichtetes Tracking und die regelmäßige Auswertung realer Suchanfragen — welche Begriffe Besucher bringen, welche Seiten konvertieren und wo Nachfrage besteht, die noch keine passende Seite hat. Rankings allein sagen wenig; entscheidend ist, ob aus Sichtbarkeit qualifizierte Anfragen werden.
Über den Autor: cosoweb entwickelt und betreibt Webservices für den Mittelstand. SEO gehört dabei zum Handwerk, nicht zu einem Zusatzpaket — dieselbe technische Basis trägt auch cosoweb.de.
SEO gehört bei cosoweb zum Webservices-Handwerk, nicht zu einem Zusatzpaket. Mehr dazu im Geschäftsfeld Webservices.
Sie fragen sich, warum Ihre Seite nicht gefunden wird? Wir schauen uns die Technik an.
← Vorheriger Beitrag: Rechenzentrums-Konsolidierung ohne Betriebsunterbrechung
Zurück zur Wissen-Übersicht
Nächster Beitrag: Individuelles WordPress-Template: wann es günstiger ist →
Kurz gefasst
- Gekaufte Multipurpose-Themes sind billig in der Anschaffung, aber teuer in Pflege und Performance.
- Individuelle Templates bilden nur die benötigte Struktur ab — schlanker, schneller, leichter pflegbar.
- Die Entscheidung ist eine Rechenaufgabe — sie hängt an erwarteter Lebensdauer und Komplexität des Auftritts, nicht am Geschmack.
Was ist ein Multipurpose-Theme? Ein Multipurpose-Theme ist ein universell einsetzbares WordPress-Theme, das sich per Page-Builder für nahezu jeden Zweck anpassen lässt. Der Preis dieser Flexibilität ist ein großer, meist ungenutzter Funktionsumfang, der die Ladezeit belastet und den Wartungsaufwand erhöht.
Weil ungenutzter Funktionsumfang trotzdem gewartet werden muss. Gekaufte Multipurpose-Themes bringen Funktionsumfang mit, den man nie nutzt — und der trotzdem gewartet, aktualisiert und gegen Sicherheitslücken abgesichert werden muss. Sie hängen oft an schweren Page-Buildern, die die Performance belasten und Updates riskant machen. Was beim Kauf gespart wurde, zahlt man über Jahre in Wartungsaufwand und langsameren Seiten zurück — und langsame Seiten kosten Sichtbarkeit, wie der Beitrag zu technischem SEO im Mittelstand zeigt.
Im Gegenteil — es bildet nur ab, was gebraucht wird. Ein individuelles Template bildet genau die Struktur ab, die das Unternehmen braucht — nicht mehr. Das Ergebnis ist schlanker, schneller und leichter pflegbar, weil niemand gegen die Annahmen eines fremden Baukastens arbeiten muss. Bei Auftritten mit klarer Informationsarchitektur und langfristiger Pflegeperspektive ist das häufig die wirtschaftlichere Wahl.
Von erwarteter Lebensdauer und Komplexität, nicht vom Geschmack. Wer zwei Jahre plant, fährt mit dem Baukasten gut. Wer eine Plattform für die nächsten fünf bis acht Jahre baut, sollte den Vergleich ehrlich rechnen — inklusive Wartung, Performance und der Kosten, die entstehen, wenn ein Theme-Anbieter die Weiterentwicklung einstellt.
Sobald ein Auftritt ein komplexes Leistungsportfolio, Mehrsprachigkeit, Systemanbindungen oder eine lange Pflegeperspektive hat. Ein typisches Beispiel ist ein B2B-Shop mit WooCommerce und Warenwirtschafts-Anbindung. Bei kleinen, kurzlebigen Websites bleibt ein gekauftes Theme die pragmatische Wahl; bei Plattformen für fünf bis acht Jahre rechnet sich die schlanke Eigenlösung meist über die Laufzeit.
Nicht in der Anschaffung, aber oft in der Summe. Wartung ungenutzter Funktionen, Sicherheitsupdates, Performance-Einbußen durch schwere Page-Builder und die Abhängigkeit vom Theme-Anbieter summieren sich über Jahre zu Kosten, die den niedrigen Kaufpreis übersteigen können.
Page-Builder erzeugen zusätzlichen Code und laden Funktionen, die eine konkrete Seite gar nicht braucht. Das vergrößert Dateigrößen und Ladezeit — ein direkter Nachteil für Ranking und Conversion, wie im Beitrag zu technischem SEO beschrieben.
Im Gegenteil — ein sauber gebautes, schlankes Template ist meist leichter zu pflegen, weil es nur die tatsächlich genutzten Funktionen enthält und niemand gegen die Annahmen eines fremden Baukastens arbeiten muss. Voraussetzung ist eine ordentliche technische Umsetzung und Dokumentation.
Über den Autor: cosoweb entwickelt und betreibt Webservices für den Mittelstand — Websites, WordPress und Systemanbindungen aus einer Hand. Wer cosoweb beauftragt, arbeitet direkt mit den Inhabern, nicht mit einem Account-Layer.
Wie cosoweb WordPress-Auftritte jenseits des Baukastens umsetzt, steht auf der Seite Websites und CMS.
Sie überlegen, ob Baukasten oder individuelle Lösung? Wir rechnen es mit Ihnen durch.
← Vorheriger Beitrag: Technisches SEO im Mittelstand: Wo Sichtbarkeit wirklich entsteht
Zurück zur Wissen-Übersicht
Nächster Beitrag: B2B-Shop mit WooCommerce: Schnittstellen zur Warenwirtschaft →
Kurz gefasst
- Inventarisieren — alle Authentifizierungswege inklusive Legacy-Protokollen erfassen.
- Report-only testen — jede Richtlinie zunächst nur protokollieren, ohne den Zugriff zu blockieren.
- Schrittweise durchsetzen — erst scharf schalten, wenn ausschließlich die beabsichtigten Fälle betroffen sind.
Was ist Conditional Access? Conditional Access ist die richtlinienbasierte Zugriffssteuerung in Microsoft Entra ID. Sie prüft bei jeder Anmeldung Signale wie Benutzer, Gerät, Standort und Anmelderisiko und entscheidet daraufhin, ob der Zugriff erlaubt, blockiert oder an zusätzliche Bedingungen wie Multi-Faktor-Authentifizierung (MFA) geknüpft wird.
Weil sie zeigt, wen eine Regel treffen würde, bevor sie tatsächlich blockiert. Jede neue Richtlinie sollte zunächst im Report-only-Modus laufen. Dabei protokolliert Entra ID, wen die Regel getroffen hätte, ohne den Zugriff tatsächlich zu blockieren. Erst wenn die Auswertung zeigt, dass ausschließlich die beabsichtigten Fälle betroffen sind, wird die Regel scharf geschaltet. Diese Phase kostet Wochen — und verhindert genau den Ausfall, der ein Sicherheitsprojekt politisch beschädigt.
Weil die Pilotgruppe moderne Clients nutzt und die Altlasten verdeckt. In der Pilotgruppe läuft meist alles, weil Piloten moderne Clients nutzen. Beim breiten Rollout tauchen dann die Anwendungen auf, die über Legacy-Authentifizierung anmelden und sich moderner Absicherung entziehen. Wer diese Fälle nicht vorher inventarisiert, erzwingt MFA gegen eine Landschaft, die er nicht kennt. Diese Altfälle sind einer der drei Stolperfallen im Hybrid-Betrieb, die eine AD-zu-Entra-ID-Migration regelmäßig ausbremsen.
Weil kein technischer Kniff eine falsche Reihenfolge rettet. Der belastbare Weg ist immer derselbe: erst die Authentifizierungswege inklusive Legacy-Protokollen inventarisieren, dann Richtlinien in Report-only testen, dann schrittweise durchsetzen. Keine dieser Stufen lässt sich sinnvoll überspringen.
Im Report-only-Modus wertet Entra ID bei jeder Anmeldung aus, ob eine Richtlinie gegriffen hätte, blockiert den Zugriff aber nicht. So lässt sich vor der scharfen Schaltung prüfen, wen eine Regel tatsächlich treffen würde — und ob unbeabsichtigte Fälle darunter sind.
Weil ältere Anwendungen häufig über Legacy-Authentifizierungsprotokolle anmelden, die moderne Bedingungen wie MFA nicht unterstützen. Werden solche Anwendungen vor dem Rollout nicht inventarisiert, blockiert eine scharfe Richtlinie unerwartet ganze Fachbereiche.
Conditional Access entfaltet seine Wirkung erst mit dem Schritt in Entra ID, und die Legacy-Altfälle stammen meist aus der gewachsenen On-Premises-Welt. Beide Themen gehören deshalb zusammen — mehr dazu im Beitrag über die Stolperfallen im Hybrid-Betrieb.
Nicht zwangsläufig — aber Anwendungen, die nur Legacy-Authentifizierung beherrschen, lassen sich mit modernen Richtlinien nicht sauber absichern. Sie müssen entweder abgelöst, gekapselt oder bewusst über Ausnahmen behandelt werden, und genau diese Entscheidung gehört vor die Durchsetzung.
Über den Autor: Stefan Gröne berät seit 1998 Konzerne und Banken zu Active Directory, Microsoft Entra ID und Identitäts- und Berechtigungsmanagement. cosoweb betreut unter anderem seit 2018 ein Banking-Mandat im IAM-Umfeld.
cosoweb begleitet die Absicherung hybrider Microsoft-Umgebungen als Senior-Mandat — siehe Active Directory und Entra ID sowie IAM und IDM.
Sie planen die Einführung von Conditional Access in einer regulierten Umgebung? Sprechen Sie uns an.
← Vorheriger Beitrag: Active Directory zu Entra ID: Drei Stolperfallen im Hybrid-Betrieb
Zurück zur Wissen-Übersicht
Nächster Beitrag: Rechenzentrums-Konsolidierung ohne Betriebsunterbrechung →
Kurz gefasst
- Abhängigkeitsanalyse zuerst — die vollständige Landkarte aller Anwendungs- und Datenflüsse steht vor dem ersten Serverumzug.
- Migration in Wellen — zusammenhängende Anwendungsverbünde ziehen gemeinsam um, jede Welle mit definiertem Rückfallpunkt.
- Zielbild vor Werkzeug — die Entscheidung für Rechenzentrum, Azure oder Hybrid gehört an den Anfang, nicht in die Migrationsphase.
Was ist eine Abhängigkeitsanalyse? Die Abhängigkeitsanalyse (engl. Application Dependency Mapping) erfasst, welche Anwendung mit welcher kommuniziert — über welche Ports, mit welchen Latenzanforderungen und in welche Richtung. Sie ist die Grundlage jeder ausfallfreien Migration, weil sie sichtbar macht, was gemeinsam umziehen muss und was sich gefahrlos trennen lässt.
Weil sich hier entscheidet, ob eine Konsolidierung im laufenden Betrieb gelingt. Bevor ein einziger Server umzieht, muss die Abhängigkeitslandschaft stehen: Welche Anwendung spricht mit welcher, über welche Ports, mit welchen Latenzanforderungen. Genau hier entscheidet sich, ob eine Konsolidierung im laufenden Betrieb möglich ist oder ob sie ein Wartungsfenster braucht, das der Fachbereich nicht hergibt. Erfahrungsgemäß ist die Inventarisierung aufwendiger als die eigentliche Migration — und die Zeit, die man hier spart, holt einen später als Ausfall wieder ein.
Belastbar wird die Analyse erst, wenn sie nicht nur auf Dokumentation, sondern auf gemessenem Datenverkehr beruht. Netzflüsse über einen repräsentativen Zeitraum aufzuzeichnen, fördert genau die Abhängigkeiten zutage, die in keinem Architekturdiagramm stehen — den nächtlichen Batch-Lauf, die vergessene Schnittstelle, die feste IP-Kopplung.
Weil Wellen die Abhängigkeiten kurz halten und jederzeit einen Rückfallpunkt bieten. Bewährt hat sich das Vorgehen in klar geschnittenen Wellen: zusammenhängende Anwendungsverbünde werden gemeinsam migriert, damit die internen Abhängigkeiten kurz bleiben und nicht über die noch nicht migrierte Standort-Kopplung laufen. Jede Welle hat einen definierten Rückfallpunkt. Das klingt konservativ, ist aber der Grund, warum am Ende niemand von einem Ausfall berichten muss.
Weil ein spät gewähltes Zielbild zu teuren Lift-and-Shift-Landschaften führt. Ob klassisches Rechenzentrum, Azure oder ein hybrider Zielzustand — diese Entscheidung gehört an den Anfang, nicht in die Migrationsphase. Ein „wir schieben erstmal und entscheiden später“ führt zu Lift-and-Shift-Landschaften, die in der Cloud teuer und on-premises unaufgeräumt sind. Wo die Cloud das Ziel ist, lohnt der Blick auf die Cloud-Migration mit Azure-Fokus, bevor die erste Welle geplant wird.
Der Schlüssel ist die Reihenfolge: zuerst eine vollständige Abhängigkeitsanalyse, dann die Migration in klar geschnittenen Wellen mit Rückfallpunkten. So bleiben Abhängigkeiten innerhalb einer Welle kurz, und kein Anwendungsverbund wird über eine noch nicht migrierte Standortkopplung getrennt.
Weil die meisten Ausfälle nicht aus der Migration selbst, sondern aus unbekannten Abhängigkeiten entstehen. Erst wenn dokumentiert ist, welche Systeme miteinander sprechen, lässt sich planen, was gemeinsam umziehen muss und was sich gefahrlos trennen lässt.
Statt alle Systeme zu einem Stichtag zu verschieben, werden zusammengehörige Anwendungsverbünde nacheinander in abgegrenzten Etappen migriert. Jede Welle ist testbar, hat einen definierten Rückfallpunkt und begrenzt das Risiko auf einen überschaubaren Ausschnitt.
Beides hat seine Berechtigung, aber die Entscheidung gehört an den Anfang. Ein reines Lift-and-Shift ohne Zielbild verlagert bestehende Probleme lediglich — in der Cloud oft zu höheren laufenden Kosten. Ein bewusst gewähltes Zielbild entscheidet, welche Systeme umgebaut, welche nur verschoben und welche abgelöst werden.
Über den Autor: Stefan Gröne berät seit 1998 Konzerne und Banken zu Microsoft-Infrastruktur, Rechenzentrums-Konsolidierung und Cloud-Migration. cosoweb betreut unter anderem seit 2018 ein Banking-Mandat im IAM-Umfeld.
cosoweb plant und steuert solche Vorhaben als Senior-Mandat — von der Abhängigkeitsanalyse bis zur letzten Welle. Details zum Leistungsfeld stehen auf der Seite Microsoft- und Rechenzentrums-Infrastruktur.
Sie stehen vor einer Konsolidierung oder einem Carve-out? Schildern Sie kurz Ihre Ausgangslage.
← Vorheriger Beitrag: Conditional Access einführen: Warum Report-only zuerst kommt
Zurück zur Wissen-Übersicht
Nächster Beitrag: Technisches SEO im Mittelstand: Wo Sichtbarkeit wirklich entsteht →
Kurz gefasst
- Synchronisierung ohne sauberes Quell-Datenmodell — ungeklärte Attribut-Autorität multipliziert bestehende AD-Altlasten in der Cloud.
- Gruppen und Berechtigungen zwischen zwei Welten — ohne Gesamtsicht entsteht ein Zwitter aus AD- und Entra-Steuerung.
- Authentifizierung, die nur im Testbetrieb trägt — Legacy-Protokolle und Conditional Access kollidieren erst beim breiten Rollout.
Was bedeutet Hybrid-Betrieb? Als hybride Identität bezeichnet man den Zustand, in dem Benutzerkonten parallel im lokalen Active Directory und in Microsoft Entra ID existieren und über ein Synchronisierungswerkzeug wie Entra ID Connect abgeglichen werden. Diese Phase ist kein kurzer Übergang, sondern eine eigenständige Betriebsphase mit eigenen Regeln — und genau deshalb unterschätzt.
Aus wiederkehrenden Mandaten lassen sich die drei Stolperfallen konkret benennen. Keine davon ist exotisch. Alle drei werden regelmäßig unterschätzt, weil sie in der Testumgebung nicht auffallen und erst unter Produktivlast sichtbar werden.
Weil ungeklärte Attribut-Autorität bestehende AD-Altlasten in die Cloud multipliziert. Entra ID Connect (bzw. Cloud Sync) ist schnell installiert, und genau das ist das Problem. Die eigentliche Arbeit liegt nicht im Tool, sondern in der Frage, welches System die Autorität über welches Attribut besitzt. Wird das nicht vorab geklärt, synchronisiert man gewachsene Inkonsistenzen aus dem AD unverändert in die Cloud — und multipliziert sie dort.
Typische Symptome: Konten, die sich beim sogenannten Soft-Match nicht sauber zuordnen lassen und als Duplikate in Entra ID landen. Uneinheitliche UPN-Suffixe, die nicht zur verifizierten Domäne passen, sodass Anmeldungen scheitern. Oder ein mail-Attribut, das im AD nie konsequent gepflegt wurde und nun über die Cloud-Sichtbarkeit erstmals auffällt. Die Korrektur unter laufendem Sync ist deutlich aufwendiger als eine vorgeschaltete Bereinigung.
Der belastbare Weg führt über ein explizites Attribut- und Autoritätsmodell vor dem ersten Sync: Welche Quelle ist führend, welche UPN-Strategie gilt, wie werden Alt-Lasten bereinigt. Das klingt nach Vorarbeit, die man sich sparen könnte — bis der erste Rezertifizierungslauf die Duplikate zutage fördert.
Weil im Hybrid-Betrieb On-Premises- und Cloud-Gruppen gleichzeitig existieren und unterschiedlicher Logik folgen. Wer weiterhin im AD gepflegte Sicherheitsgruppen für den Zugriff auf Cloud-Ressourcen nutzen will, braucht Group Writeback und muss dessen Grenzen kennen — etwa beim Verhalten verschachtelter Gruppen oder bei dynamischen Gruppen, die es on-premises so nicht gibt.
Die Stolperfalle ist selten technischer, sondern konzeptioneller Natur: Es entsteht ein Zwitter, in dem manche Berechtigungen aus dem AD, andere aus Entra ID gesteuert werden, ohne dass jemand die Gesamtsicht hält. Für ein sauberes Berechtigungsmodell — Thema unseres IAM- und IDM-Angebots — ist genau diese Gesamtsicht die Voraussetzung. Ohne sie wird jede spätere Governance- oder Rezertifizierungsanforderung zur Archäologie.
Praktisch bewährt sich, früh zu entscheiden, welche Welt für welchen Ressourcentyp führend ist, und diese Entscheidung zu dokumentieren, statt sie implizit dem jeweiligen Administrator zu überlassen.
Weil die Wahl des Verfahrens früh und leise fällt, ohne Blick auf den Zielzustand. Die Wahl zwischen Password Hash Synchronization, Pass-through Authentication und Federation wird oft früh und leise getroffen — und selten mit Blick auf den Zielzustand. Im Hybrid-Betrieb rächt sich das, wenn Conditional-Access-Richtlinien eingeführt werden, während ältere Anwendungen noch über Legacy-Authentifizierungsprotokolle anmelden, die sich der modernen Absicherung entziehen.
Das Muster ist immer ähnlich: In der Pilotgruppe läuft alles, weil die Piloten moderne Clients nutzen. Beim breiten Rollout melden sich dann die Fachbereiche mit Anwendungen, die niemand auf dem Schirm hatte. Wird MFA erzwungen, bevor diese Fälle identifiziert sind, steht im schlechtesten Fall ein Teil des Betriebs still.
Der Ausweg ist keine Technik, sondern Reihenfolge: erst eine belastbare Inventarisierung der Authentifizierungswege inklusive Legacy-Protokollen, dann die schrittweise Einführung von Conditional Access mit einer Report-only-Phase, und erst danach die harte Durchsetzung. Diese Disziplin kostet Wochen — verhindert aber den Ausfall, der ein Projekt politisch beschädigt.
Alle drei Stolperfallen haben dieselbe Wurzel: Der Hybrid-Zustand wird als Übergang behandelt, den man schnell hinter sich bringt, statt als eigenständige Betriebsphase mit eigenen Regeln. Wer ihn ernst nimmt — mit sauberem Datenmodell, klarer Berechtigungs-Autorität und einer disziplinierten Authentifizierungs-Reihenfolge — verliert weniger Zeit, als er in die Vorarbeit steckt.
In regulierten Großumgebungen erstreckt sich die Hybrid-Phase meist über mehrere Monate bis Jahre. Sie endet nicht mit einem Stichtag, sondern wenn alle Anwendungen, Berechtigungen und Authentifizierungswege sauber in die Cloud überführt sind. Bis dahin sollte der Hybrid-Betrieb als eigenständige Betriebsphase geplant und gesteuert werden.
Entra ID Connect ist die klassische, funktionsreiche Synchronisierungslösung mit lokaler Serverkomponente und breiter Konfigurierbarkeit. Entra Cloud Sync arbeitet mit einem leichtgewichtigen Agenten und eignet sich besonders für verteilte oder mehrere Verzeichnisse, hat aber Funktionsgrenzen. Die Wahl hängt vom Attributmodell und den Anforderungen an Writeback und Filterung ab.
Nein. Bewährt hat sich der Weg über eine Report-only-Phase: Die Richtlinien werden zunächst nur protokolliert, um Legacy-Anwendungen und Sonderfälle sichtbar zu machen, bevor die harte Durchsetzung greift. Details dazu im Beitrag Conditional Access einführen: Warum Report-only zuerst kommt.
In den meisten Umgebungen bleibt das lokale Active Directory zunächst bestehen, weil Anwendungen, Fileserver oder Drucker weiterhin daran gebunden sind. Der vollständige Abschied vom AD ist ein eigenes Teilprojekt und steht am Ende, nicht am Anfang der Migration.
Über den Autor: Stefan Gröne berät seit 1998 Konzerne und Banken zu Active Directory, Microsoft Entra ID und Identitäts- und Berechtigungsmanagement. cosoweb betreut unter anderem seit 2018 ein Banking-Mandat im IAM-Umfeld.
cosoweb begleitet Migrationen von Active Directory zu Entra ID als Senior-Mandat, von der Architektur bis in den Hybrid-Betrieb. Wie wir dabei vorgehen, steht auf der Leistungsseite Active Directory und Microsoft Entra ID; angrenzende Themen wie Cloud-Migration mit Azure-Fokus und IAM und IDM finden Sie in denselben Rubriken. Verwandt ist der Beitrag zur Rechenzentrums-Konsolidierung ohne Betriebsunterbrechung.
Sie stehen vor einer AD-zu-Entra-ID-Migration in einer regulierten Umgebung? Schildern Sie uns kurz Ihre Ausgangslage — Sie erhalten in der Regel innerhalb von zwei Werktagen eine erste Einschätzung.
← Zurück zur Wissen-Übersicht
Nächster Beitrag: Conditional Access einführen: Warum Report-only zuerst kommt →