Pozn.: Popis v článku byl testován na Veeam Backup & Replication 13.0.1, licencováno pomocí Veeam Universal License (VUL), tedy obdoba Enterprise Plus. Věnuje se platformě VMware a Hyper-V. Na některé otázky jsem nenalezl odpověď v oficiální dokumentaci a moje informace vychází z praktických testů.
Úvodní informace o technologiích
První polovina článku stručně popisuje technologie. Dále se věnujeme otázce, kde můžeme gMSA použít a jestli pro Application-Aware Processing vůbec speciální účet potřebujeme. Koho zajímá pouze praktická konfigurace gMSA účtů, tak může přeskočit na druhou polovinu článku.
Co je gMSA?
Group Managed Service Account (gMSA) je typ spravovaného doménového účtu, který zajišťuje automatickou správu hesel. Operační systém Windows heslo (náhodně generované 240 bytů dlouhé), které se standardně každých 30 dní mění, získává sám od DC, bez zásahu administrátora (ten heslo nezná).
Jak je již uvedeno v názvu, tak se používá pro servisní účty. Neumožňuje interaktivní přihlášení. Jinak jej můžeme využívat standardně. Například zařadit do bezpečnostních skupin nebo použít pro nastavení oprávnění na souborový systém.
Správu hesel (změnu) zajišťuje služba Microsoft Key Distribution Service (kdssvc.dll) na doménovém řadiči (DC). Členské počítače získávají aktuální heslo od DC. gMSA jsou podporovány od Windows Server 2012.
Veeam Application-Aware Processing (Guest Processing)
Pokud nám nestačí Crash-consistent záloha (jako bychom serveru vypnuli proud), ale požadujeme Application-Aware zálohu (aplikačně či transakčně konzistentní - Application / Transaction Consistent), kdy jsou aplikace a OS uvedeni do klidového stavu. Tak ve Veeam Backup & Replication musíme využít Application-Aware Processing spolu s dostatečnými credentials (často jde o lokálního administrátora) pro přihlášení do zálohovaného OS. Potřebujeme tedy servisní účet. Je také potřeba komunikace přes síť (případně pomocí VMware VIX API nebo Microsoft PowerShell Direct).
Pozn.: Konzistentní zde znamená platný, soudržný stav. Konzistentní souborový systém má ukončeny všechny zápisy na disk (není to stav v půlce zápisu, kdy by byl určitý soubor poškozen). Podobně aplikační konzistence znamená, že jsou dokončeny transakce (třeba na SQL, Exchange nebo AD) a vyprázdněna cache na disk.
Těžko se dohledávají přesné detaily, jak tyto věci ve VBR fungují. Záleží také hodně na virtualizační platformě, hostovaném OS a dalších okolnostech. Ve VBR můžeme konfigurovat Guest Quiescence nebo Application-Aware Processing (to je doporučená varianta).
Pokud zapneme Application-Aware Processing, tak Veeam nainstaluje do hostovaného OS dočasné nebo trvalé komponenty. Jde primárně o Veeam Guest Helper, který je u trvalých komponent součástí Veeam Guest Agent. Případně také Log Shipping Service pro zálohu transakčních logů.
Snapshots (snímky)
Při standardní záloze VM (Crash-consistent) se provede Snapshot / Checkpoint VM v rámci virtualizace a z něj probíhá záloha.
Při konzistentní záloze VM (File-system / Application consistent) se nejprve provede Snapshot systému. K tomu se využívá například Volume Shadow Copy Service (VSS) na Windows nebo File System Freeze na Linuxu. Může se volat pomocí VMware Tools nebo Hyper-V Integration Services při vytváření Snapshotu VM. Označuje se jako Hyper-V Production Checkpoint (vs. Standard Checkpoint) nebo VMware Snapshot with Quiesce Guest File System. Aby se uvedla do klidového stavu aplikace, tak je na Windows potřeba příslušný VSS Writer pro tuto aplikaci.
Veeam VSS logy
Pokud používáme Application-Aware Processing, tak se na Windows VM vytváří logy, kde můžeme zjistit řadu informací nebo chyb. Standardní cesta je C:\ProgramData\Veeam\Backup. Věci okolo VSS se ukládají do souboru VeeamVssSupport.log.
Guest Interaction Proxy
Guest Interaction Proxy (GIP) je komponenta, která funguje jako prostředník mezi Backup serverem a zálohovaným VM. Slouží ke komunikaci Veeam Backup & Replication s OS hostovaného VM pro Guest Processing. Její roli může zastávat Backup server nebo libovolný Windows či Linux server, který přidáme mezi spravované servery ve VBR. GIP může také sloužit jako Log Shipping Server.
Dokumentace není moc jasná v otázce, co všechno GIP dělá. Uvádí se, že provádí instalaci Non-Persistent Runtime Components nebo Persistent Agent Components. Pro instalaci Non-Persistent Runtime Components potřebuje zadaný účet (Guest OS credentials), pod kterým instalaci provede (hlásí se z GIP). Následně se komunikuje s komponentami a ověřuje certifikátem. Určité informace můžeme zjistit v požadavcích na porty Ports - Guest Processing Components.
Persistent Guest Agent
Když chceme využít Persistent Guest Agent, tak neproběhne celá instalace komponent automaticky (z GIP). Prvně musíme na zálohovaný server nasadit Veeam Installer Service nebo správněji Veeam Deployment Kit (Backup Infrastructure - Managed Servers - Create Veeam deployment kit). Díky tomu se odstraní řada požadavků na bezpečnost a porty. Backup Server nebo Guest Interaction Proxy komunikuje s Installer Service, která má na serveru administrátorská oprávnění.
Na serveru pak běží služba Veeam Installer Service (VeeamDeploymentSvc.exe), která standardně poslouchá na portu 6160. A Veeam Guest Agent (VeeamGuestHelper.exe), která standardně poslouchá na portu 6173. Obě běží pod účtem Local System.
Na jakých místech Veeam podporuje gMSA
Ve Veeam Backup & Replication (od verze 12) můžeme použít gMSA (pouze) pro spouštění úloh Guest Processing (zpracování hosta). Konkrétně jde o operace
- Application-Aware Processing - zajištění transakční konzistence záloh pro AD doménové řadiče, Exchange, SQL Server a Oracle DB (nepodporuje SharePoint), patří sem také možnost zálohy transakčních logů (Transaction log backup), zkrácení transakčních logů (Transaction log truncation) a zpracování skriptů uvnitř OS (pre-freeze and post-thaw scripts)
- Guest File System Indexing - indexování souborů
Toto platí pro zálohy nebo repliky na úrovni obrazu (image-level). V případě záloh pomocí Veeam Agent jsou gMSA podporovány pro zálohovací úlohy spravované Backup serverem a pouze pro SQL server a zpracování skriptů.
Kde gMSA podporováno není
Účet gMSA nemůžeme využít všude jinde než pro Guest Processing. Taková běžná místa jsou přidávání infrastrukturních komponent (spravované servery, virtuální infrastruktura s Windows Server, Hyper-V, SCVMM), počítače v Protection Group (Veeam Agent) a Veeam Explorers pro granulární obnovu dat.
Oficiální požadavky
Oficiální dokumentace uvádí následující požadavky, abychom mohli použít gMSA. Guest Interaction Proxy i zálohovaný počítač musí běžet na Windows, být členem domény a mít síťový přístup k doménovému řadiči (ten jim vydává aktuální heslo pro gMSA). Na zálohovaném počítači musí být gMSA přidán do skupiny Administrators a musí mít oprávnění Logon as a service (to Administrators standardně mají). Samotný GIP pak tento gMSA účet používá pro přístup do hostovaného OS zálohovaných strojů.
To jsou patrně požadavky pro pokrytí všech možných situací. Pro některé praktické situace nemusíme dodržet vše. Provedl jsem různé testy (pouze na Hyper-V a VMware), které jsou stručně popsány v závěru článku. Z toho jsem odvodil následující požadavky pro určité situace.
Admin práva na zálohovaném serveru potřebujeme hlavně pro instalaci Non-Persistent Runtime Components. A pro tento účel také potřebuje Guest Interaction Proxy použít gMSA. Pokud budeme využívat Persistent Guest Agent, tak nám tyto požadavky odpadají.
Windows Server bez speciální aplikace
Máme Windows server, kde se nenachází žádná podporovaná aplikace (jako SQL Server, Exchange Server). Chceme provést zálohu, kdy bude souborový systém (OS) v konzistentním stavu. Může jít třeba o souborový server.
Pokud použijeme Persistent Guest Agent (na server nasadíme Deployment Kit), tak se účet zadaný v Guest OS credentials (v našem případě gMSA) nemusí vůbec použít, a tudíž nejsou žádné požadavky. Komunikuje se na Installer Service, přes tuto službu se provede instalace Veeam Guest Agent.
Pokud chceme využít Non-Persistent Runtime Components, tak se při každém běhu úlohy musí vložit komponenty. K tomu se asi využívá Administrative share nebo VIX API / PowerShell Direct. Guest Interaction Proxy musí mít možnost získat gMSA heslo a použije tento účet pro přístup na zálohovaný server. Na zálohovaném VM musí být gMSA zařazen mezi lokální administrátory (ale nepotřebuje práva získat heslo gMSA). GIP tedy musí být zařazena do domény.
SQL Server
Na Windows serveru nám běží SQL Server. Chceme provést zálohu, kdy budou databáze v konzistentním stavu, zkrátit SQL transakční logy (případně provést jejich zálohu).
Pokud použijeme Persistent Guest Agent, tak je účet zadaný v Guest OS credentials potřeba pro zkrácení logů. Použije se přímo na zálohovaném serveru, takže ten musí mít možnost získat gMSA heslo. Musí mít dostatečná práva na SQL Server, ale nemusí být lokální administrátor. GIP s gMSA nepracuje.
Pokud chceme využít Non-Persistent Runtime Components, tak Guest Interaction Proxy i zálohované VM musí mít možnost získat gMSA heslo (a být zařazeni do domény). Na zálohovaném serveru musí být gMSA lokální administrátor a mít práva na SQL Server.
Exchange Server
Na Windows serveru nám běží Exchange Server. Chceme provést zálohu, kdy bude vše v konzistentním stavu a zkrátit Exchange transakční logy. Zkrácení logů probíhá tak, že Volume Shadow Copy Service (VSS) Microsoft Exchange Writer pošle Exchange Serveru informaci, že proběhla korektní záloha. Exchange sám provede odmazání logů.
Zkoušel jsem již pouze Persistent Guest Agent (využití Non-Persistent Runtime Components bude stejné jako v předchozích případech). Zadaný účet se nevyužije / není potřeba (vše proběhlo korektně s vybraným gMSA, který neměl žádná práva).
Active Directory (AD) Domain Controller (DC)
Na Windows serveru nám běží doménový řadič. Chceme provést zálohu, kdy bude vše v konzistentním stavu.
Také v tomto případě jsem zkoušel pouze Persistent Guest Agent. Zadaný účet se nevyužije / není potřeba. Používají se Veeam služby a VSS s NTDS Writer.
Použití Guest OS credentials
Na zálohovaném serveru se můžeme podívat do logu VeeamVssSupport.log. Nalezneme zde, kdy se služba snažila použít zadaný účet (Guest OS credentials).
Ve všech případech, které jsem prohlížel, se snaží zjistit informace o SQL AlwaysOn, připojit k Microsoft Failover Cluster a Detect Oracle Installation. Pokud nemá účet oprávnění, tak vidíme, že použití selhalo (příklad níže). Ale to ničemu nevadí, pokud se na serveru nenachází daná aplikace. VBR při zálohování ani žádnou chybu nesignalizuje.
| CVssSupportInvokeDispatcher::Invoke DetectOracleInstallation | RPC: DetectOracleInstallation | RPC: DetectOracleInstallation | ERR |Failed to detect Oracle installation. | ERR |Failed to create a process token for MSA account: MSA-VBR-SQL, domain: FIRMA | >> |Win32 error:Access is denied.
Doporučení
Backup server by neměl být členem domény. To znamená, že v případě, kdy potřebujeme využít gMSA účet na Guest Interaction Proxy, potřebujeme jiný server zařazený do domény, který bude sloužit jako GIP. Nebo můžeme všude používat Persistent Guest Agent.
Pokud bychom při zálohování doménového řadiče potřebovali práva lokálního administrátora, tak to v tomto případě znamená oprávnění Domain Admin. Nedoporučuje se dávat tato práva gMSA účtu. Řešení je opět využít Persistent Guest Agent, který nepotřebuje účet.
Vytvoření gMSA a použití ve VBR
Podrobně je popsáno v článku Jak na Group Managed Service Accounts (gMSA), zde pouze stručně.
Vytvoření KDS Root Key
Aby mohl doménový řadič (DC) generovat gMSA hesla, tak Key Distribution Services (KDS) potřebuje Root Key (kořenový klíč). Pomocí PowerShellu (s dostatečnými právy na DC) můžeme ověřit, že nějaký klíč existuje (měl by být pouze jeden).
Get-KdsRootKey
Pokud ne, tak musíme vytvořit nový klíč.
Add-KdsRootKey -EffectiveImmediately
Aby byla jistota, že došlo k synchronizaci na všechna DC, tak je možno vytvořit první gMSA až po 10 hodinách. Pokud bychom chtěli urychlit (pro testování), tak můžeme vytvořit klíč s posunem času.
Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
Vytvoření Group Managed Service Account (gMSA)
Pro vytvoření účtu musíme použít PowerShell.
New-ADServiceAccount -Name MSA-VBR-SQL -DNSHostName msa-vbr-sql.firma.local -PrincipalsAllowedToRetrieveManagedPassword sql$,gip$ ` -KerberosEncryptionType AES128, AES256
V příkladu vytváříme účet se jménem MSA-VBR-SQL (název může mít max 15 znaků) s následujícími parametry
DNSHostName- povinný parametr, FQDN pro účet (možná nemá velký význam)PrincipalsAllowedToRetrieveManagedPassword- počítač(e), které mohou používat gMSA (získat heslo), můžeme zadat jména počítačů (s$na konci) nebo bezpečnostní skupinu, která obsahuje jejich účtyKerberosEncryptionType- volitelně, povolené typy šifrování pro Kerberos
Pozn.: Existuje určité bezpečnostní doporučení nepoužívat pro názvy serverů nebo účtů popisná jména (která máme v příkladu).
Změna nastavení účtu
Dodatečně můžeme upravit parametry účtu. V příkladu přidáváme práva pro další server.
Set-ADServiceAccount -Identity MSA-VBR-SQL -PrincipalsAllowedToRetrieveManagedPassword sql$,gip$,server2$
Instalace a test gMSA na cílovém serveru
Oficiální Microsoft dokumentace říká, že je potřeba nainstalovat gMSA na cílovém počítači (Install a gMSA on your system), aby došlo k uložení hesla do keše. V mých testech vše funguje bez této instalace.
Na mnoha místech se uvádí, že je tento krok zbytečný. Četl jsem také vysvětlení, že je to pro případ, kdy nastavujeme práva na gMSA přes skupinu, aby došlo k obnově členství počítače ve skupině (získání aktuálního Kerberos ticketu). Uvádí se, že alternativně můžeme vymazat tickety pro počítač (Local System).
klist.exe -lh 0 -li 0x3e7 purge
Pokud bychom chtěli instalaci gMSA provést, tak musíme mít na cílovém počítači Active Directory module for Windows PowerShell. Instalace také ověří, že je počítač oprávněn hostovat daný účet.
Install-WindowsFeature RSAT-AD-PowerShell -IncludeAllSubFeature Install-ADServiceAccount -Identity MSA-VBR-SQL
Prováděl jsem řadu testů. Když jsem serveru odebral práva na získání gMSA hesla, tak někdy okamžitě přestal fungovat (neprošel ani test). Ale někdy stále fungoval, patrně díky kešovaným údajům. Řešením je odinstalovat gMSA na serveru, pak okamžitě přestane fungovat, když nemá práva (po opětovném přidání práv hned fungovat začne).
Uninstall-ADServiceAccount -Identity MSA-VBR-SQL
Můžeme také provést přímo test, že počítač má oprávnění získat heslo.
Test-ADServiceAccount -Identity MSA-VBR-SQL
Nastavení gMSA na cílovém serveru
Aby mohl účet provádět požadované operace, tak potřebuje na zálohovaném serveru dostatečná oprávnění (na GIP práva dávat nemusíme). Veeam v dokumentaci rovnou uvádí zařadit jej mezi lokální administrátory. To můžeme provést standardně v GUI Computer Management nebo PowerShellu.
Add-LocalGroupMember -Group "Administrators" -Member MSA-VBR-SQL$
Pokud zálohujeme Microsoft SQL Server, tak náš účet potřebuje dostatečná oprávnění, aby mohl provést zkrácení či zálohu transakčních logů. Ne moc hezké řešení je dát roli sysadmin, ale asi není jednoduché přidělit nižší oprávnění.
Nastavení účtu ve Veeam Backup & Replication
Přidání gMSA
Vytvořený gMSA musíme přidat do Credentials Manager ve VBR. Můžeme to udělat v rámci úlohy, kde jej budeme chtít použít, nebo přes hlavní menu.
- Veeam Backup & Replication Console
- Main menu - Credentials and Passwords - Datacenter Credentials
- Add - Managed service account
- zadáváme pouze uživatelské jméno (buď v zápise NetBIOS logon name nebo User Principal Name), například
FIRMA\MSA-VBR-SQL, a popis
Nastavení gMSA na úloze
Poté můžeme účet vybrat v nastavení zálohovací úlohy jako Guest OS credentials.
- Veeam Backup & Replication Console
- Home - Jobs - vytvoříme novou úlohu nebo editujeme existující
- Guest Processing - musíme zapnout jednu z možností zpracování, pak vybereme gMSA účet pod Guest OS credentials, můžeme vybrat vhodnou Guest interaction proxy nebo ponechat automatickou volbu
- pokud chceme použít různé účty pro různé VM, tak můžeme v Guest OS credentials for individual machines
- užitečná volba je provést test připojení pomocí Verify network connectivity and credentials
Použití Persistent Guest Agent
- v části Guest Processing klikneme na Application handling options for individual machines
- vybereme požadované VM a klikneme na Edit
- zatrhneme Use persistent guest agent
Testy různých nastavení
SQL Server
Testoval jsem gMSA na existující úloze, která zálohuje SQL servery. Dříve se používal standardní účet a Persistent Guest Agent. VM běží na Hyper-V.
Při prvním testu jsem na gMSA dal práva pouze pro počítač, kde běží SQL server. Při záloze se použil Backup Server jako Guest Interaction Proxy, který není členem domény (a neměl práva na gMSA). Přesto záloha proběhla korektně, včetně zkrácení transakčních logů pod gMSA účtem (ve chvíli, kdy dostal účet dostatečná práva na SQL) a zálohy transakčních logů.
Odebral jsem práva na gMSA pro SQL server. Nepovedlo se zkrácení transakčních logů.
09.05.2026 20:38:54 Warning : Failed to truncate Microsoft SQL Server transaction logs. Details: Failed to create a process token for MSA account: MSA-VBR-SQL, domain: FIRMA Win32 error:Access is denied. Code: 5 (Failed to create a process token for MSA account: MSA-VBR-SQL, domain: FIRMA ) (Win32 error:Access is denied. ) ( Code: 5)
Dalšími testy jsem ověřil, že je potřeba, aby měl gMSA oprávnění získat heslo na SQL Serveru a dostatečná práva pro SQL Server. Nepotřebuje být na serveru zařazen do skupiny Administrators.
Test připojení
Na zálohovací úloze jsem spustil Verify network connectivity and credentials. Neprošlo připojení ke Guest OS přes Administrative Share. Vůbec se netestovalo připojení pomocí PowerShell Direct.
07.05.2026 18:16:17 Failed : Failed to connect via Administrative share. Host: [sql2025.firma.local]. (Failed to connect to the guest OS. [Failed to connect to guest agent. Errors: 'Failed to connect to the administrative share.;Failed to connect to the administrative share.;']);
Nastavil jsem jiný Windows server (zařazený do domény) jako GIP. Na gMSA jsem přidal práva pro tento server. Připojení na Administrative Share proběhlo korektně.
Testoval jsem další SQL server, kde nebyl gMSA zařazen mezi lokální administrátory. Neprošlo připojení na Administrative Share kvůli právům.
07.05.2026 18:17:25 Failed : Failed to connect via Administrative share. Host: [sql2019.firma.local]. (Failed to connect to the guest OS. [Cannot connect to remote SCM database. Machine: [10.10.0.10]. Requested rights: [0x20005].;Win32 error:Access is denied.; Code: 5]);
Windows Server
Pro další test jsem vytvořil nový Backup Job, kam jsem přidal nové VM, kde byl čistě instalovaný Windows Server zařazený do domény. Na úloze jsem zapnul Application-Aware Processing a vybral gMSA účet. Vyzkoušel jsem VM běžící na Hyper-V i VMware.
Nejprve jsem nechal automatickou volbu GIP, použil se Backup Server (který není členem domény a nemá práva na gMSA). Zálohované VM také nemělo práva na gMSA. Došlo k chybě, že se nepovedlo vložit běhové komponenty.
10.05.2026 17:15:48 Succeeded : Failed to inject guest runtime components via GIP, failing over to guest agent connection via GIP 10.05.2026 17:15:50 Succeeded : Failed to connect to guest agent via GIP, failing over to guest runtime components 10.05.2026 17:15:50 Succeeded : Failed to inject guest runtime components, failing over to guest agent connection
Jako GIP jsem vybral připravený Windows server (v doméně a má práva na gMSA). Došlo ke stejné chybě.
Na zálohovaném VM jsem zařadil gMSA do skupiny lokálních administrátorů. Úloha korektně proběhla, použily se dočasné komponenty a vytvořil se VSS Snapshot. Zkusil jsem na úloze vrátit automatickou volbu GIP, opět se nepovedlo vložit dočasné komponenty.
Nastavil jsem použití Persistent Guest Agent a dostal jsem chybu připojení na agenta.
10.05.2026 17:49:45 Succeeded : Failed to connect to guest agent via GIP, failing over to guest agent connection 10.05.2026 17:49:45 Warning : Failed to create VM recovery checkpoint (mode: Veeam application-aware processing) Details: Unable to perform application-aware processing because connection to the guest could not be established
Došlo mi, že jsem zapomněl na zálohovaný server nainstalovat Veeam Deployment Kit. Když jsem svou chybu napravil, tak vše proběhlo korektně. S automatickou volbou Guest Interaction Proxy, kdy se použije Backup Server. Nejspíš se gMSA vůbec nepoužije, připojení je na Veeam Guest Agent s autentizací certifikátem.
Závěrem z těchto testů (v tomto scénáři) je, že když použijeme Persistent Guest Agent, tak může být jako GIP Backup Server a gMSA nepotřebujeme. Vše funguje, i když gMSA nemá nikde admin práva a žádný server nemá oprávnění získat jeho heslo. Zkusil jsem použít i neexistující účet a vše fungovalo.
Zatím zde nejsou žádné komentáře.