Avamar : Sécurité de la session
Summary: Cet article décrit la sécurité de la session sur Avamar, son fonctionnement et comment la gérer.
Instructions
Sécurité de la 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 avant qu’un processus Avamar n’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
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é de la session ?
La sécurité de la session est activée sur l’Avamar Server. 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 la stocker et lui faire confiance. Le client génère une demande de signature de certificat (CSR). La CSR (avclient.csr) est envoyée par le client au processus MCS d’Avamar Server, qui la signe 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 Data Domain ne dispose pas d’un certificat signé de lui-même ou d’un autre Avamar validé (ddboost de l’hôte importé). Avamar utilise la clé privée ssh Data Domain pour se connecter au Data Domain et exécuter des commandes ssh sur le shell Data Domain (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 Data Domain dispose du certificat signé par Avamar (ddboost de l’hôte importé), Avamar importe l’autorité de certification racine qui a signé le certificat (chain.pem en tant qu’autorité de certification importée 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 mis en œuvre et gère automatiquement la manière dont un client ou un proxy doit présenter ses certificats client à gsan pendant l’établissement d’une liaison TLS.
Voici une démonstration de l’établissement d’une liaison mutuelle/bidirectionnelle TLS lorsque verifypeer est activé.
Du point de vue du client ou du proxy, une flèche pointant vers la droite indique une connexion à Avamar Server. 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 d’une 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é de la session
Les deux articles suivants permettent de gérer les paramètres de sécurité de la session à partir de la ligne de commande ou du service Web Avinstaller.
000222234 | Avamar : Gérer les paramètres de sécurité de la session à partir du CLI (en anglais)
000222279 | Avamar : Gérer les paramètres de sécurité de la session avec le module d’installation Avinstaller (AVP) (en anglais)
Quatre configurations possibles sont prises en charge :
- Désactivé
- Mixte - Unique
- Authentifié - Unique
- 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 la session est désactivée, les données de sauvegarde qui sont transférées entre le client et Avamar sont chiffrées en transit.
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é - 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é - 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 : autorité de certification racine auto-signée interne d’Avamar
L’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.
Cela peut ne pas être acceptable dans certains environnements. Nous vous recommandons donc de consulter l’article de la base de connaissances 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.
Article de la base de connaissance 000204629 | Avamar : Installer/Remplacer l’autorité de certification (CA) Avamar par l’autorité de certification (CA) fournie par l’utilisateur (en anglais)
Le processus explique comment utiliser le script importcert.sh pour installer une autorité de certification fournie par l’utilisateur interne à la société. 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.
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
- Les fonctions de sécurité de la session ne peuvent pas être utilisées avec les Avamar Clients suivants :
- 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, voir l’article de la base de connaissances suivant : Article de la base de connaissance000056252 | 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 (en anglais)
- L’authentification par jeton sécurisé ne fonctionne pas dans les conditions suivantes :
Planification des modifications de sécurité de la session
Avant 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 d’Avamar à 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 la session ou la régénération des certificats est simple.
Cette section explique comment tout fonctionne à 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), celui-ci échoue en raison de l’échec de l’établissement d’une liaison TLS. Cela est dû au fait que les certificats client pour avtar s’exécutant sur 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.
Pour plus d’informations, voir l’article de la base de connaissances suivant :
000214340 | Avamar : Avtar ne parvient pas à se connecter au service GSAN d’Avamar, « Problème fatal de connexion au serveur, interruption de l’initialisation. Vérifiez que l’adresse du serveur et les identifiants de connexion sont corrects. » (en anglais)
Réplication
Dans le cas 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 journal 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 réenregistrer de force Avagent avec MCS immédiatement, la procédure suivante doit être suivie :
Obtenez le nom de compte MC_SYSTEM, qui sera probablement le FQDN d’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 : Avtar ne parvient pas à se connecter au service GSAN d’Avamar, « Problème fatal de connexion au serveur, interruption de l’initialisation. Vérifiez que l’adresse du serveur et les identifiants de connexion sont corrects. » (en anglais)
Supprimez le dossier de certificats Avamar de destination existant de la session ssh Avamar source :
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 :
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.
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 »
- 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.
./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 à se connecter en SSH au proxy et à exécuter 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 de la base de connaissances suivant décrit ce scénario et explique comment échanger les nouveaux certificats avec Data Domain.
000197106 | Intégration d’Avamar et de Data Domain : DD affiche du rouge dans l’interface Avamar AUI et ou le chemin de résolution de l’interface utilisateur
Il est fortement conseillé d’utiliser l’outil Goav pour le dépannage SSL d’Avamar et de Data Domain.
Avec Goav, la connexion SSL Data Domain avec Avamar peut être automatiquement diagnostiquée et résolue. Pour plus d’informations, voir l’article suivant de la base de connaissances :
000215679 | Avamar : Informations sur la fonctionnalité de vérification ssl dd Goav
Exécutez la commande suivante pour corriger automatiquement les certificats Avamar et Data Domain :
./goav dd check-ssl --fix