cs 
Pokud jste někdy zkusili otočit (rotovat) heslo servisního účtu a následně vám spadla polovina firemní aplikace, už víte, jak to v praxi chodí: servisní účty jsou zároveň nepostradatelné i křehké.
Jsou nepostradatelné, protože pohánějí „neviditelnou“ infrastrukturu – Windows služby, plánované úlohy, IIS aplikační pooly, integrace a automatizace, které musí fungovat i tehdy, když není nikdo přihlášený. Jsou křehké, protože bývají přepřevilegované, dlouhodobě používané, sdílené napříč systémy a typicky je těžké je bezpečně rotovat bez výpadků.
V PAM360 se pojem „service account“ v dokumentaci i praxi používá ve třech souvisejících významech – a většina nejasností vzniká tím, že se tyto významy míchají:
- Servisní účty, které v PAM360 spravujete (ukládané přihlašovací údaje, governance, rotace a synchronizace závislostí)
- Servisní účet, pod kterým běží samotné PAM360 (používá se pro vzdálené operace, např. reset hesel)
- Cloudový „service account“ pro API operace (např. Google Workspace service account + klíčový soubor)
Pojďme si to rozebrat přehledně a pak si ukázat, jak PAM360 dokáže najít závislosti a bezpečně propagovat změny hesel.
1. Servisní účty – jednoduše vysvětleno
Servisní účet je nelidský účet používaný aplikacemi, službami, skripty a plánovanými úlohami k autentizaci a vykonávání práce. Často potřebuje vyšší oprávnění, protože služba, kterou provozuje, je ze své podstaty privilegovaná (zálohování, monitoring, synchronizace adresářů, databázové joby apod.). ManageEngine popisuje service accounts jako privilegované doménové účty používané aplikacemi/službami a plánovanými úlohami pro interakci s OS a dalšími komponentami.
V praxi to vypadá takto:
- Windows služba běží pod DOMAIN\svc_app
- Noční plánovaná úloha běží pod DOMAIN\svc_batch
- IIS AppPool identity je nastavená na DOMAIN\svc_web
- V web.config je uložené DB heslo, které aplikace používá
- V cloudu existuje identita (např. Google Workspace „service account“) pro volání admin API
PAM360 je navrženo tak, aby z těchto rozptýlených a rizikových identit udělalo řízené účty s governance, rotací a auditní stopou.
2. „Servisní účty“ v PAM360: 3 významy, které musíte oddělit
A) Servisní účty, které spravujete (účty, které něco „běží“)
PAM360 podporuje discovery privilegovaných účtů a zahrnuje také discovery service accounts spojených s Windows a Linux (SSH only) doménovými účty, spolu s discovery zařízení jako Windows, Linux, VMware a síťové prvky.
Pro Windows má PAM360 speciální funkce, které po změně doménového hesla zajistí synchronizaci „závislých použití“ tohoto účtu:
- Windows Service Accounts Password Reset (Windows služby + plánované úlohy využívající doménový účet)
- Windows Scheduled Tasks Password Reset (workflow zaměřený na úlohy; má specifická omezení)
- IIS AppPool account password reset (aktualizuje identitu aplikačního poolu po změně hesla)
- IIS web.config credential discovery/reset (najde weby, kde je účet v connection stringu, a po resetu aktualizuje heslo)
Tohle jsou „spravované“ servisní účty v tom PAM smyslu: PAM360 heslo nejen uloží/rotuje, ale také sleduje, kde se používá, a pomáhá změnu propagovat.
B) Servisní účet serveru PAM360 (identita, kterou PAM360 používá k provádění operací)
Pokud provozujete PAM360 na Windows, běží jako Windows služba. Dokumentace k remote password reset uvádí, že defaultně PAM360 resetuje hesla Windows lokálních účtů pomocí servisního účtu, pod kterým běží PAM360 služba, a pokud je tento účet privilegovaný (Domain Admin / lokální admin na cílech), dokáže reset provést i bez znalosti původního hesla.
FAQ zároveň zmiňuje, že pro discovery a funkce password reset potřebujete service account nebo gMSA s Domain Admin právy nebo lokálními admin právy na PAM360 serveru a spravovaných systémech.
Tohle je zásadní architektonický bod:
- Spravované identity = hesla, která ukládáte/rotujete (servisní účty ve vaší infrastruktuře)
- Provozní identita = účet, kterým se PAM360 připojuje a provádí discovery/reset
Není to totéž – ale v dokumentaci se pro obojí často používá „service account“.
C) Cloudový „service account“ (API identita pro vzdálené resety)
Pro reset hesel v Google Workspace používá PAM360 Google Cloud service account. Od PAM360 build 7200 se reset hesel v Google Workspace dělá přes service account key file (změna na straně Google).
ManageEngine k tomu má samostatný konfigurační návod, který popisuje domain-wide delegation a povolení Admin SDK API apod.
To je „service account“ ve smyslu cloudu: API principal, kterým PAM360 volá administrátorské funkce.
3. Co PAM360 reálně dělá s Windows servisními účty
Základní problém: rotace hesel rozbije závislosti
V doméně může být jeden účet použitý pro:
- Windows služby
- Plánované úlohy
- IIS AppPools
- Aplikace, které mají heslo uložené v konfiguraci (např. connection string v IIS web.config)
Změnit doménové heslo je snadné. Aktualizovat všechna „místa použití“ na desítkách serverů je to, co způsobuje výpadky.
Přístup PAM360: mapovat závislosti a propagovat změny
Funkce Windows Service Account Password Reset popisuje:
- U doménového účtu, u kterého je reset servisního účtu povolen, PAM360 vyhledá služby, které používají tento účet jako logon identity, a automaticky provede reset při změně doménového hesla.
- Může projít asociované resource groups a aktualizovat služby i plánované úlohy, poté služby dle potřeby restartovat.
Dokumentace uvádí i předpoklady, které je potřeba brát vážně:
- .NET Framework 4.5.2+
- Visual C++ 2015 redistributable
- RPC a WMI povoleno na cílových serverech
- PAM360 služba běžící pod doménovým admin účtem pro tento scénář
Pro IIS:
- PAM360 identifikuje IIS AppPooly běžící pod konkrétním doménovým účtem a automaticky po resetu aktualizuje identitu app poolu.
- Pro IIS web.config může PAM360 vylistovat weby, kde je účet v connection stringu, a následně aktualizovat heslo napříč servery.
Timing restartu je důležitý
I když se heslo správně promítne, služba může selhat, pokud se restart provede „příliš rychle“. PAM360 má v nastavení možnost čekat X sekund mezi stop/start služeb po resetu servisního účtu, specificky pro Windows Domain service account reset.
V praxi to často rozhoduje o tom, zda rotace proběhne hladce, nebo vznikne incident.
4. Kde „servisní účty“ v PAM360 žijí: resources, domains, groups a asociace
PAM360 je postaveno kolem Resources a Accounts a kolem skupin (groups), které umožňují automatizaci ve větším měřítku.
Několik detailů je u service accounts zásadních:
WindowsDomain resources a NETBIOS doménové jméno
Při přidávání doménového kontroleru jako WindowsDomain resource dokumentace zdůrazňuje, že v poli Domain Name musíte zadat doménu jako NETBIOS, a zmiňuje, že je to potřeba pro Windows Service Account Reset feature.
Tohle je typický detail, který dokáže celý scénář tiše rozbít.
Resource groups jako bezpečnostní hranice propagace
Ve workflow Windows Service Account reset se doménový účet asociuje s jednou nebo více resource groups a PAM360 pak pomocí těchto skupin zjišťuje a aplikuje změny na serverech, kde se účet používá.
Pokud jsou resource groups příliš široké, výrazně zvyšujete „blast radius“. Dobrá praxe je stavět skupiny podle aplikačních hranic (např. „ERP Web Tier“, „Payroll App Servers“, „SQL Cluster Nodes“ apod.).
Discovery a sync: udržení inventáře aktuálního
Průvodce privileged accounts discovery uvádí, že PAM360 umí objevovat resources a enumerovat privilegované účty, a také umí periodicky dotazovat AD pro udržení synchronizace. Doporučuje nastavit AD sync interval na 3 hodiny nebo více podle velikosti prostředí.
Závislosti servisních účtů se mění – servery se rebuildí, aplikace se přesouvají, scheduled tasks se znovu vytváří. Discovery + sync je to, co drží rotace bezpečné dlouhodobě.
5. Scheduled tasks: podobný problém, ale s omezeními
Scheduled tasks mají své specifikum. Dokumentace k Windows Scheduled Tasks Password Reset uvádí dvě zásadní omezení:
- Reset hesla je podporovaný jen pro úlohy V2
- Pokud PAM360 běží na vyšší verzi OS, může selhat reset scheduled task hesel na úlohách běžících na nižších OS verzích (příklad: PAM360 na 2016 vs tasks na 2008 a nižší).
Prakticky: pokud máte legacy Windows servery s kritickými scheduled tasks, ověřte kompatibilitu hned na začátku, ne až v prvním rotačním okně.
6. Provozní identita PAM360: service account vs gMSA
Varianta 1: Spouštět PAM360 službu pod privilegovaným servisním účtem
Dokumentace uvádí, že pokud PAM360 Windows služba běží pod privilegovaným účtem (Domain Admin / lokální admin na cílech), dokáže resetovat hesla i bez znalosti starého hesla. FAQ opakuje potřebu service account (nebo gMSA) s odpovídajícími právy pro discovery/reset.
Je to silné – ale jde o velmi citlivou identitu. Zacházejte s ní jako s Tier-0:
- zakázat interaktivní logon,
- monitorovat její použití,
- minimalizovat scope a práva.
Varianta 2: Spouštět PAM360 službu pod gMSA
PAM360 má návod k použití gMSA pro běh služby a popisuje jej jako „passwordless“ autentizaci pro service logon, včetně kroků konfigurace.
gMSA často snižuje operativní riziko (neexistuje klasické statické heslo, které by se sdílelo). Pořád ale platí, že výsledná bezpečnost závisí na tom, jak nastavíte oprávnění a kde dovolíte dané gMSA autentizovat.
7. Servisní účty a izolované sítě: Application Gateway
Pokud máte segmentované/oddělené sítě, kde PAM360 nemůže přímo na cíle, dává smysl Application Gateway. Přehled Application Gateway výslovně uvádí, že přes gateway lze dělat discovery mimo jiné pro:
- Service Accounts
- Scheduled Tasks
- IIS AppPools
- IIS Web.config credentials
To znamená, že i v segmented prostředí lze service account governance rozumně realizovat – jen musíte správně navrhnout konektivitu a hranice důvěry.
8. Nejužitečnější mentální model pro „servisní účty v PAM360“
Vrstva 1: Identity, které spravujete (co rotujete)
- Doménové účty používané službami/úlohami/app pooly
- Hesla uložená v konfiguračních souborech aplikací
- API identity typu Google Workspace service account
Vrstva 2: Závislosti, které musíte synchronizovat (kde se musí aktualizovat heslo)
- Windows Services + Scheduled Tasks
- IIS AppPools
- IIS web.config connection stringy / webové konfigurace
Vrstva 3: Provozní identita, která změny provádí (jak se to technicky vykoná)
- Účet, pod kterým běží PAM360 (service account nebo gMSA) s potřebnými právy
Jakmile si tohle v týmu jasně pojmenujete, architektura i troubleshooting je výrazně jednodušší.
9. Praktický „starter playbook“ pro service accounts v PAM360
Krok 1: Vymezte scope inventáře servisních účtů
Začněte u účtů, které jsou nejrizikovější nebo nejvíc bolí při výpadku:
- účty s lokálním adminem / vysokými právy
- účty používané na více serverech
- účty, které sahají na DB nebo identity systémy
Krok 2: Vytvořte úzké resource groups podle aplikací
Cíl: rotovat bezpečně a propagovat změnu jen tam, kde opravdu má být.
Krok 3: Zapněte dependency-aware reset funkce
- Windows Service Accounts reset (služby + úlohy)
- Scheduled tasks reset (pokud máte oddělené identity pro úlohy)
- IIS AppPools reset
- IIS web.config discovery/reset
Krok 4: Dolaďte restart chování
- zapnout restart tam, kde to dává smysl
- nastavit „wait X seconds“ mezi stop/start po resetu, pokud to služby vyžadují
Krok 5: Automatizujte rotaci až po ověření
PAM360 podporuje plánovanou periodickou rotaci na úrovni resource groups (včetně retry a notifikací).
Automatizaci berte jako poslední krok – až po několika úspěšných manuálních/on-demand rotacích.
10. Typické pasti (a jak se jim vyhnout)
- „Rotace proběhla, ale aplikace spadla.“
Nejčastěji restart timing nebo chybějící závislost (AppPool, scheduled task, web.config). Používejte podporované discovery/reset funkce a dolaďte čekání mezi stop/start.
- „Discovery nenajde všechno.“
Zkontrolujte prerequisites (.NET, VC++), konektivitu a scope AD discovery/sync.
- „Service account reset nefunguje vůbec.“
Často je problém v konfiguraci WindowsDomain resource (NETBIOS), WMI/RPC, nebo právech účtu, pod kterým PAM360 běží.
- „Scheduled tasks se neaktualizují.“
Ověřte V2 požadavek a OS omezení.
- „Máme segmentaci, PAM360 se nedostane na cíle.“
Použijte Application Gateway pro discovery a password ops v izolovaných sítích.
Referenční URL (oficiální dokumentace a klíčové návody)
https://www.manageengine.com/privileged-access-management/help/windows_service_account_reset.html
https://www.manageengine.com/privileged-access-management/help/windows-scheduled-tasks-reset.html
https://www.manageengine.com/privileged-access-management/help/iis_apppool_account_reset.html
https://www.manageengine.com/privileged-access-management/help/discovery-of-iis-web-config.html
https://www.manageengine.com/privileged-access-management/help/remote_password_reset.html
https://www.manageengine.com/privileged-access-management/help/privileged_accounts_discovery.html
https://www.manageengine.com/privileged-access-management/help/adding_resources.html
https://www.manageengine.com/privileged-access-management/help/general_settings.html
https://www.manageengine.com/privileged-access-management/help/get-started.html
https://www.manageengine.com/privileged-access-management/help/faq.html
https://www.manageengine.com/privileged-access-management/help/ag-overview.html
https://www.manageengine.com/privileged-access-management/help/google-service-account-config.html
https://www.manageengine.com/products/passwordmanagerpro/what-is-service-account-management.html
https://www.manageengine.com/privileged-access-management/help/checklist.html
