Nachdem ich in Nutanix Prism Central gesehen habe, dass man „IdP“ auswählen kann, musste ich es direkt ausprobieren 🙂
Ein paar Dinge vorab:
- Out of the box müsste man jeden User in Nutanix eintragen
- Es kann nur eine Cluster Admin „Gruppe“ geben
- Rollenzuordnung über Azure AD geht nicht
- Aber man kann tricksen 🙂
Metadata.xml
Zunächst laden wir uns in Prism Central die Metadata.xml herunter.
Azure AD Enterprise Application
Danach registrieren wir in Azure AD ein Enterprise Application. Lasst euch nicht verwirren: Die Nutanix App aus dem Marketplace ist nicht für Prism Central!
Den Namen für die App könnt ihr natürlich frei vergeben.
SAML Konfiguration
Sobald die App erstellt ist, können wir dort die Single sign-on Konfiguration vornehmen.
Wir laden also die zuvor heruntergeladene Metadata.xml hoch.
Die Einstellungen speichern wir.
Damit wir nicht jeden User einzeln in Nutanix eintragen müssen, benutzen wir einen Trick. Wir nehmen ein anderes Attribut von den Users und präsentieren es anstatt des UPNs. In diesem Fall nehme ich den Firmen-Namen. Dafür müssen wir die Claims anpassen.
Die zusätzlichen Claims können wir löschen oder lassen. Prism Central nutzt sie nicht und wir können es ihm auch nicht beibringen. Das ist sehr schade, denn ansonsten könnten wir super mit den Rollen innerhalb der App arbeiten 🙁
Den „required claim“ passen wir nun so an, dass er nicht den UPN zurück gibt, sondern den Firmen-Namen. Später im Artikel zeige ich euch noch eine andere Möglichkeit, nämlich das UPN-Suffix selbst zu nehmen.
Auf Transform umstellen und einen Transform Regeln bauen (Transformation, Parameter und ggf. Value) welche „true“ ergibt und somit den Output triggert.
Speichern und erstmal fertig.
Information für Prism Central sammeln
Prism Central muss wissen womit es es zu tun hat. Darum brauchen wir ein paar Infos.
Azure AD: Azure AD Identifier –> Prism Central: Identity Provider URL
https://sts.windows.net/18faa55d-74f4-4c18-a284-a339279aa756/
Azure AD: Logout URL –> Prism Central: Logout URL
https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0
Certificate in Base64 (als Text)
Azure AD: Azure AD Identifier –> Prism Central: Identity Provider URL
Azure AD: Logout URL –> Prism Central: Logout URL
Azure AD: User Access –> Prism Central: Login URL
Achtung! Login URL wird NICHT benötigt. Statt dessen braucht ihr die User access URL aus den Properties!
Ich habe mir das als kleine Hilfe in eine Text Datei gepackt.
User anpassen
In diesem Beispiel nehmen wir ja das Feld „Company Name“, weshalb ich meinen User noch fix anpassen musste…
Später seht ihr, dass ihr mit den Transform-Regeln auch andere Felder nehmen könntet.
User auf Application berechtigen
Damit der User die App überhaupt nutzen kann und sich einloggen darf, muss er berechtigt werden. Würde ich auch UNBEDINGT so lassen, sonst kann in diesem Setup Hinz und Kunz als Admin auf Prism Central…
Prism Central konfigurieren
Jetzt wo alle Vorbereitungen getroffen wurden, können wir den IdP konfgurieren.
Anzeigename vergeben und Daten manuell eingeben… Er mag die Metadata.xml von Azure leider nicht haben.
Die Werte aus Azure AD wie folgt eintragen:
Certificate in Base64 (als Text)
Azure AD: Azure AD Identifier –> Prism Central: Identity Provider URL
Azure AD: Logout URL –> Prism Central: Logout URL
Azure AD: User Access –> Prism Central: Login URL
Nachdem wir gespeichert haben, muss noch das Mapping konfiguriert werden. Und hier zeigt sich der Vor- aber auch der Nachteil meines Vorgehens…
Wir definieren also die Rollen (in diesem Fall „Cluster Admin“) und definieren den erwarteten Wert. Nämlich den Company Name des Users im Azure AD.
Was heißt das? Das heißt, dass jeder User im Azure AD, der die App zugewiesen bekommen hat UND im seinem Company Feld „PowerShell24“ (nicht case-sensetive) stehen hat, sich an Prism Central anmelden darf und Cluster Admin ist.
Das heißt aber auch, dass Prism Central denkt, dass die ALLE der User „PowerShell24“ wären. Es ist also keine Unterscheidung möglich. Will man eine Unterscheidung, dann darf man am Anfang im SAML Claim nichts ändern, muss aber dafür hier den UPN von JEDEM User eintragen der Admin sein soll.
Sicherheit haben wir trotzdem noch, da wir da App ja im Azure AD zuweisen müssen UND der User muss Mitglied der Firma sein. Bei Gast-Accounts nimmt er bsplw. das Attribut vom eigenen Tenant. Aber ja, es ist ein Risiko, vor allem wenn man nicht die Hoheit über die App-Zuweisung hat, bzw. wenn man dieser einer Gruppe zugewiesen hat und mehrere Leute die Gruppenmitgliedschaft steuern können!
Login testen
Nachdem wir alles gespeichert habe, können wir und an Prism Central mit einem neuen Button anmelden.
Jetzt gibt es eine Weiterleitung zu Azure AD. Alle Conditional Access Policies würden hier entsprechend ihrer Konfiguration greifen!
Und wir sehen: Wir sind als User „powershell24“ angemeldet. Aber wie gesagt: Jeder der sich hier aus dem Tenant anmelden dürfte, würde als „powershell24“ auftauchen. Nur die Frage OB er sich anmelden darf, das entscheidet nun Azure AD.
Weitere Überlegungen
Das mit der Firma ist nur ein einfaches Beispiel um zu zeigen, wie man das abstrahieren kann. Man könnte auch direkt auf das UPN-Suffix gehen, wie in folgendem Beispiel.
Natürlich muss dann auch das Mapping in Prism Central angepasst werden.
Nutanix scheint nur den „namedidentifier“ auszuwerten. Somit haben wir nur die Option Attribute zu nutzen die lediglich einen einzige String zurückgeben, keine Collection. Somit also auch keine Gruppen- und vor allem keine leider keine Rollen-Mitgliedschaften. 🙁
Zusammenfassung
Prism Central an Azure AD anzubinden, ist sicherlich ein nettes Feature, vor allem für Szenarien in welchen eine IT-Dienstleister den Betrieb der Nutanix Installation übernimmt. Dadurch spart man sich interne Accounts, sei es in Nutanix oder innerhalb des ADs. In diesem Fall müsste der Dienstleister für jeden seiner Kunden eine eigene Enterprise Application erstellen und konfigurieren. Ob die Compliance-Richtlinien des Kunden dann aber erlauben, dass der Admin nicht 100% auszumachen ist, ist eine andere Sache. (Wobei die Sign-In Logs in Azure AD auf Seiten des Dienstleisters im Zweifelsfall ggf. Aufschluss geben könnten….)
Leider ist das Thema SAML bei Nutanix jedoch noch nicht komplett ausgereift, es fehlen aber auch nicht viele Dinge. Ad-Hoc fällt mir nur ein:
- Anpassen der Claims
- Bereitstellen einer App im Azure Marketplace
- Ausgereifteres Rollen-Konzept