Azure Active Directory mit PowerShell

Dieser Artikel erschien zuerst auf Ralfs Blog.

Da ich ja in meinem früheren Leben einige Zeit lang MVP für Active Directory war, wollte ich mir mal das Azure Active Directory anschauen. Und weil das mit der Powershell so toll ist, dachte ich, ein kurzer Artikel darüber kann nicht schaden. Und tatsächlich, wenn man die ersten Hürden mal überwunden hat, funktioniert auch alles prima. Ich hab mich aber dennoch entschieden, den (Leidens)weg kurz aufzuschreiben, falls einer irgendwo dabei hängenbleibt oder eine Abkürzung nehmen will (so wie ich) und dann nichts funktioniert. Am Ende gibt es die Zusammenfassung für die Ungeduldigen …

Als erstes habe ich mir eine leere Test-Subscription für Azure besorgt (siehe auch Link in der rechten Spalte) mit einer meiner Live-IDs. Geht ja ruck-zuck. Gleich mal im Browser angemeldet und bei den Services auf Azure Active Directory geklickt. Und tatsächlich, meine Windows Live ID war dort als Benutzer im Active Directory schon eingetragen mit der Rolle „Globaler Administrator. Aber ich wollte das ganze ja mit PowerShell machen, also habe ich mir gleich die Azure PowerShell Cmdlets runtergeladen und installiert. Da das etwas länger geht so mit Profile Settings und so habe ich das in einem anderen kurzen Blogartikel aufgeschrieben.

Die ersten Versuche liefen auch ganz gut. Ein get-AzureSubscription zeigte tatsächlich meine Subscription, und auch ein get-AZureVM listete meine eine VM auf, die ich für diese Tests mal nebenbei schnell angelegt hatte.

Wie sind jetzt aber die Kommandos für Azure Active Directory? Auch nach einiger Suche konnte ich keine finden. Und alle Artikel, die ich fand, handelten immer von einem Office Online Service und Office365-Benutzern. Ich war ja aber bei Azure und nicht bei Office365. Die Lösung: Es sind tatsächlich zwei verschiedene Module nötig. Das hat teilweise historische Ursachen, auf die ich jetzt aber nicht näher eingehen werde. Auf jeden Fall wurde das Modul irgendwann einmal umbenannt von „Office 365 Admin PowerShell Modul“ nach „Azure Active Directory Modul„. Also auch noch dieses heruntergeladen und installiert, aber: Überraschung! Dieses Modul benötigt zusätzlich noch den „Microsoft Online Sign-in Assistenten„, also auch noch dieses heruntergeladen und installiert (und den Laptop neu gebootet).

Jetzt aber konnte es endlich losgehen – zumindest dachte ich das. Aber alle Versuche, mit connect-MsolService eine Verbindung herzustellen, scheiterten mit der Meldung, dass Benutzername oder Passwort falsch wären. Testweise nochmal am Portal angemeldet: klappt. Mit PowerShell angemeldet: Klappt micht! Was denn jetzt wieder? Die Windows Live ID, die ich verwendet habe (und mit der das Login am Portal prima klappt), die ist nichts für den Sign-In Assistenten, der kann nur mit „reinen“ AAD-Benutzern arbeiten. Über den Unterschied (und wie man ihn erkennt) werde ich wohl auch noch einen Artikel schreiben müssen…

Die Lösung ist dann aber ganz einfach: Nochmal in das Azure Portal, Und beim Active Directory Service einen weiteren Benutzer anlegen. Das geht ja ganz einfach mit dem entsprechenden Menüpunkt in der Fußzeile, wenn man als Service Azure Active Directory auswählt und auf Benutzer klickt. Wir wählen „neuer Benutzer in Ihrem Unternehmen“, vergeben einen Benutzernamen (zum Beispiel „admin“) und lassen den Domänenteil auf dem länglichen sonstwas.onmicrosoft.com. Im zweiten Fenster wählen wir bei „Rolle“ den „Globalen Administrator““ und klicken uns durch das dritte Fenster durch (und merken uns das neue Passwort). Erledigt.

Da dieser neue Benutzer, den wir später für das PowerShell Login verwenden wollen, sein Passwort bei der ersten Anmeldung ändern muss, empfiehlt es sich, das gleich in der GUI noch zu machen, also abmelden, als der neu angelegte Benutzer admin@sonstwas.onmicrosoft.com anmelden und den Prozess der Passwortänderung durchführen. Ansonsten bekommt man spätestens (so wie ich) beim PowerShell Login die entsprechende Fehlermeldung und muss die GUI neu starten.

Und endlich, endlich ist es soweit: ein get-MsolService liefert uns tatsächlich ein Login. Als Benutzername den vollständigen neuen Benutzer angeben, also admin@sonstwas.onmicrosoft.com. Puh!

Allgemeines

Am Start einer jeden Session steht das Kommando connect-MsolService. Gerne kann man das auch kombinieren mit get-credential wie im folgenden Beispiel:

$cred=get-credential
connect-MsolServce -credential $cred

Die für uns interessanten Befehle (ok, Cmdlets) haben ein „-Msol“ im Namen, also gerne mal für eine lange Liste von möglichen Cmdlets eingeben:

get-command *Msol*

und für einzelne Befehle dann wie üblich in PowerShell ein get-help get-MsolUser oder so.

Benutzerinfos abrufen

get-MsolUser zeigt eine Liste der vorhandenen Benutzer im AAD. Das sind in unserem Beispiel hier genau 2, nämlich der ursprüngliche Benutzer und der neu angelegte Admin-User. Um mit der Bedienung der ganzen (mehr als 15) Optionen vertraut zu werden, habe ich die GUI offen gelassen und dort erst mal ein paar Eingaben gemacht, um dann zu vergleichen, wie sich das auf die Optionen auswirkt. Zum Beispiel kann man in der GUI mal eben schnell einen Ort angeben (Karlsruhe) und dann in der PowerShell eingeben:

get-MsolUser -city Karlsruhe

und schon wird genau dieser Benutzer angezeigt. Die vollständige Liste der Optionen gibt’s wie immer in PowerShell mittels get-help get-MsolUser.

Für alle, die noch nicht so viel mit PowerShell gearbeitet haben (jetzt wird’s aber höchste Zeit!), hier noch ein paar Kommandos, die vielleicht weiterhelfen:

get-MsolUser -userPrincipalName admin@sonstwas.onmicrosoft.com | format-list   (viele Infos zu dem Benutzer)

get-MsolUser | select-object SignInName,LastPasswordChangeTimestamp   (zeigt für alle Benutzer das Datum der letzten Passwort-Änderung an)

Die meisten der Attribute aus dem ersten Kommando können für den zweiten Teil hinter dem senkrechten Strich (das ist das Pipe-Zeichen, da kommt gleich noch was dazu im nächsten Abschnitt) verwendet werden, also auch zum Beispiel für eine Telefonliste. Einfach in der Ausgabe die entsprechenden Felder suchen und dann selektieren:

get-MsolUser | select-object DisplayName,PhoneNumber,MobilePhone

Ganz hilfreich fand ich übrigens noch die Option „searchstring“. Damit wird im Anzeigenamen und in der Email-Adresse gesucht, das hilft zum Beispiel bei der Suche nach Vornamen, da es keinen eigenen Suchparameter dafür gibt:

get-MsolUser -firstname Ralf    geht nicht, aber
get-MsolUser -searchstring Ralf    das geht (natürlich nur, wenn es einen Ralf gibt).

Benutzerinfos verändern

Das mit der GUI mag ja für den Anfang nett sein, aber wir wollten ja mit PowerShell arbeiten, also auf zum nächsten Kommando. Wir wollen die Benutzerinfos jetzt direkt von PowerShell aus ändern. Welcher Befehl könnte das wohl sein? Richtig: set-MsolUser! PowerShell ist so toll…

set-MsolUser -UserPrincipalName admin@sonstwas.onmicrosoft.com -city Berlin

Welchen Benutzer wir verändern wollen, geben wir durch den UserPrincipalName an, und was wir verändern wollen, einfach hintendran. Unser Admin ist jetzt von Karlsruhe nach Berlin umgezogen. Ob das so gut ist? 🙂

Die Angabe des UserPrincipalNames (UPN) ist etwas hinderlich, weil die dann doch recht lang sein können. Wie das einfacher geht? Na, mit PowerShell Pipelines. Wir nehmen einfach die Ausgabe eines Kommandos und reichen die weiter an die Eingabe des nächsten Kommandos. Und müssen uns noch nicht einmal Gedanken machen, welches Feld das ist. Beispiel:

get-MsolUser -city Bonn | set-MsolUser -City Berlin

Der erste Teil sucht alle Benutzer, die in Bonn wohnen. Das sind 0, 1 oder viele. Sie können das Ergebnis ja sehen, wenn sie nur den ersten Teil vor dem senkrechten Strich, dem Pipe-Symbol, eingeben. Uns ist aber ganz egal, wie viele das sind und auch das Format der Ausgabe interessiert uns nicht. Wir reichen das direkt weiter an den zweiten Teil. Der sucht sich schon das passende Feld heraus, um das gewünschte Objekt zu finden, und ändert (für alle) die Stadt nach Berlin ab. So schnell geht das mit dem Umzug von Bonn nach Berlin, wenn unsere Abgeordneten nur damals schon PowerShell gehabt hätten…

Nicht ändern kann man mit diesem Befehl übrigens die Lizenz (set-MsolUserLicense), das Kennwort (set-MsolUserPassword) und den UPN (set-MsolUserPrincipalName).

Neuen Benutzer anlegen

Und weil wir für unsere Tests noch ein paar Benutzer brauchen, legen wir doch welche an mit PowerShell. Wenn wir jetzt gar keine Ahnung haben, wie der Befehl heißt, wie gehen wir vor? Jemanden fragen, der sich damit auskennt? Ok, ein Punkt. Diesen sinnlosen Absatz überspringen und weiter unten nachlesen? Auch ok, aber schade. Nein, im Ernst: Wir wissen ja schon, dass die Befehle alle ein „msol“ für „Microsoft Online Service“ drin haben. Und da wir irgendwas mit einem Benutzer machen wollen, könnten wir ja nach einem Kommando suchen, dass diese beiden dinge enthält:

get-command *MsolUser*

liefert eine recht kurze Liste, und eines der gefundenen Kommandos ist new-MsolUser. Das versuchen wir gleich mal. Infos bekommen wir wie immer mit get-help new-MsolUser. In der Liste der ganzen möglichen Parameter sind zwei, die nicht in eckigen Klammern stehen, dass sind die nicht-optionalen Parameter, die müssen also angegeben werden (DisplayName und UserPrincipalName). Na dann, versuchen wir es einfach mal mit einem rudimentären neuen Benutzer:

new-MsolUser -displayName versuch1 -UserPrincipalName versuch1@sonstwas.onmicrosoft.com

Et voila. Ein neuer User ist entstanden. Und in der Ausgabe in der ersten Spalte sehen wir auch das zufällige Passwort, dass für den Neuen gesetzt wurde. Jetzt machen wir gleich weiter und geben gleich ein paar mehr Infos mit, den Wohnort und die Telefonnummer zum Beispiel (das gehört alles in eine Zeile, klar!):

new-MsolUser -displayName versuch2 -UserPrincipalName versuch2@sonstwas.onmicrosoft.com -city Karlsruhe -phoneNumber „+49 721 12345678“

Auch hier kommt das Passwort in der ersten Spalte der Ausgabe. Aber jetzt haben wir den neuen Mitarbeiter gleich in Karlsruhe hingesetzt, und seine Büronummer wird – wie man in der GUI schön sehen kann – auch gleich in den Länderteil und den lokalen Teil aufgeteilt. Das Aufteilen macht aber nur die GUI, wie wir uns leicht überzeugen können. Wie? Na, jetzt bin ich aber enttäuscht! Einfach mal oben nachlesen…

Und jetzt noch die Königsdisziplin, wir geben auch gleich ein Passwort mit:

new-MsolUser -displayName versuch3 -UserPrincipalName versuch3@sonstwas.onmicrosoft.com -password „veryweak“

Und Gott sei Dank kommt eine Fehlermeldung:

new-msolUser : You must choose a strong password that contains 9 to 16
characters, a combination of letters, and at least one number or symbol.

Neue Benutzer werden nämlich standardmäßig mit der Pflicht für ein starkes Passwort angelegt, wie man auch sehen kann:

get-MsolUser | select-object displayName,strongPasswordRequired

Dann also ein neuer Versuch:

new-MsolUser -displayName versuch3 -UserPrincipalName versuch3@sonstwas.onmicrosoft.com -password „P@ssw0rd“

Und dieses Mal klappt’s. Übrigens auch ein schöner Test, ob jemand die Fehlermeldungen auch durchliest. Mal kurz nachzählen, wieviel Buchstaben das neue Passwort aus Versuch 2 hat, und dann mit der Fehlermeldung vergleichen.Verwundert? Ich auch 🙂

Passwort zurücksetzen

Das Passwort kann natürlich auch zurückgesetzt werden. Hier kann ebenfalls mit dem UPN gearbeitet werden (oder mit der Object-ID, aber ob das lesbarer ist…). Das Kommando hierzu ist (wer hätte es gedacht?):
set-MsolUserPassword

set-msolUserPassword -UserPrincipalName versuch2@sonstwas.onmicrosoft.com -newPassword „P@ssw0rd“

Als Ergebnis wird das Passwort (das neue natürlich!) ausgegeben.

Zusammenfassung

Dann nochmal schnell zusammengefasst:

• Microsoft Online Services Sign-In Assistant for IT Professionals RTW runterladen und installieren
• Azure Active Directory Module for Windows PowerShell (64-bit version) runterladen und installieren
• In der GUI einen Benutzer anlegen (Globaler administrator), die Live-ID reicht nicht.
• als dieser Benutzer an der GUI anmelden und Passwort ändern
• connect-Msolservice

Die englischen Seiten für AAD mit PowerShell sind übrigens hier. Weiter geht’s mit dem nächsten Blogartikel mit weiteren Befehlen.