Microsoft-Konto vs. Azure-Konto
Ich hatte mal einen Blogartikel, in dem hatte ich nebenbei von leichten Problemen geschrieben, mich per PowerShell an Azure Active Directory (AAD) anzumelden. Mittlerweile hab ich mich etwas schlau gemacht (Thanks, Philippe) und möchte euch das nicht verheimlichen. Also dann…
Das Ganze fing damals damit an, dass ich versucht habe, mit dem Azure PowerShell Modul Benutzer im AAD anzulegen. Was gar nicht geht, sondern nur mit dem Azure Active Directory PowerShell Modul (formerly known as Office365 Admin PowerShell Modul). Dieses wiederum braucht für das Sign-In noch den Microsoft Online Sign-In Assistenten. Aber selbst dann konnte ich mich nicht zum AAD verbinden, erst nachdem ich in AAD selbst über die GUI einen weiteren Azure-Amin angelegt hatte.
Wenn man sich diese beiden Benutzer mal anschaut (Azure-Portal, Verzeichnisdienst, Benutzer), dann sieht man einen Unterschied, und zwar in der Spalte “Quelle”. Der Benutzer, der nicht funktioniert hat, steht dort mit der Quelle “Microsoft-Konto”, der Benutzer, mit dem man sich anmelden kann, hat als Quelle “Microsoft Azure Active Directory”. Beide sind aber “Globaler Administrator” und mit beiden kann ich mich am Portal anmelden, aber nur mit einem der beiden per PowerShell, und zwar mit dem “Azure”-User und nicht mit dem “Microsoft”-User. Was ist jetzt aber der Unterschied?
Wenn man sich zum ersten Mal (als neuer Tenant quasi) bei Azure anmelden möchte, zum Beispiel für den kostenlosen Azure-Test-Zugang, dann steht da am unteren Ende der Webseite ein Link “Haben Sie noch kein Microsoft Konto? Jetzt registrieren”. Klickt man da drauf, dann wird ein – wie es da auch steht – Microsoft Konto angelegt, auch bekannt als Live-ID, MSA etc. Das ist zum Beispiel so etwas wie “tom@wigand.de”. Kaum angelegt, kann man seine Azure-Subscription (im obigen Beispiel kostenfrei) testen und sich anmelden. Prima. Aber genau dieser Benutzer funktioniert nicht mit den Azure Active Directory PowerShell Modul. Weil… das ist ein Microsoft-Konto, kein Azure-AD-Konto. Und das PowerShell-Modul kann nur mit Azure-AD-Konten. Erst nachdem man einen “reinen” Azure-AD-Benutzer angelegt hat, ist der Connect möglich. Was passiert da im Hintergrund?
Azure legt den Benutzer als Microsoft-Konto (MSA) an und gleichzeitig wird eine AD-Domäne zeugt, die eine Unterdomäne (Subdomain) der Standard-Azure-AD-Domäne “onmicrosoft.com” ist. der Domänenname wird aus dem Startbenutzer hergeleitet, in unserem Beispiel wäre es wahrscheinlich so etwas wie “@tomwigand.onmicrosoft.com”.
Jetzt fragt man sich, warum dieser Umweg notwendig ist. Nun, eigentlich ist er das gar nicht. Nur der Link auf der Anmeldeseite ist “schuld” daran. Nimmt man den direkten Weg über die Azure-Anmeldung für Organisationen, dann wird keine Live-ID, äh, ich meine kein Microsoft-Konto angelegt. Mit dem dort angegebenen Benutzer kann man dann auch direkt die PowerShell-Module verwenden. Der Unterschied der beiden Wege ist, dass beim Azure Unternehmensportal etwas mehr Informationen abgefragt werden, unter anderem auch noch eine Domäne.
Hier ein Bild der Eingabemaske. Wie man leicht testen kann, baut die Website den Domänennamen zuerst mal aus Vorname und Nachname auf:
Gibt man aber einen Unternehmensnamen ein, dann wird dieser als Vorschlag angezeigt (ohne Sonderzeichen):
Man kann aber in dem Feld auch direkt seinen Lieblingsnamen eingeben… Die Folgeseiten spare ich mir, es ging ja nur um den Unterschied der beiden Benutzertypen. Da kommt nur eine Verifizierung der Mailadresse und Eingabe der Kreditkartennummer (und nein, da wird nix abgebucht. Ehrlich!)
Nochmal die Zusammenfassung:
- Der Link auf der (leider) weiter verbreiteten Azure-“kostenfrei-testen”-Webseite legt ein Microsoft Account an, das wiederum auf einen Azure-AD-Benutzer abgebildet wird, in dem aus der Mailadresse und “onmicrosoft.com” eine Azure-AD-Domäne automatisch konstruiert wird. Dieses Konto ist nicht für das Azure Active Directory PowerShell Modul geeignet.
- Der Link zur Azure-Anmeldung für Unternehmen legt direkt einen Azure-AD-User an, und der kann auch direkt für das PowerShell-Modul verwendet werden.
So. Alle Klarheiten beseitigt?