Native Key Provider nicht kompatibel mit neuer Hardware

[pcpanik]

Hallo zusammen,

zu unseren bestehenden Dell ESXi Hosts ist nun ein HPE ProLiant hinzu gekommen, den ich derzeit einrichte.

Das vCenter meckert an: Host Requires Encryptiopn Mode Enabled Alarm.

Nach Prüfung, ob Secure Boot und TPM sowie ein gesetztes BIOS Passwirt auf der Hardware aktiv sind, habe ich also versucht Encryption einzuschalten:

Host / Configure / System-Security Profile / Host Encryption Mode - Edit... - Enable

Dann erhalte ich folgenden Fehler:

A general runtime error ovccured. Key Provider "mein Key Name" is not compatible witrh the host "HOST". Reason: "The host does not support Native Key Provider."

Da bin ich nun Ratlos, was zu tun ist. Liegt es daran, dass dies nun eine HPE statt Dell Maschine ist?
Was ist zu tun? KB von Broadcom hat mir noch nicht wirklich geholfen, da ist nur die Rede davon, ich soll Secure Boot prüfen. Ist wie gesagt aktiv.
Auch der Hinweise "noch mal neu zum vCenter connecten" ändert nichts.

Falls jemand eine Idee hat, würede ich mich freuen.

[Santa]

Was für ein Server?
Bei älteren Proliant (Gen8/9) ist das TPM nicht auf dem Mainboard, sondern wird auf einer Tochterplatine dazu gesteckt.
Diese Tochterplatinen gibt es mindestens als TPM1.2 und TPM2.0.
Zudem gibt es im BIOS eine Einstellung, die das Vorhandensein eines TPM ans Betriebssystem weitermeldet, aber kein Beschreiben zuläßt.
(visible und enabled)

[irix]

Moin,

also Ausloeser ist das du bei der Konfiguration des Native Key Providers den Haken gemacht hast "Host required TPM".

Die Frage ist nun ob dein neuer Host:
ein TPM hat
ein TPM 2.x hat
das TPM aktiviert ist

Gruss
Joerg

[pcpanik]

Moin zusammen und Danke für eure Antworten.

Der Neue HPE ist ein ProLiant DL385 Gen11 mit TPM 2.0.

In den Technische Daten heißt es: − TPM (Trusted Platform Module) 2.0. Notes: TPM 2.0 is now embedded and no longer requires a separate module option kit.

TPM ist aktiviert, Secure Boot ist aktiviert, Ein UEFI Passwort ist gesetzt. Exakt wie auf den Dell Büchsen. Ich frage mich, wo es hakt?

Das mit der BIOS EInstellung bezüglich Sichtbarkeit checke ich gleich noch mal.

Liebe Grüße

[irix]

Das ist dann eine gute Frage.

Ich wuerde nun nen Supportticket aufmachen.

Gruss
Joerg

[irix]

Ansonsten... hast du VMs mit vTPM im Einsatz? Wenn nein dann wuerde ich den Keyprovider mal neu erstellen. Vom alten hast du ja nen Backup

[pcpanik]

Moin Joerg, Danke für die Antwort. Ja, ich habe TPM VMs im Einsatz .... reichlich. In sofern kann ich den nicht neu machen.

P.S. ich wollte auch gerade nach System-Updates bei HPE schauen, aber deren Support Seite lädt bei mir nicht. Nur weiß.

https://support.hpe.com/connect/s/produ ... ndSoftware

[irix]

Bei Dell kannst du ja was den KeyAlgorythmus angeht was einsellen und ESX haette gerne Sha256* oder besser. Ist beim HPE was höreres eingestellt?

* Das wirst du schon haben weil ist nen Requirement. Die Frage ob alle Hosts gleich sein muessen.

Gruss
Joerg

[pcpanik]

Ich schaue mal im BIOS nach, was dort für Optionen verfügbar sind.
Das ist bei HPE meines Erachtens nach ziemlich unübersichtlich.
Ich Denke zudem, ein Update von allem auf den allerletzten Stand kann auch nicht schaden.
Ich gebe nachher Rückmeldung.

[pcpanik]

Bei Dell kannst du ja was den KeyAlgorythmus angeht was einsellen und ESX haette gerne Sha256* oder besser. Ist beim HPE was höreres eingestellt?

Also im Security Bereich ist TPM Enabled, Visable und auf SHA256 oder SHA384 gestellt. Letzteres habe ich jetzt mal Fix auf SHA256 gestellt. Mal schauen, ob es ein Auswirkung hat. >>>> Edit: Nein, hat es nicht. Ich versuche jetzt noch das neueste Service Pack, wenn das auch nicht hilft mache ich einen Supportfall bei Braodcom auf.

[pcpanik]

Wenngleich der Weg zum Supportfall bei Broadcom schwierig ist, die Antwort kam innerhalb 30 Minuten.

Geholfen hat folgender Weg wobei bitte zu beachten ist:
Vorher sicherstellen, dass ein Backup von vCenter und Datenbank besteht.
Alles geschieht auf eigenes Risiko, ich übernheme keine Garantie auf Richtigkeit und eventuelle Folgen die aus der Nutzung der folgenden Befehele und Schritte entstehen

Worum geht es? > Veraltete Verschlüsselungsdaten aus der vCenter Datenbank löschen

1. Den Host im vSphere Client in den Wartungsmodus versetzen und danach ein Dsiconnect.
2. Beenden des vpxd-Dienst auf der vCenter Server Appliance (VCSA): service-control --stop vmware-vpxd
3. Über die Postgres-Shell eine Verbindung zur vCenter-Datenbank herstellen: /opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres
4. Ermitteln der Host-ID für den betroffenen FQDN: select id, dns_name, crypto_state, crypto_key_id, crypto_key_provider_id, crypto_enable from vpx_host where dns_name='<esxi.host.fqdn>';
5. Löschen der veralteten Informationen anhand der im vorherigen Schritt ermittelten ID: update vpx_host set crypto_state=0, crypto_enable=0, crypto_key_id='', crypto_key_provider_id='' where id=<HOST_ID>;
6. Aus der Postgres-Shell austeigen mit: exit
7. Den vpxd-Dienst neu starten: service-control --start vmware-vpxd
8. Den Host aus dem Datacenter entfernen.
9. Den host wieder hinzufügen

Hat bei mir so funktioniert. Der Support hat es zunächst ohne den Remove des Host beschrieben, das allein löste das Problem aber nicht. Remove und Add Host haben es dann am Ende in Kombination mit dem Entfernen der Daten aus der DB gebracht.