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":
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!
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":
- User auf der Shell des XenServer Hosts anlegen:
useradd lurch - Passwort für den User setzen
passwd lurch - 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. - 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 - 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 - Und die neue Datei mit vi oder nano mit passenderem Inhalt versehen
nano /etc/pam.d/xapi - 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
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
Kommentar veröffentlichen