Übergang in die Cloud

  • Artikel

Nachdem Sie Ihre Organisation auf das anhaltende Wachstum des Active Directory-Fußabdrucks ausgerichtet haben, können Sie sich auf das Verschieben der vorhandenen lokalen Workloads nach Microsoft Entra ID konzentrieren. In diesem Artikel werden die verschiedenen Migrationsarbeitsstreams beschrieben. Sie können die Arbeitsstreams in diesem Artikel je nach Ihren Prioritäten und Ressourcen ausführen.

Ein typischer Migrationsarbeitsstream umfasst die folgenden Phasen:

  • Entdecken: Ermitteln Sie, was Ihre Umgebung derzeit umfasst.

  • Pilot: Stellen Sie neue Cloudfunktionen für eine kleine Teilmenge (von Benutzern, Anwendungen oder Geräten, je nach Arbeitsstream).

  • Aufskalieren: Erweitern Sie das Pilotprojekt, um den Übergang einer Funktion in die Cloud abzuschließen.

  • Übernehmen (falls zutreffend): Beenden Sie die Verwendung der alten lokalen Workload.

Benutzer und Gruppen

Aktivieren des Self-Service für Kennwörter

Wir empfehlen eine kennwortlose Umgebung. Bis dahin können Sie die Self-Service-Workflows zum Migrieren von Kennwörtern von lokalen Systemen zu Microsoft Entra ID migrieren, um Ihre Umgebung zu vereinfachen. Mit der Self-Service-Kennwortzurücksetzung (SSPR) von Microsoft Entra können Benutzer*innen ihr Kennwort ohne Beteiligung von Administrator*innen oder des Helpdesks ändern oder zurücksetzen.

Um Self-Service-Funktionen zu aktivieren, wählen Sie die entsprechenden Authentifizierungsmethoden für Ihre Organisation aus. Nachdem die Authentifizierungsmethoden aktualisiert wurden, können Sie die Möglichkeit der Self-Service-Kennwortfunktionen für Benutzer in Ihrer Microsoft Entra-Authentifizierungsumgebung aktivieren. Anleitungen zur Bereitstellung finden Sie unter Überlegungen zur Bereitstellung der Self-Service-Kennwortzurücksetzung von Microsoft Entra.

Zusätzliche Überlegungen:

Hinweis

Verschieben der Verwaltung von Gruppen

So transformieren Sie Gruppen und Verteilerlisten

Verschieben der Bereitstellung von Benutzern und Gruppen in Anwendungen

Sie können Ihre Umgebung vereinfachen, indem Sie Anwendungsbereitstellungsflüsse aus lokalen IDM-Systemen für die Identitätsverwaltung wie Microsoft Identity Manager entfernen. Basierend auf Ihrer Anwendungsermittlung kategorisieren Sie Ihre Anwendung anhand der folgenden Merkmale:

  • Anwendungen in Ihrer Umgebung, die über eine Bereitstellungsintegration mit dem Microsoft Entra-Anwendungskatalog verfügen.

  • Anwendungen, die sich im Katalog befinden, aber das SCIM 2.0-Protokoll unterstützen. Diese Anwendungen sind nativ kompatibel mit dem Microsoft Entra-Cloudbereitstellungsdienst.

  • Lokale Anwendungen, für die ein ECMA-Connector verfügbar ist. Diese Anwendungen können in die lokale Microsoft Entra-Anwendungsbereitstellung integriert werden.

Weitere Informationen finden Sie unter: Planen einer automatischen Benutzerbereitstellung für Microsoft Entra ID.

Wechsel zur HR-Cloudbereitstellung

Sie können den lokalen Fußabdruck verringern, indem Sie die Workflows für die HR-Bereitstellung von lokalen (IDM) wie Microsoft Identity Manager nach Microsoft Entra ID verlagern. Für die HR-Cloudbereitstellung von Microsoft Entra sind zwei Kontotypen verfügbar:

  • Für neue Mitarbeiter, die ausschließlich Anwendungen verwenden, die Microsoft Entra ID nutzen, können Sie sich für die Bereitstellung von reinen Cloudkonten entscheiden. Diese Bereitstellung wiederum hilft, den Fußabdruck von Active Directory zu begrenzen.

  • Für neue Mitarbeiter, die Zugriff auf Anwendungen benötigen, die von Active Directory abhängig sind, können Sie Hybridkonten bereitstellen.

Die HR-Cloudbereitstellung von Microsoft Entra kann auch Active Directory-Konten für bestehende Mitarbeiter verwalten. Weitere Informationen finden Sie unter: Planen der HR-Cloudanwendung für die Microsoft Entra-Benutzerbereitstellung und Planen des Bereitstellungsprojekts.

Verschieben von Lebenszyklus-Workflows

Bewerten Sie Ihre vorhandenen Joiner/Mover/Leaver-Workflows und -Prozesse auf Anwendbarkeit und Relevanz für Ihre Microsoft Entra-Cloudumgebung. Anschließend können Sie diese Workflows vereinfachen und mithilfe von Lebenszyklus-Workflowsneue erstellen.

Verschieben der externen Identitätsverwaltung

Wenn Ihr Unternehmen Konten in Active Directory oder anderen lokalen Verzeichnissen für externe Identitäten wie Anbieter, Auftragnehmer, Berater bereitstellt, können Sie diese Benutzerobjekte nativ in der Cloud verwalten. Sie können Ihre Umgebung vereinfachen, indem Sie diese Benutzerobjekte von Drittanbietern nativ in der Cloud verwalten. Einige mögliche Ursachen:

  • Verwenden Sie für neue externe Benutzer*innen Microsoft Entra External ID, sodass kein Active Directory-Fußabdruck für Benutzer*innen entsteht.

  • Bei bestehenden Active Directory-Konten, die Sie für externe Identitäten bereitstellen, können Sie den Aufwand für die Verwaltung lokaler Anmeldeinformationen (z. B. Kennwörter) entfernen, indem Sie sie für die B2B-Zusammenarbeit konfigurieren. Führen Sie die Schritte in Einladen von internen Benutzern zur B2B-Zusammenarbeit aus.

  • Verwenden Sie die Microsoft Entra-Berechtigungsverwaltung, um Zugriff auf Anwendungen und Ressourcen zu gewähren. Die meisten Unternehmen verfügen über dedizierte Systeme und Workflows für diesen Zweck, die Sie jetzt mit lokalen Tools auslagern können.

  • Verwenden Sie Zugriffsüberprüfungen, um Zugriffsrechte und/oder externe Identitäten zu entfernen, die nicht mehr benötigt werden.

Geräte

Verschieben von Nicht-Windows-Arbeitsstationen

Sie können Nicht-Windows-Arbeitsstationen in Microsoft Entra ID integrieren, um die Benutzererfahrung zu verbessern und von cloudbasierten Sicherheitsfeatures wie dem bedingten Zugriff zu profitieren.

Ersetzen anderer Windows-Versionen für Arbeitsstation

Bei den folgenden Betriebssystemen für Arbeitsstationen sollten Sie ein Upgrade auf die neuesten Versionen durchführen, um von der cloudnativen Verwaltung zu profitieren (Microsoft Entra-Verknüpfung und einheitliche Endpunktverwaltung):

  • Windows 7 oder 8.x

  • Windows Server

VDI-Lösung

Dieses Projekt umfasst zwei primäre Initiativen:

  • Neue Bereitstellungen: Stellen Sie eine cloudverwaltete VDI-Lösung (Virtual Desktop Infrastructure) bereit, z. B. Windows 365 oder Azure Virtual Desktop, für die kein lokales Active Directory erforderlich ist.

  • Vorhandene Bereitstellungen: Wenn Ihre bestehende VDI-Bereitstellung von Active Directory abhängig ist, verwenden Sie Unternehmensziele, um zu entscheiden, ob Sie die Lösung beibehalten oder zu Microsoft Entra ID migrieren.

Weitere Informationen finden Sie unter:

Anwendungen

Um eine sichere Umgebung sicherzustellen, unterstützt Microsoft Entra ID moderne Authentifizierungsprotokolle. Sie müssen wie folgt vorgehen, um bei der Authentifizierung von Anwendungen von Active Directory zu Microsoft Entra ID zu wechseln:

  • Ermitteln Sie, welche Anwendungen ohne Änderungen zu Microsoft Entra ID migriert werden können.

  • Ermitteln Sie, welche Anwendungen über einen Upgradepfad verfügen, der Ihnen eine Migration mit einem Upgrade ermöglicht.

  • Ermitteln Sie, welche Anwendungen ersetzt werden müssen oder erhebliche Codeänderungen erfordern, um sie zu migrieren.

Das Ergebnis Ihrer Initiative zur Anwendungsermittlung ist die Erstellung einer Prioritätenliste für die Migration Ihres Anwendungsportfolios. Die Liste enthält Anwendungen, für die Folgendes gilt:

  • Sie benötigen ein Upgrade oder ein Update für die Software, und es gibt einen Upgradepfad.

  • Sie benötigen ein Upgrade oder ein Update für die Software, es gibt aber keinen Upgradepfad.

Anhand dieser Liste können Sie die Anwendungen, für die es keinen Upgradepfad gibt, weiter auswerten. Ermitteln Sie, ob der Geschäftswert eine Aktualisierung der Software rechtfertigt oder ob sie außer Betrieb gesetzt werden sollte. Wenn die Software eingestellt werden soll, müssen Sie entscheiden, ob ein Ersatz benötigt wird.

Auf der Grundlage der Ergebnisse können Sie Aspekte Ihrer Transformation von Active Directory zu Microsoft Entra ID umgestalten. Es gibt Ansätze, mit denen Sie ein lokales Active Directory für Anwendungen mit nicht unterstützten Authentifizierungsprotokollen in eine Azure IaaS (Infrastructure-as-a-Service) erweitern können (Lift & Shift). Es wird empfohlen, eine Richtlinie festzulegen, die die Verwendung dieses Ansatzes nur in Ausnahmefällen zulässt.

Anwendungsermittlung

Nachdem Sie Ihr App-Portfolio segmentiert haben, können Sie die Migration auf der Grundlage des Geschäftswerts und der geschäftlichen Priorität priorisieren. Zum Erstellen oder Aktualisieren Ihres App-Inventars können Sie Tools verwenden.

Es gibt drei Hauptmöglichkeiten zum Kategorisieren von Apps:

  • Apps mit moderner Authentifizierung: Diese Anwendungen verwenden moderne Authentifizierungsprotokolle (z. B. OIDC, OAuth2, SAML oder WS-Federation) oder einen Verbunddienst wie Active Directory-Verbunddienste (AD FS).

  • WAM-Tools (Web Access Management): Diese Anwendungen verwenden Header, Cookies und ähnliche Techniken für einmaliges Anmelden (SSO). Diese Apps erfordern in der Regel einen WAM-Identitätsanbieter wie Symantec SiteMinder.

  • Legacy-Apps: Diese Anwendungen verwenden Legacyprotokolle wie Kerberos, LDAP, Radius, Remotedesktop und NTLM (nicht empfohlen).

Microsoft Entra ID kann mit jeder Art von Anwendung verwendet werden, um Funktionalitätsebenen bereitzustellen, was zu unterschiedlichen Migrationsstrategien, Komplexität und Kompromissen führt. Einige Unternehmen verfügen über ein Anwendungsinventar, das als Grundlage für die Ermittlung verwendet werden kann. (Häufig ist dieses Inventar nicht vollständig oder auf dem aktuellen Stand.)

So entdecken Sie moderne Authentifizierungs-Apps

  • Wenn Sie AD FS verwenden, verwenden Sie den AD FS-Anwendungsaktivitätsbericht.

  • Wenn Sie einen anderen Identitätsanbieter verwenden, verwenden Sie die Protokolle und die Konfiguration.

Die folgenden Tools können Ihnen helfen, Anwendungen zu entdecken, die LDAP verwenden:

  • Event1644Reader: Beispiel für ein Tool zur Sammlung von Daten über LDAP-Abfragen, die mithilfe von Field Engineering Logs an Domänencontroller gestellt wurden.

  • Microsoft 365 Defender für Identität: Sicherheitslösung, die eine Überwachungsfunktion für Anmeldevorgänge verwendet. (Beachten Sie, dass Bindungen mit LDAP, nicht mit Secure LDAP erfasst werden.)

  • PSLDAPQueryLogging: GitHub-Tool für die Berichterstellung über LDAP-Abfragen.

Migrieren von AD FS oder anderen Verbunddiensten

Wenn Sie die Migration zu Microsoft Entra ID planen, empfiehlt es sich, zunächst die Apps zu migrieren, die moderne Authentifizierungsprotokolle (SAML und OpenID Connect) verwenden. Sie können diese Apps für die Authentifizierung mit Microsoft Entra ID entweder über einen integrierten Connector aus dem Azure App-Katalog oder durch Registrieren in Microsoft Entra ID neu konfigurieren.

Nachdem Sie SaaS-Anwendungen, die in Microsoft Entra ID vereint wurden, verschoben haben, sind einige Schritte erforderlich, um das lokale Verbundsystem außer Betrieb zu setzen:

Wichtig

Überprüfen Sie bei Verwendung anderer Features, ob diese Dienste verlagert werden, bevor Sie die Active Directory-Verbunddienste außer Betrieb nehmen.

Verschieben von WAM-Authentifizierungs-Apps

Dieses Projekt konzentriert sich auf die Migration der SSO-Funktionalität von WAM-Systemen nach Microsoft Entra ID. Weitere Informationen finden Sie unter Migrieren von Anwendungen von Symantec SiteMinder zu Microsoft Entra ID.

Definieren der Strategie für die Anwendungsserververwaltung

Was die Verwaltung der Infrastruktur betrifft, so verwenden lokale Umgebungen häufig eine Kombination aus Gruppenrichtlinienobjekten (GPOs) und Features von Microsoft Configuration Manager, um die Verwaltungsaufgaben aufzuteilen. Aufgaben können beispielsweise in Sicherheitsrichtlinienverwaltung, Updateverwaltung, Konfigurationsverwaltung und Überwachung segmentiert werden.

Active Directory ist für lokale IT-Umgebungen vorgesehen, Microsoft Entra ID ist für cloudbasierte IT-Umgebungen. Es gibt keine 1:1-Parität von Features, sodass Sie verschiedene Möglichkeiten haben, um Anwendungsserver zu verwalten.

Azure Arc hilft beispielsweise dabei, viele der in Active Directory vorhandenen Features in einer einzigen Ansicht zusammenzubringen, wenn Sie Microsoft Entra ID für die Identitäts- und Zugriffsverwaltung (IAM) verwenden. Sie können auch Microsoft Entra-Domänenservices verwenden, um Domänenbeitrittsserver in Microsoft Entra ID zu verwenden, insbesondere, wenn diese Server Gruppenrichtlinienobjekte aus bestimmten geschäftlichen oder technischen Gründen verwenden sollen.

Verwenden Sie die folgende Tabelle, um zu bestimmen, welche Azure-basierten Tools Sie verwenden können, um die lokale Umgebung zu ersetzen:

Verwaltungsbereich Lokales (Active Directory)-Feature Gleichwertige Microsoft Entra-Funktion
Sicherheitsrichtlinienverwaltung GPO, Microsoft Configuration Manager Microsoft 365 Defender for Cloud
Updateverwaltung Microsoft Configuration Manager, Windows Server Update Services Azure Automation-Updateverwaltung
Konfigurationsverwaltung GPO, Microsoft Configuration Manager Azure Automation State Configuration
Überwachung System Center Operations Manager Azure Monitor Log Analytics

Hier finden Sie weitere Informationen, die Sie für die Verwaltung von Anwendungsservern verwenden können:

Wenn Sie Anwendungsserver mit Microsoft Configuration Manager verwalten müssen, können Sie diese Anforderung nicht mit Microsoft Entra Domain Services erfüllen. Die Ausführung von Microsoft Configuration Manager in einer Microsoft Entra Domain Services-Umgebung wird nicht unterstützt. Stattdessen müssen Sie Ihre lokale Active Directory-Instanz auf einen Domänencontroller erweitern, der auf einer Azure-VM ausgeführt wird, oder eine neue Active Directory-Instanz in einem virtuellen Azure IaaS-Netzwerk bereitstellen.

Definieren der Migrationsstrategie für Legacy-Anwendungen

Legacy-Anwendungen weisen Abhängigkeiten wie die folgenden zu Active Directory auf:

  • Benutzerauthentifizierung und Autorisierung: Kerberos, NTLM, LDAP-Bindung, ACLs.

  • Zugriff auf Verzeichnisdaten: LDAP-Abfragen, Schemaerweiterungen, Lese-/Schreibzugriff von Verzeichnisobjekten.

  • Serververwaltung: Wie durch die Serververwaltungsstrategie bestimmt.

Um diese Abhängigkeiten zu reduzieren oder zu beseitigen, gibt es drei Hauptansätze.

Ansatz 1

Bei diesem Ansatz, den Sie vorzugsweise verwenden sollten, führen Sie Projekte zur Migration von Legacy-Anwendungen zu SaaS-Alternativen durch, die eine moderne Authentifizierung verwenden. Lassen Sie die SaaS-Alternativen direkt bei Microsoft Entra ID authentifizieren:

  1. Stellen Sie Microsoft Entra Domain Services in einem virtuellen Azure-Netzwerk bereit, und erweitern Sie das Schema, um zusätzliche Attribute zu integrieren, die von den Anwendungen benötigt werden.

  2. Migrieren Sie Legacy-Apps per Lift & Shift auf VMs im virtuellen Azure-Netzwerk, die in eine Domäne in Microsoft Entra Domain Services eingebunden sind.

  3. Veröffentlichen Sie Legacy-Apps in der Cloud mit dem Microsoft Entra-Anwendungsproxy oder einem Partner für den sicheren Hybridzugriff.

  4. Wenn Legacy-Apps durch Abgang außer Betrieb genommen werden, setzen Sie die Microsoft Entra Domain Services, die im virtuellen Azure-Netzwerk ausgeführt werden, schließlich außer Betrieb.

Hinweis

Ansatz 2

Wenn der erste Ansatz nicht möglich ist und eine Anwendung eine starke Abhängigkeit von Active Directory aufweist, können Sie das lokale Active Directory auf Azure IaaS erweitern.

Sie können die Plattform wechseln, um modernes serverloses Hosting zu unterstützen, z. B. Platform-as-a-Service (PaaS). Alternativ können Sie den Code so aktualisieren, dass die moderne Authentifizierung unterstützt wird. Sie können die App auch so gestalten, dass sie direkt in Microsoft Entra ID integriert werden kann. Erfahren Sie mehr über die Microsoft-Authentifizierungsbibliothek in Microsoft Identity Platform.

  1. Verbinden Sie ein virtuelles Azure-Netzwerk über virtuelles privates Netzwerk (VPN) oder Azure ExpressRoute mit dem lokalen Netzwerk.

  2. Stellen Sie neue Domänencontroller für die lokale Active Directory-Instanz als virtuelle Computer im virtuellen Azure-Netzwerk bereit.

  3. Migrieren Sie Legacy-Apps per Lift & Shift auf VMs im virtuellen Azure-Netzwerk, die in eine Domäne eingebunden sind.

  4. Veröffentlichen Sie Legacy-Apps in der Cloud mit dem Microsoft Entra-Anwendungsproxy oder einem Partner für den sicheren Hybridzugriff.

  5. Setzen Sie schließlich die lokale Active Directory-Infrastruktur außer Betrieb, und führen Sie Active Directory vollständig im virtuellen Azure-Netzwerk aus.

  6. Wenn Legacy-Apps durch Abgang außer Betrieb genommen werden, setzen Sie die Active Directory-Instanz, die im virtuellen Azure-Netzwerk ausgeführt wird, schließlich außer Betrieb.

Ansatz 3

Wenn die erste Migration nicht möglich ist und eine Anwendung eine starke Abhängigkeit von Active Directory aufweist, können Sie eine neue Active Directory-Instanz in Azure IaaS bereitstellen. Belassen Sie die Anwendungen für die absehbare Zukunft als Legacy-Anwendungen oder stellen Sie sie ein, wenn sich dazu eine Gelegenheit ergibt.

Dieser Ansatz ermöglicht es Ihnen, die App von der vorhandenen Active Directory-Instanz zu entkoppeln, um die Oberfläche zu reduzieren. Es wird empfohlen, dies nur als letztes Mittel in Betracht zu ziehen.

  1. Stellen Sie eine neue Active Directory-Instanz als virtuelle Computer in einem virtuellen Azure-Netzwerk bereit.

  2. Migrieren Sie Legacy-Apps per Lift & Shift auf VMs im virtuellen Azure-Netzwerk, die in eine Domäne der neuen Active Directory-Instanz eingebunden sind.

  3. Veröffentlichen Sie Legacy-Apps in der Cloud mit dem Microsoft Entra-Anwendungsproxy oder einem Partner für den sicheren Hybridzugriff.

  4. Wenn Legacy-Apps durch Abgang außer Betrieb genommen werden, setzen Sie die Active Directory-Instanz, die im virtuellen Azure-Netzwerk ausgeführt wird, schließlich außer Betrieb.

Vergleich von Strategien

Strategie Microsoft Entra Domain Services Erweitern von Active Directory auf IaaS Unabhängige Active Directory-Instanz in IaaS
Entkoppelung vom lokalen Active Directory Ja Keine Ja
Zulassen von Schemaerweiterungen Nein Ja Ja
Vollständige administrative Kontrolle Nein Ja Yes
Mögliche Neukonfiguration von Apps erforderlich (z. B. ACLs oder Autorisierung) Ja Keine Ja

Verschieben der VPN-Authentifizierung

Dieses Projekt konzentriert sich auf das Verschieben Ihrer VPN-Authentifizierung zu Microsoft Entra ID. Für VPN-Gateway-Verbindungen ist es wichtig zu wissen, dass verschiedene Konfigurationen verfügbar sind. Sie müssen ermitteln, welche Konfiguration am besten zu Ihren Anforderungen passt. Weitere Informationen zum Entwerfen einer Lösung finden Sie unter VPN Gateway-Entwurf.

Einige wichtige Punkte im Zusammenhang mit der Verwendung von Microsoft Entra ID für die VPN-Authentifizierung sind:

Verschieben des Remotezugriffs auf interne Anwendungen

Um Ihre Umgebung zu vereinfachen, können Sie den Microsoft Entra-Anwendungsproxy oder Partner für den sicheren Hybridzugriff für den Remotezugriff verwenden. Dadurch können Sie die Abhängigkeit von lokalen Reverseproxylösungen beseitigen.

Es muss erwähnt werden, dass die Aktivierung des Remotezugriffs auf eine Anwendung mit den oben genannten Technologien ein Zwischenschritt ist. Der Aufwand, um die Anwendung vollständig von Active Directory zu entkoppeln, ist größer.

Mit Microsoft Entra Domain Services können Sie Anwendungsserver in die IaaS der Cloud migrieren und von Active Directory entkoppeln, während Sie den Microsoft Entra-Anwendungsproxy verwenden, um Remotezugriff zu ermöglichen. Weitere Informationen zu diesem Szenario finden Sie unter Bereitstellen von Microsoft Entra-Anwendungsproxys für Microsoft Entra Domänenservices.

Nächste Schritte