avamar-sécurité-session

Qu’est-ce que la sécurité de session ?

Guide de sécurité du produit

Les Avamar Clients peuvent utiliser la sécurité de la session pour sécuriser toutes les communications entre Avamar Server et le logiciel Avamar Client. Avamar Server assure l’authentification d’Avamar Client, et Avamar Client fournit l’authentification à Avamar Server.

Les fonctions de sécurité de la session comprennent des améliorations de la sécurité des communications entre les processus du système Avamar.
Avamar sécurise toutes les communications entre les processus du système Avamar à l’aide de tickets de session. Un ticket de session valide est requis pour qu’un processus Avamar accepte une transmission en provenance d’un autre processus Avamar.

Les tickets de session présentent les caractéristiques générales suivantes :

• Le ticket de session est chiffré et signé pour ne pas être modifié
• Le ticket de session est valide sur une courte période
• Chaque ticket de session contient une signature unique et n’est affecté qu’à un seul processus Avamar
• L’intégrité d’un ticket de session est protégée par le chiffrement
• Chaque nœud du système Avamar vérifie séparément la signature du ticket de session
• Si nécessaire, une session peut être prolongée au-delà de la durée de vie du ticket de session

Avamar agit en tant qu’autorité de certification privée et génère un certificat de serveur unique pour le système Avamar.

Le système Avamar installe la clé publique du certificat de serveur sur chaque Avamar Client enregistré sur l’Avamar Server. Les Avamar Clients utilisent la clé publique pour authentifier les transmissions provenant du système Avamar.

Pour les clients actuellement enregistrés, la clé publique du certificat de serveur et les autres fichiers de certificat requis sont propagés au client dans l’heure qui suit l’installation.

Par ailleurs, le système Avamar partage automatiquement le certificat d’Avamar Server avec les nœuds de stockage Avamar. Le partage du certificat permet au nœud utilitaire et aux nœuds de stockage de fournir le même certificat pour l’authentification.

Un certificat client est généré lorsque l’Avamar Server enregistre un Avamar Client.

Après avoir généré un certificat client, le système Avamar utilise une connexion chiffrée avec l’Avamar Client pour installer le certificat sur le client. Le système Avamar stocke également la clé publique du certificat client. La clé publique est utilisée pour authentifier le client dans toutes les communications ultérieures.

Comment fonctionne la sécurité des sessions ?

La sécurité de session est activée sur le serveur Avamar. Lorsque cette option est activée, les clients, les proxys et les systèmes Data Domain passent par un processus d’enregistrement de certificat spécial auprès d’Avamar.

Sur un client et un proxy Windows ou Linux, au moment de l’enregistrement, il voit que la sécurité de la session est activée sur l’Avamar Server. Avamar envoie son autorité de certification racine interne au client (chain.pem) afin que le client puisse le stocker et lui faire confiance. Le client génère une demande de signature de certificat (CSR). La RSE (avclient.csr) est envoyé par le client au processus MCS d’Avamar Server qui signe la CSR et renvoie une paire de clés de certificat au client (key.pem et cert.pem).

Sur un système Data Domain, lors du rattachement du système Data Domain à Avamar ou lorsque la communication SSL est actualisée, Avamar constate que le système Data Domain ne dispose pas d’un certificat signé de lui-même ou d’un autre système Avamar validé (imported-host DDBoost). Avamar utilise Data Domain SSH Clé privée permettant de se connecter au système Data Domain pour exécuter SSH» sur le shell Data Domin (ddsh). Avamar extrait la demande de signature de certificat (CSR) Data Domain sur SCP et signe la CSR avec l’autorité de certification racine interne d’Avamar. Une fois que le Data Domain dispose du certificat signé par Avamar (imported-host DDBoost), Avamar importe l’autorité de certification racine qui a signé le certificat (chain.pem as imported-CA DDBoost/login-auth).

Maintenant qu’un client/proxy est enregistré et dispose des certificats côté client requis pour s’authentifier auprès du serveur MCS d’Avamar, une sauvegarde est tentée. Avamar envoie un ordre de travail à l’écouteur Avagent du client ou du proxy, qui récupère l’ordre de travail. Le client ou le proxy valide ensuite la chaîne de certificats d’Avamar Server à l’aide de l’autorité de certification racine d’Avamar que ce dernier avait importée dans le client au moment de l’enregistrement. De même, Avamar authentifie le client ou le proxy. Aucune donnée n’a été transmise à ce stade.

Une fois l’authentification réussie, l’ordre de travail démarre et l’état de l’ordre de travail passe de « Waiting-Client » à « Running ».

Désormais, les clients et les proxys finissent par déplacer des données vers Avamar et Data Domain à l’aide du fichier binaire avtar installé sur eux. Le fichier binaire avtar transmet des balises qui contrôlent les détails de la manière dont les données sont déplacées et quelles données sont déplacées.

Lorsque avtar sur un client ou un proxy se connecte au GSAN d’Avamar, il doit savoir si verifypeer est activé. Le paramètre verifypeer est un paramètre du serveur GSAN qui fait partie de la configuration de sécurité de la session et qui contrôle le socket SSL de GSAN sur le port 29000 en lui indiquant s’il doit ou non exiger des certificats client pour chaque connexion entrante. Heureusement, le protocole TLS 1.2 est implémenté et gère automatiquement la façon dont un client ou un proxy doit présenter ses certificats client au GSAN pendant l’établissement d’une liaison TLS.

Ce qui suit est une démonstration de l’établissement d’une liaison mutuelle/bidirectionnelle TLS lorsque la vérification de l’homologue est activée.
Du point de vue du client ou du proxy, une flèche pointant vers la droite indique une connexion au serveur Avamar. Une flèche pointant vers la gauche indique une connexion entre Avamar Server et le client.

[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

Lorsque verifypeer est désactivé, le client n’est pas tenu d’envoyer un certificat client à GSAN.

[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

L’essentiel est que le client ou le proxy ait obtenu les certificats nécessaires côté client pour l’établissement d’une liaison TLS mutuelle si le GSAN l’exige.

Cela signifie qu’en cas de modification de l’autorité de certification racine interne d’Avamar, le client, le proxy ou Data Domain doit obtenir la nouvelle autorité de certification racine pour signer les certificats en leur nom.

Une fois que le client ou le proxy se connecte avec succès à GSAN, il tente de se connecter au Data Domain.

Le journal suivant montre un proxy se connectant à Data Domain avec avtar. Le paramètre verifypeer est désactivé, mais la sécurité de la session est activée (mode unique authentifié).

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

Verifypeer étant un paramètre du serveur GSAN d’Avamar, il n’a aucune incidence sur la façon dont avtar se connecte directement à Data Domain si la sécurité de la session est activée. Cela signifie que l’établissement d’une liaison TLS mutuelle se produit entre le client ou le proxy et le Data Domain.

Le client ou le proxy peut valider la chaîne de certificats Data Domain, car il partage la même autorité de certification racine interne d’Avamar que celle importée par Avamar au moment de l’enregistrement du client (ou au moment de la modification DD ou de la pièce jointe).

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

Après la validation du certificat, l’établissement de la liaison se termine et les données de sauvegarde sont déplacées du client vers Data Domain et Avamar sur le réseau.

Gestion des paramètres de sécurité

Les deux articles suivants permettent de gérer les paramètres de sécurité de session à partir de la ligne de commande ou du service Web Avinstaller.

Avamar : gestion des paramètres de sécurité de session à partir de la CLI
Avamar : gestion des paramètres de sécurité de session avec Avinstaller Installation Package (AVP)

Quatre configurations possibles sont prises en charge :

1. Désactivé
2. Mixte - Unique
3. Authentifié - Unique
4. Authentifié - Double

Désactivé

Paramètres :

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"

Lorsque la sécurité de la session est désactivée, les clients se connectent uniquement au service Avagent d’Avamar sur le port 28001, et ils écoutent les demandes d’Avamar sur le port 28002.

Un proxy écoute sur 28009.

Le port 28001 est un socket TCP brut qui n’établit pas de liaisons TLS.

Le client se connecte au GSAN Avamar sur le port 29000 et établit une liaison TLS unidirectionnelle. Cela signifie que même lorsque la sécurité de session est désactivée, lorsque des données de sauvegarde sont transférées entre le client et Avamar, elles sont chiffrées à la volée.

Les certificats d’authentification avec le logiciel Avamar ne sont pas échangés entre Avamar, les proxys, les clients et Data Domain.

Mixte - Unique

Paramètres :

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"

Le mode Mixte - Unique a été davantage utilisé lors de la première introduction de la sécurité de la session dans Avamar 7.3, en particulier pour permettre aux clients dotés d’une version antérieure à 7.3 de s’enregistrer et de sauvegarder sur Avamar. Au moment de la rédaction de cet article, Avamar 19.10 est la dernière version et le mode Mixte - Unique sera le même que le mode suivant à aborder ; Authentifié - Unique.Authentifié - UniqueParamètres :

Authentifié - Unique

Paramètres :

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"

Dans ce mode, la sécurité de la session est activée et les certificats sont transmis entre Avamar, les clients, les proxys et Data Domain à des fins d’authentification avant d’effectuer une sauvegarde.

Les clients écoutent désormais sur le port 30002 les demandes d’ordre de travail Avagent en provenance d’Avamar. Les proxys écoutent sur le port 30009. Avamar écoute sur les ports 30001 et 30003 les demandes de connexion émanant des clients et des proxys. Il s’agit de sockets SSL qui établissent des liaisons TLS.

Le mode Authentifié - Unique force tous les clients à s’enregistrer à l’aide des méthodes de sécurité de la session, contrairement au mode Mixte - Unique.

Ce mode définit verifypeer sur le GSAN d’Avamar sur désactivé, ce qui signifie que GSAN n’aura pas besoin de certificats client provenant d’une connexion avtar entrante.Authentifié - DoubleParamètres :

Authentifié - Double

Paramètres :

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"

Authentifié - Double est identique à Authentifié - Unique, sauf qu’il active le paramètre VerifyPeer sur le service GSAN d’Avamar.

Authentifié - Double est considéré comme le paramètre le plus fort à appliquer à une instance d’Avamar Server et constitue la sélection par défaut lors des déploiements Avamar.Aperçu :

Présentation : autorité de certification racine auto-signée interne Avamar

autorité de certification racine auto-signée interne d’AvamarL’autorité de certification racine interne d’Avamar est une autorité de certification de confiance interne pour Avamar et les clients, proxys et systèmes Data Domain qu’Avamar importe vers eux.

Avamar est sa propre autorité de certification interne, car il émet des certificats pour les demandes de signature de certificat (CSR)..

Lorsqu’Avamar utilise son autorité de certification racine pour signer les certificats GSAN, ceux-ci sont stockés à l’emplacement suivant :

/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

Si un scanner de sécurité analyse le port 29000 sur Avamar, il signale les certificats auto-signés sur ce port, qui traite les sauvegardes vers GSAN.

Dans certains environnements, cela peut ne pas être acceptable. Nous vous recommandons donc de consulter l’article Dell suivant pour plus d’informations sur le remplacement de l’autorité de certification racine interne Avamar par une autorité de certification racine interne fournie par l’utilisateur.

Avamar : installation ou remplacement de l’autorité de certification (CA) Avamar par une autorité de certification (CA) 

fournie par l’utilisateurLe processus explique comment utiliser le script importcert.sh pour installer une autorité de certification interne à la société fournie par l’utilisateur. L’autorité de certification fournie par l’utilisateur est probablement gérée par l’équipe de sécurité. En effet, aucune autorité de certification publique ne divulguera la clé privée de son autorité de certification, car c’est la raison pour laquelle elle gagne de l’argent en signant des certificats pour d’autres et en maintenant une chaîne de confiance.

Les services de certification de Microsoft Active Directory sont un exemple d’autorité de certification interne.
Qu’est-ce que les services de certificats Active Directory ? | Microsoft Learn

DigiCert est un exemple d’autorité de certification publique.

Le remplacement de l’autorité de certification racine interne d’Avamar s’effectue en remplaçant la paire de clés racine dans le magasin de clés Avamar par la paire de clés de l’autorité de certification fournie par l’utilisateur. GSAN génère ensuite une CSR et une clé privée, fait signer la CSR par la nouvelle paire de clés de l’autorité de certification et les fichiers mentionnés précédemment dans cette section sont remplacés. GSAN recharge le socket SSL sur le port 29000 et les nouveaux clients qui se connectent à GSAN voient l’autorité de certification fournie par l’utilisateur.

Les scanners de sécurité affichent désormais les certificats signés sur le port, et les clients, les proxys et Data Domain doivent se réenregistrer pour obtenir la nouvelle autorité de certification.LimitationsLes fonctions de sécurité de la session Avamar sont soumises à certaines restrictions :

Limitations

Les fonctions de sécurité de la session Avamar sont soumises à certaines restrictions :

• Clients
  • Les fonctions de sécurité de la session ne peuvent pas être utilisées avec les Avamar Clients suivants :
    • Avamar Cluster Client for Solaris sur Veritas Cluster Server
    • Avamar Client for Solaris dans des clusters Solaris
• Autres produits
  • Il est recommandé d’utiliser la synchronisation de l’heure NTP d’Avamar Server, Avamar Clients et du système Data Domain (le cas échéant). Si l’heure n’est pas synchronisée, l’enregistrement et la sauvegarde/restauration peuvent échouer en raison de la validité du certificat et des délais d’expiration. La modification du fuseau horaire d’un hôte peut avoir un impact similaire et peut nécessiter la régénération du certificat.
• Jeton sécurisé
  • L’authentification par jeton sécurisé ne fonctionne pas dans les conditions suivantes :
    • La machine client se trouve derrière un périphérique de pare-feu NAT (Network Address Translation)
    • Le nom d’hôte du client est un nom virtuel différent du nom de domaine complet résolu à partir de son adresse IP
    • La machine client dispose de plusieurs interfaces IP et chacune d’entre elles est résolue en un nom de domaine complet différent. Pour plus d’informations, reportez-vous à l’article Dell suivant : Avamar : Échec de la sauvegarde sur Data Domain avec le message « DDR_GET_AUTH_TOKEN » en raison d’un trop grand nombre d’adresses IP 

Planification des modifications de sécurité de session

Planification des modifications de sécurité de la sessionAvant de modifier les paramètres de sécurité de la session, vous pouvez effectuer les étapes suivantes pour restaurer la configuration ou les certificats précédents.

N’oubliez pas que si l’autorité de certification racine interne d’Avamar est modifiée, les clients, les proxys et Data Domain doivent s’enregistrer à nouveau. En fonction de la taille de l’environnement (nombre de clients, proxys et Data Domains), cette tâche peut s’avérer fastidieuse et s’étaler sur plusieurs jours.

Le cas d’utilisation serait que les certificats soient régénérés et qu’il y ait des échecs d’enregistrement et de sauvegarde.

En supposant que les certificats n’ont pas expiré ou ne sont pas sur le point d’expirer, et qu’ils sont régénérés peut-être par accident, les étapes suivantes donnent des indications sur la manière d’éviter de se retrouver dans une situation de perte de données ou d’indisponibilité des données.

Obtenez les paramètres actuels de sécurité de la session et notez-les :

enable_secure_config.sh --showconfig

Effectuez une copie du magasin de clés Avamar :

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

Supposons que les certificats soient maintenant régénérés, soit en utilisant l’AVP de sécurité de la session, soit en utilisant les méthodes CLI.

Cela signifie que le magasin de clés Avamar a changé et que les certificats GSAN ont été resignés.

Le magasin de clés Avamar d’origine peut simplement être remis en place :

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

Régénérez les certificats GSAN :

enable_secure_config.sh --certs

Redémarrez MCS et Backup Scheduler :

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

Cela rétablit l’autorité de certification racine interne Avamar d’origine à laquelle les clients, les proxys et Data Domain faisaient déjà confiance.

Dépannage

La plupart du temps, la modification des paramètres de sécurité de session ou la régénération des certificats est simple.

Cette section explique comment tout fonctionner à nouveau après la régénération des certificats ou la modification des paramètres.

Vidages locaux

Dans le cas où la fonction verifypeer est activée, lorsque tous les certificats Avamar sont régénérés, les certificats clients utilisés par avtar et avmgr d’Avamar Server ne sont pas immédiatement mis à jour.

Cela signifie que lorsque MCS exécute un vidage planifié (sauvegarde de la configuration MCS sur GSAN), il échoue en raison d’un échec de l’établissement d’une liaison TLS. Cela est dû au fait que les certificats client d’avtar s’exécutant sur l’instance d’Avamar Server n’ont pas encore reçu l’autorité de certification racine interne Avamar mise à jour et le nouvel ensemble de certificats clients signés.


Réplication

Dans le scénario où verifypeer est activé sur la destination de réplication et où les certificats sont régénérés sur la destination, vous devez adopter une approche similaire à celle de la section « Vidages locaux » ci-dessus.

Tout d’abord, assurez-vous que l’Avagent de destination de réplication est enregistré afin qu’il puisse accepter les ordres de travail de réplication.

Sur la destination, vérifiez le log Avagent à l’emplacement suivant :

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

Un journal intègre peut ressembler à ceci :

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

Lorsque vous remontez dans le journal, vous constaterez peut-être qu’un réenregistrement a réussi récemment :

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

Un journal défectueux avec des problèmes d’enregistrement causés par des modifications de certificat peut ressembler à ceci :

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.

Dans ce cas, afin de forcer la réinscription immédiate d’Avagent auprès de MCS, les étapes suivantes doivent être effectuées :

Obtenez le MC_SYSTEM le nom du compte, qui est probablement le FQDN Avamar :

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

Désactivez le compte MC_SYSTEM :

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

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

Réenregistrez le compte MC_SYSTEM :

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

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

Une fois l’enregistrement réussi, Avagent peut accepter la réplication sur la destination.

Maintenant, sur l’Avamar source, si l’option verifypeer est activée sur l’Avamar de destination de réplication, nous devons régénérer les certificats clients utilisés pour se connecter à l’Avamar de destination.

Similaire à l’article de la base de connaissance 000214340 | Avamar : SSH Sessions

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

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

Régénérez les certificats clients :

/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

La communication avec l’Avamar de destination peut être testée à partir de la ligne de commande ssh d’Avamar source : SSH ligne de commande

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

Enregistrement du client

Des sauvegardes peuvent être tentées après avoir modifié les paramètres de sécurité de la session ou régénéré les certificats.

Cela peut entraîner la recherche de nombreux clients basés sur des agents dans l’état « Waiting-Client » jusqu’à ce que la sauvegarde échoue avec le message « Timed-Out Start ».

Une fois les nouveaux certificats régénérés, il faut compter environ 23 heures pour que le client tente automatiquement de se réenregistrer.

La commande suivante peut être utilisée sur Avamar Server pour inviter les clients basés sur des agents à se réenregistrer auprès d’Avamar MCS.

mccli client re-register-all

La commande peut prendre un certain temps en fonction du nombre de clients, car elle envoie une invitation à chacun d’eux dans l’ordre séquentiel. Envisagez d’exécuter la commande en arrière-plan au cas où la session ssh expirerait. SSH expiration des sessions

nohup mccli client re-register-all &

Il se peut que cette méthode ne permette pas de réenregistrer tous les clients basés sur des agents, et que certains doivent être réenregistrés manuellement.

Le processus manuel de réenregistrement d’un client sous Windows est le suivant :

• Supprimer le contenu du répertoire suivant qui contient les anciens certificats client :

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

• Redémarrer le service « Backup Agent »

Le processus manuel de réenregistrement d’un client sur Linux consiste à :

• Supprimer le contenu du répertoire suivant qui contient les anciens certificats client :

  • /usr/local/avamar/etc

• Redémarrer le service avagent :

  • service avagent restart

Vous pouvez également redémarrer la machine client pour tenter de déclencher un réenregistrement complet.

Notez que la résolution de noms joue un rôle important dans l’enregistrement des clients lorsque la sécurité de la session est activée. Assurez-vous que les clients peuvent effectuer une recherche DNS normale et inversée de l’instance d’Avamar Server et vice versa. Pour ce faire, vous pouvez configurer des enregistrements DNS A ou des entrées d’hôtes sur le client.

Avamar ne fournit aucun script qui puisse atteindre chaque client attaché pour effectuer un réenregistrement manuel. La commande mccli mentionnée précédemment est celle qui s’en rapproche le plus.

Enregistrement du proxy

Les machines virtuelles sauvegardées sur Avamar à l’aide de proxys sont quelque peu avantagées en ce qui concerne les changements de sécurité post-session, car il y a généralement beaucoup moins de proxys que sur les clients basés sur des agents.

Les proxys doivent également tenter un réenregistrement automatique dans les 23 heures, mais il peut être plus facile et plus rapide de les réenregistrer immédiatement.

Il existe plusieurs options pour tenter de forcer un réenregistrement sur les proxys.

La première option peut consister à redémarrer les proxys à l’aide de la commande suivante :

mccli mcs reboot-proxy --all

La deuxième option consiste à utiliser l’outil Goav pour gérer les proxys.

Définissez le mot de passe du proxy pour l’outil Goav afin qu’il puisse se connecter aux proxys quand il le faut. La commande suivante ne modifie pas le mot de passe du système d’exploitation du proxy, elle stocke simplement le mot de passe chiffré afin que l’outil Goav puisse l’utiliser pour se connecter au proxy chaque fois qu’il doit utiliser ssh. SSH.

./goav proxy set-password

Redémarrez Avagent sur tous les proxys rattachés :

./goav proxy exec "service avagent restart"

Pour vérifier le journal Avagent dans le proxy afin de voir si un nouvel enregistrement a réussi, exécutez la commande suivante :

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

La sortie devrait être similaire à ce qui suit :

============== 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.

La troisième option consiste à SSH dans le proxy et exécutez le script d’initialisation :

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

Data Domain Sync

Une fois les paramètres de sécurité de la session modifiés ou les certificats régénérés sur Avamar, le Data Domain doit être resynchronisé ou la connexion SSL rétablie.

L’article Dell suivant décrit ce scénario et explique comment échanger les nouveaux certificats avec Data Domain.
Avamar : DD s’affiche en rouge dans l’AUI Avamar et/ou l’interface utilisateur (chemin de résolution)

Il est vivement conseillé de gérer le dépannage SSL d’Avamar et de Data Domain à l’aide de l’outil GoAV.

Avec GoAV, la connexion SSL Data Domain avec Avamar peut être automatiquement diagnostiquée et résolue. Pour plus d’informations, reportez-vous à l’article Dell suivant :
Avamar : Informations sur GoAV Fonctionnalité

DD Check-SSL Exécutez la commande suivante pour corriger automatiquement les certificats Avamar et Data Domain :

./goav dd check-ssl --fix