Ein Zweitschlüssel für den XenServer

Um sich an einem XenServer nicht immer als User "root" anmelden zu müssen oder sogar das Kennwort mit Arbeitskollegen teilen zu müssen, kann man ja den XenServer / Pool mit dem Active Directory verbinden und das "role-based access" (RBAC) Konzept benutzen, um AD-User oder -Gruppen mit bestimmten Rollen und Rechten zu versehen.

Dies funktioniert allerdings nur in der lizenzierten Version von XenServer und erfordert Rechte im AD für den Beitritt der XenServer aus dem Pool. Wem dies zuviel ist, der kann sich auch einen weiteren lokalen User (wie "root) anlegen, um sich am XenServer anzumelden.

Dazu muss auf der Shell des XenServers zunächst ein User angelegt werden, der sich prinzipiell anmelden kann und ggf. mit den passenden Rechten ausgestattet ist. Danach ist der Zugriff dieses Users auf die Managementschnittstelle zum XenServer, die XAPI, zu regeln.

Los geht's - am Beispiel des Users "lurch":


  1. User auf der Shell des XenServer Hosts anlegen:
    useradd lurch
  2. Passwort für den User setzen
    passwd lurch
  3. Der User sollte sich nun schon am System und via SSH anmelden können. Damit er sich aber über die XAPI anmelden kann, also z.B. im XenCenter, tragen wir ihn in eine Liste ein. Diese Liste existiert normalerweise noch nicht und wir müssen sicherstellen, dass wir den User "root" nicht aussperren!
    Anlegen der Liste:
    touch /etc/xapi_allow
    dann mit vi oder nano die Liste öffnen und Zeile für Zeile die Xapi-berechtigten User eintragen:
    nano /etc/xapi_allow
    root
    lurch

    In nano kann die Liste mit STRG+O gespeichert werden, beim Versuch, nano zu beenden (STRG+X) wird auch nachgefragt, ob die Änderungen gespeichert werden sollen.
  4. Damit nun nicht jeder User seine Freunde in diese Liste schreibt, sollten die Berechtigungen für diese Liste angepasst werden:
    chmod 600 /etc/xapi_allow
  5. Nun fehlt noch, dass diese Liste auch ausgewertet wird - dazu müssen wir das Authentifizierungssystem anpassen... richtig, hier ist Vorsicht angebracht.
    Zuerst eine Sicherungskopie der bisherigen Konfigurationsdatei erstellen:
    mv /etc/pam.d/xapi /etc/pam.d/xapi.bak
    Dann eine neue, leere Konfiguration erstellen:
    touch /etc/pam.d/xapi
  6. Und die neue Datei mit vi oder nano mit passenderem Inhalt versehen
    nano /etc/pam.d/xapi
  7. Dies ist der neue Inhalt (die Inhalte sind quasi eine Tabelle, deren Spaltenmit mehreren Leerzeichen getrennt sind):
#%PAM-1.0
auth        required   pam_env.so
auth        required   pam_listfile.so item=user sense=allow file=/etc/xapi_allow
auth        sufficient pam_unix.so try_first_pass nullok
auth        required   pam_deny.so

account     required   pam_unix.so

password    required   pam_cracklib.so try_first_pass retry=3
password    sufficient pam_unix.so try_first_pass use_authtok nullok md5
password    required   pam_deny.so

session     optional   pam_keyinit.so revoke
session     required   pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required   pam_unix.so


Spätestens nach einem Neustart des Systems sollte sich nun der User "lurch" über XenCenter anmelden können. Für den Fall eines Pools und eines damit wahrscheinlichen Wechsels der Master-Rolle, sollten diese Änderungen analog natürlich auch auf den anderen Hosts vollzogen werden.

ACHTUNG, diese Modifikation ist vermutlich nicht von Citrix supported und vor dem Einsatz in produktiven Umgebungen noch zu testen! Ich habe ebenfalls nicht getestet, wie und ob sich diese Funktion mit dem RBAC verträgt...
Ich danke den Teilnehmern meines letzten XenServer Kurses in München für den Denkanstoß.

Live long and prosper!


Kommentare

Beliebte Posts aus diesem Blog

Auf NFS Shares mit Windows zugreifen

Citrix Default Passwords

Lokales ISO Repository im XenServer anlegen