Freigeben über

Best Practices zum Migrieren von Anwendungen und Authentifizierung zu Microsoft Entra ID

Sie haben gehört, dass Azure Active Directory jetzt Microsoft Entra ID heißt, und halten es für einen guten Zeitpunkt, Ihre Active Directory Federation Service (AD FS) zur Cloudauthentifizierung in Microsoft Entra ID zu migrieren. Während Sie Ihre Optionen überprüfen, sehen Sie sich unsere umfangreichen Ressourcen zum Migrieren von Apps zu Microsoft Entra ID und Best Practices an.

Bis Sie AD FS zu Microsoft Entra ID migrieren können, schützen Sie Ihre lokalen Ressourcen mit Microsoft Defender for Identity. Sie können Sicherheitsrisiken proaktiv suchen und korrigieren. Verwenden Sie Bewertungen, Analysen und Data Intelligence, eine Prioritätseinstufung für die Benutzeruntersuchung und automatische Reaktion auf kompromittierte Identitäten. Die Migration in die Cloud bedeutet, dass Ihre Organisation von der modernen Authentifizierung profitieren kann, z. B. kennwortlose Methoden zur Authentifizierung.

Hier sind die Gründe, aus denen Sie AD FS möglicherweise nicht migrieren möchten:

  • Ihre Umgebung verwendet flache Benutzernamen (z. B. Mitarbeiter-ID).
  • Sie benötigen weitere Optionen für benutzerdefinierte MFA-Anbieter (Multi-Faktor-Authentifizierung).
  • Sie verwenden Geräteauthentifizierungslösungen von MDM-Systemen (Mobile Device Management, Verwaltung mobiler Geräte) von Drittanbietern wie VMware.
  • Active Directory-Verbunddienste (AD FS) hat einen Doppelverbund mit mehreren Clouds.
  • Sie müssen Netzwerke per Air Gap trennen.

Migrieren von Anwendungen

Planen Sie einen gestaffelten Rollout der Anwendungsmigration, und wählen Sie Benutzer aus, die sich testweise bei Microsoft Entra ID authentifizieren sollen. Verwenden Sie die Anleitungen unter Planen der Anwendungsmigration zu Microsoft Entra ID und Ressourcen zum Migrieren von Apps zu Microsoft Entra ID.

Weitere Informationen finden Sie im folgenden Video: Mühelose Anwendungsmigration mithilfe von Microsoft Entra ID.

Anwendungsmigrationstool

Die AD FS-Anwendungsmigration zum Verschieben von AD FS-Apps zu Microsoft Entra ID befindet sich derzeit in der Vorschauphase und ist ein Leitfaden für IT-Administratoren zum Migrieren von AD FS-Anwendungen von AD FS zu Microsoft Entra ID. Der Assistent für die AD FS-Anwendungsmigration bietet Ihnen eine einheitliche Oberfläche zum Entdecken, Auswerten und Konfigurieren neuer Microsoft Entra-Anwendungen. Er ermöglicht eine Konfiguration mit einem Klick für grundlegende SAML-URLs, Anspruchszuordnungen und Benutzerzuweisungen, um Anwendungen mit Microsoft Entra ID zu integrieren. Es gibt eine vollständige Unterstützung zum Migrieren lokaler AD FS-Anwendungen mit den folgenden Features:

  • Um die Nutzung von Anwendungen und deren Auswirkungen zu ermitteln, werten Sie die Anmeldeaktivitäten der AD FS-Anwendung der vertrauenden Seite aus
  • Um Migrationshindernisse und erforderliche Aktionen für die Migration von Anwendungen zu Microsoft Entra ID zu ermitteln, analysieren Sie die Durchführbarkeit der Migration von AD FS zu Microsoft Entra
  • Um eine neue Microsoft Entra-Anwendung automatisch für eine AD FS-Anwendung zu konfigurieren, konfigurieren Sie neue Microsoft Entra-Anwendungen mit einem Ein-Klick-Anwendungsmigrationsprozess

Phase 1: Ermittlung und Bereichsfestlegung für Apps

Beziehen Sie beim Auswählen von Apps auch in Entwicklung befindliche und geplante Apps ein. Beschränken Sie sie auf die Authentifizierung mit Microsoft Entra ID nach Abschluss der Migration.

Verwenden Sie den Aktivitätsbericht, um AD FS-Apps zu Microsoft Entra ID zu verschieben. Dieser Bericht hilft Ihnen, Anwendungen zu ermitteln, die zu Microsoft Entra ID migriert werden können. Es prüft AD FS-Anwendungen auf Kompatibilität mit Microsoft Entra, sucht nach Problemen und gibt Hinweise zur Vorbereitung einzelner Anwendungen auf die Migration.

Verwenden Sie das Tool zur App-Migration von AD FS zu Microsoft Entra, um anspruchsbasierte Anwendungen von Ihrem AD FS-Server zu sammeln und die Konfiguration zu analysieren. Auf Grundlage dieser Analyse zeigt der Bericht, welche Apps für die Migration zu Microsoft Entra ID infrage kommen. Für nicht infrage kommende Apps finden Sie Erläuterungen dazu, warum sie nicht migriert werden können.

Installieren Sie Microsoft Entra Connect für lokale Umgebungen mit Microsoft Entra Connect AD FS-Integritätsagents.

Erfahren Sie mehr über Was ist Microsoft Entra Connect?

Phase 2: Klassifizieren von Apps und Planen des Pilotprojekts

Das Klassifizieren der App-Migration ist eine wichtige Aufgabe. Planen Sie die App-Migration und den Übergang in Phasen, nachdem Sie entschieden haben, in welcher Reihenfolge Sie Apps migrieren wollen. Beziehen Sie die folgenden Kriterien in die App-Klassifizierung ein:

  • Moderne Authentifizierungsprotokolle wie Software-as-a-Service-Apps (SaaS) von Drittanbietern im Microsoft Entra-Anwendungskatalog, aber nicht über Microsoft Entra ID.
  • Legacy-Authentifizierungsprotokolle zur Modernisierung, z. B. SaaS-Apps von Drittanbietern (nicht im Katalog, können jedoch hinzugefügt werden)
  • Verbund-Apps, die AD FS verwenden und zu Microsoft Entra ID migriert werden können
  • Legacy-Authentifizierungsprotokolle, die NICHT modernisiert werden sollen. Die Modernisierung kann Protokolle hinter Web Application Proxy (WinSCP (WAP)), die Microsoft Entra-Anwendungsproxy verwenden können, und Application Delivery Network/Application Delivery Controllers, die Secure Hybrid Access verwenden können, ausschließen.
  • Neue branchenspezifische (LOB) Anwendungen.
  • Einzustellende Apps verfügen möglicherweise über Funktionen, die in anderen Systemen redundant sind und keine Geschäftsbesitzer oder -nutzung aufweisen.

Wenn Sie die ersten Apps für die Migration auswählen, halten Sie es einfach. Die Kriterien können auf SaaS-Apps im Katalog zutreffen, die Mehrere Identitätsanbieterverbindungen unterstützen. Es gibt Apps mit Testinstanzzugriff, Apps mit einfachen Anspruchsregeln und Apps, die den Benutzergruppenzugriff steuern.

Phase 3: Planen und Testen der Migration

Zu den Migrations- und Testtools zählt das Microsoft Entra-App-Migrationstoolkit, um Apps zu ermitteln, zu klassifizieren und zu migrieren. Sehen Sie sich die Liste der SaaS-App-Tutorials und den Microsoft Entra-SSO-Bereitstellungsplan an, die den gesamten Prozess abdecken.

Lesen Sie mehr über den Microsoft Entra-Anwendungsproxy und verwenden Sie den vollständigen Bereitstellungsplan für den Microsoft Entra-Anwendungsproxy. Erwägen Sie Secure Hybrid Access (SHA),, um Ihre Legacy-Authentifizierungsanwendungen (lokal und in der Cloud) zu schützen, indem Sie sie mit Microsoft Entra ID verknüpfen. Verwenden Sie Microsoft Entra Connect, um AD FS-Benutzer und -Gruppen mit Microsoft Entra ID zu synchronisieren.

Phase 4: Planen der Verwaltung und Einblicke

Befolgen Sie nach der App-Migration den Verwaltungs- und Erkenntnisleitfaden, um sicherzustellen, dass Benutzer sicher auf Apps zugreifen und diese verwalten können. Gewinnen und teilen Sie Erkenntnisse zur Nutzung und App-Integrität.

Überwachen Sie über das Microsoft Entra Admin Center alle Apps mit den folgenden Methoden:

  • App-Überwachung mithilfe von Unternehmensanwendungen > Überwachen oder Zugriff auf diese Informationen über die Berichterstellungs-API von Microsoft Entra, um eine Integration mit Ihren bevorzugten Tools durchzuführen
  • Anwendungsberechtigungen mit Unternehmensanwendungen, Berechtigungen anzeigen für Anwendungen mit Open Authorization (OAuth)/OpenID Connect.
  • Gewinnen von Erkenntnissen zur Anmeldung mit Unternehmensanwendungen > Anmeldungen und über die Berichterstellungs-API von Microsoft Entra
  • Visualisieren der App-Nutzung über Microsoft Entra-Arbeitsmappen

Vorbereiten der Überprüfungsumgebung

Das Verwalten, die Problembehandlung und die Berichterstellung für Microsoft Identity-Produkte und -Dienste ist mit MSIdentityTools im PowerShell-Katalog möglich. Überwachen Sie Ihre AD FS-Infrastruktur mit Microsoft Entra Connect Health. Erstellen Sie Testanwendungen in AD FS und generieren Sie regelmäßig Benutzeraktivitäten und überwachen Sie die Aktivitäten im Microsoft Entra Admin Center.

Wenn Sie Objekte mit Microsoft Entra ID synchronisieren, überprüfen Sie Anspruchsregeln der vertrauenden AD FS-Seite für Gruppen, Benutzer und Benutzerattribute, die für in der Cloud verfügbare Anspruchsregeln verwendet werden. Sorgen Sie für Container- und Attributsynchronisierung.

Unterschiede in App-Migrationsszenarios

Ihr App-Migrationsplan benötigt besondere Aufmerksamkeit, wenn Ihre Umgebung die folgenden Szenarios aufweist. Folgen Sie den Links, um weitere Anleitungen zu erhalten.

  • Zertifikate: (globales AD FS-Signaturzertifikat): In Microsoft Entra ID können Sie ein Zertifikat pro Anwendung oder ein Zertifikat für alle Anwendungen verwenden. Staffeln Sie die Ablaufdaten, und konfigurieren Sie Erinnerungen. Delegieren Sie die Zertifikatverwaltung an die Rollen mit den geringsten Rechten. Überprüfen Sie häufige Fragen und Informationen im Zusammenhang mit Zertifikaten, die Microsoft Entra ID erstellt, um Verbund-SSO für SaaS-Anwendungen einzurichten.
  • Anspruchsregeln und grundlegende Attributzuordnung: Für SaaS-Anwendungen benötigen Sie möglicherweise nur eine einfache Attribut-zu-Anspruch-Zuordnung. Hier erfahren Sie, wie Sie SAML-Tokenansprüche anpassen.
  • Benutzernamen aus UPN extrahieren: Microsoft Entra-ID unterstützt die RegEx-basierte Transformation (auch im Zusammenhang mit der SAML-Tokenanspruchsanpassung).
  • Gruppenansprüche: Geben Sie Gruppenansprüche aus, die von den Benutzern gefiltert werden, die Mitglieder und der Anwendung zugewiesen sind. Sie können Gruppenansprüche für Anwendungen mit Microsoft Entra ID konfigurieren.
  • Webanwendungsproxy: Veröffentlichen Sie mit dem Microsoft Entra-Anwendungsproxy, um eine sichere Verbindung ohne VPN mit lokalen Webanwendungen herzustellen. Ermöglichen Sie Remotezugriff auf lokale Web-Apps und native Unterstützung für Legacy-Authentifizierungsprotokolle.

Plan für den Anwendungsmigrationsprozess

Erwägen Sie, die folgenden Schritte in Ihren Anwendungsmigrationsprozess einzubeziehen.

  • AD FS-App-Konfiguration klonen: Richten Sie eine Testinstanz der Anwendung ein oder verwenden Sie eine Mock-App auf einem Test-Microsoft Entra-Mandanten. Ordnen Sie die AD FS-Einstellungen den Microsoft Entra-Konfigurationen zu. Planen Sie für den Fall eines Rollbacks. Wechseln Sie die Testinstanz zu Microsoft Entra ID, und überprüfen Sie sie.
  • Ansprüche und Bezeichner konfigurieren: Simulieren Sie Produktions-Apps zur Bestätigung und Problembehandlung. Verweisen Sie in einer Testinstanz der App auf die Microsoft Entra ID-Testanwendung. Überprüfen und behandeln Sie Probleme beim Zugriff, und aktualisieren Sie die Konfiguration nach Bedarf.
  • Produktionsinstanz für die Migration vorbereiten: Fügen Sie die Produktionsanwendung basierend auf den Testergebnissen zu Microsoft Entra ID hinzu. Für Anwendungen, die mehrere Identitätsanbieter (IdPs) zulassen, konfigurieren Sie Microsoft Entra ID als zusätzlichen IdP für die Produktionsinstanz.
  • Stellen Sie die Produktionsinstanz auf Microsoft Entra ID um. Ändern Sie für Anwendungen, die mehrere gleichzeitige IdPs zulassen, den Standard-IdP in Microsoft Entra ID. Konfigurieren Sie andernfalls Microsoft Entra ID als IdP für die Produktionsinstanz. Aktualisieren Sie die Produktionsinstanz, um die Microsoft Entra-Produktionsanwendung als primären IdP zu verwenden.
  • Migrieren Sie die erste App, führen Sie Migrationstests aus, und beheben Sie Probleme. Berücksichtigen Sie den Migrationsstatus in AD FS-Anwendungsaktivitätsberichten, die Anleitungen zur Behebung potenzieller Migrationsprobleme bieten.
  • Migration in großem Umfang: Migrieren Sie Apps und Benutzer in Phasen. Verwenden Sie Microsoft Entra ID, um migrierte Apps und Benutzer zu verwalten, während die Authentifizierung ausreichend getestet wird.
  • Verbund entfernen: Vergewissern Sie sich, dass Ihre AD FS-Farm nicht mehr für die Authentifizierung verwendet wird. Verwenden Sie failback-, sicherungs- und exportbezogene Konfigurationen.

Migrieren der Authentifizierung

Während Sie sich auf die Authentifizierungsmigration vorbereiten, entscheiden Sie, welche Authentifizierungsmethoden für Ihre Organisation erforderlich sind.

Kennwort- und Authentifizierungsrichtlinien

Stimmen Sie mit dedizierten Richtlinien für lokales AD FS und Microsoft Entra ID die Kennwortablaufrichtlinien lokal und in Microsoft Entra ID aufeinander ab. Erwägen Sie die Implementierung einer kombinierten Kennwortrichtlinie und Überprüfung auf schwache Kennwörter in Microsoft Entra ID. Nachdem Sie zu einer verwalteten Domäne gewechselt haben, gelten beide Kennwortablaufrichtlinien.

Ermöglichen Sie Benutzern das Zurücksetzen vergessener Kennwörter mit der Self-Service-Kennwortzurücksetzung (SSPR), um die Helpdeskkosten zu reduzieren. Beschränken Sie gerätebasierte Authentifizierungsmethoden. Modernisieren Sie Ihre Kennwortrichtlinie so, dass keine regelmäßigen Ablaufzeiten vorhanden sind, die widerrufen werden können, wenn ein Risiko besteht. Blockieren Sie schwache Kennwörter, und vergleichen Sie Kennwörter mit gesperrten Kennwortlisten. Aktivieren Sie den Kennwortschutz sowohl für lokales AD FS als auch für die Cloud.

Migrieren Sie die Legacy-Richtlinieneinstellungen von Microsoft Entra ID, welche die Multifaktor-Authentifizierung und SSPR separat steuern, in eine einheitliche Verwaltung mit der Richtlinie Authentifizierungsmethoden. Migrieren Sie Richtlinieneinstellungen mit einem umkehrbaren Prozess. Sie können weiterhin die mandantenweite Multi-Faktor-Authentifizierung und SSPR-Richtlinien verwenden, während Sie die Authentifizierungsmethoden für Benutzer und Gruppen genau konfigurieren.

Da die Windows-Anmeldung und andere kennwortlose Methoden eine ausführliche Konfiguration erfordern, aktivieren Sie die Anmeldung mit Microsoft Authenticator und FIDO2-Sicherheitsschlüsseln. Verwenden Sie Gruppen zum Verwalten von Bereitstellungs- und Bereichsbenutzern.

Sie können die automatische Anmeldung mithilfe der Startbereichsermittlung konfigurieren. Hier erfahren Sie, wie Sie die automatisch beschleunigte Anmeldung verwenden, um den Eingabebildschirm für den Benutzernamen zu überspringen und Benutzer automatisch an Endpunkte für die Verbundanmeldung weiterzuleiten. Verhindern Sie die automatische Beschleunigung der Anmeldung mithilfe der Richtlinie zur Startbereichsermittlung, um über mehrere Wege steuern zu können, wie und wo Benutzer sich authentifizieren.

Ablaufrichtlinien für Konten

Das accountExpires-Attribut der Benutzerkontenverwaltung wird nicht mit Microsoft Entra ID synchronisiert. Deshalb bleibt ein abgelaufenes Active Directory-Konto in einer für die Kennwort-Hashsynchronisierung konfigurierten Umgebung in Microsoft Entra ID aktiv. Verwenden Sie ein geplantes PowerShell-Skript, um benutzerbasierte Microsoft Windows Server Active Directory-Konten nach Ablauf zu deaktivieren, z. B. das Cmdlet-Set-ADUser. Umgekehrt können Sie das Konto beim Entfernen des Ablaufs aus einem Microsoft Windows Server Active Directory-Konto erneut aktivieren.

Mit Microsoft Entra ID können Sie Angriffe mithilfe von Smart Lockout verhindern. Sperren Sie Konten in der Cloud, bevor Sie sie lokal sperren, um Brute-Force-Angriffe abzuschwächen. Legen Sie für die Cloud ein kürzeres Intervall fest und stellen Sie sicher, dass der Schwellenwert vor Ort mindestens zwei- bis dreimal so hoch ist wie der Schwellenwert von Microsoft Entra. Legen Sie die Dauer der Sperrung von Microsoft Entra länger fest als die lokale Dauer der Sperrung. Wenn Die Migration abgeschlossen ist, konfigurieren Sie den ESL-Schutz (Extranet Smart Lockout) für AD FS.

Planen der Bereitstellung des bedingten Zugriffs

Die Flexibilität der Richtlinie für bedingten Zugriff erfordert eine sorgfältige Planung. Die Planungsschritte finden Sie unter Planen einer Bereitstellung des bedingten Zugriffs für Microsoft Entra. Hier sind die wichtigsten Punkte, die es zu beachten gilt:

  • Entwerfen Sie Richtlinien für bedingten Zugriff mit aussagekräftigen Namenskonventionen
  • Verwenden Sie eine Entwurfsentscheidungstabelle mit den folgenden Feldern:
    • Zuordnungsfaktoren: Benutzer, Cloud-Apps
    • Bedingungen: Standorte, Gerätetyp, Art von Client-Apps, Anmelderisiko
    • Steuerelemente: Blockieren, Multi-Faktor-Authentifizierung erforderlich, Hybrid-Microsoft Windows Server Active Directory, kompatibles Gerät erforderlich, genehmigter Client-App-Typ
  • Wählen Sie kleine Gruppen von Testbenutzern für Richtlinien für bedingten Zugriff aus
  • Testen Sie Richtlinien für bedingten Zugriff im Modus „Nur melden“
  • Validieren Sie Richtlinien für den bedingten Zugriff mit dem Was-wäre-wenn-Tool
  • Verwenden Sie Vorlagen für bedingten Zugriff, insbesondere, wenn Ihre Organisation noch nicht mit bedingtem Zugriff arbeitet

Richtlinien für bedingten Zugriff

Wenn Sie die Ein-Faktor-Authentifizierung abschließen, erzwingen Sie Richtlinien für bedingten Zugriff. Bedingter Zugriff ist keine Verteidigungsmaßnahme für Szenarios wie Denial-of-Service-Angriffe (DoS). Der bedingte Zugriff kann jedoch Signale aus diesen Ereignissen verwenden, z. B. Anmelderisiko und Standort einer Anforderung, um den Zugriff zu bestimmen. Der Ablauf einer Richtlinie für bedingten Zugriff untersucht eine Sitzung und die zugehörigen Bedingungen und speist dann Ergebnisse in die zentrale Richtlinien-Engine ein.

Mit bedingtem Zugriff können Sie den Zugriff auf genehmigte, moderne und authentifizierungsfähige Client-Apps mithilfe von Intune-App-Schutzrichtlinien einschränken. Für ältere Client-Apps, die möglicherweise keine App-Schutzrichtlinien unterstützen, können Sie den Zugriff auf genehmigte Client-Apps beschränken.

Schützen Sie Apps automatisch basierend auf Attributen. Verwenden Sie zum Ändern von Kundensicherheitsattributen die dynamische Filterung von Cloudanwendungen, um Anwendungsrichtlinienbereiche hinzuzufügen und zu entfernen. Verwenden Sie benutzerdefinierte Sicherheitsattribute für Microsoft-Anwendungen, die nicht in der Anwendungsauswahl für bedingten Zugriff aufgeführt werden.

Verwenden Sie die Kontrollmaßnahme Authentifizierungsstärke für den bedingten Zugriff, um festzulegen, welche Kombination von Authentifizierungsmethoden auf eine Ressource zugreifen darf. Beispielsweise können Sie den Zugriff auf eine vertrauliche Ressource ausschließlich mit phishingresistenten Authentifizierungsmethoden erlauben.

Werten Sie die benutzerdefinierten Kontrollmaßnahmen im bedingten Zugriff aus. Benutzer werden zu einem kompatiblen Dienst umgeleitet, um die Authentifizierungsanforderungen außerhalb von Microsoft Entra ID zu erfüllen. Microsoft Entra ID überprüft die Antwort, und wenn der Benutzer authentifiziert oder validiert wurde, verbleibt dieser im Ablauf des bedingten Zugriffs. Wie unter Bevorstehende Änderungen an benutzerdefinierten Steuerelementen erwähnt, funktionieren die vom Partner bereitgestellten Authentifizierungsfunktionen nahtlos mit den Microsoft Entra-Administrator- und -Endbenutzererfahrungen.

Benutzerdefinierte Multi-Faktor-Authentifizierungslösungen

Wenn Sie benutzerdefinierte Anbieter für die Multi-Faktor-Authentifizierung verwenden, sollten Sie eine Migration von Multi-Factor Authentication Server zu Microsoft Entra Multi-Faktor-Authentifizierung in Betracht ziehen. Verwenden Sie bei Bedarf das Dienstprogramm zur Multi-Factor Authentication-Server-Migration, um auf die Multi-Faktor-Authentifizierung umzustellen. Passen Sie die Endbenutzerumgebung mit Einstellungen für den Schwellenwert zur Kontosperrung, Betrugswarnungen und Benachrichtigungen an.

Erfahren Sie, wie Sie zur Multi-Faktor-Authentifizierung und zur Microsoft Entra-Benutzerauthentifizierung migrieren. Verschieben Sie alle Anwendungen, den Multi-Faktor-Authentifizierungsdienst und die Benutzerauthentifizierung in die Microsoft Entra-ID.

Sie können die Multi-Faktor-Authentifizierung von Microsoft Entra aktivieren und erfahren, wie Sie Richtlinien für den bedingten Zugriff für Benutzergruppen erstellen, Richtlinienbedingungen konfigurieren, die zur Multi-Faktor-Authentifizierung auffordern und die Benutzerkonfiguration und Verwendung der Multi-Faktor-Authentifizierung testen.

Die Network Policy Server (NPS)-Erweiterung für die Multi-Faktor-Authentifizierung fügt Ihrer Authentifizierungsinfrastruktur über Ihre Server cloudbasierte Multi-Faktor-Authentifizierungsfunktionen hinzu. Wenn Sie die Multi-Faktor-Authentifizierung von Microsoft Entra mit NPS verwenden, bestimmen Sie, was zu modernen Protokollen wie Security Assertion Markup Language (SAML) und OAuth2 migriert werden kann. Bewerten Sie den Microsoft Entra-Anwendungsproxy für den Remotezugriff und verwenden Sie Secure Hybrid Access (SHA), um Legacy-Apps mit Microsoft Entra ID zu schützen.

Überwachen von Anmeldungen

Verwenden Sie Connect Health, um AD FS-Anmeldeinformationen zu integrieren, wodurch je nach Serverversion mehrere Ereignis-IDs aus AD FS korreliert werden, um Informationen zu Anforderungs- und Fehlerdetails zu erhalten. Der Bericht über Microsoft Entra-Anmeldungen enthält Informationen dazu, wann sich Benutzer, Anwendungen und verwaltete Ressourcen bei Microsoft Entra ID anmelden und auf Ressourcen zugreifen. Diese Informationen korrelieren mit dem Microsoft Entra-Anmeldeberichtschema und werden in der Benutzeroberfläche für Microsoft Entra-Anmeldeberichte angezeigt. Mit dem Bericht stellt ein Log Analytics-Stream die AD FS-Daten bereit. Verwenden Sie die Azure Monitor-Arbeitsmappenvorlage, und passen Sie sie für die Szenarioanalyse an. Beispiele hierfür sind AD FS-Kontosperrungen, ungültige Kennwortversuche und die Zunahme unerwarteter Anmeldeversuche.

Microsoft Entra protokolliert alle Anmeldungen bei einem Azure-Mandanten, einschließlich Ihrer internen Apps und Ressourcen. Überprüfen Sie Anmeldefehler und -muster, um Einblicke in den Zugriff von Benutzern auf Anwendungen und Dienste zu erhalten. Die Anmeldeprotokolle in Microsoft Entra ID sind als Aktivitätsprotokolle für die Analyse hilfreich. Konfigurieren Sie Protokolle mit bis zu 30 Tagen Datenaufbewahrung, abhängig von der Lizenzierung, und exportieren Sie sie in Azure Monitor, Sentinel, Splunk und andere SIEM-Systeme (Security Information & Event Management).

Unternehmensnetzwerkinterne Ansprüche

Unabhängig vom Ursprung der Anforderungen oder der Ressource, auf die zugegriffen wird, lehrt uns das Zero-Trust-Modell „Niemals vertrauen, immer überprüfen.“ Schützen Sie alle Speicherorte so, als ob sie sich außerhalb des Unternehmensnetzwerks befänden. Deklarieren Sie interne Netzwerke als vertrauenswürdige Speicherorte, um falsch positive Ergebnisse des Identitätsschutzes zu reduzieren. Erzwingen Sie die Multi-Faktor-Authentifizierung für alle Benutzer, und richten Sie gerätebasierte Richtlinien für bedingten Zugriff ein.

Führen Sie eine Abfrage für Anmeldeprotokolle aus, um Benutzende zu ermitteln, die eine Verbindung aus dem Unternehmensnetzwerk herstellen, aber keine Hybrideinbindung in Microsoft Entra aufweisen oder damit nicht konform sind. Denken Sie auch an Benutzer auf konformen Geräten und die Verwendung von nicht unterstützten Browsern wie Firefox oder Chrome ohne die Erweiterung. Verwenden Sie stattdessen den Computerdomänen- und Compliancestatus.

Gestaffelte Authentifizierungsmigrationstests und Cutover

Verwenden Sie zum Testen die Microsoft Entra Connect-Cloudauthentifizierung mit gestaffeltem Rollout, um die Testbenutzerauthentifizierung mit Gruppen zu steuern. Testen Sie selektiv Benutzergruppen mit Cloud-Authentifizierungsfunktionen wie Microsoft Entra Multi-Faktor-Authentifizierung, Bedingter Zugriff und Microsoft Entra ID-Schutz. Verwenden Sie den gestaffelten Rollout jedoch nicht für inkrementelle Migrationen.

Um die Migration zur Cloudauthentifizierung abzuschließen, verwenden Sie den gestaffelten Rollout, um neue Anmeldemethoden zu testen. Konvertieren Sie Domänen von der Verbundauthentifizierung zur verwalteten Authentifizierung. Beginnen Sie mit einer Testdomäne oder mit der Domäne mit der niedrigsten Benutzeranzahl.

Planen Sie den Domänencutover außerhalb der Geschäftszeiten, falls ein Rollback erforderlich ist. Verwenden Sie die aktuellen Verbundeinstellungen, um den Rollback zu planen. Weitere Informationen finden Sie im Leitfaden für Verbundentwurf und -bereitstellung.

Schließen Sie die Konvertierung von verwalteten Domänen in Verbunddomänen in Ihren Rollbackprozess ein. Verwenden Sie das Cmdlet New-MgDomainFederationConfiguration. Konfigurieren Sie bei Bedarf zusätzliche Anspruchsregeln. Um einen abgeschlossenen Prozess sicherzustellen, belassen Sie den Rollback für den gestaffelten Rollout bei 24 bis 48 Stunden nach dem Cutover. Entfernen Sie Benutzer und Gruppen aus dem gestaffelten Rollout, und deaktivieren Sie ihn dann.

Drehen Sie nach dem Cutover alle 30 Tage den Schlüssel für das nahtlose SSO:

Update-AzureADSSOForest -OnPremCredentials $creds -PreserveCustomPermissionsOnDesktopSsoAccount

Außerbetriebnahme von AD FS

Überwachen Sie die AD FS-Aktivität über die Connect Health-Nutzungsanalyse für AD FS. Aktivieren Sie zuerst die Überwachung für AD FS. Bevor Sie die AD FS-Farm außer Betrieb nehmen, stellen Sie sicher, dass keine AD FS-Aktivität vorhanden ist. Verwenden Sie den Leitfaden zur Außerbetriebnahme von AD FS und die Referenz zur Außerbetriebnahme von AD FS. Hier ist eine Zusammenfassung der wichtigsten Schritte für die Außerbetriebnahme:

  1. Erstellen Sie eine letzte Sicherung, bevor Sie AD FS-Server außer Betrieb nehmen.
  2. Entfernen Sie AD FS-Einträge aus internen und externen Lastenausgleichen.
  3. Löschen Sie die entsprechenden DNS-Einträge (Domain Name Server) für AD FS-Serverfarmnamen.
  4. Führen Sie auf dem primären AD FS-Server Get-ADFSProperties aus, und suchen Sie nach CertificateSharingContainer.

    Hinweis

    Löschen Sie den Domänennamen (Domain Name, DN) am Ende der Installation, nach einigen Neustarts, und wenn er nicht mehr verfügbar ist.

  5. Löschen Sie die AD FS-Konfigurationsdatenbank, wenn sie eine SQL Server-Datenbankinstanz als Speicher verwendet.
  6. Deinstallieren Sie WAP-Server.
  7. Deinstallieren Sie AD FS-Server.
  8. Löschen Sie SSL-Zertifikate (AD FS Secure Sockets Layer) aus jedem Serverspeicher.
  9. Führen Sie ein Reimaging der AD FS-Server mit vollständiger Datenträgerformatierung durch.
  10. Löschen Sie Ihr AD FS-Konto.
  11. Verwenden Sie Active Directory-Dienstschnittstellen (Active Directory Service Interfaces, ADSI), bearbeiten Sie diese, um den Inhalt des CertificateSharingContainer-DN zu entfernen.

Nächste Schritte

  • Last updated on