V poslední době se člověkům dost zvyšuje používání PowerShell příkazové řádky na správu více serverů. Speciálně s Hyper-V cluster a podobně. A člověk rád používá remoting, tedy Invoke-Command a podobně. A začíná bojovat s problémem přístupu na ještě vzdálenější servery - tedy double hop (neboli delegation).
Už jsem tu před nějakou dobou psal o tom, jak (ne)povolovat delegaci pro PowerShell remoting a jeho příkazy jako je Invoke-Command nebo Enter-PSSession. Článek byl o tom, že musíte použít pouze volbu Trust this computer for delegation to any service. Teď jsem to vyzkoušel na Windows 2012 a jede to i s druhou volbou Trust this computer for delegation to specified services only with Any authentication protocol.
Ani jedna volba není ideální, ale podívejme se tedy na obě možnosti pořádně.
PowerShell remoting a problém s double-hop (neboli delegation)
Scénář je tento Client8 ---> Srv2k12r2 ---> Data1. Na klientovi máte puštěný PowerShell. Na prostředním serveru Srv2k12r2 chcete spouštět příkazy. Spouštíte nějaký příkaz pomocí Invoke-Command, nebo třeba Enter-PSSession.
K tomu musíte být samozřejmě členem skupiny Administrators na tom vzdáleném počítači, bez toho byste se tam ani nedostali (tohle povolit by bylo ještě stokrát složitější). To je ok.
Jenže ten příkaz, který poběží na vzdáleném počítači chce jít ještě na nějaký další počítač. Děláte tedy tak zvaný double-hop, neboli delegation (Kerberos delegation).
Pokud to nemáte nějak povoleno, tak Invoke-Command neuspěje stejně, jako v prvním případě na obrázku. Tedy chyba jako:
Access is denied (error 0x5, 0xC0000005)
Permission denied, UnauthorizedAccessException, Anonymous logon
To stejné byste zažili, kdybyste dělali kompletní Enter-PSSession.
Ve druhém případě se to už povedlo, což by mělo dokumentovat okamžik, kdy už máte tu delegaci (delegation, double hop) povolenu.
Jak povolit delegation a dokázat potom udělat double hop?
Máte v zásadě dvě základní možnosti:
- použijete CredSSP ověřování. To ale budete muset zadávat login a heslo při připojování a ještě to budete muset povolovat v politice.
- použijete jednu ze dvou možných Kerberos delegation. Jak už jsem psal dříve, původně fungovala jenom jedna metoda Kerberos delegace, na Windows 2012 už fungují dvě ze tří. Asi to soudruzi vylepšili.
- funguje - Trust this computer for delegation to any service
- nefunguje - Trust this computer for delegation to specified services only with Kerberos only
- funguje od Windows 2012 - Trust this computer for delegation to specified services only with Any authentication protocol
Povolení double hop PowerShell remoting pomocí Trust this computer for delegation to any service
Tahle metoda povolí delegaci úplně kamkoliv. Kdokoliv se dokáže připojit přes WinRM na ten server vzdáleně, se potom dostane už úplně kamkoliv jinam. Současně povolujete také libovolným službám na tom serveru, aby po příchodu nějakého libovolného ověřeného uživatele pokračovaly kamkoliv dále.
To je hrozně nebezpečné. Ale funguje to už od domain functional level 2000. Nastavíte prostě delegaci pro prostřední server takto:
Obrázek: volba Trust this computer for delegation to any service, v češtině Důvěřovat tomuto počítači pro delegování libovolné službě (pouze protokol Kerberos).
Dále musíte ještě přidat ten účet prostředního serveru do skupiny WAAG (Windows Authorization Access Group). Tahle skupina totož umí číst atribut tokenGroupsGlobalAndUniversal. Obvykle to sice není potřeba, protože skupina Authenticated Users je by default členem skupiny Pre-Windows 2000 compatible access, ale pro jistotu tím nic nezkazíte:
A musíte ten prostřední server (v mém případě Srv2k12r2) restartovat! LSASS má různé keše, které je potřeba vyhodit. Nepomůže ani chvilku počkat, ani restartovat jen nějakou službu. Otočte to celé. Samozřejmě možná něco někdy pojede i bez restartu, ale už jsem na tom strávil hodně bezesných nocí.
Na klientovi se musíte odhlásit! Aby se vám vyčistila klientská keš Kerberos tiketů. Opět by mohlo pomoci klist purge, ale není to úplně na jistotu.
Poněkud omezenější a bezpečnější Kerberos delegation za pomoci Trust this computer for delegation to specified services only with Any authentication protocol
Druhá možnost delegace je na jedné straně více omezená. Na druhé straně je tedy také komplikovanější, pokud chcete povolit více double hop služeb na vzdálených serverech. Na třetí straně tím dáváte možnost prostřednímu serveru (a tedy jeho libovolným službám běžícím jako SYSTEM, Network Service, nebo pod virtuální servisní identitou - virtual service identity) dělat si delegaci, aniž by se k nim vůbec musel někdo připojovat. Takže za jistých podmínek dokonce nebezpečnější.
Podle obrázků to povolíte podobně, jenom musíte vyjmenovat seznam služeb, do kterých může prostřední server delegovat:
Obrázek: volba Trust this computer for delegation to specified services only, Any authentication protocol. V češtině Důvěřovat tomuto počítači pro delegování pouze určeným službám - Používající libovolný protokol pro ověření.
Závěr
Ani CredSSP, ani Kerberos delegation není v podstatě jednoduchá na zapnutí a navíc to vyvolává bezpečnostní pochybnosti. Já to nerad používám. Vždycky se to dá obejít nějak jinak.
Jak jsme dneska zjistili, například to koliduje s nastavením delegace pro Hyper-V live migration.