NetBackup-Smartcard-Authentifizierung: Was Sie prüfen sollten

Wenn die einfache NetBackup-Authentifizierung über LDAP funktioniert, die Smartcard-Authentifizierung aber nicht, konzentrieren Sie sich auf den Zertifikat-Authentifizierungspfad, statt zuerst LDAP neu aufzubauen. Die NetBackup-Smartcard-Anmeldung hängt davon ab, dass mehrere getrennte Teile zusammenpassen: die Benutzerdomäne, RBAC, die vertrauenswürdige Zertifikatskette, das gewählte CN- oder UPN-Mapping-Attribut, das Verhalten bei der Zertifikatssperrung und der Zustand des Web-UI-Dienstes.

Deshalb wirkt das Problem oft undurchsichtig. Ein Administrator hatte bereits CA-Zertifikate geladen, mit und ohne LDAP getestet, Ports geprüft und eine normale LDAP-Anmeldung bestätigt, und trotzdem schlug die Smartcard-Anmeldung weiterhin fehl. Am meisten frustrierte ihn, nicht zu wissen, ob der Fehler an Trust, Mapping oder einem undokumentierten Schritt lag.

Warum kann LDAP funktionieren, während die Smartcard-Anmeldung weiterhin fehlschlägt?

Eine erfolgreiche LDAP-Anmeldung beweist nur, dass NetBackup einen Benutzernamen und ein Passwort gegen das konfigurierte Verzeichnis authentifizieren kann. Die Smartcard-Authentifizierung fügt eine Zertifikatsebene hinzu, bevor NetBackup diese Zertifikatsidentität auf einen Benutzer abbilden kann, der berechtigt ist, die Web UI zu betreten.

Kann sich ein Benutzer normal über LDAP anmelden, ist die Domänenverbindung für die Passwort-Authentifizierung wahrscheinlich ausreichend funktionsfähig. Das beweist nicht, dass das Zertifikat-Subject die erwartete Identität enthält, dass die ausstellende CA von NetBackup als vertrauenswürdig eingestuft wird oder dass das Zertifikat-Mapping-Attribut mit dem NetBackup bekannten Konto übereinstimmt.

Der gemeldete Fall zeigt gut, warum man nicht jeden Anmeldefehler als Verzeichnisproblem behandeln sollte. Der Administrator hatte bereits sowohl den LDAP- als auch den Nicht-LDAP-Pfad ausprobiert. Sinnvoller ist als nächster Schritt, das tatsächlich vom Browser präsentierte Zertifikat zu dokumentieren und es Feld für Feld mit der NetBackup-Konfiguration zu vergleichen.

Wirkt der Fehler eher wie eine Berechtigungsverweigerung nach erfolgreicher Authentifizierung, nutzen Sie den Leitfaden zur Fehlerbehebung bei NetBackup-11-Web-UI und -RBAC, um Identitätsfehler von Autorisierungsfehlern zu trennen.

Welche Voraussetzungen verlangt NetBackup für die Smartcard-Anmeldung?

Für die domänenbasierte Smartcard-Authentifizierung gibt die NetBackup-Dokumentation an, dass die dem Benutzer zugeordnete AD- oder LDAP-Domäne bereits hinzugefügt und RBAC bereits konfiguriert sein muss. Beides sind Voraussetzungen, die vor dem ersten Test der Zertifikatsanmeldung erledigt sein müssen, und keine Aufräumarbeiten für später, wenn die Anmeldung schon läuft.

NetBackup braucht einen Ort, auf den die Zertifikatsidentität abgebildet werden kann. Ein gültiges Zertifikat allein gewährt keinen administrativen Zugriff, denn der Benutzer muss sich weiterhin zu einer Identität auflösen lassen, die NetBackup erkennt, und diese Identität braucht eine Rolle mit den erforderlichen Berechtigungen.

Für die Authentifizierung ohne AD- oder LDAP-Domäne unterstützt NetBackup Benutzer, aber keine Gruppen. Das verändert, wie die Identität in RBAC dargestellt werden sollte, und lohnt sich zu prüfen, wenn Sie sich bewusst für den Pfad ohne Domäne entschieden haben.

Wechseln Sie bei der Fehlersuche nicht wahllos zwischen Domänen- und Nicht-Domänen-Modus. Entscheiden Sie zuerst, welches Identitätsmodell die Umgebung verwenden soll, dokumentieren Sie es, und testen Sie dann gegen genau dieses Design.

Sollte das Zertifikat per UPN oder Common Name gemappt werden?

NetBackup unterstützt Zertifikat-Mapping per Universal Principal Name oder Common Name, und die richtige Wahl ist diejenige, die konsistent auf die in der Umgebung konfigurierte Benutzeridentität abbildet. Eine Abweichung hier kann ein einwandfreies Zertifikat wie einen fehlgeschlagenen Authentifizierungsversuch aussehen lassen.

Ein Smartcard-Zertifikat kann zum Beispiel einen UPN enthalten, der wie user@example.com aussieht, während die Verzeichnis- oder RBAC-Konfiguration das Konto in einer anderen Form identifiziert. Ist NetBackup für das Mapping per UPN konfiguriert, prüfen Sie das Zertifikat und bestätigen Sie, dass der UPN-Wert vorhanden ist und das vorgesehene Konto repräsentiert.

Wenn Sie CN-Mapping wählen, prüfen Sie den Common Name und bestätigen Sie, dass er eindeutig und für das erwartete Konto-Mapping nutzbar ist. Gehen Sie nicht davon aus, dass der auf einem Ausweis aufgedruckte sichtbare Name oder der Windows-Anzeigename mit dem von NetBackup verwendeten Zertifikatsfeld identisch ist.

In der gemeldeten Diskussion fehlte vor allem an dieser Stelle der Einblick in die Diagnose. Geht es speziell um UPN-Mapping, erfassen Sie die Zertifikatsfelder zunächst außerhalb von NetBackup. Die Zertifikatsprüfung im Browser und Standard-Zertifikat-Tools können belegen, welche Identität tatsächlich präsentiert wird, bevor Sie die Serverkonfiguration ändern.

Welche CA-Zertifikate sollten geladen werden?

NetBackup benötigt vertrauenswürdige Root- oder Intermediate-CA-Zertifikate, die den Benutzerzertifikaten oder Smartcards zugeordnet sind. Das Laden eines Zertifikats, das passend aussieht, reicht nicht aus, wenn das präsentierte Zertifikat über ein Intermediate verkettet ist, das NetBackup nicht bis zu einem vertrauenswürdigen Root aufbauen kann.

Die aktuelle Dokumentation akzeptiert gängige Zertifikat-Dateiformate wie CRT, CER, DER, PEM und PKCS #7. Entscheidend ist aber, ob die importierte Kette den Zertifikaten entspricht, die von Benutzern tatsächlich präsentiert werden.

Erstellen Sie ein einfaches Ketten-Inventar. Notieren Sie den Aussteller des Benutzerzertifikats, die Intermediate-CA, die Root-CA, Ablaufdaten sowie ob im Unternehmen mehrere Smartcard-Aussteller existieren. Vergleichen Sie dieses Inventar dann mit den in NetBackup konfigurierten CA-Zertifikaten.

Vermeiden Sie es, themenfremde Trust Anchors zu importieren, nur um zu sehen, ob die Anmeldung dann funktioniert. Das schwächt das Signal bei der Fehlersuche und kann das endgültige Sicherheitsdesign breiter machen als nötig. Fügen Sie die Kette hinzu, der Sie tatsächlich vertrauen wollen, und weisen Sie zuerst diese Kette nach.

Können OCSP oder die Sperrprüfung die Smartcard-Authentifizierung stören?

Ja, die Zertifikatssperrprüfung ist eine weitere Abhängigkeit, die fehlschlagen kann, selbst wenn Zertifikat und Verzeichnisidentität korrekt aussehen. NetBackup erlaubt die Konfiguration einer OCSP-URI, und falls keine angegeben ist, kann die URI im Benutzerzertifikat verwendet werden.

Das erzeugt eine Netzwerkabhängigkeit. Die NetBackup-Seite muss den relevanten Responder erreichen können, wo eine Sperrprüfung erforderlich ist, und der Responder muss ein verwertbares Ergebnis liefern. Eine blockierte Route, eine Proxy-Anforderung, eine veraltete Responder-URL oder ein Zertifikat mit einem nicht erreichbaren OCSP-Standort können zu einem Authentifizierungsfehler werden, der scheinbar nichts mit dem Netzwerk zu tun hat.

Prüfen Sie das Zertifikat auf seine Sperrinformationen und testen Sie dann die Erreichbarkeit von dem System aus, das die Validierung durchführt. Gehen Sie nicht davon aus, dass das Öffnen der OCSP-URL von einem Administrator-Laptop aus beweist, dass der NetBackup-Dienst sie erreichen kann.

Wenn die Richtlinie es zulässt, vergleichen Sie einen kontrollierten Test mit expliziter OCSP-Konfiguration mit der standardmäßig vom Zertifikat bereitgestellten URI. So isolieren Sie die Abhängigkeit, ohne die Sperrprüfung dauerhaft zu schwächen.

Muss der Web-UI-Dienst neu gestartet werden?

Die aktuelle NetBackup-Dokumentation weist Administratoren an, den NetBackup Web Management Console-Dienst nach der Konfiguration der Smartcard-Authentifizierung neu zu starten. Dieser Schritt wird leicht übersehen, da die meisten Web-UI-Einstellungen scheinbar sofort gespeichert werden.

Sind CA-Zertifikate, Mapping-Attribut und Domäne korrekt, verhält sich die Anmeldeoption aber so, als wären noch alte Einstellungen aktiv, bestätigen Sie, dass der dokumentierte Dienst-Neustart für Ihre genaue Produktversion durchgeführt wurde. Öffnen Sie dann eine neue Browser-Sitzung und testen Sie erneut.

An dieser Stelle lohnt es sich auch, Probleme mit der Dienstidentität von der Benutzerauthentifizierung zu trennen. Hatte Ihre NetBackup-Installation selbst Probleme mit dem Windows-Web-Service-Konto, behandelt der Leitfaden zur NetBackup-Domänenkonto-Installation die Prüfungen zu lokaler Gruppe und Dienstanmeldung, die hinter dieser Ebene stehen.

Starten Sie nicht blind jeden NetBackup-Prozess neu. Starten Sie die Komponente neu, die die Produktdokumentation vorgibt, bestätigen Sie den Dienststatus, und führen Sie dann einen einzigen kontrollierten Anmeldetest erneut durch.

Wie sollten Sie einen UPN-Mapping-Fehler ohne brauchbare Logs untersuchen?

Wenn das Produkt in der UI nicht genug Details preisgibt, schaffen Sie an jeder Grenze eigene Belege. Beginnen Sie mit dem Client-Zertifikat, dann die Vertrauenskette, dann das gewählte Mapping-Feld, dann die Verzeichnisidentität, dann RBAC und schließlich den Zustand des Web-UI-Dienstes.

Notieren Sie sich die erwartete Identität auf jeder Ebene: zum Beispiel Zertifikat-UPN, Verzeichniskonto, NetBackup-Domäne, RBAC-Principal und Rolle. Sind diese fünf Strings logisch nicht dieselbe Identität, verdient das Mapping mehr Aufmerksamkeit als Firewall-Regeln.

Testen Sie als Nächstes mit einem bekannten Benutzer und einer bekannten Smartcard. Mehrere Zertifikate, mehrere Verzeichnisdomänen und mehrere RBAC-Rollen erzeugen zu viele Variablen. Sobald ein Konto funktioniert, weiten Sie den Test auf einen zweiten Benutzer aus, um zu belegen, dass die Konfiguration wiederverwendbar ist und nicht zufällig nur auf ein Zertifikat zugeschnitten wurde.

Die Ausgangsdiskussion liefert keine bestätigte versteckte Einstellung und keine endgültige Lösung, und ich will mir hier auch keine ausdenken. Was sie hergibt, ist eine Reihenfolge für die Fehlersuche, mit der ein undurchsichtiger Anmeldefehler in eine kleine Menge testbarer Identitäts- und Zertifikatsabhängigkeiten zerfällt.

Was würde ich in genau dieser Situation zuerst prüfen?

Ich würde die einfache LDAP-Authentifizierung als bekanntermaßen funktionierende Kontrolle beibehalten und die Smartcard-Authentifizierung getrennt untersuchen. Zuerst würde ich den vorgesehenen Domänen-Modus und den RBAC-Principal prüfen. Dann würde ich das tatsächliche Smartcard-Zertifikat inspizieren und bestätigen, dass das konfigurierte UPN- oder CN-Feld zu diesem Principal passt.

Als Nächstes würde ich die vollständige CA-Kette und den OCSP-Pfad validieren, den NetBackup Web Management Console-Dienst wie dokumentiert neu starten und mit einer neuen Browser-Sitzung testen. Wird das Zertifikat vom Browser ausgewählt, NetBackup lehnt es aber weiterhin ab, würde ich den genauen Zeitpunkt und die Benutzeridentität festhalten und mit diesem Beleg eskalieren, statt unzusammenhängende Ports oder LDAP-Einstellungen zu ändern.

Smartcard-Authentifizierung ist eine Kette aus Vertrauen und Identitäts-Mapping, und wenn Sie jede Grenze darin unabhängig nachweisen, wird das Problem meist deutlich kleiner als „Smartcards funktionieren nicht".