avamar-sitzungssicherheit

Was ist Sitzungssicherheit?

Produktsicherheitshandbuch

Avamar Clients können Sitzungssicherheit verwenden, um die gesamte Kommunikation zwischen dem Avamar Server und der Avamar Client-Software zu sichern. Der Avamar Server authentifiziert sich beim Avamar Client und der Avamar Client authentifiziert sich beim Avamar Server.

Die Sitzungssicherheitsfunktionen umfassen Sicherheitsverbesserungen für die Kommunikation zwischen Avamar-Systemprozessen.
Avamar sichert die gesamte Kommunikation zwischen Avamar-Systemprozessen mithilfe von Sitzungstickets. Bevor ein Avamar-Prozess eine Übertragung von einem anderen Avamar-Prozess akzeptiert, ist ein gültiges Sitzungsticket erforderlich.

Die Sitzungstickets weisen die folgenden allgemeinen Merkmale auf:

• Das Sitzungsticket ist verschlüsselt und signiert, um es vor Änderungen zu schützen.
• Das Sitzungsticket ist nur für kurze Zeit gültig.
• Jedes Sitzungsticket enthält eine eindeutige Signatur und ist nur einem Avamar-Prozess zugewiesen.
• Die Integrität eines Sitzungstickets wird durch Verschlüsselung geschützt.
• Die Signatur des Sitzungstickets wird von jedem Avamar-System-Node separat überprüft.
• Bei Bedarf kann eine Sitzung über die Lebensdauer des Sitzungstickets hinaus verlängert werden.

Avamar fungiert als private Zertifizierungsstelle und erzeugt ein eindeutiges Serverzertifikat für das Avamar-System.

Das Avamar-System installiert den öffentlichen Schlüssel für das Serverzertifikat auf jedem Avamar Client, der beim Avamar Server registriert ist. Avamar Clients authentifizieren Übertragungen vom Avamar-System mithilfe des öffentlichen Schlüssels.

Bei Clients, die derzeit registriert sind, werden der öffentliche Schlüssel für das Serverzertifikat und andere erforderliche Zertifikatdateien innerhalb einer Stunde nach der Installation an den Client übertragen.

Das Avamar-System teilt das Avamar Server-Zertifikat auch automatisch mit den Avamar Storage Nodes. Durch das Teilen des Zertifikats können der Utility-Node und die Storage Nodes dasselbe Zertifikat für die Authentifizierung bereitstellen.

Wenn der Avamar Server einen Avamar Client registriert, wird ein Client-Zertifikat erzeugt.

Nach dem Erzeugen eines Client-Zertifikats verwendet das Avamar-System eine verschlüsselte Verbindung zum Avamar Client, um das Zertifikat auf dem Client zu installieren. Das Avamar-System speichert außerdem den öffentlichen Schlüssel für das Client-Zertifikat. Der öffentliche Schlüssel wird verwendet, um den Client bei allen nachfolgenden Kommunikationen zu authentifizieren.

Wie funktioniert die Sitzungssicherheit?

Die Sitzungssicherheit ist auf dem Avamar-Server aktiviert. Wenn die Option aktiviert ist, durchlaufen die Clients, Proxys und Data Domain-Systeme einen speziellen Zertifikatregistrierungsprozess mit Avamar.

Ein Windows- oder Linux-Client und -Proxy sieht bei der Registrierung, dass auf dem Avamar Server Sitzungssicherheit aktiviert ist. Avamar sendet seine interne Stammzertifizierungsstelle an den Client (chain.pem), damit der Client es speichern und ihm vertrauen kann. Der Client erzeugt eine Zertifikatsignieranfrage (Certificate Signing Request, CSR). Die CSR (avclient.csr) wird vom Client an den MCS-Prozess des Avamar-Servers gesendet, der die CSR signiert und ein Schlüsselpaar für das Zertifikat an den Client zurückgibt (key.pem und cert.pem).

Wenn Data Domain auf einer Data Domain an Avamar angehängt wird oder wenn die SSL-Kommunikation aktualisiert wird, stellt Avamar fest, dass die Data Domain kein signiertes Zertifikat von sich selbst oder einem anderen validierten Avamar (imported-host DDBoost). Avamar nutzt Data Domain SSH Privater Schlüssel zum Anmelden bei Data Domain für die Ausführung SSH" über die Data Domin Shell (ddsh). Avamar ruft die Data Domain-Zertifikatsignieranfrage (CSR) über SCP ab und signiert die CSR mit der internen Stammzertifizierungsstelle von Avamar. Sobald Data Domain über das signierte Zertifikat von Avamar verfügt (imported-host DDBoost), importiert Avamar die Stammzertifizierungsstelle, die das Zertifikat signiert hat (chain.pem Mit imported-CA DDBoost/login-auth).

Nachdem ein Client/Proxy registriert ist und über die clientseitigen Zertifikate verfügt, die für die Authentifizierung beim MCS von Avamar erforderlich sind, wird ein Backup versucht. Avamar sendet einen Arbeitsauftrag an den Avagent-Listener des Clients oder Proxys, der den Arbeitsauftrag annimmt. Der Client oder Proxy validiert und verifiziert nun die Zertifikatkette des Avamar Servers mithilfe der Avamar-Stammzertifizierungsstelle, die Avamar bei der Registrierung in den Client importiert hat. Ebenso authentifiziert Avamar den Client oder Proxy. Zu diesem Zeitpunkt wurden noch keine Daten übertragen.

Nach der erfolgreichen Authentifizierung wird der Arbeitsauftrag gestartet und der Status des Arbeitsauftrags ändert sich von „Waiting-Client“ zu „Running“.

Die Clients und Proxys übertragen jetzt Daten an Avamar und die Data Domain unter Verwendung der auf ihnen installierten avtar-Binärdatei. Die avtar-Binärdatei überträgt einige Markierungen, die steuern, wie die Daten und welche Daten verschoben werden.

Wenn avtar auf einem Client oder Proxy eine Verbindung zum GSAN von Avamar herstellt, muss es wissen, ob verifypeer aktiviert ist. Die verifypeer-Einstellung ist eine Einstellung des GSAN-Servers und Teil der Sitzungssicherheitskonfiguration, die den SSL-Sockel von GSAN auf Port 29000 steuert, indem sie ihm mitteilt, ob für jede eingehende Verbindung Client-Zertifikate erforderlich sind oder nicht. Glücklicherweise wurde das TLS 1.2-Protokoll implementiert, das automatisch handhabt, wie ein Client oder Proxy GSAN seine Clientzertifikate während des TLS-Handshake präsentieren soll.

Im Folgenden wird der gegenseitige/bidirektionale TLS-Handshake demonstriert, wenn verifypeer aktiviert ist.
Aus der Client- oder Proxyperspektive zeigt ein nach rechts weisender Pfeil eine Verbindung zum Avamar-Server an. Ein Pfeil nach links zeigt eine Verbindung vom Avamar Server zum Client an.

[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, ClientHello
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerHello
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, Certificate
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerKeyExchange
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, CertificateRequest
[avtar]  <-- TLS 1.2 Handshake, ServerHelloDone
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, Certificate
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, ClientKeyExchange
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, CertificateVerify
[avtar]  --> SSL
[avtar]  --> TLS 1.2 ChangeCipherSpec
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, Finished
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 ChangeCipherSpec
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, Finished

Wenn verifypeer deaktiviert ist, muss der Client kein Client-Zertifikat an GSAN senden.

[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, ClientHello
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerHello
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, Certificate
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerKeyExchange
[avtar]  <-- SSL
[avtar]  <-- TLS 1.2 Handshake, ServerHelloDone
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, ClientKeyExchange
[avtar]  --> SSL
[avtar]  --> TLS 1.2 ChangeCipherSpec
[avtar]  --> SSL
[avtar]  --> TLS 1.2 Handshake, Finished
[avtar]  <-- SSL 
[avtar]  <-- TLS 1.2 ChangeCipherSpec
[avtar]  <-- SSL 
[avtar]  <-- TLS 1.2 Handshake, Finished

Wichtig ist, dass der Client oder Proxy die erforderlichen Client-seitigen Zertifikate erhalten hat, um einen gegenseitigen TLS-Handshake durchführen zu können, wenn dies von GSAN verlangt wird.

Das heißt, wenn sich die interne Avamar-Stammzertifizierungsstelle ändert, müssen die Clients, Proxys oder Data Domains die neue Stammzertifizierungsstelle erhalten, um ihre Zertifikate zu signieren.

Nachdem der Client oder Proxy erfolgreich eine Verbindung zum GSAN hergestellt hat, versucht er, eine Verbindung zur Data Domain herzustellen.

Das folgende Protokoll zeigt einen Proxy, der über avtar eine Verbindung zur Data Domain herstellt. Die verifypeer-Einstellung ist deaktiviert, aber die Sitzungssicherheit ist aktiviert (Authenticated-Single-Modus).

2024-02-22 17:37:32 avtar Info <40058>: - Client connecting to the Avamar Server using authentication, client connecting to the Data Domain system using two-way authentication
2024-02-22 17:37:33 avtar Info <44068>: - Data Domain Engine Set FIPS OFF
2024-02-22 17:37:33 avtar Info <16684>: - Data Domain Engine (7.11.0.0 build 1033042)
2024-02-22 17:37:33 avtar Info <40174>: Multi-stream restore via cloning is enabled.
2024-02-22 17:37:33 avtar Info <10632>: Using Client-ID='6bf19b025be80a12da2e7b932da60079709906ae'
2024-02-22 17:37:33 avtar Info <40062>: GSAN connected via: IPv4, retrieved Data Domain IPv4 hostname = lab.dd.com
2024-02-22 17:37:33 avtar Info <10539>: Connecting to Data Domain Server "lab.dd.com"(1)  (LSU: avamar-1704339590) with auth token
2024-02-22 17:37:33 avtar Info <10540>: - Resolved Data Domain Server name "lab.dd.com" to the IP address "10.x.x.x"
2024-02-22 17:37:33 avtar Info <41236>: - Connecting to Data Domain Server name "lab.dd.com" with token:e2602cc64ce8c4782ca877cabe355191042d0fb4
2024-02-22 17:37:33 avtar Info <0000>: - Connecting to:
DataDomain:           lab.dd.com
encryption strength:  2
auth_mode:            2
client_cert           /usr/local/avamarclient/etc/cert.pem
client_key:           /usr/local/avamarclient/etc/key.pem
server_cert:          /tmp/.tmp_avamar/MOD-1708623043157#1_65d7865c_68ce32dc.pem
chain_cert:           /usr/local/avamarclient/etc/chain.pem

Da verifypeer eine Einstellung des Avamar-GSAN-Servers ist, hat sie keinen Einfluss darauf, wie avtar eine direkte Verbindung zur Data Domain herstellt, wenn Sitzungssicherheit aktiviert ist. Das bedeutet, dass ein gegenseitiger TLS-Handshake zwischen dem Client oder Proxy und der Data Domain stattfindet.

Der Client oder Proxy kann die Data Domain-Zertifikatkette validieren, da sie dieselbe interne Avamar-Stammzertifizierungsstelle verwendet, die von Avamar zum Zeitpunkt der Client-Registrierung (oder Zeitpunkt der Bearbeitung oder des Anschlusses der DD) importiert wurde.

Proxy
------
Avamar internal root CA
/usr/local/avamarclient/etc/chain.pem


Data Domain
--------------
Avamar internal root CA
run command to view certificate list on DD: adminaccess certificate show
imported-ca ddboost


/usr/local/avamarclient/etc/chain.pem == imported-ca ddboost

Nach der Zertifikatsvalidierung wird der Handshake abgeschlossen und die Backupdaten werden vom Client zu Data Domain und Avamar im Netzwerk verschoben.

Verwalten von Sicherheitseinstellungen

Die folgenden beiden Artikel werden verwendet, um die Sitzungssicherheitseinstellungen entweder über die Befehlszeile oder den Avinstaller-Webservice zu managen.

Avamar: Sitzungssicherheitseinstellungen über die CLI
managenAvamar: Managen von Sitzungssicherheitseinstellungen mit dem Avinstaller-Installationspaket (AVP)

Es gibt vier mögliche unterstützte Konfigurationen:

1. Deaktiviert
2. Mixed-Single
3. Authenticated-Single
4. Authenticated-Dual

Deaktiviert

Einstellungen:

Current Session Security Settings
----------------------------------
"encrypt_server_authenticate"                           ="false"
"secure_agent_feature_on"                               ="false"
"session_ticket_feature_on"                             ="false"
"secure_agents_mode"                                    ="unsecure_only"
"secure_st_mode"                                        ="unsecure_only"
"secure_dd_feature_on"                                  ="false"
"verifypeer"                                            ="no"

Wenn die Sitzungssicherheit deaktiviert ist, stellen Clients ausschließlich auf Port 28001 eine Verbindung zum Avagent-Service von Avamar her und die Clients überwachen den Avagent-Port 28002 auf Anfragen von Avamar.

Ein Proxy überwacht den Port 28009.

Port 28001 ist ein einfacher TCP-Sockel, der keine TLS-Handshakes durchführt.

Der Client stellt eine Verbindung zum Avamar-GSAN auf Port 29000 her und führt einen unidirektionalen TLS-Handshake durch. Das bedeutet, dass selbst bei deaktivierter Sitzungssicherheit Backupdaten bei der Übertragung zwischen dem Client und Avamar weiterhin während der Übertragung verschlüsselt werden.

Zertifikate für die Authentifizierung mit der Avamar-Software werden nicht zwischen Avamar, Proxys, Clients und Data Domain ausgetauscht.

Mixed-Single

Einstellungen:

Current Session Security Settings
----------------------------------
"encrypt_server_authenticate"                           ="true"
"secure_agent_feature_on"                               ="true"
"session_ticket_feature_on"                             ="true"
"secure_agents_mode"                                    ="mixed"
"secure_st_mode"                                        ="mixed"
"secure_dd_feature_on"                                  ="true"
"verifypeer"                                            ="no"

Der Mixed-Single-Modus wurde bei der Einführung der Sitzungssicherheit in Avamar 7.3 häufiger verwendet, sodass insbesondere Clients, deren Version nicht 7.3 oder höher war, sich bei Avamar registrieren und Backups auf Avamar durchführen konnten. Zum Zeitpunkt der Erstellung dieses Artikels ist Avamar 19.10 die aktuelle Version und Mixed-Single ist im Wesentlichen identisch mit dem als nächstes vorgestellten Modus: Authenticated-Single.Authenticated-SingleEinstellungen:

Authenticated-Single

Einstellungen:

Current Session Security Settings
----------------------------------
"encrypt_server_authenticate"                           ="true"
"secure_agent_feature_on"                               ="true"
"session_ticket_feature_on"                             ="true"
"secure_agents_mode"                                    ="secure_only"
"secure_st_mode"                                        ="secure_only"
"secure_dd_feature_on"                                  ="true"
"verifypeer"                                            ="no"

In diesem Modus ist die Sitzungssicherheit aktiviert und die Zertifikate werden zur Authentifizierung vor einem Backup zwischen Avamar, den Clients, Proxys und Data Domains übertragen.

Clients überwachen jetzt Port 30002 auf Avagent-Arbeitsauftragsanfragen von Avamar, während Proxys Port 30009 überwachen. Avamar überwacht die Ports 30001 und 30003 auf Verbindungsanfragen von Clients und Proxys. Hierbei handelt es sich um SSL-Sockel, die TLS-Handshakes durchführen.

Im Gegensatz zum Mixed-Single-Modus zwingt der Authenticated-Single-Modus alle Clients dazu, sich unter Verwendung von Sitzungssicherheitsmethoden zu registrieren.

In diesem Modus wird verifypeer im Avamar-GSAN deaktiviert, was bedeutet, dass GSAN keine Client-Zertifikate von einer eingehenden avtar-Verbindung benötigt.Authenticated-DualEinstellungen:

Authenticated-Dual

Einstellungen:

Current Session Security Settings
----------------------------------
"encrypt_server_authenticate"                           ="true"
"secure_agent_feature_on"                               ="true"
"session_ticket_feature_on"                             ="true"
"secure_agents_mode"                                    ="secure_only"
"secure_st_mode"                                        ="secure_only"
"secure_dd_feature_on"                                  ="true"
"verifypeer"                                            ="yes"

Authenticated-Dual ist identisch mit Authenticated-Single, außer dass die verifypeer-Einstellung für den GSAN-Service von Avamar aktiviert wird.

Authenticated-Dual gilt als stärkste Einstellung, die auf einen Avamar Server angewendet werden kann, und ist die Standardauswahl bei Avamar-Bereitstellungen.Übersicht:

Übersicht: Interne selbstsignierte Root-CA von Avamar

Interne selbstsignierte Avamar-StammzertifizierungsstelleDie interne Stammzertifizierungsstelle von Avamar ist eine intern vertrauenswürdige Zertifizierungsstelle für Avamar und die Clients und Proxys sowie Data Domains, die Avamar in diese importiert.

Avamar ist die interne Zertifizierungsstelle für sich selbst, da es Zertifikate für Zertifikatsignieranfragen (CSRs) ausstellt.

Wenn Avamar seine Stammzertifizierungsstelle verwendet, um Zertifikate für GSAN zu signieren, werden diese am folgenden Speicherort gespeichert:

/home/admin/chain.pem
/home/admin/cert.pem
/home/admin/key.pem

/usr/local/avamar/etc/chain.pem
/usr/local/avamar/etc/cert.pem
/usr/local/avamar/etc/key.pem

Wenn ein Sicherheitsscanner Port 29000 auf Avamar scannt, meldet er selbstsignierte Zertifikate auf dem Port, der Backups an GSAN verarbeitet.

In einigen Umgebungen ist dies möglicherweise nicht akzeptabel und es wird empfohlen, den folgenden Dell Artikel zu lesen, um weitere Informationen zum Ersetzen der internen Avamar-Stamm-CA durch eine vom Nutzer bereitgestellte interne Root-CA zu erhalten.

Avamar: Installieren oder Ersetzen der Avamar-Zertifizierungsstelle (CA) durch eine vom Nutzer bereitgestellte Zertifizierungsstelle (CA) 

Der Prozess beschreibt detailliert, wie Sie das importcert.sh Skript verwenden, um eine vom Nutzer bereitgestellte Zertifizierungsstelle intern für das Unternehmen zu installieren. Die vom Nutzer bereitgestellte Zertifizierungsstelle wird höchstwahrscheinlich vom Sicherheitsteam verwaltet, da keine öffentliche Zertifizierungsstelle ihren privaten Schlüssel herausgibt. Schließlich verdienen sie ihr Geld damit, Zertifikate für andere zu signieren und eine Vertrauenskette aufrechtzuerhalten.

Ein Beispiel für eine interne Zertifizierungsstelle sind die Microsoft Active Directory-Zertifikatdienste.
Was sind die Active Directory-Zertifikatdienste? | Microsoft Learn

Ein Beispiel für eine öffentliche Zertifizierungsstelle ist DigiCert.

Um die interne Avamar-Stammzertifizierungsstelle zu ersetzen, muss das Schlüsselpaar der Stammzertifizierungsstelle im Avamar Keystore durch das Schlüsselpaar der vom Nutzer bereitgestellten Zertifizierungsstelle ersetzt werden. Dann erzeugt GSAN eine CSR und einen privaten Schlüssel, lässt die CSR vom Schlüsselpaar der neuen Zertifizierungsstelle signieren und anschließend werden die zuvor in diesem Abschnitt erwähnten Dateien ersetzt. GSAN lädt den SSL-Sockel erneut auf Port 29000 und neue Clients, die eine Verbindung zum GSAN herstellen, sehen die vom Nutzer bereitgestellte Zertifizierungsstelle.

Sicherheitsscanner zeigen nun signierte Zertifikate auf dem Port an und Clients, Proxys und Data Domains müssen sich erneut registrieren, um die neue Zertifizierungsstelle zu erhalten.EinschränkungenDie Sicherheitsfunktionen für Avamar-Sitzungen unterliegen jedoch einigen Einschränkungen:

Einschränkungen

Die Avamar-Sitzungssicherheitsfunktionen unterliegen einigen Einschränkungen:

• Clients
  • Die Sitzungssicherheitsfunktionen können mit den folgenden Avamar Clients nicht verwendet werden:
    • Avamar Clusterclient für Solaris auf Veritas Cluster Server
    • Avamar Client für Solaris in Solaris-Clustern
• Andere Produkte
  • Es wird empfohlen, auf dem Avamar Server, den Avamar Clients und dem Data Domain-System (falls zutreffend) die NTP-Zeitsynchronisierung zu verwenden. Wenn die Zeit nicht synchronisiert ist, kann dies aufgrund der Gültigkeitsdauer und der Ablaufzeiten von Zertifikaten zu Registrierungs- und Backup-/Wiederherstellungsfehlern führen. Das Ändern der Zeitzone auf einem Host kann ähnliche Auswirkungen haben und möglicherweise eine Neuerzeugung des Zertifikats erfordern.
• Sicherheitstoken
  • Die Authentifizierung mittels Sicherheitstoken funktioniert unter den folgenden Bedingungen nicht:
    • Der Client-Computer befindet sich hinter einem NAT-Firewallgerät (Network Address Translation)
    • Der Hostname des Clients ist ein virtueller Name, der sich vom FQDN unterscheidet, der von seiner IP-Adresse aufgelöst wird.
    • Der Client-Computer verfügt über mehrere IP-Schnittstellen und jede wird in einen anderen vollständig qualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) aufgelöst. Weitere Informationen finden Sie im folgenden Dell Artikel: Avamar: Backup auf Data Domain ist aufgrund zu vieler IP-Adressen mit der Meldung "DDR_GET_AUTH_TOKEN" fehlgeschlagen 

Planung von Sitzungssicherheitsänderungen

Geplante Änderungen an der SitzungssicherheitBevor Sie eine Änderung an den Sitzungssicherheitseinstellungen vornehmen, können Sie die folgenden Schritte ausführen, um die vorherige Konfiguration oder die vorherigen Zertifikate wiederherzustellen, bevor Sie Änderungen vornehmen.

Denken Sie daran, dass Clients, Proxys und Data Domains neu registriert werden müssen, wenn die interne Stammzertifizierungsstelle von Avamar geändert wird. Je nach Größe der Umgebung (Anzahl der Clients, Proxys und Data Domains) kann dies eine langwierige Aufgabe sein, die sich über mehrere Tage erstreckt.

Der Anwendungsfall würde sich ergeben, wenn Zertifikate neu erzeugt werden und dann Registrierungs- und Backupfehler auftreten.

Unter der Annahme, dass die Zertifikate noch nicht abgelaufen sind bzw. in Kürze ablaufen und möglicherweise versehentlich neu erzeugt werden, bieten die folgenden Schritte Unterstützung, um Datenverluste oder eine Nichtverfügbarkeit von Daten zu vermeiden.

Rufen Sie die aktuellen Sitzungssicherheitseinstellungen ab und notieren Sie sie:

enable_secure_config.sh --showconfig

Erstellen Sie eine Kopie des Avamar Keystores:

cp -p /usr/local/avamar/lib/avamar_keystore /usr/local/avamar/lib/x-avamar_keystore-original

Angenommen, die Zertifikate wurden jetzt neu erzeugt, entweder über das Sitzungssicherheits-AVP oder die CLI.

Dadurch wurde der Avamar Keystore geändert und die GSAN-Zertifikate wurden neu signiert.

Der ursprüngliche Avamar Keystore kann nun einfach wieder an seinen Speicherort verschoben werden:

cp -p /usr/local/avamar/lib/x-avamar_keystore-original /usr/local/avamar/lib/avamar_keystore

Erzeugen Sie die GSAN-Zertifikate neu:

enable_secure_config.sh --certs

Starten Sie MCS und den Backup Scheduler neu:

mcserver.sh --restart --force
dpnctl start sched

Dadurch wird die ursprüngliche interne Avamar-Stammzertifizierungsstelle wiederhergestellt, der Clients, Proxys und Data Domain bereits vertrauten.

Beim Troubleshooting

In den meisten Fällen ist das Ändern der Sitzungssicherheitseinstellungen oder das erneute Generieren von Zertifikaten unkompliziert.

In diesem Abschnitt wird erläutert, wie alles wieder funktioniert, nachdem Zertifikate neu erzeugt oder Einstellungen geändert wurden.

Lokale Leerungen

Wenn in dem Szenario, in dem verifypeer aktiviert ist, alle Avamar Zertifikate neu erzeugt werden, werden die Clientzertifikate, die avtar und avmgr des Avamar -Servers verwenden, nicht sofort aktualisiert.

Das bedeutet, wenn MCS eine geplante Leerung (Backup der MCS-Konfiguration auf GSAN) ausführt, schlägt diese aufgrund eines TLS-Handshake-Fehlers fehl. Dies liegt daran, dass die auf dem Avamar-Server ausgeführten Avamar-Clientzertifikate für avtar noch nicht die aktualisierte interne Avamar-Stammzertifizierungsstelle und den neuen Satz signierter Clientzertifikate erhalten haben.


Replikation

In dem Szenario, in dem verifypeer auf dem Replikationsziel aktiviert ist und Zertifikate auf dem Ziel neu erzeugt werden, muss ein ähnlicher Ansatz wie im obigen Abschnitt "Lokale Leerungen" gewählt werden.

Stellen Sie zunächst sicher, dass der Replikationsziel-Avagent registriert ist, damit er Replikationsarbeitsaufträge akzeptieren kann.

Überprüfen Sie auf dem Ziel das Avagent-Protokoll an folgendem Speicherort:

/usr/local/avamar/var/client/avagent.log

Ein fehlerfreies Protokoll könnte wie folgt aussehen:

2024-02-22 15:31:57 avagent Info <5964>: Requesting work from avamar.lab
2024-02-22 15:31:57 avagent Info <5264>: Workorder received: sleep
2024-02-22 15:31:57 avagent Info <5996>: Sleeping 15 seconds
2024-02-22 15:32:12 avagent Info <40019>: Checking certificate status.
2024-02-22 15:32:12 avagent Info <43701>: agent_message::resolve_client_ip ping to MCS avamar.lab:10.x.x.x using local IP:10.x.x.x failed, timed out on receive


2024-02-22 15:32:12 avagent Info <5964>: Requesting work from avamar.lab
2024-02-22 15:32:12 avagent Info <5264>: Workorder received: sleep
2024-02-22 15:32:12 avagent Info <5996>: Sleeping 15 seconds

Wenn Sie das Protokoll weiter durchgehen, finden Sie möglicherweise eine kürzlich durchgeführte erfolgreiche Neuregistrierung:

2024-02-22 15:09:00 avagent Info <7502>: Registration of client /MC_SYSTEM/avamar.lab with MCS avamar.lab:30001 successful.
2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1008 Replicate successful.
2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1038 vmir successful.
2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1046 Migrate successful.
2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1051 Tiering successful.
2024-02-22 15:09:00 avagent Info <5619>: Registration of client and plugins complete.
2024-02-22 15:09:00 avagent Info <5996>: Sleeping 60 seconds

Ein fehlerhaftes Protokoll mit Registrierungsproblemen, die durch Zertifikatsänderungen verursacht wurden, könnte wie folgt aussehen:

2024-02-22 15:04:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure
2024-02-22 15:04:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001.
2024-02-22 15:04:57 avagent Info <5059>: unable to connect, sleep(60) then retrying
2024-02-22 15:05:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure
2024-02-22 15:05:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001.
2024-02-22 15:05:57 avagent Info <5059>: unable to connect, sleep(60) then retrying
2024-02-22 15:06:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure
2024-02-22 15:06:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001.

Um in diesem Fall die sofortige erneute Registrierung von Avagent bei MCS zu erzwingen, müssen die folgenden Schritte durchgeführt werden:

Rufen Sie die MC_SYSTEM Kontoname, wahrscheinlich der Avamar-FQDN:

mccli client show --domain=/MC_SYSTEM | grep MC_SYSTEM | awk '{print $1}'

example:
root@avamar:/usr/local/avamar/lib/#: mccli client show --domain=/MC_SYSTEM | grep MC_SYSTEM | awk '{print $1}'
avamar.lab

Deaktivieren Sie das MC_SYSTEM-Konto:

mccli client edit --name=/MC_SYSTEM/<avamar_fqdn> --activated=false

example:
mccli client edit --name=/MC_SYSTEM/avamar.lab --activated=false

Registrieren Sie das MC_SYSTEM-Konto neu:

/etc/init.d/avagent register <avamar_fqdn> /MC_SYSTEM

example:
/etc/init.d/avagent register avamar.lab /MC_SYSTEM

Nach der erfolgreichen Registrierung kann Avagent die Replikation auf dem Ziel akzeptieren.

Wenn verifypeer auf dem Avamar-Replikationsziel aktiviert ist, müssen auf dem Avamar-Quellsystem die Client-Zertifikate neu erzeugt werden, die für die Verbindung mit dem Avamar-Zielsystem verwendet werden.

Ähnlich wie im Wissensdatenbank-Artikel 000214340 | Avamar: SSH Sitzungen

rm -r /usr/local/avamar/etc/<destination_avamar_ip_address>

rm -r /usr/local/avamar/etc/client/<destination_avamar_ip_address>

Erzeugen Sie die Client-Zertifikate neu:

/usr/local/avamar/bin/avagent.bin --gencerts=true --mcsaddr=<destination_avamar_ip_address>

/usr/local/avamar/bin/avagent.bin --gencerts=true --mcsaddr=<destination_avamar_ip_address> --sysdir=/usr/local/avamar/etc/client

Die Kommunikation mit dem Avamar-Zielsystem kann über die SSH-Befehlszeile des Avamar-Quellsystems getestet werden: SSH Befehlszeile

avmgr logn --id=repluser --ap=<destination_repluser_password> --hfsaddr=<destination_avamar_ip_address> --debug --x19=1024 --x30=8192

Client-Registrierung

Nach dem Ändern der Sitzungssicherheitseinstellungen oder dem erneuten Erzeugen der Zertifikate kann es zu Backupversuchen kommen.

Dies kann dazu führen, dass sich viele Agent-basierte Clients im Status „Waiting-Client“ befinden, bis das Backup mit der Meldung „Timed-Out Start“ fehlschlägt.

Nachdem die neuen Zertifikate erzeugt wurden, dauert es ca. 23 Stunden, bis der Client automatisch eine erneute Registrierung versucht.

Der folgende Befehl kann auf dem Avamar Server verwendet werden, um eine Einladung an Agent-basierte Clients zur erneuten Registrierung beim Avamar MCS zu senden.

mccli client re-register-all

Der Befehl kann je nach Anzahl der Clients einige Zeit in Anspruch nehmen, da er die Einladungen nacheinander an jeden Client sendet. Führen Sie den Befehl im Hintergrund aus, falls es zu einem Timeout der SSH-Sitzung kommt. SSH Sitzungs-Timeout

nohup mccli client re-register-all &

Beachten Sie, dass dadurch möglicherweise nicht alle Agent-basierten Clients erneut registriert werden, und dass einige möglicherweise manuell neu registriert werden müssen.

Der manuelle Prozess für die erneute Registrierung eines Clients unter Windows sieht wie folgt aus:

• Entfernen Sie den Inhalt des folgenden Verzeichnisses, das die alten Client-Zertifikate enthält:

  • "C:\Program Files\avs\etc"

• Starten Sie den „Backup Agent“-Service neu.

Der manuelle Prozess für die erneute Registrierung eines Clients unter Linux sieht wie folgt aus:

• Entfernen Sie den Inhalt des folgenden Verzeichnisses, das die alten Client-Zertifikate enthält:

  • /usr/local/avamar/etc

• Starten Sie den Avagent-Service neu:

  • service avagent restart

Der Client-Computer kann auch neu gestartet werden, um eine vollständige Neuregistrierung auszulösen.

Beachten Sie, dass die Namensauflösung eine wichtige Rolle bei der Registrierung von Clients spielt, wenn Sitzungssicherheit aktiviert ist. Stellen Sie daher sicher, dass die Clients eine Vorwärts- und Rückwärts-DNS-Suche des Avamar Servers durchführen können und umgekehrt. Dies kann entweder durch die Konfiguration von DNS-A-Datensätzen oder Hosteinträgen auf dem Client erreicht werden.

Avamar bietet keinerlei Skript, mit dem jeder verbundene Client erreicht werden kann, um eine manuelle Neuregistrierung durchzuführen. Der zuvor erwähnte mccli-Befehl erreicht dies noch am ehesten.

Proxy-Registrierung

Virtuelle Maschinen, die mithilfe von Proxys in Avamar gesichert werden, haben einen gewissen Vorteil, was Sicherheitsänderungen nach der Sitzung betrifft, da es in der Regel deutlich weniger Proxys als Agent-basierte Clients gibt.

Proxys sollten ebenfalls versuchen, innerhalb von 23 Stunden eine automatische Neuregistrierung durchzuführen. Es kann jedoch einfacher und schneller sein, sie sofort neu zu registrieren.

Es stehen einige Optionen zur Verfügung, um auf den Proxys eine erneute Registrierung zu erzwingen.

Die erste Option besteht darin, die Proxys mit dem folgenden Befehl neu zu starten:

mccli mcs reboot-proxy --all

Die zweite Option besteht darin, die Proxys mit dem Goav-Tool zu verwalten.

Legen Sie das Proxykennwort für das Goav-Tool fest, damit es sich bei den Proxys anmelden kann, wann immer nötig. Mit dem folgenden Befehl wird das Betriebssystemkennwort des Proxys nicht geändert, sondern lediglich verschlüsselt gespeichert, sodass das Goav-Tool es verwenden kann, um sich beim Proxy über SSH anzumelden. SSH.

./goav proxy set-password

Führen Sie auf allen verbundenen Proxys einen Avagent-Neustart durch:

./goav proxy exec "service avagent restart"

Führen Sie den folgenden Befehl aus, um das Avagent-Protokoll im Proxy daraufhin zu überprüfen, ob eine erfolgreiche erneute Registrierung stattgefunden hat:

./goav proxy exec "grep -i registration /usr/local/avamarclient/var/avagent.log"

Eine erfolgreiche Ausgabe könnte wie folgt aussehen:

============== proxy.lab.emc.com =========================
Executing grep -i registration /usr/local/avamarclient/var/avagent.log on proxy.lab.emc.com
2024-02-23 17:54:06 avagent Info <18918>: Registration: Processing secure registration with the MCS.
2024-02-23 17:54:06 avagent Info <18923>: Registration: Certificate files are present.
2024-02-23 17:54:09 avagent Info <5470>: Updating registration information with the MCS (10.x.x.x), paging enabled
2024-02-23 17:54:09 avagent Info <7501>: Client registration updated 3cbe29134da771ac547b7105743e66633ff12d40 10.x.x.x(1704339590)
2024-02-23 17:54:09 avagent Info <7502>: Registration of client /clients/proxy.lab.emc.com with MCS 10.x.x.x:30001 successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1019 vmwfilel successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 3019 vmwfilew successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1016 vmimagel successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 3016 vmimagew successful.
2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1001 Unix successful.
2024-02-23 17:54:09 avagent Info <5619>: Registration of client and plugins complete.

Die dritte Möglichkeit besteht darin, SSH an den Proxy und führen Sie das Initialisierungsskript aus:

/usr/local/avamarclient/etc/initproxyappliance.sh start

Data Domain-Synchronisierung

Nachdem die Sitzungssicherheitseinstellungen geändert oder Zertifikate auf Avamar neu erzeugt wurden, muss Data Domain neu synchronisiert oder die SSL-Verbindung wiederhergestellt werden.

Der folgende Dell Artikel behandelt dieses Szenario und wie Sie die neuen Zertifikate mit Data Domain austauschen.
Avamar: DD wird in der Avamar AUI und/oder der Benutzeroberfläche rot angezeigt (Lösungspfad)

Es wird dringend empfohlen, das Avamar- und Data Domain-SSL-Troubleshooting mit dem GoAV-Tool durchzuführen.

Mit GoAV kann die Data Domain-SSL-Verbindung mit Avamar automatisch diagnostiziert und behoben werden. Weitere Informationen finden Sie im folgenden Dell Artikel:
Avamar: Informationen zur GoAV dd check-ssl-Funktion

Führen Sie den folgenden Befehl aus, um Avamar- und Data Domain-Zertifikate automatisch zu korrigieren:

./goav dd check-ssl --fix