T2T Azure Subscription

Solange eine Firma "nur" Microsoft 365-Dienste nutzt, kann sich die Migration auch auf diese Daten beschränken. Aber wenn Sie ein AzureAD nutzen, dann ist es nicht unwahrscheinlich, dass die Firma auch andere Dienste wie Azure DevOps oder ganz generell Azure Services nutzt, die in einer oder mehrerer Subsciptions angelegt wurden.

Subscriptions und Admins

Eine Azure Subscription ist ein logischer Bereich, für den es einen Administrator und eine Abrechnung gibt. Eine Subscription kennt natürlich Berechtigungen aber keine eigene Benutzerverwaltung wie z.B. Azure DevOps sondern referenziert ein AzureAD. Daher ist der ersten Schritt eines Admins eines AzureAD die verknüpften Subscriptions zu ermitteln. Das geht im Portal recht einfach.

Das Portal zeigt ihnen dann alle verbundenen Subscriptions:

Sie sehen hier aber auch, dass meine Rolle nicht auf allen "Subscriptions" gleich ist und es kann schon etwas mühe bedeuten, sich alle Inhaber aller Subscriptions zu ermitteln. Beim "Owner" ist es klar und bei "Specific Access" kann ich oft noch die Rechte und damit einen Owner ermitteln. Hoffentlich gibt es den Benutzer dann auch noch. Die Rechte werden dabei über AzureAD-Rollen und Azure-Rollen vergeben.

Diagram of User Access Administrator elevated permissions.
Quelle: https://docs.microsoft.com/en-us/learn/modules/manage-subscription-access-azure-rbac/2-identify-appropriate-role-assign

Sie können sich als Administrator der verbundenen AzureAD-Instanz natürlich temporär die Rechte auf eine Azure Subscription beschaffen, wenn der originale Besitzer z.B. nicht mehr im Unternehmen ist. Das geht per PowerShell aber auch per Browser.

New-AzRoleAssignment `
   -SignInName azadmin@msxfaq.de `
   -RoleDefinitionName "Owner" ``
   -Scope "/subscriptions/<subscriptionID>"

Durch diese Einstellung sind sie "User Access Administrator" auf allen verknüpften Subscriptions und können damit die Berechtigungen verwalten.

Vorarbeiten

Nachdem Sie mit den Zusammenhängen und Anpassung der Berechtigungen nun alle Subscriptions im Zugriff haben, die mit ihrem AzureAD verbunden sind, sollten Sie ein erweitertes Inventory starten, denn mit dem Umhängen der Subscription an ein anderes AzureAD verlieren natürlich die bisherigen Benutzer ihre Berechtigungen.

Es ist sicher eine gute Idee, in dem Zuge generell die Zuweisung von Berechtigungen zu prüfen und ggfls. an das Konzept des Ziel-AzureAD anzupassen.

Aber es sind nicht nur die Berechtigungen, Auch andere Azure-Dienste haben ggfls. Verbindungen zum AzureAD und müssen mit dem Umzug in ein neues AzureAD und insbesondere mit dem Abbau das alten AzureAD umkonfiguriert werden. Ich denke nur an alle Eintragungen, die etwas mit der AzureAD-ObjectID zu tun haben, z.B. registrierte Enterprise Apps. Microsoft hat aber auch selbst eine Liste mit Abhängigkeiten veröffentlicht und verweist vor dem Umschwenken darauf:

Am 6. Juli 2022 wurden insgesamt 15 Azure Services und Ressources aufgelistet, die "Affected" sind und die folgenden vier Dienste davon sind "nicht recoverable"

  • Azure Active Directory Domain Services
    Dieser Service kann nicht von einem AzureAD zu einem anderen umgezogen werden sondern muss neu im Ziel aufgebaut und davon abhänge Systeme müssen quasi mit allen Folgenden "neu gejoined" werden.
  • Azure Policy
    Richtlinien können maximal exportiert und im Ziel neu angelegt und zu gewiesen werden.
  • Azure Kubernetes Services
    Keine Übernahme möglich
  • Azure SQL databases with Azure AD authentication integration enabled
    Keine Übertragung möglich.

Die Liste ist vermutlich noch nicht komplett.

Umzug: Change Directory

Der Wechsel einer Subscription zu einem anderen AzureAD können sie einfach als Administrator der Subscription im Portal starten.

Ich kann eine Subscription "übergeben" oder "übernehmen", d.h. ich kann ein Subscription-Administrator in dem abgebenden AzureAD sein und mit dem Konto als Gast im Ziel AzureAD mit ausreichend Berechtigungen dort anbinden. Ich kann mich aber auch mit einem ausreichend privilegierten Konto im Ziel-AzureAD anmelden und wenn dieses Konto auch Administrator in der Quell-Subscription ist, kann ich die Subscription quasi "ranholen".

Am einfachsten machen Sie es sich, wenn ihr genutztes Konto in der im jeweils anderen AzureAD als "Gast" angelegt ist und "GlobalAdmin" ist.
Ich nutze dazu immer ein Konto im Ziel-AzureAD, welches als Gast in der Quelle eingeladen und dann zum Administrator über die Subscription in der Quelle gemacht wurde.

I understand that changing directory does not transfer some resources, for example, all Azure role-based access control assignments are deleted (See affected users) and system/user assigned managed identities are invalidated and not transferred to target directory. Learn more
Quelle: Azure  Portal   

Nachbearbeitung

Nachdem die Subscription mit dem neuen AzureAD verknüpft ist, können die alten Berechtigungen natürlich erst einmal nicht mehr wirken. Alle Verweise aus der Subscription auf das Objekt des Quell-AzureAD sind ungültig. Sie müssen also hier die vorab per Export oder manuell dokumentierten Berechtigungen wieder einrichten oder entsprechend dem Berechtigungskonzept im Ziel neu vergeben.

Kontrollieren sie auch, ob die Abrechnungseinstellungen passen. Nicht dass ein Limit im neuen Tenant dazu führt, dass Ressourcen nicht mehr "online" genommen werden oder die Kosten aus dem Ruder laufen.

Aber letztlich müssen Sie am besten Wissen, welche Ressourcen und Dienste in der Subscription mit dem neuen AzureAD betrieben werden. Es kann durchaus sein, dass Sie sogar Ressourcen in einem zweiten Schritt dann in andere Subscriptions verschieben.

Weitere Links