EOL MSOnline und AzureAD PowerShell

Lange hat es Microsoft angekündigt aber am 30. März 2024 werden die PowerShell Module "Azure AD", "Azure AD-Preview" und "MS Online" abgekündigt und durch entsprechende Graph-API Aufrufe ersetzt.

Bin ich betroffen?

Ich bin relativ sicher, dass Sie direkt oder indirekt betroffen sind und ich sehe zwei Anwendungsfälle.

  • Aktionen des Administrators
    Ich ich habe immer noch das "Connect-MSOnline" oder "Connect-AzureAD" in den Finger, wenn ich per PowerShell einige Einstellungen lesen oder ändern möchte. Auch auf der MSXFAQ wird es noch einige Zeit entsprechende Anleitungen geben, die auf Commandlets mit *-msol*" oder "*-azuread*" lauten und danach nicht mehr funktionieren.
  • Code und Skripte
    Auch im Bereich "Automatisierung" und "Provisioning kann es entsprechende Skripte geben, die ohne Interaktion eines Administrators gegen Microsoft Online oder AzureAD laufen. Ich selbst habe einige Auswerteskripte im Betrieb, die z.B. mit Get-AzureAD* verschiedene Daten auswerten.

Microsoft sagt, dass mit der Abkündigung es keine Updates oder Fixes mehr für diese Module gibt. Das bedeutet aber nicht, dass diese sofort die Funktion Einstellen. Microsoft schreibt zwar, das die alten APIs noch mindestens 6 Monate verfügbar sein werden, aber auch die Zeit geht schnell vorbei.

Beim Aufruf der AzureAD-PowerShell werden sie schon länger auf das nahende Ende hingewiesen:

Nicht betroffen ist die Exchange Online PowerShell, wobei auch hier der Wechsel zu Exchange PowerShell V3 vor einigen Monaten erfolgt ist. Die früher genutzten Exchange Online PowerShell V2 oder Version1 sind schon lange obsolet. Auch das Azure AD Graph-Modul ist schon seit 30 Juni 2023 ausgelaufen.


https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview

Nutzung ermitteln

An das, was Sie als Administrator interaktiv in eine Shell eintippen, können Sie sich sicherlich erinnern. Aber wie ist das mit all den anderen Aktivitäten. Ich habe ihnen mal ein paar Optionen aufgeschrieben, wie Sie die Nutzung der "alten" Commandlets erkennen können.

Methode Beschreibung

AzureAD Anmeldeprotokolle

Jeder, der sich am AzureAD oder MSOnline anmeldet, hinterlässt mindestens einen Eintrag im Anmeldeprotokoll von Azure. Unter der URL "https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/SignIns" können Sie direkt alle Anmeldungen sehen.

Achten Sie darauf, dass es mehrere Reiter gibt. Nach meiner Recherche nutzen alle drei Module die gleiche AppID:

1b730954-1685-4b74-9bfd-dac224a7b894

Wer nach der GUID sucht, findet direkt einige Seiten, mit denen Sie früher den Zugriff auf die PowerShell beschränken konnten. Nun wird sie natürlich abgeschaltet aber wir können direkt im Portal die Anmeldungen mit der AppID über die letzten 30 Tage abfragen.

Volltext-Suche

Wenn Sie PowerShell Script ausführen, dann könne eine Inventar-Software oder eine Suche z.B. alle PS1-Dateien (u.a.) nach den String "Connect-MSOLService" oder "Connect-AzureAD" durchsuchen.

Get-ChildItem *.ps1 -Recurse | get-content | Select-String "Connect-AzureAD"
Get-ChildItem *.ps1 -Recurse | get-content | Select-String "Connect-MSOLService"

Effektiv kann auch "FindStr" sein

findstr /s "connect-msol" *.ps1
findstr /s "connect-AzureAD" *.ps1

PowerShell Protokolle

Auf dem Client selbst könnte es sein dass Sie "PowerShell Logging" aktiv haben und damit. Das ist aber leider eher die Ausnahme. Verwechseln Sie dieses Logging nicht mit dem Exchange PowerShell Protokolle

Script Errorhandling

Wenn Sie ihre Skript halbwegs professionell geschrieben haben, dann überprüfen Sie mit einem Try/Catch oder "if $error" oder einer Test-Funktion, ob die Verbindung zur Cloud erfolgreich war, ehe ihr Skript weiter arbeitet. Meine Exchange Skripte, mit einem "Connect-ExchangeOnline" haben danach immer einen "Get-Recipient -resultsize 1" o.ä., bei der eine Antwort kommen muss. Wenn der Aufruf dann fehlschlägt oder keine Daten liefert, dann melde ich einen Fehler

Das funktioniert natürlich auch wieder nur, wenn die Fehlermeldung auch bei ihnen ankommt.

Ich hoffe, dass Sie alle betroffenen Skripte und Code-Teile finden und auch 3rd Party Lösungen anderer Hersteller rechtzeitig den Wechsel geschafft haben.

Ablösung durch MSGraph

Microsoft hat schon viele Monate darüber informiert, dass diese "alten" Commandlets mit der entsprechend alten API im Backend zugunsten von Microsoft Graph-basierten Commandlets ersetzt werden.

Leider zeigt die Praxis, dass viele Administratoren noch die alten "gewohnten" Module verwenden, weil Sie vielleicht lange auch der Ansicht waren, dass Microsoft Graph nur was für Entwickler ist, die auf Daten und Einstellungen zugreifen wollen. Das war lange auch meine Einschätzung, dass die Graph API doch eher was mit Daten zu tun hat. Entsprechend gibt es auch Hinweise zur Anpassung:

Dennoch bleibt es ihre Aufgabe, eigene Skripte möglichst schnell zu ertüchtigen:

Auch wenn es aus der Community weitere Tools und Werkzeuge gibt. Die suchen in ihren Skripten nach alten Aufrufen und zeigen ihnen die neuen CMDlets.

Sie stellen aber nichts um oder passen das Skript an. Das bleibt ihre Aufgabe

Authentifizierung als App

Sowohl bei Connect-MSOLService als auch bei Connect-AzureAD können Sie über den Parameter "-Credential" auch die Anmeldedaten für eine Automatisierung mit übergeben.

Beim Befehl "Connect-MGGraph" finden sie diesen Parameter aber nicht. Eine Nutzung von Graph ist zwar auch per Benutzername und Kennwort (Delegated Access) möglich, aber nur mit interaktiver Anmeldung, Per Device Authentication oder mit einem bereits vorhandenen Access-Token. Für die Anmeldung im Skript mit gespeicherten Zugangsdaten gibt es nur folgende Optionen:

  • Application mit Zertifikat
  • Application mit Client Credentials
  • Managed Identity als Skript in Azure
  • Nutzung eines bestehenden Access-Tokens

Für die Automatisierung von Aktivitäten per MgGraph Powershell ist die Nutzung einer App Registration oder Managed Identity aus meiner Sicht Pflicht.
Ein reguläres Benutzerkonto, welches als Dienstkonto missbraucht wird, ist nur Interaktiv zu verwenden.

Das bedeutet natürlich auch, dass Sie nun entsprechende Apps Registrations einrichten und berechtigen müssen. Hier haben Sie nun wieder die Wahl, ob sie nun bequem sind und eine App mit vielen Rechten einrichten, die dann von den verschiedensten Skripten genutzt wird oder ob sie wirklich für jede Lösung eine eigene App mit genau den passenden Berechtigungen nutzen.

Ich würde zur zweiten Variante tendieren, weil dann jedes Skript nur die erforderlichen rechte hat und sie im Azure SignIn-Log auch genau nachvollziehen können. wann welche Skripte laufen

Sie sollten dann aber nicht mit "Client Credentials" arbeiten, die maximal 24 Monate gültig sind.

Bauen Sie sich am besten eine Überwachung, welches die Gültigkeit der App Credentials überwacht und frühzeitig Bescheid sagt.

Authentifizierung als Dienstkonto

Wenn Sie im Internet recherchieren, dann gibt es verschiedene Hinweise, wie sie auch als Benutzer ein "Access-Token" anfordern und dann zugreifen. Letztlich ist es aber eher mühselig und nicht zukunftssicher. Der Zugriff auf die neuen Funktionen von MgGraph erfolgt besser über eine App Registration. Nur über den Weg können Sie aber auch er Azure Admin granular steuern, welche App, also auch welches Skript welche Berechtigungen bekommt. Es gibt aber schon einen Weg, da Connect-MgGraph auch ein AccessToken erlaubt, welches Sie sich selbst besorgen können.

Zuerst melden Sie sich einmal "interaktiv" mit Connect-MgGraph, de erforderlichen "Scope" und dem gewünschten Konto an. Wenn Sie die Consent-Anfrage erhalten, dann müssen Sie sich diese Rechte erst einmal einräumen. Hier ein Beispiel:

Connect-MgGraph `
   -Scopes "Application.Read.All", "Application.ReadWrite.All" `
   -ClientId 14d82eec-204b-4c2f-b7e8-296a70dab67e

Ich nutze hier die ClientID der App "Microsoft Graph Command Line Tools". Schließlich ist das ja MGGraph. Ich melde mich interaktiv mit einem "Userkonto" an und kann über die Consent-Anfrage kann ich, sofern noch nicht schon als Admin erfolgt, die Berechtigungen an diesen Benutzer zuweisen.

Danach habe ich mich mit "Disconnect-MGGraph" gleich wieder abgemeldet. Nun versucht ich mir erst ein Ticket als User zu besorgen, welches ich dann beim Connect-MGGraph verwende.

$cred=Get-Credential
$Token = Get-MSALToken `
            -Scopes "Application.Read.All", "Application.ReadWrite.All" `
            -ClientId 14d82eec-204b-4c2f-b7e8-296a70dab67e `
            -UserCredential $cred `
            -TenantId msxfaqdev.onmicrosoft.com 

$AccessToken = $Token.AccessToken
Connect-MGGraph -AccessToken (ConvertTo-SecureString $AccessToken -AsPlainText)

Die erfolgreiche Anmeldung sehe ich mit "Get-MgContext":

Allerdings hat das bei mir nur mit einem Konto ohne MFA funktioniert oder wenn entsprechende Conditional Access Regeln z.B. mit AzureAD P1 über den Netzwerkstandort erfüllt waren. Ansonsten wurde auch das Token mit z.B. folgender Fehlermeldung nicht ausgestellt:

Machen wir es kurz: Der Wechsel von "Connect-MSOLServer" und "Conect-AzureAD" zu "Connect-MgGraph" ist auch mit einer Umstellung der Authentifizierung verbunden

Empfehlung

Sie müssen an ihre Skripte ran, und das möglichst schnell, denn das Ende der APIs ist nahe und niemand möchte dann unter Zugzwang stehen. Soweit ich gesehen habe, gibt es für fast alle alten CMDLets auch entsprechende Alternativen. Allerdings recht es nicht einfach den "Connect-MSOLService/Connect-AzureAD" durch die Alternative zu ersetzen. Auch im Code drin müssen quais alle *-azuread*" und "-msol*"-CMDets ersetzt und ggfls. Parameter angepasst werden. Eventuell sind damit noch weitere Änderungen am Code erforderlich, der dann natürlich auch wieder versioniert, getestet und in Produktion überführt werden muss.

Bei meinen Umstellungen habe ich gemerkt, dass einige Skripte schon viele Jahre alt waren und meine eigenen PowerShell-Kenntnisse sich seitdem auch weiterentwickelt haben. Einige kürzere Skripte habe ich dann lieber gleich neu geschrieben, weil Sie vielen alten Code und noch auf der PowerShell 2.0 basiert haben. Da war ein Neuanfang mit PowerShell Core und meinen aktuellen Funktionen zur Protokollierung, Alarmierung und Parameterübergabe letztlich besser für den zukünftigen Betrieb.

Auch wenn viele Skripte vielleicht wirklich nur durch ein "Suchen/Ersetzen" der CMDLets weiter funktionieren könnten, würde ich jedes Skript noch einmal in Augenschein nehmen, und zuerst prüfen ob es überhaupt noch benötigt wird oder ob es sogar bessere Wege zum Ziel gibt. Damit ist aber auch klar, das eine Aufwandsschätzung kaum möglich ist. Aber sie müssen da ran, sonst haben sie sprichwörtlich einen heissen Herbst.

Weitere Links