In einer Kundenanfrage ging es heute darum, wie man sich mit Azure AD Credentials an Linux VMs in Azure anmelden kann. Hierzu gibt es natürlich einen Artikel von Microsoft: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/login-using-aad
Das wichtigste vorab (Stand 18.08.2020):
- Preview Feature
Was die SLA angeht, vielleicht nicht ganz so optimal. :/ - “Currently, Azure network security groups can’t be configured for VMs enabled with Azure AD authentication.”
Je nach Firewall Konzept, ist es also nicht machbar. - Folgende OS Versionen sind supportet:
CentOS 6, CentOS 7, Debian 9, openSUSE Leap 42.3, RHEL 6, RHEL 7, SLES 12, Ubuntu 14.04 LTS, Ubuntu Server 16.04, Ubuntu Server 18.04 - VM sollte mind. “1GB of memory” haben.
- Zudem müssen div. URLs aus der VM heraus erreichbar sein.
VM erstellen
Als erstes brauchen wir natürlich eine passende VM. Zum Testen haben ich mir eine Ubuntu Maschine aus dem Store genommen.
Diese standardmäßig deployen, jedoch mit einer Anpassung bei „Management“. Der Radio Button für „Login with AAD credentials“ muss auf „On“.
Rechte vergeben
Das Deployment läuft dann wie gewohnt weiter. Darum können wir anschl. direkt mit dem Assignment der Rechte weitermachen. Die Rollen heißen „Virtual Machine Administrator Login“ und „Virtual Machine User Login“. Die Namen sind selbsterklärend.
Anmelden
Und los geht der Test. Public IP raussuchen, SSH Client öffnen, connecten und den AAD Usernamen eintickern.
Hier wird es interessant. Er sagt uns, wir sollen auf die URL https://microsoft.com/devicelogin gehen und einen Code eingeben. Dieser ist für diese bestimmte Session wohingegen die URL natürlich für jedermann ist. Gut, dann machen wir das also. Geben wir den Code ein und loggen uns dann wie gewohnt ein. Der Username ist klar, derselbe wie wir ihn im Linux System eingegeben haben, nämlich der entsprechende Azure AD Account.
Ergebnis…
Root Rechte
Wenn man jetzt jedoch einen sudo macht, wird man wieder an die Anmeldung von Microsoft geleitet.
Das Prozedere ist dasselbe. Abhängig davon, mit welchem Browser, welcher Session und welchen Conditional Access Policies ihr kommt, gibt es entsprechende unterschiedliche Verhalten die zu erwarten sind.
Apropos…
Conditional Access
Da der Zugriff über eine Enterprise Application authentifiziert wird, kann man diese für Conditional Access herziehen. Dieses findet man hier.
Also fix eine CA Policy erstellen und testen ob dann MFA erzwungen wird.
Na das hat doch einmal einwandfrei funktioniert. Das Ganze hat aber einen Wehmutstropfen: Es gibt keine Separierung der verschiedenen Linux VMs. Also entweder gilt die CA Policy für alle Linux VMs oder für keine. Ob das in reellen Szenarien eine Rolle spielen wird, muss sich für mich noch zeigen.
Root Rechte und Conditional Access
Wie ist das denn nun mit sudo und MFA? Genauso wie vorher auch. Per Default muss man sudo neu bestätigen. Je nach Browser, Session, etc. muss man das MFA dann aber nicht erneut ausführen, weil man bereit MFA authentifiziert ist, etc.
Azure AD Gast Accounts
Jetzt wird es interessant: Kann man sich mit den Gast Accounts anmelden? Antwort vorweg: Ja, gar kein Problem! Hier erstellen wir nun also einen Gast Account, berechtigen ihn entsprechend und loggen uns ein.
Also, auch das hat wunderbar funktioniert. Und auch das MFA hat gegriffen, weil ja vorher eingestellt wurde, dass ALLE User das machen müssen. Passt soweit.
Home Namen
Pro angemeldetem User wird das Präfix vor dem @ als Username für die Homes genommen. Auf den ersten Blick sieht das nicht schlimm aus.
Bei dem Gast Account ist das genauso.
Aber was wenn der Name schon vorhanden ist? Bei den meisten Tenants wird es das Präfix nur einmal geben, aber bei mehreren Domains und vor allem bei Gast Accounts kann es das Präfix definitiv mehrfach geben. Forcieren wir das doch einmal. Ich erstelle einen Account mit dem gleichen Präfix –> jarmbruster@PowerShell24.de –> danach melde ich mich an.
Und auch hier: Kein Problem. Azure hängt einfach ein _1 hintendran und gut ist. Ja, ist jetzt nicht mehr klar zu unterscheiden, aber es technische gibt es (zumindest in diesem Kontext) keine Constraints.
Abschließende Worte
Linux Leute: Weg mit euren SSH Public Keys! Die Macht gehört den AD Leuten 😀 😀 😀