Cloud-First Identitätsverwaltung: Leitfaden für IT-Architekten

Moderne Unternehmen stehen unter dem zunehmenden Druck, die Sicherheit zu verbessern, indem sie das Identitätsmanagement modernisieren und Abläufe straffen. Dieses Dokument bietet einen strategischen und technischen Rahmen für IT-Architekten, um die Benutzer- und Gruppenverwaltung von lokalem Active Directory (AD) zu Microsoft Entra ID mithilfe der SoA-Konvertierung (Source of Authority) zu verschieben. Eine ältere AD-Umgebung kann komplex, kostspielig zu verwalten und, wenn sie nicht auf dem neuesten Stand gehalten wird, zunehmend anfällig für moderne Bedrohungen sein. Das Ziel von Microsoft besteht darin, Optionen zum Sichern von Hybridkunden bereitzustellen, indem sie microsoft Entra ID für die Identitätsverwaltung einrichten können. Der Transfer von SOA ermöglicht einen phasenweisen, risikoarmen Migrationspfad und vermeidet so die Störung einer "Big-Bang-Umstellung."

Dieser Leitfaden bietet IT-Architekten einen umfassenden Überblick über das Cloud-First Identity Management. Es erläutert die Geschäftlichen und Sicherheitsvorteile des Wechsels zu cloudbasierter Identität, beschreibt eine phasenweise Roadmap für den Übergang von Hybridumgebungen zu cloudbasierten und AD-minimierten Zuständen und beschreibt, wie die Bereitschaft für die SOA-Übertragung von Benutzern und Gruppen bewertet wird. In diesem Leitfaden wird auch ein App-zentrierter Ansatz für Organisationen beschrieben, die noch nicht bereit sind, sich vollständig zu ändern, Integrationsstrategien für Kerberos- und LDAP-basierte Anwendungen behandelt, wichtige Einschränkungen und Überlegungen zum hybriden Betrieb erläutert und eine praktische Checkliste zur Unterstützung der Planung, Ausführung und Governance während des gesamten Migrationsprozesses angeboten.

Unternehmens- und Sicherheitsvorteile

Active Directory gilt seit langem als "Schlüssel für das Königreich" für Organisationen und macht es zu einem attraktiven Ziel für Angreifer, wenn sie kompromittiert werden. Durch die Reduzierung der Abhängigkeit von AD und die Migration der Anwendungsauthentifizierung zur Verwendung der Microsoft Entra ID wird die Sicherheit verbessert, indem die Benutzer durch bedingten Zugriff und MFA geschützt sind. Durch die Migration von Identitäten und Authentifizierung zu Microsoft Entra-ID werden moderne Funktionen wie Richtlinien für bedingten Zugriff, passwortlose Authentifizierung und erweiterte Identitätsgovernance für Benutzer und Anwendungen ermöglicht, einschließlich solcher, die ursprünglich lokal verwaltet wurden. Im Wesentlichen stärkt die Zentralisierung der Verwaltung in der Microsoft Entra-ID den allgemeinen Sicherheitsstatus einer Organisation.

Verbessern der IT-Effizienz und Benutzerfreundlichkeit

Ein Cloud-First-Ansatz kann dazu beitragen, die IT-Effizienz und die Benutzererfahrung in Ihrer Organisation auf folgende Weise zu verbessern:

IT-Administratoren können Benutzeridentitäten, Gruppen und Verbund- oder Bereitstellungsrichtlinien für den Anwendungszugriff über das Admin Center und die Microsoft Graph-APIs von Microsoft Entra ID verwalten.
Microsoft Entra ID Governance-Features wie Berechtigungsverwaltung, Zugriffsüberprüfungen und Lebenszyklusworkflows optimieren die Governance für Apps, die auf Gruppen basieren, die zuvor in AD verwaltet werden. Dadurch wird die Automatisierung eingeführt, die die Compliance während des gesamten Identitätslebenszyklus unterstützt.
Benutzer profitieren von einmaligem Anmelden sowohl in der Cloud als auch in lokalen Anwendungen, die moderne Zugriffssteuerungen wie risikobasierte Richtlinien für bedingten Zugriff verwenden. Nach der Migration können Mitarbeiter ihre Microsoft Entra-ID-Anmeldeinformationen wie phishingsichere, kennwortlose Methoden verwenden, um nahtlos auf ältere Intranetanwendungen zuzugreifen. Dies reduziert die Notwendigkeit, mehrere AD-Kennwörter zu verwalten und die Ausbreitung von Anmeldeinformationen zu verringern.

Roadmap zu Cloud Identity: Vom Hybrid- zum cloudorientierten Zustand / Minimierung der AD-Nutzung

Organisationen durchlaufen in der Regel unterschiedliche Phasen auf dem Weg zur Cloud, beginnend mit einem Hybridansatz , der aus der Verwendung von Cloud und lokalem AD in ihrer Umgebung besteht. Darauf folgt die Cloud-First Phase, in der Ressourcen zunehmend in die Cloud verschoben werden. Organisationen erreichen als nächsten Schritt den Zustand der AD-Minimierung. DIE SOA-Übertragung von Benutzern, Gruppen und Kontakten erleichtert diese Reise, indem die inkrementelle Migration von Identitäten zu Microsoft Entra ID ermöglicht wird. Anstatt AD auf einmal außer Betrieb zu setzen, was das Umschreiben oder Erneutes Plattformieren zahlreicher Anwendungen erfordern würde, ermöglicht SOA einen phasenweisen Ansatz. Mit diesem Ansatz können Organisationen geeignete Identitäten sofort in die Cloud migrieren und ihren AD-Speicherbedarf im Laufe der Zeit schrittweise reduzieren.

Hinweis

Beginnen Sie immer mit einem Anwendungsbestand, bevor Sie die SOA-Übertragung initiieren. Auf diese Weise können Sie den Zugriff für Benutzer verwalten, die mit älteren AD-Apps verknüpft sind.

Szenarien, die Sie entsperren können

Minimieren des AD-Speicherbedarfs für Benutzer und Gruppen, die in AD nicht mehr benötigt werden

Nach dem Übergang zu Clouddiensten und modernen Anwendungen werden bestimmte AD-Konten und -Gruppen möglicherweise veraltet. Heute werden diese Benutzer und Gruppen weiterhin in AD über herkömmliche Identitätsverwaltungslösungen wie MIM erstellt. Dies geschieht, da das manuelle Erstellen dieser Objekte in der Cloud ein intensiver manueller Aufwand ist. Wenn Sie mit der Entscheidung beginnen, für wen Sie SOA übertragen möchten, können Sie AD aus dem Bild für diese Benutzer und Gruppen entfernen. Auf diese Weise können Sie sie aus AD und Microsoft Entra entfernen oder wenn sie nur in Microsoft Entra benötigt werden, können sie ihre SOA übertragen lassen, bevor sie allein aus AD entfernt werden. Dieser gezielte Übergang ermöglicht Es Organisationen, die Migration zu automatisieren und den Fortschritt zu überwachen und gleichzeitig betriebsbedingte Unterbrechungen zu minimieren. Weitere Informationen finden Sie unter: Minimieren von AD-Benutzern und Verwalten des Benutzerlebenszyklus mit Microsoft Entra ID Governance.

Verschiebung der Lebenszyklusverwaltung in die Cloud

Sie können Microsoft Entra ID Governance verwenden, um lebenszyklus- und Zugriffsgovernance von SOA übertragenen Benutzern und Gruppen aus der Cloud zu ermöglichen. Für Benutzer bedeutet dies, dass Sie die Benutzer jetzt direkt in die Microsoft Entra-ID bereitstellen und die ID-Governance-Funktionen von Microsoft Entra verwenden können, um diese Benutzer zu steuern. Für Gruppen können Sie Ihre Gruppen modernisieren und die Zugriffssteuerung von Apps aktivieren, die mit ihnen über die Cloud verbunden sind. Hier gelten einige Einschränkungen, bei denen Gruppen, die Exchange-Konstrukte sind, wie z. B. Mail-Enabled Sicherheitsgruppen (MESGs) und Verteilerlisten (DLs) eine Modernisierung erfordern, bevor sie in der Cloud verwaltet werden. Weitere Informationen finden Sie in den Gruppen-SOA-Anleitungen.

Ist SOA die richtige Lösung für Sie?

Im folgenden Diagramm wird beschrieben, ob Sie bereit sind, die Autoritätsquelle (SOA) von Benutzern und Gruppen zu übertragen:

Überlegungen

Benutzer: SOA eignet sich für Benutzer, die keine Anwendungsabhängigkeiten haben, die mit AD DS verknüpft sind. Die Identifizierung, welche Benutzer bestimmten Anwendungen zugeordnet sind, ist für eine effektive Migrationsplanung von entscheidender Bedeutung.

Gruppen: Für Gruppen empfehlen wir, mit dem Verschieben von Sicherheitsgruppen in die Cloud zu beginnen. Sobald sie sich in der Cloud befinden, stellen Sie sie bei Bedarf aus Microsoft Entra ID wieder in AD bereit. Für Verteilerlisten (DLs) und Mail-Enabled Sicherheitsgruppen (MESGs) empfehlen wir, sie zu verschieben, sobald sich alle Exchange-Arbeitslasten in der Cloud befinden, und Sie benötigen keinen lokalen Exchange-Server mehr.

Application-Centric Ansatz: Modernisieren der lokalen Authentifizierung

In diesem Abschnitt wird eine zentrale Cloudmigrationsstrategie für AD-schwere Umgebungen beschrieben, die als anwendungsorientierter Ansatz bezeichnet werden. Dieser Ansatz ermöglicht lokalen Anwendungen die Verwendung der Microsoft Entra-ID für Identität. Dieser Abschnitt enthält auch detaillierte Schritte, Voraussetzungen und Anleitungen zur Bewältigung von Herausforderungen wie der Synchronisierung von Legacy-Anwendungskennworten. Der anwendungsorientierte Ansatz funktioniert für Kunden, die weit in ihrer kennwortlosen Reise vorangekommen sind. Für Apps, die ein Kennwort erfordern, gibt es derzeit keinen Pfad, um Benutzer in die Cloud zu verschieben.

Der anwendungsorientierte Ansatz befasst sich mit der Cloudmigration aus der Perspektive Ihrer Anwendungen. Bei diesem Ansatz versuchen Sie, die App-Authentifizierung zu modernisieren, indem Sie das folgende Framework anwenden:

Bestandsanwendungen: Auflisten aller lokalen Apps, die AD für die Authentifizierung verwenden (Kerberos/NTLM oder LDAP).
Integrationsziel: Konfigurieren Sie jede App neu, um die Microsoft Entra-ID für die Authentifizierung zu verwenden, wodurch die Abhängigkeit von lokalem AD reduziert wird.
Brückenlösungen: Verwenden Sie Microsoft Entra Application Proxy, Microsoft Entra Domain Services oder andere Clouddienste, um ältere Apps ohne wichtige Neuschreibungen mit Microsoft Entra ID zu verbinden.

Empfohlene Sequenz für anwendungsorientierte Migration

Es kann auch einige Apps geben, die bereits moderne Protokolle wie SAML/OIDC über Active Directory-Verbunddienst (AD FS) oder IdPs von Drittanbietern verwenden. Diese Apps sind einfacher direkt zu Microsoft Entra zu migrieren, während einige andere Legacy-Fälle wie hartcodierte NTLM-only-Apps spezielle Behandlung benötigen.

Anwendungsinventar- und Authentifizierungsanalyse

Es ist wichtig, alle lokalen Anwendungen vor der Planung der Migration zu ermitteln und zu kategorisieren . Ziel ist es, für jede App zu bestimmen: Wie authentifiziert sie benutzer derzeit und was ist der beste Weg, diese Authentifizierung mit Microsoft Entra ID zu integrieren oder zu modernisieren?

Checkliste, was in Bezug auf Anwendungsbesitzer und Telemetrie berücksichtigt werden muss, bevor die Autoritätsquelle übertragen wird.

Eine gründliche Anwendungsanalyse bildet die Grundlage für eine erfolgreiche Migration zur cloudbasierten Identitätsverwaltung in AD-schweren Umgebungen. Dieser Prozess umfasst eine methodische Bewertung jeder Anwendung, die von Active Directory für die Authentifizierung abhängt, die Bestimmung, wie die einzelnen Benutzer authentifiziert werden, und das Zuordnen eines Modernisierungs- oder Integrationsplans, der den individuellen Anforderungen jeder Anwendung entspricht. Die folgenden Schritte sind die empfohlene Sequenz für eine app-zentrierte Migration:

Schritt 1. Katalogisieren von Active Directory-integrierten Anwendungen

Starten Sie Ihre Migration, indem Sie alle Anwendungen identifizieren, die AD für die Authentifizierung oder Autorisierung verwenden. Verstehen Sie ihre Abhängigkeiten, um eine Umstellung auf die Cloudidentitätsverwaltung zu planen, und notieren Sie, welche AD-Gruppen und Benutzerkonten mit jeder Anwendung verbunden sind. Auf diese Weise können Sie priorisieren, welche Benutzer und Gruppen zuerst übergehen, insbesondere diejenigen, die mit geschäftskritischen Apps verknüpft sind.

Entdecken von Active Directory-integrierten Anwendungen

Verwenden Sie Tools wie Microsoft Entra Global Secure Access Application Discovery - und AD-Domänencontrollerprotokolle, um zu bestimmen, auf welche Apps Mitarbeiter zugreifen und wie diese Apps mit AD interagieren. Priorisieren Sie Anwendungen mit hoher Auslastung mithilfe von Dashboards, die nach Benutzeranzahl sortieren und nach einzelnen Benutzeraktivitäten filtern.

Zuordnen von Anwendungen zu AD-Sicherheitsgruppen

Identifizieren Sie für jede gefundene App die AD-Sicherheitsgruppen, die den Zugriff steuern. Arbeiten Sie mit Besitzern zusammen, oder überprüfen Sie Konfigurationen, um diese Gruppen auflisten zu können. Verwenden Sie Skripts oder AD-Abfragen, wenn dies erforderlich ist, um relevante Gruppen zu finden, insbesondere, wenn Gruppennamen oder Beschreibungen auf die App verweisen. Weitere Informationen zum Identifizieren von Sicherheitsgruppen finden Sie unter: Aufräumen nicht verwendeter Active Directory-Domänendienste-Gruppen in einer einzelnen Domäne.

Identifizieren von Benutzern für jede Anwendung

Bestimmen Sie Benutzer, indem Sie Gruppenmitgliedschaften für die AD-Gruppen jeder Anwendung extrahieren und tatsächliche Nutzungsdaten analysieren. Kombinieren Sie Mitgliedschaftslisten und Verwendungsprotokolle, um eine endgültige Liste der Benutzer für jede App zu erstellen. Verwenden Sie diese Informationen, um die Planung der Cloudmigration zu unterstützen, um sicherzustellen, dass der Zugriff während des gesamten Prozesses beibehalten wird.

Schritt 2. Ermitteln der Authentifizierungsmethode

Identifizieren Sie für jede Anwendung in Ihrem Bestand den von ihr verwendeten Authentifizierungsmechanismus. Dieser Schritt ist für die Auswahl der am besten geeigneten Migration oder Integrationsstrategie unerlässlich. Die wichtigsten Kategorien, die sie berücksichtigen sollten, sind:

Integrierte Windows-Authentifizierung (Kerberos/NTLM) – Häufig in IIS/.NET-Anwendungen mit Windows-Authentifizierung, Dateiservern, SharePoint und ähnlichen Plattformen. Diese ermöglichen es Benutzern in der Regel, sich mit Domänenanmeldeinformationen anzumelden, häufig ohne separate Eingabeaufforderung.
LDAP-Authentifizierung/Abfragen – Anwendungen können ÜBER LDAP-Servereinstellungen verfügen, die auf AD verweisen und Bindungen oder Nachschlagevorgänge, benutzerdefinierte oder Drittanbieterprodukte ausführen, die Benutzer zur Eingabe von AD-Anmeldeinformationen auffordern.
Verbund-/Moderne Authentifizierung – Einige Anwendungen werden bereits über AD FS verbunden oder unterstützen moderne Protokolle wie SAML oder OAuth. Diese können in der Regel so konfiguriert werden, dass microsoft Entra-ID mit minimalem Aufwand verwendet wird.
Andere Legacymethoden – umfasst Fälle, in denen Apps RADIUS für AD- oder lokale Konten verwenden. Obwohl nicht der primäre Fokus, sollten diese für Vollständigkeit dokumentiert werden. Weitere Informationen finden Sie unter : RADIUS-Authentifizierung mit Microsoft Entra ID.

Schritt 3. Bewertung der Durchführbarkeit der Modernisierung

Bewerten Sie die Fähigkeit jeder Anwendung, moderne Authentifizierungsprotokolle (SAML/OIDC) nativ zu übernehmen. Wenn ein Anbieterupdate verfügbar ist oder die App intern entwickelt wurde und neu codiert werden kann, ist der Übergang zur Microsoft Entra-ID als Identitätsanbieter in der Regel die beste langfristige Lösung. Dieser Ansatz entfernt AD-Abhängigkeiten und entsperrt die vollständigen Vorteile der Cloudidentitätsverwaltung. Planen Sie jedoch für ältere Anwendungen, die nicht einfach aktualisiert werden können, eine "Brücke"-Lösung, um sie in die Microsoft Entra-ID zu integrieren, auch wenn eine indirekte Integration erforderlich ist.

Einige ältere Anwendungen haben möglicherweise fest kodierte Annahmen über Active Directory, wie etwa die Erwartung, einen Benutzer in einer bestimmten Organisationseinheit zu finden oder Attribute in Active Directory einzutragen. Diese Apps sind außerhalb des Gültigkeitsbereichs für diese Art von Identitätsmigration. Diese Anwendungen werden nicht einfach von Microsoft Entra ID oder Microsoft Entra Domain Services unterstützt, es sei denn, Sie behalten dort Schreibberechtigungen bei, was möglich ist, aber dann haben Sie abweichende Daten. Stellen Sie sicher, ob eine App LDAP-Schreibvorgänge durchführt oder von obskuren AD-Features wie dynamische Hilfsklassen abhängt. Diese müssen möglicherweise auf AD verbleiben, bis sie ausgemustert werden. Der Fokus sollte auf Apps liegen, die über AD gelesen/authentifiziert werden, da diese wie beschrieben in die Cloudauthentifizierung verschoben werden können.

Schritt 4. Kategorisieren von Anwendungen und Planen des Integrationsansatzes

Nachdem Sie Authentifizierungsmethoden und Modernisierungs-Machbarkeit ermittelt haben, gruppieren Sie Anwendungen in verschiedene Kategorien, um Ihren Integrationsplan zu unterstützen:

Minimieren Sie die Anzahl der Apps, die Sie verwalten müssen: Für Apps, deren Einstellung mit einem Zieldatum geplant ist, können diese als nicht mehr relevant betrachtet werden, und die Verwaltung der Benutzer/Gruppen, die an diese Apps gebunden sind, kann in die Cloud verschoben werden. Konsolidieren Sie redundante Apps und bestimmen Sie, ob diese modernisiert werden können oder nicht.
Apps, die bereits moderne Authentifizierung nutzen oder dazu fähig sind: Diese können direkt zu Microsoft Entra ID als Identitätsanbieter migriert werden, z. B.: das Aktualisieren von AD FS-Anwendungen, um auf Microsoft Entra ID zu verweisen, oder Dateien in Azure-Dateifreigaben zu verschieben. Obwohl dies nicht der zentrale Schwerpunkt ist, trägt die Behandlung dieser Punkte dazu bei, die allgemeine Abhängigkeit von veralteten Systemen zu reduzieren. Die Verwaltung von Benutzern/Gruppen, die mit diesen Apps verbunden sind, fällt in den Geltungsbereich der Übertragung in die Cloud.
Kerberos/NTLM-Apps (nicht leicht zu modernisieren): Verwenden Sie Microsoft Entra als Front-End über einen Anwendungsproxy oder ähnliche Lösungen. Die Anwendung bleibt lokal, aber die Benutzerauthentifizierung wechselt zu Microsoft Entra ID-Token, die in Kerberos-Tickets in AD übersetzt werden.
LDAP-Binding Apps: Stellen Sie eine verwaltete AD-Instanz in Azure vor, insbesondere Microsoft Entra Domain Services, sodass diese Apps anstelle der lokalen Umgebung an eine cloudverwaltete AD-Instanz gebunden werden können.
Andere Sonderfälle: Für Anwendungen, die nicht geändert oder proxiiert werden können, z. B. ältere Clientserver-Apps, die auf AD-verbundene Computer beschränkt sind, sollten Sie sie auf VDI-Lösungen wie Azure Virtual Desktop, Windows 365 Cloud PC oder anderen hosten. Dadurch wird eine verwaltete Umgebung für diese Apps aufrechterhalten, während die Cloud-Migration an anderer Stelle ermöglicht wird. Dies sollte aufgrund zusätzlicher Komplexität und Kosten eine letzte Möglichkeit sein.
Nicht verbundene Apps: Für Apps, die geschäftliche Anforderungen haben, ohne Internetverbindung zu arbeiten oder in einer getrennten Umgebung zu arbeiten, müssen Sie lokal bleiben. Benutzer, die diese Apps verwenden, sind nicht berechtigt, SOA zu übertragen.

Schritt 5. Kartierung und Planung

Wenn Sie die Analysephase abschließen, sollten Sie eine klare Zuordnung haben, welche Anwendungen in die "Kerberos-Kategorie", "LDAP-Kategorie" oder andere Buckets fallen, zusammen mit dem jeweiligen Integrationsmechanismus. Dieser Planungsschritt ist von entscheidender Bedeutung, da jede Anwendung über einzigartige Merkmale verfügt, die sorgfältig berücksichtigt werden müssen, bevor Sie eine Migrationsstrategie auswählen. Microsoft Entra ID bietet glücklicherweise Lösungen für die meisten AD-basierten Authentifizierungsmuster, und sogar ältere Anwendungen, die nicht geändert werden können, können von sicherem Hybridzugriff und moderner Governance profitieren.

Schritt 6. Migrieren von Gruppen in die Cloud

Bei einem App-zentrierten Ansatz empfiehlt es sich, Zuerst Sicherheitsgruppen und App-Zugriffssteuerungen in die Cloud zu migrieren. Dies ermöglicht die zentrale Zugriffsverwaltung und stellt sicher, dass Gruppenmitgliedschaften erhalten bleiben, bevor Benutzer verschoben werden. Microsoft empfiehlt, die SOA der Gruppe vor den Benutzern zu übertragen, um die Mitgliedschaftsintegrität aufrechtzuerhalten und Tests zuzulassen. Sie können auch die Reihenfolge für jede App anpassen, z. B. indem Sie eine Anwendung in einer Pilotphase mit den zugehörigen Benutzergruppen und Endanwendern Ende-zu-Ende testen. Bei der Umstellung auf die Cloud haben wir spezifische Anleitungen dazu skizziert, wie Sie sie Cloudgruppen zuordnen können, wie in "Leitfaden für die Verwendung der Gruppenquelle der Autorität (GROUP Source of Authority, SOA) in Microsoft Entra ID beschrieben" , oder sehen Sie sich das folgende Video an:

Tipp

Migrieren Sie Zuerst Sicherheitsgruppen in die Cloud. Auf diese Weise können Sie App-Zugriffssteuerelemente testen, bevor Sie den Benutzer verschieben.

Schritt 7. Bearbeitung von LDAP-basierten Anwendungen (Directory-Bound Anwendungen)

LDAP-gebundene Anwendungen oder Dienste fragen Active Directory Domain Services (AD DS) direkt über LDAP ab, am häufigsten für die Authentifizierung mithilfe einer einfachen Bindung mit Benutzername und Kennwort oder für Verzeichnislesevorgänge. Häufige Beispiele sind ältere Unternehmensanwendungen, Netzwerkgeräte oder benutzerdefinierte Apps, die auf LDAP-Bindungen basieren, um Anmeldeinformationen zu überprüfen. Diese Anwendungen erfordern in der Regel einen LDAP-Server und können nicht einfach zu modernen Authentifizierungsprotokollen wechseln. Weitere Informationen finden Sie unter : LDAP-Authentifizierung mit Microsoft Entra ID.

Empfohlene Lösung: Microsoft Entra Domain Services

Die empfohlene Lösung für die Unterstützung von LDAP-gebundenen Apps in der Cloud ist Microsoft Entra Domain Services. In Azure gehostet, bietet Microsoft Entra Domain Services LDAP-, Kerberos- und NTLM-Endpunkte, das Synchronisieren von Benutzerkonten und Anmeldeinformationen von Ihrem Microsoft Entra ID-Mandanten. Auf diese Weise können Legacyanwendungen cloudgehostete AD für die Authentifizierung verwenden, ohne zu modernen Protokollen zu wechseln. Die verwaltete Domäne unterstützt hauptsächlich Lese- und Authentifizierung für LDAP-Clients. Weitere Informationen finden Sie unter: Was ist Microsoft Entra Domain Services?

Schritt 8: Verwaltung von Kerberos-basierten Anwendungen (Windows-Integrierte Authentifizierung)

Kerberos-basierte Apps umfassen in der Regel interne Webanwendungen mit Windows-Authentifizierung, Dateiservern (SMB), die auf Kerberos-Tickets basieren, und andere Dienste, bei denen die Anmeldung von Active Directory (AD) erforderlich ist. Microsoft bietet Vermittlerlösungen für die Integration dieser Anwendungen in die Microsoft Entra-ID.

Microsoft Entra-Anwendungsproxy oder privater Zugriff mit eingeschränkter Kerberos-Delegierung (KCD):

Empfohlene Lösung:

Microsoft Entra-Anwendungsproxy oder privater Zugriff mit eingeschränkter Kerberos-Delegierung (KCD): Dieser Clouddienst ermöglicht die Veröffentlichung einer lokalen Webanwendung über die Microsoft Entra-ID. Benutzer authentifizieren sich bei Microsoft Entra ID, z. B. mit OAuth/OpenID Connect, und der lokale Anwendungsproxy-Connector erhält ein Kerberos-Ticket für die Backend-Anwendung für den Benutzer mithilfe von KCD. Microsoft Entra ID dient als Authentifizierungsgateway und übersetzt die Authentifizierung der Anwendung in Kerberos. Diese Lösung unterstützt webbasierte Anwendungen (HTTP/HTTPS) und kann einmaliges Anmelden (Single Sign-On, SSO) für in der Cloud verwaltete Benutzer bereitstellen, sofern diese Benutzer über ein Konto in AD verfügen. Weitere Informationen finden Sie unter: Microsoft Entra Application Proxy und Microsoft Entra Private Access
Kennwortlos mit Cloud Kerberos Trust: Mit dieser Methode kann Microsoft Entra ID Kerberos-Tickets für lokale AD-Ressourcen ausgeben, wenn Benutzer sich mit Microsoft Entra-ID-Anmeldeinformationen mit kennwortloser Authentifizierung wie Windows Hello for Business und FIDO2 anmelden. Sie erfordert die Konfiguration der AD-Domäne, um dem Cloud Kerberos-Dienst der Microsoft Entra-ID zu vertrauen und sicherzustellen, dass die AD-Objekte der Benutzer über die erforderlichen Schlüssel verfügen. Der Prozess ist vollständig kennwortfrei und eignet sich ideal für Cloudbenutzer für den Zugriff auf lokale Ressourcen. Weitere Informationen finden Sie unter Cloud Kerberos Trust.

Wichtige Überlegungen vor der Migration von Kerberos-Workloads

Im Folgenden finden Sie wichtige Überlegungen für Kerberos-Anwendungen vor dem Verschieben von Benutzer- und Gruppenarbeitslasten, die diesen Apps zugeordnet sind:

Verwaltung des Benutzerlebenszyklus: Auch nachdem Sie einen Benutzer zur Cloudverwaltung umgestellt haben, muss ein AD-Konto mit übereinstimmenden UserPrincipalName für die Kerberos-Funktionalität verbleiben.
Authentifizierung und Attribute: Migrieren Sie keine Benutzer, die Zugriff auf Anwendungen benötigen, die auf Kennwörtern zur Authentifizierung angewiesen sind, und können nicht aktualisiert werden, um die Kerberos-Authentifizierung zu verwenden. Anwendungen, die Kerberos-Authentifizierungs- und Abfrageattribute aus Active Directory unterstützen können, erfordern, dass diese Attribute synchronisiert sind, wobei möglicherweise ein doppelter Schreibzugriff auf Microsoft Entra ID und Active Directory verwendet wird.
In Microsoft Entra ID eingebundene Geräte: Bei true Single Sign-On sollten Geräte, die auf Kerberos-Ressourcen zugreifen, Microsoft Entra ID-eingebunden oder hybrid eingebunden sein. Wenn sich ein Benutzer mit Microsoft Entra-ID-Anmeldeinformationen bei einem Gerät anmeldet, kann das Gerät ein Token von Microsoft Entra ID abrufen, das per Vertrauensstellung oder Konnektor in ein Kerberos-Ticket umgewandelt wird. Wenn ein Gerät nur einer Domäne beigetreten ist und der Benutzer in der Cloud verwaltet wird, kann nahtloses SSO schwierig sein, was möglicherweise eine manuelle Eingabe von Anmeldeinformationen erfordert. Microsoft empfiehlt, Geräte als Teil der Cloudtransformation zur Microsoft Entra ID-Verknüpfung mit Cloud-Vertrauen zu migrieren, sodass das Vertrauensverhältnis zwischen Benutzern und Geräten ausgerichtet ist.

Hinweis

Die Gerätemigration liegt außerhalb des aktuellen Bereichs für die Übertragung von SOA.
Bedingter Zugriff für lokale Apps: Sobald App-Proxy oder Microsoft Entra Private Access für eine Anwendung bereitgestellt wurde, können Richtlinien für bedingten Zugriff wie MFA für den Anwendungszugriff erzwungen werden, da die Authentifizierung über die Microsoft Entra-ID erfolgt. Dadurch wird die Sicherheit verbessert, da sogar ältere Apps ohne Änderung von Zero Trust-Bedingungen profitieren. Für Kerberos-Vertrauensszenarien gilt der bedingte Zugriff, wenn sich der Benutzer anfänglich bei Microsoft Entra-ID auf dem Gerät authentifiziert.

Schritt 9 Überprüfen und Optimieren

Testen Sie jede integrierte Anwendung gründlich. Stellen Sie sicher, dass vorhandene AD-bezogene Benutzer über die neue Methode auf die Anwendung zugreifen können. Überprüfen Sie, ob Gruppenmitgliedschaften aus der Microsoft Entra ID beim Bereitstellen der Gruppen zu Active Directory korrekt berücksichtigt werden. Überwachen Sie die Leistung und die Anmeldeprotokolle. Optimieren Sie alle Einstellungen für die Produktionsverwendung.

Stellen Sie sicher, dass alle Benutzer, deren Autoritätsquelle übertragen wurde, weiterhin auf die Anwendung zugreifen können. Stellen Sie sicher, dass Gruppenmitgliedschaften, die in AD vorhanden waren, auch in der Microsoft Entra-ID vorhanden sind. Überprüfen Sie mithilfe von Gruppenprotokollen und Benutzerprotokollen , ob die Autoritätsquelle erfolgreich übertragen wurde.

Conclusion

Die folgende Tabelle enthält eine Zusammenfassung der Optionen für die Behandlung lokaler Apps in einem Cloud-first-Modell:

App-Typ	Cloudintegrationsmethode & Tools	Anforderungen und Überlegungen
Kerberos-basierte Apps (Integrierte Windows-Authentifizierung, Intranet-Webanwendungen, Freigeben von Dateien)	Microsoft Entra ID-Anwendungsproxy mit Kerberos (KCD): Veröffentlichen Sie lokale Web-Apps mithilfe der Microsoft Entra-ID und verwenden Sie ein Verbindungselement für Kerberos vor Ort. Microsoft Entra ID Cloud Kerberos Trust: Für Geräte, die mit Microsoft Entra ID verbunden sind (nicht webbasiert, z. B. Dateifreigaben).	Anforderungen: – Microsoft Entra Private Access ist lokal installiert – Konfigurierte SPN- und Delegierungsrechte - Entra-ID-P1/P2- oder Suite-Lizenzen - AD-Konto für Benutzer (synchronisiert oder bereitgestellt) Considerations: – Bietet nahtlose SSO mithilfe von Entra-ID-Anmeldeinformationen oder nutzt eine kennwortlose Anmeldung für Kerberos-basierte Apps und verwendet eine phishing-resistente Methode, um auf lokale Ressourcen zuzugreifen und diese zu sichern.
LDAP-basierte Apps (Apps, die eine Bindung an AD DS über LDAP für Authentifizierung/Abfragen durchführen)	Entra ID Domain Services (Managed AD): In der Cloud gehostete AD-Domäne mit Microsoft-ID synchronisiert; die LDAP-Verbindung der App zu dieser Domäne (LDAPS) neu anpointen.	Anforderungen: – Einrichten der Microsoft Entra Domain Services-Instanz in Azure – Konfigurieren des virtuellen Netzwerks, sicheres LDAP-Zertifikat, Firewallregeln – Benutzer/Gruppen müssen sich in der Microsoft Entra-ID befinden (mit Microsoft Entra Domain Services synchronisiert) – Möglicherweise ist eine Zurücksetzung des Passworts erforderlich, um Hashes zu generieren. Considerations: – Minimale App-Änderungen (nur neuer LDAP-Endpunkt) – Die Kennwörter von Cloudbenutzern, die in Microsoft Entra ID DS vorhanden sind – Wenn Microsoft Entra Domain Services nicht machbar ist, besteht die Fallback-Option darin, Benutzer in die lokale AD zu provisionieren und die Kennwortparität manuell zu verwalten.

SOA Transfer Checkliste für IT-Architekten

Strategische Vorteile verstehen

Verringern Sie Sicherheitsrisiken, indem Sie die lokale AD-Abhängigkeit minimieren.
Aktivieren sie moderne Identitätsfeatures (bedingter Zugriff, kennwortloses Kennwort, Zero Trust).
Optimieren Sie die Identitätsverwaltung und -governance in der Microsoft Entra-ID.

Bereitschaft bewerten

Inventarisieren Sie alle Benutzer, Gruppen und Anwendungen.
Identifizieren Sie Benutzer/Gruppen, die nicht mehr an AD-abhängige Apps gebunden sind.
Zuordnen von Authentifizierungsabhängigkeiten für jede Anwendung (Kerberos, LDAP, SAML/OIDC).

Gruppenmigration planen

Sicherheitsgruppen in die Cloud verschieben; stellen Sie bei Bedarf von Microsoft Entra-ID zurück zu AD bereit.
Verschieben Sie DLs und MESGs erst, nachdem die Exchange-Workloads vollständig in die Cloud verlagert wurden.

Modernisieren der Anwendungsauthentifizierung

Für Kerberos-/NTLM-Apps:
Cloud Kerberos Trust
Für LDAP-Apps:
LDAP-Übersicht
Für moderne/Verbund-Apps:
Konfigurieren Sie die Authentifizierung direkt mit microsoft Entra ID (SAML/OIDC) neu.

Kennwortlose Authentifizierung aktivieren

Bereitstellen von Hello for Business
Integrieren Sie sich mit Cloud Kerberos-Vertrauensstellung, um eine nahtlose ticketbasierte Authentifizierung zu ermöglichen.

Implementieren von Entra ID Governance

Adressschlüsselbeschränkungen

Kein Kennwortrückschreiben für reine Cloudbenutzer. Behalten Sie das Hybridverzeichnis bei, wenn Sie einen Rückschreibvorgang benötigen
Ältere Apps mit hartcodierten AD-Abhängigkeiten erfordern möglicherweise benutzerdefinierte Proxys oder bleiben lokal.

Überwachen und Iterieren

Nachverfolgen des Migrationsfortschritts: Benutzer/Gruppen konvertiert, Apps modernisiert.
Überprüfen Sie kontinuierlich den Sicherheitsstatus und die Compliance.