NetBackup-11-Installation schlägt mit Domänenkonten fehl

Wenn eine NetBackup-11-Installation unter Windows meldet, dass das Web-Service-Konto nicht existiert, sollte das zunächst gegen NetBackups Anforderungen an das Webserver-Konto geprüft werden, bevor Active Directory selbst verantwortlich gemacht wird. Unter Windows müssen Konto und Gruppe in der von NetBackup erwarteten Form existieren, der Benutzer muss zur Web-Service-Gruppe gehören, und das Konto braucht auf dem Primary Server das effektive Recht „Log on as a service".

Ein aktueller Installationsfall betraf einen Windows Server 2019, der einer Active Directory beigetreten war. Der Administrator wollte ein Domänenkonto verwenden und meldete einen Fehler, der besagte, das Konto existiere nicht oder ein Benutzer in der Gruppe existiere nicht auf dem Primary Server. DNS funktionierte, und eine Gruppenrichtlinie gewährte angeblich „Log on as a service", trotzdem schlug die Installation weiterhin fehl. Diese Kombination macht die lokale effektive Konfiguration wichtiger als Annahmen über die Domäne.

Benötigt ein domänengebundener NetBackup-Server ein Domänen-Web-Service-Konto?

Ein domänengebundener Server benötigt nicht automatisch ein Domänenkonto für NetBackups Web Service. Veritas dokumentiert ein lokales Konto und eine lokale Gruppe als das normale Windows-Beispiel, mit nbwebsvc als Standard-Lokalbenutzer und nbwebgrp als Standard-Lokalgruppe.

Die wichtige Ausnahme ist Clustering. Veritas gibt an, dass für geclusterte Umgebungen unter Windows Domänenkonten verwendet werden müssen. Diese Unterscheidung sollte getroffen werden, bevor das Troubleshooting beginnt. Ein eigenständiger Windows-Primary-Server, der zufällig Mitglied einer Active-Directory-Domäne ist, hat nicht dieselbe Architektur wie ein geclusterter NetBackup-Primary-Server.

Wenn der Server eigenständig ist, kann ein Test mit dem dokumentierten lokalen Kontomuster zeigen, ob Installer und lokale Berechtigungen gesund sind. Wenn der Server geclustert ist, verwenden Sie das erforderliche Domänenkonto-Design und prüfen Sie es konsistent auf jedem beteiligten Node.

Wählen Sie den Kontotyp nicht, weil sich „Domäne mehr nach Enterprise anfühlt". Wählen Sie ihn, weil die Deployment-Architektur und die Sicherheitsrichtlinie es verlangen.

Was verlangt NetBackup vom Web-Service-Konto?

NetBackup benötigt für den Web Service seines Primary Servers ein Konto mit niedrigen Rechten, und Veritas warnt ausdrücklich davor, diesem Benutzer Administratorrechte zu geben. Die Standard-Lokalnamen sind nbwebsvc für den Benutzer und nbwebgrp für die Gruppe, wobei die Namen geändert werden können.

Unter Windows legt das dokumentierte Setup den Benutzer an, legt die lokale Gruppe an, macht den Benutzer zum Mitglied dieser Gruppe und gewährt dem Benutzer das Recht „Log on as a service". Veritas gibt an, dass die Primary-Server-Installation fehlschlägt, wenn diese Anforderungen nicht erfüllt sind.

Es gibt außerdem ein kleines Detail, das ein ansonsten korrektes Domänendesign zunichtemachen kann: Der Windows-Web-Service-Benutzername ist auf 20 Zeichen begrenzt. Lange, beschreibende Servicekonto-Namen sind in Active Directory üblich. Zählen Sie den tatsächlichen Kontonamen, bevor Sie Zeit in DNS- und Richtlinien-Debugging investieren.

Das Konto soll bewusst eingeschränkt sein. Es zu einem lokalen Administrator zu machen, nur um am Setup vorbeizukommen, hebelt das Sicherheitsmodell aus und kann die eigentlich fehlende Berechtigung verschleiern.

Warum kann die Gruppenrichtlinie das Recht als gewährt anzeigen, während das Setup trotzdem fehlschlägt?

Eine Gruppenrichtlinie kann das beabsichtigte Recht beschreiben, während der effektive lokale Zustand auf dem NetBackup-Server trotzdem abweicht. Genau diese Spannung steckte im Installationsfall: Der Administrator sagte, das Domänenkonto habe „Log on as a service" über die Gruppenrichtlinie, während die Kommentatoren ihn immer wieder drängten, die tatsächliche lokale Sicherheitszuweisung zu prüfen.

Prüfen Sie die effektiven Benutzerrechte auf dem Primary Server, nachdem die Gruppenrichtlinie angewendet wurde. Bestätigen Sie, dass die relevante Richtlinie nicht von einer anderen GPO mit höherer Priorität überschrieben wird. Prüfen Sie, ob das Recht direkt dem Konto oder über eine Gruppe gewährt wird, und verifizieren Sie, dass das aktuelle Token des Kontos diese Gruppenmitgliedschaft tatsächlich enthält.

Prüfen Sie auch die gegenteilige Richtlinie. Windows kann die Serviceanmeldung explizit verweigern. Ein Deny-Recht gewinnt gegenüber einem Allow-Recht. Wenn eine Enterprise-Hardening-Richtlinie Servicekonten oder breite Gruppen auf eine Deny-Liste setzt, kann das NetBackup-Konto in einer GPO korrekt aussehen und trotzdem unbrauchbar sein.

Es geht nicht darum, dass die Gruppenrichtlinie unzuverlässig ist. Es geht darum, dass der Installer den effektiven Sicherheitszustand des Servers erlebt, nicht das von den Administratoren beabsichtigte Richtliniendesign.

Wie sollte nbwebgrp bei einem Domänenkonto geprüft werden?

Das vom Web Service verwendete Konto muss als Mitglied der Web-Service-Gruppe erkannt werden, die NetBackup verwendet. Der Standard-Lokalgruppenname ist nbwebgrp, aber benutzerdefinierte Namen sind möglich, prüfen Sie also die genaue Gruppe, die an den Installer übergeben wird.

Prüfen Sie auf einem eigenständigen Windows-Server die lokale Gruppenmitgliedschaft direkt. Wenn ein Domänenkonto verwendet wird, bestätigen Sie, dass die Domänenidentität in der lokalen Gruppe erscheint und sich vom Server aus korrekt auflösen lässt. Verlassen Sie sich nicht darauf, dass das Konto in Active Directory existiert. NetBackup benötigt, dass die Beziehung zwischen dem Benutzer und der konfigurierten Web-Service-Gruppe auf dem Primary Server gültig ist.

Wenn der Fehler besagt, ein Benutzer in der Gruppe existiere nicht auf dem Primary Server, vereinfachen Sie den Test. Entfernen Sie veraltete oder falsch geschriebene Mitglieder aus der Gruppe. Bestätigen Sie, dass nur die beabsichtigte Identität vorhanden ist. Verifizieren Sie, dass der Domänencontroller das Konto auflösen kann und dass der Secure Channel des Servers zur Domäne gesund ist.

Führen Sie anschließend die Voraussetzungsprüfung oder den Installer erneut aus. Ein sauberes Konto und eine saubere Gruppe liefern deutlich bessere Evidenz als eine Gruppe voller geerbter Testidentitäten.

Was sollte vor einer Neuinstallation noch verifiziert werden?

Verifizieren Sie vor der Neuinstallation die Länge des Kontonamens, das Passwort, den Kontostatus, die Gruppenmitgliedschaft, das effektive Recht „Log on as a service" sowie ob das Deployment geclustert ist. Bestätigen Sie außerdem, dass das Konto nicht deaktiviert, abgelaufen, gesperrt oder durch eine Active-Directory-Arbeitsstationsregel von der Anmeldung am Primary Server ausgeschlossen ist.

Verwenden Sie genau das Kontoformat, das der Installer erwartet. Wenn ein Bildschirm DOMAIN\\user verwendet und ein anderer Validierungsschritt einen UPN auflöst, halten Sie die Identität konsistent und prüfen Sie, wie NetBackup sie erfasst. Ein erfolgreicher DNS-Test beweist nur, dass der Server Hosts auflösen kann. Er beweist nicht, dass ein Servicekonto aufgelöst, authentifiziert oder mit lokalen Rechten versehen werden kann.

Wenn eine vorherige fehlgeschlagene Installation teilweise lokale Benutzer oder Gruppen angelegt hat, untersuchen Sie diese vor einem weiteren Versuch. Schichten Sie nicht immer neue Konten über einen veralteten Zustand, ohne zu verstehen, welches davon der Installer tatsächlich verwendet.

Das ähnelt dem allgemeinen Recovery-Troubleshooting. Der Proxmox-Backup-Vergleich behandelt eine andere Plattform, verstärkt aber eine nützliche Gewohnheit: Trennen Sie die Control-Plane-Voraussetzung von der Datenschutzfunktion, bevor Sie das gesamte System verändern.

Sollten Sie mit einem lokalen Konto testen?

Auf einem nicht geclusterten Windows-Primary-Server kann ein lokales Konto eine nützliche Diagnose sein, weil Veritas dieses Setup direkt dokumentiert. Wenn das dokumentierte lokale Muster aus nbwebsvc und nbwebgrp erfolgreich ist, ist der Installer grundsätzlich in der Lage abzuschließen, und der Domänenkonto-Pfad verdient eine genauere Untersuchung.

Das bedeutet nicht, dass ein lokales Konto automatisch zum endgültigen Produktionsdesign werden sollte. Die Sicherheitsrichtlinie kann zentral verwaltete Serviceidentitäten verlangen. Der Test teilt das Problem lediglich auf.

Verwenden Sie diese Abkürzung bei einem geclusterten Windows-Deployment nicht, da Veritas Domänenkonten als erforderlich vorschreibt. Führen Sie stattdessen das Troubleshooting des Domänenkontos korrekt über alle Nodes hinweg durch.

Sobald die Installation erfolgreich ist, dokumentieren Sie, wie das Konto verwaltet wird, woher seine Rechte stammen, wie Passwortänderungen gehandhabt werden und welches Monitoring Service-Logon-Fehler erkennt. Ein Servicekonto ist eine Lifecycle-Abhängigkeit, kein einmaliges Installer-Feld.

Dasselbe Prinzip gilt für die Backup-Repositories im Proxmox-Backup-Server-Guide. Zugangsdaten, Verschlüsselungsschlüssel und Management-Identitäten müssen sowohl die normale Wartung als auch die Ersteinrichtung überstehen.

Was würde ich bei dem Windows-Server-2019-Fehlschlag tun?

Ich würde zunächst klären, ob der Primary Server tatsächlich geclustert ist. Wenn er eigenständig ist, würde ich genau das dokumentierte lokale Kontomuster testen, um den Installer-Pfad zu belegen. Wenn er geclustert ist, würde ich bei einem Domänenkonto bleiben und es auf jedem Node validieren.

Als Nächstes würde ich die Zeichen des Benutzernamens zählen, die nbwebgrp-Mitgliedschaft lokal prüfen, das effektive Service-Logon-Recht des Kontos verifizieren, nach einem Deny-Recht suchen und bestätigen, dass das Konto aktiviert ist und sich am Server authentifizieren darf. „Die GPO enthält die Einstellung" würde ich nicht als endgültige Verifizierung akzeptieren.

Erst nach diesen Prüfungen würde ich neu installieren oder umfassendere NetBackup-Komponenten ändern. Der ursprüngliche Fehler dreht sich um Identität und Gruppenerkennung. Behandeln Sie ihn so, bis Belege in eine andere Richtung weisen.

Die sicherste Lösung ist die, bei der der Web Service mit den eingeschränkten Rechten läuft, für die NetBackup ihn vorgesehen hat. Wenn nur ein Administratorkonto funktioniert, wurde das Problem umgangen, nicht gelöst.