Migrieren von einem Verbundserver zur zertifikatbasierten Microsoft Entra-Authentifizierung (Certificate-Based Authentication, CBA)

  • Artikel

In diesem Artikel wird erläutert, wie Sie von lokalen Verbundservern wie Active Directory-Verbunddienste (Active Directory Federation Services, AD FS) zur Cloudauthentifizierung mithilfe der zertifikatbasierten Microsoft Entra-Authentifizierung (Certificate-Based Authentification, CBA) migrieren.

Gestaffelter Rollout

Ein Mandanten-Administrator kann die Verbunddomäne ohne Pilottest vollständig auf Entra ID CBA umstellen, indem er die CBA-Authentifizierungsmethode in Entra ID aktiviert und die gesamte Domäne auf verwaltete Authentifizierung umstellt. Wenn der Kunde jedoch eine kleine Gruppe von Benutzern testweise mit der Entra ID CBA authentifizieren möchte, bevor er die gesamte Domäne auf verwaltet umstellt, kann er die Funktion des gestaffelten Rollouts nutzen.

Der gestaffelte Rollout der zertifikatsbasierten Authentifizierung (CBA) hilft Kunden bei der Umstellung von der Durchführung der CBA bei einem Verbund-IdP auf Microsoft Entra ID, indem eine kleine Gruppe von Benutzern selektiv auf die Verwendung der CBA bei Entra ID umgestellt wird (und nicht mehr an den Verbund-IdP weitergeleitet wird), bevor dann die Domänenkonfiguration in Entra ID von Verbund auf verwaltet umgestellt wird. Der gestaffelte Rollout ist nicht dafür gedacht, dass die Domäne über einen längeren Zeitraum oder für eine große Anzahl von Benutzern im Verbund bleibt.

Schauen Sie sich dieses kurze Video an, in dem die Migration von der zertifikatbasierten Authentifizierung von ADFS zu Microsoft Entra CBA veranschaulicht wird

Hinweis

Wenn der gestaffelte Rollout für einen Benutzer aktiviert ist, wird der Benutzer als verwalteter Benutzer betrachtet, und die gesamte Authentifizierung erfolgt in Microsoft Entra ID. Bei einem Verbundmandanten funktioniert die Kennwortauthentifizierung, wenn für den gestaffelten Rollout die CBA aktiviert ist, nur, wenn auch die Kennworthashsynchronisierung aktiviert ist. Andernfalls schlägt die Kennwortauthentifizierung fehl.

Aktivieren des gestaffelten Rollouts für die zertifikatbasierte Authentifizierung auf Ihrem Mandanten

Tipp

Die Schritte in diesem Artikel können je nach dem Portal, mit dem Sie beginnen, geringfügig variieren.

Führen Sie die folgenden Schritte aus, um den gestaffelten Rollout zu konfigurieren:

  1. Melden Sie sich beim Microsoft Entra Admin Center mindestens mit der Rolle Benutzeradministrator an.
  2. Suchen Sie nach Microsoft Entra Connect, und wählen Sie diese Lösung aus.
  3. Klicken Sie auf der Seite „Microsoft Entra Connect“ unter „Gestaffelter Rollout der Cloudauthentifizierung“ auf Gestaffelten Rollout für verwaltete Benutzeranmeldung aktivieren.
  4. Wählen Sie auf der Featureseite Gestaffelten Rollout aktivieren für Zertifikatbasierte Authentifizierung die Option Ein aus.
  5. Klicken Sie auf Gruppen verwalten, und fügen Sie die Gruppen hinzu, für die die Cloudauthentifizierung gelten soll. Um ein Timeout zu vermeiden, stellen Sie sicher, dass die Sicherheitsgruppen anfangs nicht mehr als 200 Mitglieder enthalten.

Weitere Informationen finden Sie unter Gestaffelter Rollout.

Verwenden von Microsoft Entra Connect zum Aktualisieren des certificateUserIds-Attributs

AD FS-Administratoren können den Synchronisierungsregel-Editor verwenden, um Regeln für die Synchronisierung der Werte von AD FS-Attributen mit Microsoft Entra-Benutzerobjekten zu erstellen. Weitere Informationen finden Sie unter Synchronisierungsregeln für certificateUserIds.

In Microsoft Entra Connect ist eine spezielle Rolle namens Hybrididentitätsadministrator erforderlich, die die erforderlichen Berechtigungen erteilt. Sie benötigen diese Rolle, um Schreibberechtigungen für das neue Cloudattribut zu erhalten.

Hinweis

Wenn ein Benutzer synchronisierte Attribute verwendet, z. B. das Attribut „onPremisesUserPrincipalName“ im Benutzerobjekt für die Benutzernamensbindung, kann jeder Benutzerin mit Administratorzugriff auf den Microsoft Entra Connect-Server die synchronisierte Attributzuordnung und den Wert des synchronisierten Attributs ändern. Der Benutzer muss kein Cloudadministrator sein. Ein AD FS-Administrator sollte sicherstellen, dass der Administratorzugriff auf den Microsoft Entra Connect-Server eingeschränkt ist. Darüber hinaus sollte es sich bei privilegierten Konten um reine Cloudkonten handeln.

Häufig gestellte Fragen zum Migrieren von AD FS zu Microsoft Entra ID

Ist es möglich, privilegierte Konten auf einem AD FS-Verbundserver einzurichten?

Obwohl es möglich ist, empfiehlt Microsoft, reine Cloudkonten als privilegierte Konten zu verwenden. Durch die Verwendung reiner Cloudkonten für den privilegierten Zugriff wird das Risiko verringert, dass Microsoft Entra ID einer kompromittierten lokalen Umgebung ausgesetzt ist. Weitere Informationen hierzu, finden Sie unter Schützen von Microsoft 365 vor Angriffen auf die lokale Umgebung.

Wenn eine Organisation sowohl AD FS als auch die Azure-CBA verwendet, besteht dann trotzdem die Gefahr einer AD FS-Kompromittierung?

Microsoft empfiehlt, reine Cloudkonten als privilegierte Konten zu verwenden. Durch diese Vorgehensweise wird das Risiko verringert, dass Microsoft Entra ID einer kompromittierten lokalen Umgebung ausgesetzt ist. Die ausschließliche Nutzung von reinen Cloudkonten als privilegierte Konten ist von grundlegender Bedeutung für dieses Ziel.

Für synchronisierte Konten:

  • Wenn sie sich in einer verwalteten Domäne befinden (keine Verbunddomäne), besteht kein Risiko durch den Verbund-IdP.
  • Wenn sie sich in einer Verbunddomäne befinden, aber ein Teil der Konten im Zuge eines gestaffelten Rollouts zur Azure Microsoft Entra-CBA migriert wird, unterliegen sie Risiken im Zusammenhang mit dem Verbund-IdP, bis die Verbunddomäne vollständig auf die Cloudauthentifizierung umgestellt wurde.

Sollten Organisationen Verbundserver wie AD FS abschaffen, um das Pivotieren von AD FS zu Azure zu verhindern?

Über den Verbund können Angreifer*innen jede Identität vorgeben, zum Beispiel die des CIO, auch wenn sie keine reine Cloudrolle wie „Globaler Administrator“ annehmen können.

Wenn eine Domäne in Microsoft Entra ID als Verbunddomäne erfasst ist, wird dem Verbund-IdP eine hohe Vertrauensstellung eingeräumt. AD FS ist nur ein Beispiel, dieses Prinzip gilt für alle Verbund-IdPs. Viele Organisationen stellen einen Verbund-IdP wie AD FS ausschließlich für die zertifikatbasierte Authentifizierung bereit. Durch die Microsoft Entra-CBA entfällt in diesem Fall die Abhängigkeit von AD FS vollständig. Mit der Microsoft Entra-CBA können Kunden ihren Anwendungsbestand in Microsoft Entra ID verschieben, um ihre IAM-Infrastruktur zu modernisieren, die Kosten zu senken und dabei die Sicherheit zu erhöhen.

Aus Sicherheitsperspektive gibt es keine Änderung an den Anmeldeinformationen. Das gilt auch für das X.509-Zertifikat, die CACs, die PIVs, die verwendete PKI und so weiter. Die PKI-Besitzer*innen behalten die vollständige Kontrolle über den Zertifikatausstellungs- und Sperrlebenszyklus und die Richtlinie. Die Sperrüberprüfung und die Authentifizierung erfolgen über Microsoft Entra ID statt über den Verbund-IdP. Diese Prüfungen ermöglichen allen Benutzern die kennwortlose, phishingresistente Authentifizierung direkt bei Microsoft Entra ID.

Wie funktioniert die Authentifizierung mit dem AD FS-Verbund und der Microsoft Entra-Cloudauthentifizierung unter Windows?

Für die Microsoft Entra-CBA muss der Benutzer oder die Anwendung den Microsoft Entra-UPN des Benutzers angeben, der sich anmeldet.

Im Browser geben Benutzer meistens den Microsoft Entra-UPN ein. Der Microsoft Entra-UPN wird für die Bereichs- und Benutzerermittlung verwendet. Das verwendete Zertifikat wird dann mithilfe einer der konfigurierten Benutzernamensbindungen in der Richtlinie mit dem oder der Benutzer*in abgeglichen.

Bei der Windows-Anmeldung hängt der Abgleich davon ab, ob es sich um ein Hybrid- oder um ein in Microsoft Entra eingebundenes Gerät handelt. Wenn ein Hinweis auf den Benutzernamen aktiviert ist, gibt Windows diesen jedoch in beiden Fällen in Form des Microsoft Entra-UPN an. Das verwendete Zertifikat wird dann mithilfe einer der konfigurierten Benutzernamensbindungen in der Richtlinie mit dem oder der Benutzer*in abgeglichen.

Nächste Schritte