Schlagwort: single sign-on

Veröffentlicht am

vCenter SSO nested groups

Das Modul vSphere Single-Signon (SSO) ist fester Bestandteil der vCenter Installation seit Version 5.1. Es ist ein zentraler Bestandteil und wird daher noch vor dem vCenter Dienst installiert. Justin King hat zum Thema eine sehr gute vierteilige Einführung im vSphere Blog (vmware) geschrieben. Updates von vCenter innerhalb der Version 5.1 hatten schon so einige Tücken, aber beim Upgrade auf Version 5.5 kann es je nach Strukturierung der Benutzergruppen zu Aussperrungen kommen.

Ausgesperrt

Beim Upgrade eines vCenter Servers von Version 5.1 auf 5.5 erlebte ich eine unangenehme Überraschung. Sämtliche vSphere Admins hatten nach dem Upgrade keinen Zugriff mehr auf den Cluster. Alle Benutzer waren Mitglieder der lokalen Admingruppe und als solche hätten sie vollen Zugriff auf vCenter haben müssen. Das Gegenteil war der Fall.

Fehlersuche

Fügte man einen Domänen Benutzer diskret hinzu, so erhielt er Zugriff. Als Mitglied einer Gruppe im Active-Directory konnten dem Benutzer ebenfalls Rechte zugeteilt werden. Der selbe Benutzer als Mitglied einer lokalen Gruppe erhielt keinen Zugriff. Offensichtlich kommt Single-Signon neuerdings nicht mehr mit geschachtelten Domänen Benutzern in lokalen Gruppen zurecht. Nach kurzer Suche wurde dies durch einen Artikel in den vmware-blogs bestätigt. Unter SSO Version 5.1 war dies noch problemlos möglich.

Vorsorge

Meine Empfehlung ist daher, vor dem Upgrade auf Version 5.5 zu kontrollieren, ob die Nutzerrechte über reine Active Directory Gruppen definiert sind. D.h. globale Gruppen mit ADS Usern.

Benutzer im Beispiel 1 erhalten Zugriff. Die selben Benutzer in einer lokalen Gruppe (Beispiel 2) erhalten keinen Zugriff. Das Problem sind hierbei nicht die lokalen Gruppen, sondern deren Verschachtelung mit Domänenbenutzern.

  1. vSphere-Admins (Sicherheitsgruppe, Domäne)
    • Domain\User1
    • Domain\User2
  2. Administratoren (Sicherheitsgruppe, lokal)
    • Domain\User1
    • Domain\User2

Links

 

Veröffentlicht am

vCenter SSO Passwort Troubleshooting

Der Single-Signon Dienst unter vCenter gibt immer wieder Anlass für Kurzweil. 🙂

Was bei der Einrichtung oft übersehen wird, ist die Tatsache, dass das Masterpasswort und andere SSO Passwörter nach 365 Tagen verfallen.
sso_Pass01

Das ist kein Bug, sondern eine Sicherheitsfunktion (ist es das?). Ich persönlich halte nichts von Passwort Alterung. Das führt nur zu unsicheren Passwörten, oder Post-It Aufklebern unter der Tastatur.

Man kann den Ablauf des Passwortes verhindern, indem man den Wert auf Null setzt. Das bedeutet unbegrenzte Laufzeit.

SSO_Pass02

„vCenter SSO Passwort Troubleshooting“ weiterlesen

Veröffentlicht am

VMware SSO Upgrade Error 1603

Tricky update

Der Updatevorgang von vCenter bietet einige Fallen. Insbesondere bei nicht-englischen Windows Versionen müssen besondere Vorbereitungen getroffen werden.

  • Single Signon (SSO) darf nicht über die GUI installiert werden. Ich berichtete darüber in einem früheren Beitrag: “vCenter Update Sequenz“
  • Die zum vCenter gehörenden Dienste müssen installiert und aktiv sein. So scheiterte eine Installation, weil die Komponenete “profile driven storage” nicht richtig installiert war.
  • Es gibt Probleme beim Update, wenn die Setupdateien als ISO in vCenter eingebunden werden. Die Setupdateien müssen entpackt, und in ein lokales Verzeichznis des vCenter kopiert werden.

Fehlerhaftes Rollback

Passiert eine Störung während der SSO Installation, so erscheint ein Fehler 1603 im Setup-Log und der Installer macht ein Rollback. In meinem Fall wurde der erste Upgradeversuch (5.1 -> 5.1 U1b) von einem ISO gestartet und scheiterte. Danach liess sich der vCenter Dienst und der Single-Signon Dienst nicht mehr starten. Erneute Updateversuche mit enpackten Setupdateien von lokalen Verzeichnissen scheiterten ebenfalls. Auch Reboot brachte keine Besserung. Nach intensiver Untersuchung der Setup-Logdatei und Recherche im Internet fand ich einen Blogartikel von Andrew Bruce (softwareAB) und einen VMware Artikel (KB2052738), die zur Lösung führten.

Während des Upgrades stoppt der Installer den SSO Dienst und verändert die  Namen einiger SSO Verzeichnisse auf vCenter, indem er einen 8-stelligen Hexcode an das Verzeichnis anhängt (Beispiel: \lib -> \lib.51a36cb4). Dies wird beim Rollback jedoch nicht wieder entfernt, so daß der SSO Dienst danach seine Programmverzeichnisse nicht mehr finden kann und daher nicht startet. Ohne SSO, kann auch der vCenter Dienst nicht starten und man endet in einer Sackgasse.

Rename to Default

Man kann das Problem lösen, indem man die Verzeichnisse wieder umbenennt und den Hexcode am Ordnernamen entfernt. VMware hat unter KB2052738 alle Verzeichnisse aufgelistet, die beim Setup verändert werden.

C:\Program Files\VMware\Infrastructure\SSOServer\lib
C:\Program Files\VMware\Infrastructure\SSOServer\thirdparty-license
C:\Program Files\VMware\Infrastructure\SSOServer\utils\lib
C:\Program Files\VMware\Infrastructure\SSOServer\utils\jars
C:\Program Files\VMware\Infrastructure\SSOServer\utils\bin\windows-x86
C:\Program Files\VMware\Infrastructure\SSOServer\utils\bin\windows-x86_64
C:\Program Files\VMware\Infrastructure\SSOServer\webapps\ims\WEB-INF\lib
C:\Program Files\VMware\Infrastructure\SSOServer\webapps\sso-adminserver\WEB-INF\lib

Entfernt man bei all diesen Verzeichnissen die Endung .aabbccdd (für einen zufälligen Hexcode), so lassen sich die Dienste wieder starten und das Update erneut (erfolgreich) durchführen.

Patrick von NerdThinking hat hierfür ein Powershell Script geschrieben. Ich habe dieses jedoch nicht getestet und bevorzuge in solchen Fällen die manuelle Ausführung. Benutzung auf eigenes Risiko!

Links

Veröffentlicht am

SSO Identity hinzufügen und entfernen mit CLI

William Lam von virtuallyGhetto beschreibt in einem interessanten Artikel, wie man Single-Sign-on (SSO) Identitätsquellen per Commandline Interface (CLI) hinzufügt oder entfernt.

Wichtigstes Werkzeug ist das Tool rsautil, welches im unten gezeigten Verzeichnis zu finden ist.

..\Program Files\VMware\Infrastructure\SSOServer\utils

Hilfe erhält man mit dem Befehl:

rsautil manage-identity-sources

Für eine Domäne mydomain.com und einem Domaincontroller dc1.mydomain.com lautet der Befehl:

rsautil manage-identity-sources -a create -u admin -p <ssopassword> -r ldap://dc1.mydomain.com --ldap-port 3268 -d mydomain.com -l mydomain --principal-base-dn DC=mydomain,DC=com --group-base-dn DC=mydomain,DC=com -f "" -L administrator@mydomain.com

 Links