Avamar: Sessiebeveiliging

Wat is sessiebeveiliging?

Sessiebeveiliging: Productbeveiligingsgids

Avamar-clients kunnen sessiebeveiliging gebruiken om alle communicatie tussen de Avamar-server en de Avamar-clientsoftware te beveiligen. De Avamar-server biedt verificatie voor de Avamar-client en de Avamar-client biedt verificatie voor de Avamar-server.

Sessiebeveiligingsfuncties omvatten beveiligingsverbeteringen voor communicatie tussen Avamar-systeemprocessen.

De Avamar beveiligt alle communicatie tussen Avamar-systeemprocessen met behulp van sessietickets. Een geldig sessieticket is vereist voordat een Avamar-proces een overdracht van een ander Avamar-proces accepteert.

De sessietickets hebben de volgende algemene kenmerken:

• Het sessieticket wordt versleuteld en ondertekend ter bescherming tegen wijziging
• Het sessieticket is korte tijd geldig
• Elk sessieticket bevat een unieke handtekening en wordt toegewezen aan slechts één Avamar-proces
• De integriteit van een sessieticket wordt beschermd door versleuteling
• Elk Avamar-systeemknooppunt verifieert afzonderlijk de handtekening van het sessieticket
• Indien nodig kan een sessie worden verlengd tot na de levensduur van het sessieticket

Avamar fungeert als een particuliere certificeringsinstantie en genereert een uniek servercertificaat voor het Avamar-systeem.

Het Avamar-systeem installeert de openbare sleutel voor het servercertificaat op elke Avamar-client die is geregistreerd bij de Avamar-server. Avamar-clients gebruiken de openbare sleutel om transmissies van het Avamar-systeem te verifiëren.

Voor clients die momenteel zijn geregistreerd, worden de openbare sleutel voor het servercertificaat en andere vereiste certificaatbestanden binnen een uur na de installatie naar de client doorgegeven.

Het Avamar-systeem deelt ook automatisch het Avamar-servercertificaat met de Avamar-storageknooppunten. Door het certificaat te delen, kunnen het hulpprogrammaknooppunt en de storageknooppunten hetzelfde certificaat leveren voor authenticatie.

Er wordt een clientcertificaat gegenereerd wanneer de Avamar-server een Avamar-client registreert.

Na het genereren van een clientcertificaat gebruikt het Avamar-systeem een versleutelde verbinding met de Avamar-client om het certificaat op de client te installeren. Het Avamar-systeem slaat ook de openbare sleutel voor het clientcertificaat op. De openbare sleutel wordt gebruikt om de client te verifiëren in alle daaropvolgende communicatie.


Hoe werkt sessiebeveiliging?

Sessiebeveiliging is ingeschakeld op de Avamar-server. Wanneer deze optie is ingeschakeld, doorlopen clients, proxy's en Data Domain-systemen een speciaal certificaatregistratieproces met Avamar.

Op een Windows- of Linux-client en proxy ziet deze tijdens de registratie dat sessiebeveiliging is ingeschakeld op de Avamar-server. De Avamar stuurt de interne root-CA naar de client (chain.pem), zodat deze kan worden opgeslagen en vertrouwd. De client genereert een CSR (Certificate Signing Request). De CSR (avclient.csr) wordt door de client naar het MCS-proces van de Avamar-server gestuurd, dat de CSR ondertekent en een certificaatsleutelpaar teruggeeft aan de client (key.pem en cert.pem).

Wanneer in een Data Domain het Data Domain aan Avamar wordt gekoppeld of wanneer de SSL-communicatie wordt vernieuwd, ziet Avamar dat het Data Domain geen ondertekend certificaat van zichzelf of een andere gevalideerde Avamar (imported-host ddboost) heeft. Avamar gebruikt de Data Domain ssh private sleutel om in te loggen bij Data Domain om ssh-opdrachten uit te voeren via de Data Domin shell (ddsh). Avamar haalt de Data Domain CSR (Certificate Signing Request) op via SCP en ondertekent de CSR met de interne Avamar-basiscertificeringsinstantie. Zodra het Data Domain het ondertekende certificaat van Avamar (imported-host ddboost) heeft, importeert Avamar de root-CA die het certificaat heeft ondertekend (chain.pem as imported-ca ddboost/login-auth).

Nu een client/proxy is geregistreerd en beschikt over de clientcertificaten die nodig zijn voor authenticatie met het MCS van Avamar, wordt een back-up geprobeerd. De Avamar stuurt een werkorder naar de Avagent-listener van de klant of gevolmachtigde, die de werkorder oppikt. De client of proxy valideert en verifieert vervolgens de certificaatketen van de Avamar-server met behulp van de Avamar-basis-CA die Avamar op het registratiemoment in de client had geïmporteerd. Op dezelfde manier verifieert Avamar de client of proxy. Er zijn op dit moment geen gegevens doorgegeven.

Nadat de authenticatie is gelukt, start de werkorder en verandert de status van de werkorder van 'Waiting-Client' naar 'Running'.

Nu verplaatsen clients en proxy's data uiteindelijk naar Avamar en Data Domain met behulp van het binaire bestand avtar dat erop is geïnstalleerd. Het binaire bestand avtar geeft enkele vlaggen door die de details bepalen van hoe de gegevens worden verplaatst en welke gegevens worden verplaatst.

Wanneer avtar op een client of proxy verbinding gaat maken met Avamar's GSAN, moet het weten of verifypeer is ingeschakeld. De Verifypeer-instelling is een GSAN-serverinstelling als onderdeel van de sessiebeveiligingsconfiguratie die de SSL-socket van GSAN op poort 29000 bestuurt door deze te vertellen of er al dan niet clientcertificaten nodig zijn voor elke inkomende verbinding. Gelukkig is het TLS 1.2-protocol geïmplementeerd dat automatisch afhandelt hoe een client of gevolmachtigde zijn clientcertificaten aan gsan zal presenteren tijdens de TLS-handshake.

Hieronder volgt een demonstratie van de TLS mutual/two-way handshake wanneer verifypeer is ingeschakeld.
Vanuit het oogpunt van de client of proxy is een pijl die naar rechts wijst een verbinding met de Avamar server. Een pijl die naar links wijst, is een verbinding van de Avamar-server naar de 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

Wanneer Verifypeer is uitgeschakeld, hoeft de client geen clientcertificaat naar GSAN te sturen.
 

[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

Het belangrijkste is dat de client of gevolmachtigde de benodigde certificaten aan de clientzijde heeft gekregen om een wederzijdse TLS-handshake te kunnen uitvoeren indien vereist door GSAN.

Dit betekent dat als de interne basiscertificeringsinstantie van Avamar wordt gewijzigd, de client, de proxy of het datadomein de nieuwe basiscertificeringsinstantie moet ophalen om certificaten voor deze CA's te ondertekenen.

Nadat de client of proxy met succes verbinding heeft gemaakt met GSAN, wordt geprobeerd verbinding te maken met het Data Domain.

Het volgende logboek toont een proxy die verbinding maakt met Data Domain met avtar. De instelling Verifypeer is uitgeschakeld, maar Sessiebeveiliging is ingeschakeld (modus Authenticated-Single). 
 

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

Aangezien Verifypeer een Avamar GSAN-serverinstelling is, heeft dit geen invloed op de manier waarop avtar rechtstreeks verbinding maakt met Data Domain als Session Security is ingeschakeld. Dit betekent dat er een wederzijdse TLS-handshake plaatsvindt tussen de client of proxy en het Data Domain.

De client of proxy kan de Data Domain-certificaatketen valideren omdat deze dezelfde interne Avamar-basis-CA deelt die door Avamar is geïmporteerd tijdens de registratie van de client (of op het moment van DD-bewerking of bijlage).
 

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

Na validatie van het certificaat wordt de handshake voltooid en worden back-updata verplaatst van de client naar Data Domain en Avamar op het netwerk.


Beveiligingsinstellingen

voor sessies beherenDe volgende twee artikelen worden gebruikt om de sessiebeveiligingsinstellingen te beheren via de opdrachtregel of de Avinstaller-webservice.

000222234 | Avamar: Sessiebeveiligingsinstellingen beheren vanuit CLI
000222279 | Avamar: Sessiebeveiligingsinstellingen beheren met Avinstaller Installation Package (AVP)
 

Er zijn vier mogelijke ondersteunde configuraties:

1. Disabled
2. Gemengd-Single
3. Geauthenticeerd-single
4. Authenticated-Dual

Handicap

Instellingen:

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"

Wanneer sessiebeveiliging is uitgeschakeld, maken clients alleen verbinding met de Avagent-service van Avamar op poort 28001 en luisteren de clients op Avagent-poort 28002 naar aanvragen van Avamar.

Een proxy luistert op 28009.

Poort 28001 is een gewone TCP-socket en voert geen TLS-handshakes uit.

De client maakt verbinding met de Avamar GSAN op poort 29000 en voert een TLS-handshake in één richting uit. Dit betekent dat zelfs wanneer sessiebeveiliging is uitgeschakeld, de overdracht van back-updata tussen de client en Avamar nog steeds wordt versleuteld. 

Certificaten voor verificatie met de Avamar-software worden niet uitgewisseld tussen Avamar, proxy's, clients en Data Domain.


Gemengd-Single

Instellingen:

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"

De modus Mixed-Single werd meer gebruikt toen Session Security voor het eerst werd geïntroduceerd in Avamar 7.3, waardoor clients met versie niet 7.3 of hoger zich konden registreren en een back-up konden maken naar Avamar. Op het moment van schrijven van dit artikel is Avamar 19.10 de nieuwste versie en zal Mixed-Single in wezen hetzelfde zijn als de volgende modus om te bespreken; Geauthenticeerd-single.


Geauthenticeerd-single

Instellingen:

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 deze modus is sessiebeveiliging ingeschakeld en worden certificaten uitgewisseld tussen Avamar, clients, proxy's en Data Domain voor authenticatie voorafgaand aan een back-up.

Klanten luisteren nu op poort 30002 voor Avagent-werkorderaanvragen van Avamar en de proxy's luisteren op poort 30009. De Avamar luistert op poorten 30001 en 30003 naar verbindingsaanvragen van clients en proxy's. Dit zijn SSL-sockets die TLS-handshakes uitvoeren.

De modus Authenticated-Single dwingt alle clients om zich te registreren met behulp van Session Security-methoden, in tegenstelling tot de modus

Mixed-Single.Deze modus stelt verifypeer op Avamar's GSAN in op uitgeschakeld, wat betekent dat GSAN geen clientcertificaten van een inkomende avtar-verbinding nodig heeft.


Authenticated-Dual

Instellingen:

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 is hetzelfde als Authenticated-Single, behalve dat het de instelling Verifypeer inschakelt op de GSAN-service van Avamar.

Geverifieerd-dubbel wordt beschouwd als de sterkste instelling om toe te passen op een Avamar-server en is de standaardselectie tijdens Avamar-implementaties.


Overzicht: Interne zelfondertekende basis-CA

van AvamarDe interne basis-CA van Avamar is een intern vertrouwde certificaatautoriteit voor Avamar en de clients, proxy's en datadomeinen die Avamar naar deze domeinen importeert.

Avamar is de interne certificeringsinstantie voor zichzelf omdat deze certificaten uitgeeft voor aanvragen voor certificaatondertekening (CSR's).

Wanneer Avamar de basis-CA gebruikt om certificaten voor GSAN te ondertekenen, worden deze opgeslagen op de volgende locatie:
 

/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

Als een beveiligingsscanner poort 29000 scant op Avamar, worden zelfondertekende certificaten op die poort gerapporteerd waarmee back-ups naar GSAN worden verwerkt.

In sommige omgevingen is dit mogelijk niet acceptabel en de aanbeveling is om het volgende KB-artikel te raadplegen voor meer informatie over het vervangen van de interne Avamar-basis-CA door een door de gebruiker geleverde interne root-CA.

KB 000204629 | Avamar: Avamar certificeringsinstantie (CA) installeren/vervangen door door de gebruiker geleverde certificeringsinstantie (CA)

In het proces wordt beschreven hoe u het script importcert.sh kunt gebruiken om een door de gebruiker geleverde certificeringsinstantie binnen hun bedrijf te installeren. De door de gebruiker geleverde certificeringsinstantie wordt waarschijnlijk beheerd door het beveiligingsteam, aangezien geen enkele openbare certificeringsinstantie de persoonlijke sleutel voor hun CA zal weggeven, omdat dit de reden is dat ze geld verdienen door certificaten voor anderen te ondertekenen en een vertrouwensketen te behouden.

Een voorbeeld van een interne CA is Microsoft Active Directory Certificate Services.
Wat is Active Directory Certificate Services? | Microsoft Learn

Een voorbeeld van een openbare CA is DigiCert.

Het vervangen van de interne Avamar-basis-CA werkt door het root-sleutelpaar in de Avamar-sleutelstore te vervangen door het door de gebruiker geleverde CA-sleutelpaar. Vervolgens genereert GSAN een CSR- en persoonlijke sleutel, laat de CSR ondertekenen door het nieuwe CA-sleutelpaar en de bestanden die eerder in deze sectie zijn genoemd, worden vervangen. GSAN laadt de SSL-socket op poort 29000 opnieuw en nieuwe clients die verbinding maken met GSAN zien de door de gebruiker opgegeven CA.

Beveiligingsscanners tonen nu ondertekende certificaten op de poort en clients, proxy's en Data Domain moeten zich opnieuw registreren om de nieuwe CA te krijgen.


Beperkingen

De beveiligingsfuncties van de Avamar-sessie zijn onderhevig aan enkele beperkingen:

• Clients
  • Sessiebeveiligingsfuncties kunnen niet worden gebruikt met een van de volgende Avamar-clients:
    • Avamar clusterclient voor Solaris op Veritas clusterserver
    • Avamar client voor Solaris in Solaris clusters
• Andere producten
  • Het gebruik van NTP-tijdsynchronisatie van de Avamar-server, Avamar-clients en het Data Domain-systeem (indien van toepassing) wordt aangemoedigd. Als de tijd niet wordt gesynchroniseerd, kan dit leiden tot een mislukte registratie en mislukte back-up/herstel vanwege de geldigheids- en vervaltijden van certificaten. Het wijzigen van de tijdzone op een host kan een vergelijkbare impact hebben en vereist mogelijk het opnieuw genereren van certificaten.
• Secure Token
  • Beveiligde tokenverificatie werkt niet onder de volgende omstandigheden:
    • De clientcomputer bevindt zich achter een NAT-firewallapparaat (Network Address Translation)
    • De hostnaam van de client is een virtuele naam die verschilt van de FQDN die is opgelost vanaf het IP-adres
    • De clientcomputer heeft meerdere IP-interfaces en elke interface wordt omgezet in een andere FQDN (Fully Qualified Domain Name). Zie de volgende KB voor meer informatie: KB 000056252 | Avamar: Back-up naar Data Domain mislukt met bericht "DDR_GET_AUTH_TOKEN" vanwege te veel IP-adressen

Planning van sessiebeveiligingswijzigingen

Voordat u een wijziging doorvoert in de sessiebeveiligingsinstellingen, kunnen de volgende stappen worden uitgevoerd om de vorige configuratie of certificaten te kunnen herstellen voordat u wijzigingen aanbrengt.

Houd er rekening mee dat als de interne basis-CA van Avamar wordt gewijzigd, clients, proxy's en Data Domain zich opnieuw moeten registreren. Afhankelijk van de grootte van de omgeving (aantal clients, proxy's en datadomeinen) kan dit een omslachtige taak zijn die enkele dagen in beslag neemt.

Het gebruiksscenario zou zijn als certificaten worden geregenereerd en er nu registratie- en back-upfouten optreden.

In de veronderstelling dat certificaten niet verlopen zijn of op het punt staan te verlopen en mogelijk per ongeluk opnieuw worden gegenereerd, bieden de volgende stappen enkele richtlijnen om te voorkomen dat u in een situatie van dataverlies of niet-beschikbaarheid van data terechtkomt.

Bekijk de huidige sessiebeveiligingsinstellingen en noteer ze:

enable_secure_config.sh --showconfig

Maak een kopie van de Avamar Keystore:

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

Stel dat certificaten nu worden geregenereerd met behulp van de Session Security AVP- of CLI-methoden.

Dit betekent dat de Avamar Keystore is gewijzigd en dat de GSAN-certificaten opnieuw zijn ondertekend.

De oorspronkelijke Avamar Keystore kan eenvoudig weer op zijn plaats worden gezet:

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

Genereer de GSAN-certificaten opnieuw:

enable_secure_config.sh --certs

MCS en back-upplanner opnieuw opstarten:

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

Hiermee wordt de oorspronkelijke interne Avamar-basis-CA hersteld die clients, proxy's en Data Domain al vertrouwden.


Probleemoplossing

Meestal is het wijzigen van de instellingen voor sessiebeveiliging of het opnieuw genereren van certificaten eenvoudig.

In dit gedeelte wordt uitgelegd hoe alles weer werkt nadat certificaten opnieuw zijn gegenereerd of instellingen zijn gewijzigd.

Lokale spoelingen

In het scenario waarin verifypeer is ingeschakeld en alle Avamar-certificaten zijn geregenereerd, worden de clientcertificaten die avtar en avmgr van de Avamar-server gebruiken, niet onmiddellijk bijgewerkt.

Dit betekent dat wanneer MCS een geplande spoeling uitvoert (back-up van de MCS-configuratie naar GSAN), deze zal mislukken vanwege een TLS-handshake-fout. Dit komt doordat de clientcertificaten voor avtar die op de Avamar-server worden uitgevoerd, nog niet de bijgewerkte interne Avamar-basiscertificeringsinstantie en een nieuwe set ondertekende clientcertificaten hebben gekregen.

Zie de volgende KB voor meer informatie:

000214340 | Avamar: Avtar kan geen verbinding maken met de GSAN-service van Avamar, "Fatal server connection problem, aborting initialization. Controleer het juiste serveradres en de aanmeldingsgegevens."

Replicatie

In het scenario waarin verifypeer is ingeschakeld op de replicatiebestemming en certificaten opnieuw worden gegenereerd op het doel, moet een vergelijkbare aanpak worden gevolgd uit de sectie 'Lokale spoelingen' hierboven.

Zorg er eerst voor dat de replicatiebestemming Avagent is geregistreerd, zodat deze replicatiewerkorders kan accepteren.

Controleer op de bestemming het logboek van Avagent op de volgende locatie:

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

Een gezond logboek kan er als volgt uitzien:

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

Wanneer u verder teruggaat in het logboek, is er mogelijk een recente succesvolle herregistratie:

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

Een ongezond logboek met registratieproblemen veroorzaakt door certificaatwijzigingen kan er als volgt uitzien:

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.

Om Avagent in dit geval onmiddellijk geforceerd opnieuw te registreren bij MCS, moeten de volgende stappen worden ondernomen:

Haal de MC_SYSTEM accountnaam op, dit is waarschijnlijk de 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

Deactiveer het MC_SYSTEM-account:

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

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

Registreer het MC_SYSTEM account opnieuw:

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

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

Nadat de registratie is geslaagd, kan Avagent replicatie op de bestemming accepteren.

Als verifypeer op de bron-Avamar is ingeschakeld op de replicatiebestemming Avamar, moeten we de clientcertificaten die worden gebruikt om verbinding te maken met de doel-Avamar opnieuw genereren.

vergelijkbaar met KB 000214340 | Avamar: Avtar kan geen verbinding maken met de GSAN-service van Avamar, "Fatal server connection problem, aborting initialization. Controleer het juiste serveradres en de aanmeldingsgegevens." 

Verwijder de bestaande doelmap met Avamar-certificaten uit de Avamar ssh-bronsessie:

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

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

Genereer de clientcertificaten opnieuw:

/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

Communicatie met de doel-Avamar kan worden getest via de Source Avamar ssh opdrachtregel:

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

Clientregistratie

Back-ups kunnen worden gemaakt na het wijzigen van de sessiebeveiligingsinstellingen of het opnieuw genereren van de certificaten.

Dit kan ertoe leiden dat veel agentgebaseerde clients de status 'Wachten-klant' hebben totdat er geen back-up wordt gemaakt met 'Timed-Out Start'.

Nadat de nieuwe certificaten zijn geregenereerd, duurt het ongeveer 23 uur voordat de client automatisch opnieuw probeert te registreren.

De volgende opdracht kan op de Avamar-server worden gebruikt om een uitnodiging te verzenden voor agentgebaseerde clients om zich opnieuw te registreren bij de Avamar MCS.

mccli client re-register-all

De opdracht kan enige tijd duren, afhankelijk van het aantal clients, omdat er een uitnodiging naar elke client in opeenvolgende volgorde wordt verzonden. Overweeg om de opdracht op de achtergrond uit te voeren voor het geval er een time-out optreedt tijdens de ssh-sessie.

nohup mccli client re-register-all &

Houd er rekening mee dat dit mogelijk niet werkt om alle agentgebaseerde klanten opnieuw te registreren, en dat sommige mogelijk handmatig opnieuw moeten worden geregistreerd.

Het handmatige proces voor het opnieuw registreren van een client op Windows zou zijn:

• Verwijder de inhoud van de volgende map die de oude clientcertificaten bevat:

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

• Start de service "Backup Agent" opnieuw

Het handmatige proces voor het opnieuw registreren van een client op Linux zou zijn:

• Verwijder de inhoud van de volgende map die de oude clientcertificaten bevat:

  • /usr/local/avamar/etc

• Start de Avagent-service opnieuw:

  • service avagent restart

Het opnieuw opstarten van de clientcomputer kan ook worden gedaan om te proberen een volledige herregistratie te activeren.

Houd er rekening mee dat naamomzetting een belangrijke rol speelt bij het registreren van clients wanneer sessiebeveiliging is ingeschakeld. Zorg ervoor dat de clients een voorwaartse en omgekeerde DNS-lookup van de Avamar-server kunnen uitvoeren en vice versa. Dit kan worden bereikt door DNS A-records of hostvermeldingen op de client te configureren.

Avamar biedt geen script dat contact kan opnemen met elke aangesloten client om een handmatige herregistratie uit te voeren. De eerder genoemde mccli-opdracht komt daar het dichtst bij in de buurt.

Proxyregistratie

Virtuele machines waarvan een back-up wordt gemaakt naar Avamar met behulp van proxy's, zijn enigszins in het voordeel als het gaat om beveiligingswijzigingen na de sessie, omdat er meestal veel minder proxy's zijn dan op agents gebaseerde clients.

Volmachten moeten ook proberen om binnen 23 uur automatisch opnieuw te registreren, maar het kan gemakkelijker en sneller zijn om ze onmiddellijk opnieuw te registreren.

Er zijn een paar opties beschikbaar om te proberen een herregistratie op de proxy's af te dwingen.

De eerste optie kan zijn om de proxy's opnieuw op te starten met de volgende opdracht:

mccli mcs reboot-proxy --all

De tweede optie zou zijn om de Goav-tool te gebruiken om de proxy's te beheren.

Stel het proxywachtwoord voor de Goav-tool in, zodat deze kan inloggen op de proxy's wanneer dat nodig is. De volgende opdracht verandert het OS-wachtwoord van de proxy niet, het slaat het wachtwoord gewoon versleuteld op, zodat de Goav-tool het kan gebruiken om in te loggen op de proxy wanneer het moet via ssh.

./goav proxy set-password

Voer een Avagent-herstart uit op alle aangesloten proxy's:

./goav proxy exec "service avagent restart"

Voer de volgende opdracht uit om het Avagent-logboek in de proxy te controleren om te zien of een geslaagde herregistratie heeft plaatsgevonden:

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

Succesvolle uitvoer kan er als volgt uitzien:

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

De derde optie is om naar de proxy te ssh en het initialisatiescript uit te voeren:

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

Data Domain-synchronisatie

Nadat de sessiebeveiligingsinstellingen zijn gewijzigd of certificaten opnieuw zijn gegenereerd op Avamar, moet het Data Domain opnieuw worden gesynchroniseerd of moet de SSL-verbinding opnieuw tot stand worden gebracht.

Het volgende KB-artikel behandelt dit scenario en hoe u de nieuwe certificaten kunt uitwisselen met Data Domain.

000197106 | Avamar en Data Domain-integratie: DD wordt rood weergegeven in Avamar AUI en/of gebruikersinterface Resolutiepad

Het wordt ten zeerste aangeraden om het oplossen van problemen met Avamar en Data Domain SSL af te handelen met de Goav-tool.

Met Goav kan de SSL-verbinding van Data Domain met Avamar automatisch worden gediagnosticeerd en opgelost. Zie de volgende KB met meer informatie:

000215679 | Avamar: Informatie over de Goav DD check-SSL-functie

Voer de volgende opdracht uit om Avamar- en Data Domain-certificaten automatisch te herstellen:

./goav dd check-ssl --fix