Passwort Richtline bei VMware Linux Appliances einstellen

Über den Sinn von regelmäßigen Passwortwechseln lässt sich lange streiten. Der Zwang, alle x Tage ein neues Kennwort zu vergeben, welches sich vom vorherigen stark unterscheiden muss, halte ich für kontraproduktiv. Aber das ist ein anderes Thema.

Das Szenari, über das ich sprechen möchte, sieht folgendermaßen aus: eine nicht produktive Labor-Umgebung, bei der immer genau dann das Passwort abgelaufen ist, wenn man gerade wichtigeres zu tun hat. Die Appliance xy zeigt mir den virtellen Mittelfinger und nötigt mich zur Eingabe eines neuen Passwortes, das mindestens 5 klingonische Sonderzeichen enthalten muss. Grrr! Dies ist ein nicht-produktives Lab und ich verwende für alle – ja, alle – Dienste und Logins das gleiche Passwort. Es geht um Machbarkeit – nicht Sicherheit.

Bevor das jetzt jemand falsch versteht: 
Ja, im Live-Betrieb wäre das eine sehr dumme Idee.

Password Expiration

Der erste Schritt ist, die Ablaufzeit des Kennworts auf Null (Achtung! nicht bei VCF!) oder einen sehr langen Zeitraum zu setzen. Standardmäßig setze ich hier 9000 Tage ein. Das sind umgerechnet etwa 24 Jahre und 7 Monate. Das sollte reichen 😉

Oftmals lässt sich dieser Wert nicht in der GUI konfigurieren. Dann ist ist die CLI gefragt. Die Einstellung verbirgt sich bei den meisten Linux Varianten in einer Konfigurationsdatei namens login.defs. Wir können auf der shell eine schnelle Abfrage machen.

cat /etc/login.defs | grep PASS

PASS_MAX_DAYS 90
PASS_MIN_DAYS 0
PASS_MIN_LEN 8
PASS_WARN_AGE 7

Voila! PASS_MAX_DAYS ist unsere Passwort Ablaufzeit.

Zur Veränderung müssen wir den vi verwenden, da nur selten andere Editoren in diesen Systemen verfügbar sind. Aber keine Angst vor vi. De ist eigentlich ganz nett. 🙂 Wir öffnen die Konfiguration mit:

vi /etc/login.defs

Jetzt Ruhe bewahren und nur die Taste i (für insert) drücken. Jetzt suchen wir in der Datei die Zeile mit PASS_MAX_DAYS und ändern den Wert auf beispielsweise 9000. Wer möchte, kann auch das Mindestalter PASS_MIN_DAYS auf 0 setzen. Damit kann das Passwort ohne Wartezeit erneut gewechselt werden.

Um unsere Änderung zu speichern drücken wir die ESC-Taste und danach die Taste mit dem Doppelpunkt. Unten links erscheint ein Doppelpunkt und zeigt, dass wir im Command-Modus sind. Wir geben die Zeichen wq (write, quit) und drücken Enter.

Sonderfall NSX-T mit VCF

Die Ablaufzeit der vordenfinierten Konten admin, root und audit unter NSX-T werden auf der Shell des NSX-Mangers mit einem eigenen Kommando gesetzt. Dazu verbindet man sich per SSH mit der Virtual-IP (VIP) des Management Clusters und wird zum aktuellen Master-Knoten weitergeleitet.

Um die Ablaufzeit der drei Konten auf 9000 Tage festzulegen, gibt man folgende drei Befehle ein:

set user admin password-expiration 9000
set user root password-expiration 9000
set user audit password-expiration 9000

In NSX-T Umgebungen ohne VCF dürfen die Ablaufzeiten der Passwörter ganz deaktiviert werden.

Achtung! bei NSX-T in Verbindung mit VCF führt dies aber zu Problemen beim Upgrade. Der Vollständigkeit halber hier die Befehle zur Deaktivierung:

clear user admin password-expiration
clear user root password-expiration
clear user audit password-expiration

Kontrolle

Die Ablaufzeit in NSX-T kann mit folgenden Kommandos abgefragt werden:

get user admin password-expiration
get user root password-expiration
get user audit password-expiration

Passwort History

Normalerweise reichen die obigen Änderungen aus. Wenn wir aber das Ablaufdatum verpasst haben und beim Login ein neues Passwort setzen mussten, dann können wir nicht wieder auf unser altes Passwort zurück wechseln. Das System merkt sich eine definierte Anzahl vergangener Passworte und erlaubt hier kein Recycling. Aber auch das können wir ändern. In vielen Linux Varianten gibt es dafür den daemon für pluggable authentication modules (pam.d). Die Konfiguration liegt unter /etc/pam.d/common-password. Systeme mit root Zugang können statt dessen auch die Konfiguration in /etc/pam.d/system-password haben.

vi /etc/pam.d/system-password

Hier setze ich den Wert remember=0. Damit kann das Wunschpasswort sofort neu gesetzt werden. Als root User genügt auf der shell das Kommando:

passwd

VMware Certified Professional – VMware Cloud Foundation Administrator 2024

Nicht nur ein weiterer Badge im CV, sondern eine Schlüsselrolle mit weitreichenden Auswirkungen.

Bis vor kurzem hatten Mitglieder des VMware vExpert Progamms Zugriff auf ein reichhaltiges Spektrum an VMware Testlizenzen. Somit konnte sichergestellt werden dass diese Spezialisten Praxiserfahrung mit VMware Software erlangen und dieses Wissen in Form von Blogs, Vorträgen oder Video-Tutorials weitergeben konnten.
Dies gilt auch weiterhin, jedoch mit einer Einschränkung:
Das VMware Kernprodukt VMware Cloud Foundation (VCF) ist hiervon ausgenommen.
Um Testlizenzen hierfür zu erhalten, müssen auch vExperts eine Qualifikation zum VMware Certified Professioanl (VCP) für VCF vorweisen können.
Das gleiche gilt für Inhaber der VMUG Adavantage Mitgliedschaft.
Auch hier gibt es künftig VCF Lizenzen nur noch gegen Nachweis der VCP-VCF Zertifizierung (2V0-11.24 oder folgende).
Als VMware Trainer hat es noch eine weitere Implikation. Eine der (vielen) Voraussetzungen, um künftig VCF Kurse lehren zu dürfen ist auch der VCP-VCF.

Um die Grundlagen dafür zu lernen gibt es ein on-demand Training von Broadcom.

Aber nicht nur in Bezug auf Lizenzen ist dieses Training und die Zertifizierung wichtig.
Alle die mit diesem Produkt künftig arbeiten werden, erhalten so Basiskenntnisse über die VCF-Architektur, die Bereitstellung und Day-2-Operations.

VMware Validated Design Guide (VVD) wurde abgekündigt

Wer sich schon einmal mit der Planung und dem Design von IT-Konzepten auf Basis von VMware Produkten beschäftigt hat, dem sollte der VMware Validated Design Guide (VVD) ein Begriff sein.

VMware Validated Design ist eine Sammlung von Empfehlungen für das Datacenter-Design in den Bereichen Compute, Storage, Networking und Management, die als Leitfaden für die Implementierung eines Software-Defined Data Center (SDDC) herangezogen werden können. Die Unterlagen des VVD bestehen aus aufeinander aufbauenden Dokumenten für alle Phasen des SDDC-Lebenszyklus. Die VVD-Dokumentation kann als Erweiterung der VMware Cloud Foundation (VCF) Dokumentation verwendet werden. Jede Version des VVD Guides korreliert genau mit einer bestimmten VCF Version.

Die VVD Version 6.2 für VCF 4.2 wird die letzte bleiben und der Leitfaden wird nicht mehr weitergeführt. Das Erbe des VVD treten die VMware Validated Solutions (VVS) an.

VMware Validated Solutions

VMware Validated Solutions sind technisch validierte Implementierungen, die beim Aufbau einer sicheren und stabilen Infrastruktur auf Basis von VCF unterstützen sollen. Jede VVS umfasst ein detailliertes Design mit Designentscheidungen, sowie eine Implementierungsanleitung. Zur Umsetzung von VMware Validated Solutions ist VMware Cloud Foundation SDDC Manager erforderlich.

Übersetzt bedeutet dies, dass jeder der sich künftig für eine VMware validierte Lösung interessiert, einen Blick auf VCF werfen muss.

NIC Reihenfolge bei VCF Erweiterung

VMware Cloud Foundation (VCF) ist die einheitliche SDDC-Plattform für die Hybrid Cloud. Sie basiert auf der Compute-, Storage- und Netzwerkvirtualisierung von VMware.

VMware Cloud Foundation kann modular um weitere Workload Cluster erweitert werden, oder eine vorhandene Management-Domain über eine zweite Availability-Zone (AZ) gestreckt werden. Der Erweiterungsprozess wird über den SDDC-Manager gesteuert. Der Ablauf hierzu ist im Prinzip recht einfach und der SDDC-Manager übernimmt im Hintergrund alle Konfigurations-Aufgben, wie z.B. die Erzeugung des vSAN Clusters, der Netzwerke, Kernelports, vCenter umd NSX-Manager.

  • Hosts mit ESXi Basisimage installieren
  • Management IP definieren
  • root Login definieren
  • DNS und NTP konfigurieren
  • neue Hosts in den SDDC-Manager importieren
  • WLD erzeugen

Es gibt jedoch einen kleinen Stolperstein, der leicht übersehen wird: Die NIC Reihenfolge der neuen Hosts. Vor dem Import der Hosts wir eine Checkliste angezeigt, die uns darüber informiert, welche Eigenschaften die Hosts haben müssen. Gefordert werden zwei physische NICs mit mindestens 10 GBit.

Was jedoch oft überlesen wird, ist das Prädikat „traditional numbering„. Das bedeutet, die beiden 10 GBit NICs müssen die Nummern vmnic0 und vmnic1 haben. Eine Information, die leider allzuleicht überlesen wird. Diese Reihenfolge ist hart-verdrahtet und läßt sich nicht auswählen. Erschwerend kommt hinzu, dass viele Serversysteme Onboard-Netzwerkadapter haben, die zum Teil in 1 GBit ausgelegt sind. ESXi beginnt bei der Nummerierung der vmnics bei diesen Onboard-Adaptern. In solch einem Fall hätten dann also die geplanten 10 GBit NICs höhere Nummern wie z.B. vmnic2 oder vmnic3. Damit scheitert das Rollout der VCF Erweiterung.

Es ist in der aktuellen VCF Version 4.2 nicht möglich, die NICs explizit zu wählen, wie dies beispielsweise im Bringup-Sheet der Fall ist. Auch die Verwendung von mehr als 2 NICs geht nur über API-Calls und nicht über den SDDC-Manager.

Ausweg

Der einzige Ausweg besteht gegenwärtig darin, die Onboard Adapter im BIOS der Server zu deaktivieren und ggf. den PCIe LAN Adapter in einen Slot mit niedriger Nummer zu stecken, damit die NICs die Nummern 0 und 1 erhalten.