Včera mi Ondrej Žilinec poslal odkaz na článeček o tom, jak se aktualizuje členství ve skupinách, aniž byste se museli odhlásit. No dobře, je to jen trošku jednoduše napsáno a neplatí to vždy.
Takže přesnější vysvětlení následuje
Pojem členství ve skupinách je trošku složitější. Pokud se přihlásíte na stanici nebo server interaktivně (tedy přes vzdálenou plochu, nebo CTRL-ALD-DEL), tak se vám vytvoří tzv. access token. To je paměťová struktura, která obsahuje všechny SIDy odpovídající vašemu účtu a skupinám, ve kterých jste. Nezapomeňte, že tam patří i SID history, případně.
Pro zajímavost jen uveďme, že tato struktura může obsáhnout maximálně 1025 SIDů. Pokud byste jich měli více, nepřihlásíte se.
Access token má každý váš proces. A systém to používá pro přístup na místní (local resource) prostředky. Zdůrazňuju jenom místní. Takže to má vliv na aplikaci Group Policy a schopnost dělat akce na daném počítači, nebo serveru. Ale pozor! To také znamená, že se to vztahuje i na to, když byste šli "přes síť". Na nějakou službu, která je na stejném operačním systému.
Sice tam možná jdete "přes síť", tedy zadáváte do prohlížeče, nebo SQL, nebo jiného klienta normální URL. Ale pokud je ta služba na stejném stroji, tak se použije (ne úplně vždy :-)) zase ten původní access token.
Tohle se vygeneruje v okamžiku přihlášení a nelze to aktualizovat jinak, než se znovu odhlásit. Stejně tak to platí pro access token systému. Takže procesy, které běží pod účtem počítače (SYSTEM, Network Service, Local Service, NT SERVICE, IIS AppPool), mají také stejný problém. Vyžaduje to restart. Tedy pokud se jedná o přístup na lokále.
I zde bacha. Pokud jste si spustili nějakou COM službu pod svým účtem, je možné, že ta se neukončí v okamžiku vašeho "odhlášení". Jí tedy ten původní access token zůstane. A museli byste si počítač restartovat.
Co když jdete do sítě
Tak ano, tam ten článek skoro platí. Do sítě se ověřujete buď pomocí Kerberos, nebo NTLM (a nebo Schannel, ale to se chová stejně, jako NTLM), nebo Basic ověřením.
Primární je Kerberos. Pro ten platí ten původní článeček. Kerberos si generuje tikety, které platí 10 hodin. I potom se dají ještě pár dnů jen prodloužit, takže by se členství opět nemuselo za všech okolností aktualizovat. Ano, můžete použít metodu z článečku a vyhodit keš pomocí KLIST PURGE.
Článeček ovšem nezmiňuje, co se děje při zapnutém User Account Control. Když máte UAC, každý uživatel má dvě keše tiketů. Tedy tu poníženou a povýšenou. Musíte pak pustit KLIST PURGE dvakrát - normálně i zvýšeně.
Jenže ani tady to není úplně pravda. Ověřování pro síťové spojení nastává obvykle jen jednou, při jeho vytvoření. Na druhé straně zase vznikne access token. A ten tam vydrží, dokud se dané TCP spojení neukončí. Jestli jste si všimli, jak HTTP, tak i SMB a samozřejmě většina dalších aplikací se jednou připojí a potom si to TCP spojení ponechá. Mnohdy až do okamžiku ukončení aplikace. V případě SMB to nelze jen tak z klienta ukončit. Musíte se odhlásit. V případě počítače ho restartovat. Jinak nemáte jistotu.
Pokud se jedná o NTLM, nebo Schannel, tak to je jednodušší. Zde se nic nekešuje. Ověřování probíhá pro každé nové TCP spojení znovu a znovu. Takže i seznam skupin (SIDů lépe řečeno) se vám osvěží při každém novém připojení. V případě sdílených souborů bych se opět raději odhlásil, protože nikdy nevíte.
Nejkrásnější je Basic ověření. To je taková ta clear-text metoda, kdy posíláte čísté heslo na server. Tohle si sami z klienta neaktualizujete. IIS web server tohle kešuje u sebe v paměti. Abyste měli jistotu, že to server zahodí, musíte ho restartovat. Server. Ne klienta.
Ještě poslední případ je Kerberos delegation. Tam taky musíte restartovat ten prostřední server. Z klienta se jeho keš vyhodit nedá.
Obecné doporučení
Takže já bych osobně řešitelům potíží doporučoval, aby se odhlašovali a restartovali, než aby pak troublešůtovali něco, co vlastně není chyba.