T2T DevOps

Diese Seite beleuchtet die Aspekte eines Tenant Wechsels hinsichtlich Azure DevOps. Mitarbeiter können umbenannt werden oder den Tenant wechseln.

DevOps Abhängigkeiten

Heute kann ja jeder Mitarbeiter mit einem AzureAD Konto sich eine eigene "DevOps Organisation" mit 5 Basis-Lizenzen kostenfrei einrichten. Weitere Details dazu habe ich schon auf Azure DevOps beschrieben. Für diese Seite habe ich mir eine Evaluierungsumgebung aufgebaut.

  • DevOps Organisation
    Das ist so etwas wie der Container, in der sich alles abspielt. Es ist aber kein Tenant aber eine DevOps Organisation hat immer einen Besitzer und ist mit einem AzureAD verknüpft und nutzt eine Azure Subscription für die Abrechnung.
  • AzureAD
    Das ist das Verzeichnis, welches die Identitäten liefert. in DevOps selbst gibt es zwar eine Benutzerverwaltung aber diese verweist immer auf das verknüpfte AzureAD. Eine Azure DevOps Organisation ist immer genau an ein AzureAD verbunden. Ein AzureAD kann aber von mehreren Azure DevOps Organisationen gleichzeitig genutzt werden.

    Damit stellt sich natürlich die Frage, ob ich eine DevOps-Organisation an ein anderes AzureAD verbinden kann und was dann mit den Benutzern passiert
  • Azure Subscription
    Wenn Sie nicht mit den kostenfreien Basis-Lizenzen auskommen, können Sie eine Verbindung zu einer Azure Subscription einrichten. Dabei werden nur die Subscriptions angeboten, auf die ich als angemeldeter Administrator natürlich die Rechte habe.

Es gibt daher schon Abhängigkeiten zum Tenant, die bei einem Umzug der DevOps Organisation in einen anderen Tenant oder den Umzug der Benutzer in einen anderen Tenant beachtet werden müssen.

Einfaches User-Rename

Ehe ich gleich Benutzer oder DevOps Organisationen umziehe, habe ich die einfache Frage beantwortet. Ich habe einen Azure-AD-Benutzer in meinem DevOps-Tenant addiert.

Danach habe ich im AzureAD den UPN des Benutzers umbenannt. Hier in dem Dialog war dennoch nichts zu sehen, aber auf der Karteikarte "Azure Active Directory" wird eine Warnung eingeblendet:

Über den Button "Resolve" kann ich nun einen Benutzer suchen, zu dem die Verknüpfung wieder hergestellt werden kann.

Der Dialog zeigt mir hier den unveränderten Displayname und den UPN. Eine Mailadresse hat mein Objekt im AzureAD nicht. Da aber das DevOps Portal den DevOps User mit "Current Email" anzeigt, interpretiere ich das als Hinweis auf den "primären Schlüssel".

Bei den Rename-Aktionen erkannte DevOps ein Problem aber ich kommt es nicht heilen, da der Benutzer doch noch verbunden war. Ich habe mir dann derart geholfen, dass ich das Mapping temporär auf einen Benutzer umgehängt und dann wieder absichtlich durch ein Rename des temporären Benutzers gebrochen habe.

Im Normalbetrieb sollte das aber nicht erforderlich sein:

Ich habe nun den Benutzer nicht wieder zurück benannt, sondern ich habe einen zweiten Benutzer mit der nun im AzureAD freien Adresse als UPN angelegt und geschaut, wie sich DevOps verhält. Kurz darauf war aber die Warnung im Bereich Active Directory wieder weg. Das vorher "unverbundene Konto" war nun mit dem neuen zweiten Konto verbunden.

Ich habe danach dem Benutzer eine Microsoft 365 E5 Lizenz zugewiesen, um zu sehen, wie es sich mit der Mailadresse verhält. Hier setzt Exchange Online erst einmal die Mailadresse auf den UPN. Danach habe ich UPN und die Mailadresse unterschiedlich eingestellt. In Azure DevOps hat das Benutzerobjekt weiterhin die "clouduser1@..." während im AzureAD kein Benutzer diesen UPN hat.

Allerdings hat ein Benutzer sehr wohl die "clouduser1@..."-Mailadresse und dennoch hat Azure DevOps diesen Benutzer nicht automatisch zugeordnet.

Nach meiner Einschätzung ist der UPN im AzureAD der Schlüssel zur Verknüpfung zum DevOps-Benutzer und der UPN kann geändert werden. Genauer: In DevOps steht der UPN und ich kann den im DevOps Benutzer hinterlegten UPN durch eine manuelle Zuordnung ändern.

Mit dem Grundverständnis kann ich mir nun auch besser vorstellen, wie ein Umzug von Anwendern in einen Tenant und der DevOps-Verknüpfung zu einem anderen AzureAD erfolgen können

Gäste

Allerdings gibt es noch eine zweite Gruppe an Anwendern, die in DevOps mitarbeiten können. Ich kann problemlos auch Personen aus anderen Tenant einladen.

Das geht natürlich nur, wenn der Administrator diese Funktion nicht blockiert hat oder es den Gast im Tenant schon gibt.

Im Azure DevOps erscheint dann aber nicht der UPN in der Form "<userpart>_<domainpart>#EXT#@<tenant>.onmicrosoft.com" sondern einfach "<userpart@domainpart>". Ich würde daher davon ausgehen, dass der Benutzer auch nach dem Umhängen der DevOps Organisation in ein anderes AzureAD damit umgehen kann, wenn es den Gast denn noch gibt.

Umzüge

Nichts ist so beständig wie der Wandel und daher müssen wir uns auch Gedanken darüber machen, welche Veränderungen eine DevOps-Organisation durchmachen kann. Nur ein Fall ist natürlich direkt das Thema dieser Seite aber auch die Beschreibung der anderen Fälle tragen zum Verständnis bei:

Aufgabe

Lösung

Benutzer heiratet

Die Änderung des Nachnamens ändert den UPN, den DevOps zur Identifizierung des Benutzers

DevOps verknüpft das Feld "Mail" in DevOps mit der Identität des Benutzers. Durch eine Heirat ändert sich oft auch der Nachname, der Teil des UPN und der Mailadresse ist. Durch die Änderung im AzureAD findet DevOps den Benutzer nicht mehr. Als DevOps-Administrator finden Sie aber die nun unverbundenen Benutzer und können Sie über "Resolve" wieder verbinden:

Umzug der UPN Domain in einen anderen Tenant

Durch den Umzug einer UPN-Domain können die DevOps Anwender mit diesem Anmeldekonto erst einmal nicht mehr zugreifen.

Wenn Sie nur eine UPN-Domain von einem Tenant zu eine anderen Tenant verschieben aber DevOps nicht ändern, dann können die Anwender mit diesem UPN nicht mehr darauf zugreifen, da DevOps nur genau ein AzureAD abfragen kann. Sie haben nun mehrere Optionen, dieses Problem zu lösen und den Benutzern wieder den Zugriff zu erlauben.

  • Einladen als Gast
    Wenn Sie Anwender mit dem UPN ein Anmeldekonto im neuen Tenant haben, dann können Sie den Benutzer einfach als "Gast" in den Tenant einladen, zu dem DevOps eine Verbindung pflegt. Wenn der UPN des Gast passt, müssen Sie in DevOps gar nichts mehr machen.
  • UPN Anpassen
    Durch den Umzug der UPN-Domain in einen anderen Tenant wurden die Benutzer im QuellTenant ja erst einmal nicht gelöscht. Sie haben nun aber einen anderen UPN, z.B.: den <tenantname.onmicrosoft.com>. Sie können in DevOps nun die nicht mehr verknüpften Benutzer mit diesem UPN verwenden aber natürlich können sie auch hier wieder den DevOps-User an den neuen UPN verbinden. Notfalls ist dass dann ein user@<tenantname>.onmicosoft.com.

Umzug der DevOps Organisation zu einem anderen AzureAD

Eine DevOps-Organisation selbst ist erst einmal komplett unabhängig und eine statische Zuordnung zu einem Tenant gibt es so nicht. Sie kann aber mit einem AzureAD und einer Azure Subscription verbunden sein. Ein Wechsel der AzureAD-Zuordnung bedeutet erst einmal nur, dass die Benutzer und der Administrator eventuell nicht mehr auflösbar sind. Daher würde ich immer erst den Administrator auf ein Konto der Zielumgebung umstellen. Technisch muss der Admin des Ziel-AzureAD als Gast im Quell-AzureAD vorhanden sein, damit der Admin geändert werden kann.

Dann ist die Änderung der AzureAD-Zuordnung einfach möglich. Die normalen Benutzer müssen natürlch auch noch entweder als Gast im neuen AzureAD auflösbar sein oder sie ziehen die Benutzer mit um oder passen die Verknüpfung an.

Umzug des kompletten Tenants

Wie werden also das bisherige AzureAD irgendwann aufgeben.

Dies ist dann der komplette Tenant zu Tenant Umzug (T2T), in dem alle Benutzer, der Administrator und auch die AzureAD-Zuordnung der DevOps-Organisationen anzupassen sind, weil der aktuelle Tenant samt seinem AzureAD in naher Zukunft entfallen soll.

Dieser Fall ist eine Kombination der drei vorher beschrieben Fälle. Eine Checkliste folgt im nächsten Kapitel.

Umzug der DevOps Org

Wir stehen vor der Aufgabe, einen Office365/Microsoft 365 Tenant aufzulösen und müssen alle Objekte in einen neuen anderen Tenant umziehen. Das gilt dann natürlich auch für alle DevOps-Organisationen, in denen es Verbindungen zum AzureAD dieses aufzulösenden Tenants gibt. Mit den entsprechenden Vorbereitungen einer DevOps Organisation, in der ein weiterer Benutzer mit einer nativen Domain und ein Gast enthalten sind, kann ich das System nun umstellen. Laut Microsoft ist das auch nicht unüblich.

Users and groups that inherit membership and permissions from an Azure AD group, will no longer inherit those permissions after the transfer. Azure AD groups that were added to your Azure DevOps organization don't get transferred and will cease to exist in your organization when the Azure AD connection is changed. All permissions and membership relationships made with these Azure AD groups will also cease to exist after the transfer. Also, note that group rules that were enabled on Azure AD groups, will cease to exist when the Azure AD connection is changed.
https://docs.microsoft.com/en-us/azure/DevOps/organizations/accounts/faq-azure-access?view=azure-DevOps#can-i-switch-to-a-different-directory-

Ich werde zuerst die Domain im Ausgangstenant entfernen, womit die Benutzer auch den UPN ändern und dann im Ziel eintragen.

Aktion Erledigt

Voraussetzungen prüfen

Auch wenn der Umzug "per Mausklick im DevOps-Portal" gehen soll, sollten Sie vorab die von Microsoft veröffentlichten Voraussetzungen prüfen. Dies gilt insbesondere, wenn Sie mehr als 100 Benutzer in ihrem DevOps-System haben.

Abhängige DevOps Organisationen auflisten

Sie brauchen dazu als Admin eine DevOps-Organisation, in der Sie selbst DevOps Administrator sind. Wenn Sie noch keine haben, dann können Sie einfach eine DevOps Organisation anlegen und im Bereich "Azure Active Directory" unter https://dev.azure.com/<devopsname>/_settings/organizationAad eine CSV-Datei der verbundenen DevOps-Organisationen auflisten. All diese DevOps Instanzen werden spätestens dann ein Problem bekommen, wenn Sie den UPN umgezogen haben oder anfangen die Benutzer in der Quelle zu löschen.

Die eigentliche Aufgabe ist nun natürlich die Inhaber der DevOps-Organisationen zu ermitteln und den Übergang abzustimmen.

Meine Empfehlung ist hier, den DevOps-Administrator auf einen UPN zu ändert, den es im Ziel schon gibt und einen vom UPN unabhängige Anmeldenamen hat, z.B. ein "devopsadmin@<zieltenant>.onmicrosoft.com.

In dem Zug könnten Sie sich natürlich generell schon einmal Gedanken darüber machen, wie zukünftig DevOps-Organisationen im Unternehmen angelegt und verwaltet werden, z.B. dass normale Anwender erst einmal keine DevOps-Organisationen anlegen dürfen.

Sie sollten den Umzug daher auch dazu nutzen, die verbundenen DevOps-Organisationen zu dokumentieren.

Domain lynclab.net in Quelle entfernen

Ich habe noch die sehr alte DNS-Domain "lynclab.net" im Besitz, welche ich im Quell-Tenant aktiviert und mit Benutzern in einer DevOps-Organisation verbunden hatte. Diese Domain will ich in einen neuen Tenant umziehen. Dazu muss ich sie aus der Quelle erst einmal entfernen. Ggfls. sind ein paar Vorarbeiten erforderlich.

Dazu gehen ich auf https://admin.microsoft.com/#/Domains und löschen die Domain. Das Portal dreht auch die UPNs der Anwender auf die "<tenantname>.onmicrosoft.com"-Domain zurück.

Kontrolle in DevOps

Meinen DevOps Administrator hatte ich vorher schon auf eine <tenantname>.onmicrosoft.com-Adresse gedreht, so dass ich weiter damit arbeiten konnte. Aber DevOps findet nun natürlich die Benutzer erst mal nicht mehr

Ich könnte nun die Benutzer wieder per "Resolve" auf die onmicrosoft.com-Konten drehen, aber das möchte ich erst einmal nicht, denn die Benutzer kommen ja später im neuen Tenant wieder online. Das Gast-Konto wurde durch diese Aktion übrigens nicht unbrauchbar.

Domain im Ziel registrieren

Nachdem die Domain in der Quelle gelöscht war, konnte ich sie problemlos im Ziel addieren.

Anlage der Benutzer und Gruppe im Ziel

Nun galt es im Ziel mal schnell einen Clouduser1@lyncfaq.net anzulegen. Auch die Gruppe "CloudGroup2" habe ich im Tenant angelegt. In Firmen können Sie das auch per ADSync erledigen lassen.

Azure DevOps umziehen

Da ich das alte AzureAD irgendwann ja abschalten will, ist nun ein guter Zeitpunkt, die AzureAD-Zuordnung zu ändern. Dazu muss mein Admin im Zielverzeichnis natürlich als Gast vorhanden sein.

Der "Switch directory"-Schalter ist nur sichtbar, wenn ihr Admin auch im anderen Tenant als Gast oder Member angelegt ist.

Bei mir hat der Zieltenant sich erst noch mit folgender Meldung geweigert:

Da ist mein Ziel wohl schon erst besser abgesichert, dass nicht jeder seine DevOps-Organisation einfach mit einem AzureAD verbinden kann. Ich wollte die Policies im Ziel aber nicht schwächen und habe mich dann zu einem "Pull" entschlossen. Dazu habe ich den Administrator aus dem Ziel-Tenant als Gast in die Quelle eingeladen, dann in DevOps den Gastzugriff aktiviert und den Gast dann in DevOps in die Gruppe "Project Collection Administrators" addiert. So war ich auch gleiche Admin für die weiteren Aktionen und benötigte den Quell Administrator nicht mehr.

Ich habe mich dann als Zieladmin angemeldet und die DevOps Organisation umgehängt.

Das Umhängen selbst war dann erfolgreich aber ich bekam natürlich die Warnung, dass nicht alle Benutzer in der DevOps Organisation bekannt sind und daher sich nicht anmelden können.

Benutzerliste prüfen

Mein erster Blick galt nun der Benutzerliste. Sie ist komplett mitgekommen. Das hat mich erst mal nicht irritiert, da DevOps seine eigene Benutzerliste pflegt:

Interessanter war nun aber, welche Objekte unter "Active Directory" als "disconnected" aufgeführt werden.

Und das war schon überraschend, den DevOps hat anscheinend die Benutzer direkt verbunden, die es sofort finden konnte. Aber er hat nicht nur den regulären "CloudUser1" gefunden, sondern auch die Gastbenutzer, zu denen auch der Admin aus der Quelle gehört. Nicht aufgelöst wurde der absichtlich nicht angelegte "Clouduser2" und mein Net at Work-Konto, welches nicht als Gast vorhanden war.

Ich habe auch eine Gruppe "CloudGroup1" angelegt, die es im Ziel nicht gibt. DevOps meldet aber kein Problem, sondern zeigt mir die Gruppe weiterhin an. Hier habe ich leider die Change verpasst, eine umfangreichre Berechtigungsstruktur vorab aufzubauen.

Heilung/Zuordnung

Auch im echten Leben könnte ich die DevOps Organisation so natürlich nicht stehen lassen. Zwei Benutzer, die keinen Zugriff mehr haben obwohl sie Zugriff benötigen. Ich muss nun dafür sorgen, dass im neuen AzureAD nun die fehlenden Benutzer als Benutzer oder Gäste angelegt werden oder mit bestehenden Konten neu verbunden werden.

Es reicht wirklich einen passenden Benutzer mit übereinstimmenden UPN zu haben, damit DevOps auch ohne manuelle Schritte zufrieden ist.

Owner Anpassen

Durch die Übernahme aller Benutzer und die Mitgliedschaft in den DevOps Gruppen funktioniert schon sehr viel. Kontrollieren Sie dennoch den Besitzer der DevOps Organisation, denn hier stand bei mir natürlich noch der Admin der Quelle drin. Sie müssen dies nicht ändern aber aus Gründen der "Sauberkeit" achte ich schon darauf, dass der Besitzer zum gleichen AzureAD gehört, mit dem auch die Verknüpfung hergestellt wurde. Dies ist aber nicht verpflichtend.

Informieren der Anwender

Durch den Umzug von DevOps ändert sich die URL nicht. Durch den Umzug der Anwender ändert sich allerdings u.a. deren SharePoint/OneDrive -URL, was für DevOps aber nichts zu tun hat. Wenn Sie auch den Benutzer samt UPN mit umgezogen haben, dann kann der Anwender direkt wieder arbeiten. Allerdings ist DevOps schon etwas mehr als nur ein Zugriff per Browser auf eine Webseite. Interessant sind hier aber auch SSH-Schlüssel, PATs (Personal Access Tokens) u.a. die der Anwender ggfls. neu anfordern oder hochladen.

Zusammenfassung

Der Umzug einer DevOps Organisation von einem Tenant zu einem anderen Tenant ist aufgrund der Bindung über den UPN sehr einfach zu bewerkstelligen. DevOps verwaltet seine Benutzer, Gruppen und Berechtigungen eigenständig und die Konfiguration bleibt beim Umzug erhalten. Sie können auch die Anwender problemlos in einen anderen Tenant umziehen und über Gäste wieder einladen. Nur wenn sich der UPN des Benutzers verändert, müssen Sie eine manuelle Zuordnung durchführen.

Weitere Links