CZ 
17.01.2025 Drahoslav VÍTEJTE V MÉM SVĚTĚ

An English translation is available for this article. Pro tento článek je dostupný anglický překlad.
Refresh membership in AD groups without logoff or reboot

Obnovení členství v AD skupinách bez odhlášení či restartu

| Petr Bouška - Samuraj |
Když pracujeme na počítači pod doménovým účtem a přistupujeme ke zdrojům v síti, kde jsou oprávnění řízena pomocí bezpečnostních skupin. Pokud je náš účet zařazen do nové skupiny (abychom získali nový přístup), tak se změna projeví až po restartu počítače nebo odhlášení a přihlášení uživatele. V případě Kerberos autentizace (ne NTLM) můžeme vyvolat nové získání ticketů (příkazem klist), které obsahují aktuální členství ve skupinách. Za určitých podmínek tak rovnou získáme přístup daný novou skupinou. Nejprve se v článku podíváme na zobrazení seznamu skupin, kterých je aktuální uživatel členem.
zobrazeno: 2 700x (1 585 CZ, 1 115 EN) | Komentáře [2]

Když jsem věnoval popisu Group Managed Service Accounts (gMSA), tak jsem narazil na rady, jak obnovit členství počítače v AD skupinách bez restartu. To, když nastavujeme práva gMSA přes bezpečnostní skupinu, v které jsou dané počítače. Chtěl jsem se na to více podívat, hlavně by se to hodilo pro obnovu členství uživatele. Na internetu je to popsáno docela často. Chování v praxi ovšem není vždy stejné. Asi bez problémů to funguje pro počítač, ale horší je to s uživatelem. Na konci článku je popsána metoda, která mi funguje.

Úvod

Kerberos a bezpečnostní skupiny

Microsoft ukládá členství v bezpečnostních skupinách (Security Groups) v Privilege Attribute Certificate (PAC). To je Microsoft rozšíření Kerberos protokolu o autorizační údaje. Když se vystavuje TGT, tak se vytvoří PAC, který je jeho součástí, a obsahuje aktuální skupiny. Když se vystavuje Service Ticket pro nějakou službu, tak se nově nevyhodnocují skupiny, ale použije se TGT.

Pozn.: Celkově zde řešíme bezpečnostní skupiny (Security Groups), netýká se distribučních skupin (Distribution Groups). Skupina může mít scope (rozsah) Domain Local, Global nebo Universal, což pro nás zde nemá vliv.

Aktualizace členství ve skupině

Členství v bezpečnostních skupinách (v rámci Kerberos protokolu) se tedy aktualizuje, když se vystavuje Kerberos ticket (TGT). To se pro počítač děje při startu a pro uživatele při přihlášení.

Pomocí příkazu klist můžeme tickety smazat a pak se vystaví nové (při prvním použití). Tím by se obešla nutnost restartu či nového přihlášení. Ovšem mohou zůstat navázané session s původním ověřením, takže stále nemusí fungovat nový přístup. Je potřeba, aby se session nově vytvořila. V praxi to dobře funguje například v rámci webových aplikací, ale horší je to při přístupu na souborový server.

Uzamknutí a odemknutí Windows

Na mnoha místech se uvádí, že se tickety pro uživatele vymažou/obnoví při uzamknutí a odemknutí Windows/počítače. Pokud potřebujeme, aby uživatel získal přístup na souborovém serveru podle nově přidané skupiny, tak to pomocí odemknutí Windows zafunguje pouze někdy. Patrně to souvisí s tím, když existuje navázaná session se starou autentizací.

Když provedeme praktické testy, tak často vidíme, že po odemknutí máme vymazané všechny tickety. Ale přihlášením při odemknutí se nevystaví žádný ticket (ani TGT). Ani když následně přistoupíme na souborový server, tak se tickety nevystaví, ale přístupy fungují (ovšem bez nových skupin).

Pozn.: Narazil jsem i na situace, kdy se po odemknutí tickety nevymazaly a zůstaly původní. Vymazání také neproběhne, pokud jsme přihlášeni vzdáleně přes RDP.

Zobrazení informací o skupinách a ticketech

Řadu užitečných informací nám zobrazí řádkový příkaz whoami a jeho informace jsou spolehlivé. Příkaz whoami zobrazuje informace z aktuálního Access Token v systému.

Existuje i řada dalších příkazů nebo PowerShell cmdletů, jako net user, dsquery user, Get-ADUser, [Security.Principal.WindowsIdentity]::GetCurrent().

Aktuálně přihlášený uživatel (sAMAccountName)

Vypíše NetBIOS jméno domény a uživatelské jméno.

C:\> whoami
firma\bouska

Aktuálně přihlášený uživatel (User Principal Name)

Vypíše uživatelské přihlašovací jméno s UPN příponou (doménou).

C:\> whoami /upn
bouska@firma.cz

Seznam bezpečnostních skupin, kde je aktuální uživatel členem

Pomocí whoami dostaneme seznam členství v bezpečnostních skupinách, včetně implicitních skupin (tyto skupiny nemůžeme upravovat, členství v nich řídí systém, třeba Authenticated Users) a vnořených skupin (uživatel je zařazen do skupiny, která je zařazena do další skupiny).

C:\> whoami /groups

GROUP INFORMATION
-----------------

Group Name                       Type             SID          Attributes
================================ ================ ============ ==================================================
Everyone                         Well-known group S-1-1-0      Mandatory group, Enabled by default, Enabled group
BUILTIN\Administrators           Alias            S-1-5-32-544 Group used for deny only
BUILTIN\Users                    Alias            S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users Well-known group S-1-5-11     Mandatory group, Enabled by default, Enabled group
FIRMA\G Média                    Group            S-1-5-21-2200562...

Pozn.: Tento příkaz neukazuje členství ve skupině Domain Users.

Můžeme jednoduše vyhledat název určité skupiny (nebo jeho část).

C:\> whoami /groups | findstr "Users"
BUILTIN\Users

Trochu jinak formátovaný výpis seznamu skupin.

C:\> whoami /groups /fo list | findstr /c:"Group Name:"
Group Name: Everyone
Group Name: BUILTIN\Administrators
Group Name: BUILTIN\Users

Pokud chceme nějak formátovat, tak můžeme využít PowerShell.

PS C:\> whoami /groups /fo csv | ConvertFrom-Csv | FT 'Group Name', Type

Group Name                                               Type            
----------                                               ----            
Everyone                                                 Well-known group
BUILTIN\Administrators                                   Alias           

Seznam skupin pomocí PowerShellu

Jiná možnost je použít přímo PowerShell a zobrazit seznam skupin včetně implicitních a vnořených.

PS C:\> [System.Security.Principal.WindowsIdentity]::GetCurrent().Groups.Translate([System.Security.Principal.NTAccount])

Value 
----- 

FIRMA\Domain Users
Everyone
BUILTIN\Administrators

Seznam skupin pomocí gpresult

Pěkný výsledek nám dá příkaz gpresult. Seznam skupin načítá z jiného zdroje než whoami (zobrazuje Resultant Set of Policy). Obsahuje také implicitní a vnořené skupiny.

Můžeme vypsat bezpečnostní skupiny uživatele.

C:\> gpresult /r /scope user
 
The user is a part of the following security groups
---------------------------------------------------
Domain Users
G Média 

Nebo počítače. Ale na to potřebujeme oprávnění lokálního administrátora.

C:\> gpresult /r /scope computer

The computer is a part of the following security groups
-------------------------------------------------------
BUILTIN\Administrators
Domain Computers

Seznam skupin z AD domény

Jiná možnost je dotázat se na členství uživatele ve skupinách přímo Active Directory, třeba příkazem net user. Standardně má uživatel oprávnění zobrazit pouze svoje skupiny. Zobrazí se pouze bezpečnostní skupiny, do kterých je uživatel přímo zařazen (ne implicitní a vnořené skupiny). Zobrazuje se aktuální stav v AD DS, nikoliv skupiny pro aktuální přihlášení na počítači.

C:\> net user /domain bouska
...
Local Group Memberships      *DHCP Users
Global Group memberships     *Domain Users     *G Média

Příkaz net user nemá moc rozumný výstup a ořezává názvy na 21 znaků. Takže je lepší použít PowerShell cmdlety.

PS C:\> Get-ADUser bouska -Properties MemberOf | Select-Object -ExpandProperty MemberOf | Get-ADGroup | FT Name -AutoSize 

Name 
---- 
DHCP Users
G Média 

Informace o získaných Kerberos Service Ticket na klientovi

Ve Windows můžeme použít řádkový příkaz klist, který vypíše všechny kešované Kerberos tickety (TGT a Service Ticket), které klient získal. Je vidět pro jakou identitu (Client) a službu (Server) byl ticket vystaven, který DC jej vystavil (Kdc Called) a kdy vznikl (Start Time).

Pozn.: Velmi důležité. Pokud používáme User Account Control (UAC). Pak záleží, jestli je příkazový řádek spuštěn standardně nebo jako administrátor (elevation prompt). Každá situace zobrazí jiné tickety, protože v systému jde o dvě různé session (používá se jiný User Access Token).

Výpis ticketů vystavených pro aktuálního uživatele.

klist

Výpis ticketů vystavených pro počítač (Local System).

klist -li 0x3e7

Získání ticketu pro určitou službu (SPN).

klist get cifs/FileServer

Vymazání všech ticketů pro uživatele.

klist purge

Vymazání všech ticketů pro počítač.

klist -li 0x3e7 purge 

Příklad výpisu TGT ticketu pro uživatele.

C:\>klist

Current LogonId is 0:0xe3ada4f

Cached Tickets: (1)

#0>     Client: bouska @ FIRMA.LOCAL
        Server: krbtgt/FIRMA.LOCAL @ FIRMA.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 10/4/2024 15:13:28 (local)
        End Time:   10/5/2024 1:13:28 (local)
        Renew Time: 10/11/2024 15:13:28 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: dc.firma.local

Příklad výpisu TGT ticketu pro uživatele spuštěno jako administrátor.

C:\>klist

Current LogonId is 0:0xe3ad6c4

Cached Tickets: (1)

#0>     Client: bouska @ FIRMA.LOCAL
        Server: krbtgt/FIRMA.LOCAL @ FIRMA.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 10/4/2024 15:14:38 (local)
        End Time:   10/5/2024 1:14:38 (local)
        Renew Time: 10/11/2024 15:14:20 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: dc.firma.local

Aktualizace členství ve skupině

Pro účet počítače

Potřebujeme administrátorská oprávnění. Příkazovou řádku (cmd.exe) spustíme jako administrátor a v ní zadáváme příkazy níže.

  • (volitelné) Můžeme si vypsat aktuální skupiny a tickety pro počítač.
gpresult /r /scope computer
klist -li 0x3e7
  • Přidáme účet počítače do bezpečnostní skupiny v AD.
  • Smažeme tickety pro počítač a aktualizujeme skupinové politiky (pro získání nových ticketů).
klist -li 0x3e7 purge
gpupdate
  • Když nyní vypíšeme seznam skupin pro počítač, tak obsahuje novou skupinu.
gpresult /r /scope computer

Pro účet uživatele

Pro operace nepotřebujeme administrátorská oprávnění. Ale jak jsme si uvedli, pokud používáme UAC, tak existují dvě různé session s různými tickety. Takže záleží, zda spustíme příkazovou řádku jako admin nebo ne. Stejně tak aplikace, v kterých budeme přístupy využívat. Když použijeme příkaz klist, tak začátek výstupu obsahuje Current LogonId is, kde je identifikovaná přihlašovací session.

  • (volitelné) Můžeme si vypsat aktuální skupiny a tickety pro uživatele. Případně vyhledat skupinu, kterou chceme přidat (že ji uživatel zatím nemá). Pro další testování je lepší používat příkaz whoami.
gpresult /r /scope user
whoami /groups | findstr ADU
klist
  • Přidáme účet uživatele do bezpečnostní skupiny v AD.
  • Smažeme tickety pro uživatele (toto vlastně dělat nemusím, viz. další popis).
klist purge

Některé návody takto končí, ale to v praxi nefunguje. Jiné uvádí, že máme spustit příkazovou řádku s novým přihlášením uživatele (RunAs). To můžeme provést příkazem níže nebo kliknout na cmd.exe Shift + pravé tlačítko a volba Run as different user.

runas /User:%USERDOMAIN%\%USERNAME% cmd.exe

Tím dojde k novému přihlášení a vznikne nová session (pouze pro tento cmd.exe). Příkaz klist zobrazí jiné LogonId. K tomu je zbytečné mazat tickety v původní session. V tomto okně uvidíme nově přidanou skupinu (pomocí whoami, gpresult ji nezobrazí).

whoami /groups | findstr ADU

Čekal bych, že když z tohoto okna spustím explorer.exe, tak bude přístup fungovat. V některých případech ale nefunguje. Další zvláštní chování je, že mi v řadě testů funguje přístup z Total Commander, ale nikoliv z File Explorer.

Na řadě míst se uvádí další rada. A ta mi v praxi funguje.

  • Ukončíme proces Windows Explorer a nastartujeme jej znovu s přihlášením uživatele.
taskkill /F /IM explorer.exe
runas /User:%USERDOMAIN%\%USERNAME% explorer.exe 

Vznikne nová session s novým přihlášením. Pokud znovu otevřeme cmd.exe (původní se nemění), tak klist ukáže jiné LogonId a zobrazí se nová skupina (gpresult ji stále nezobrazuje). Pokud spustíme nějakou aplikaci, třeba File Explorer, tak přidané přístupy fungují.

whoami /groups | findstr ADU
Obnovení členství uživatele ve skupině bez odhlášení

Související články:

Kerberos protokol se zaměřením na SSO v AD DS

Nový seriál, který se podrobně věnuje protokolu Kerberos V5, hlavně v prostředí Microsoft Active Directory. Popisuje i řadu souvisejících věcí, které jsou potřeba pro pochopení fungování Kerberos Single Sign-On (SSO).

Windows OS

Články, které se věnují operačním systémům firmy Microsoft, jak klientských, tak serverových.

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře
  1. [1] Radim Bárta

    Perfektní článek. Ještě jsem slyšel o možnosti "čištění" SMB session pro uživatele pomocí restartu služby Workstation (v CZ Pracovní stanice). Nicméně funkčnost jsem reálně nezkoušel.

    Pondělí, 14.10.2024 18:25 | odpovědět
  2. [2] Michal Habala

    Dobry den, diky za clanek, uz nejakou dobu praktikujeme reseni se sestrelenim exploreru a spusteni nove explorer session pres cmd-propmt.

    Mame ale novy pripad, ktery je ponekud komplikovanejsi tim, ze jsou ve hre dve domeny. Pocitac s Win11 je clenem domeny A a file server, na ktery dani uzivatele potrebuji pristupovat je clenem domeny B. Mezi temito domenamy neexistuje zadna forma trustu.

    Pristupy funguji spolehlive pro stavajici uzivatele, kteri meli pristup od jakziva, nicmene v situaci, kdy napriklad novy zamestnanec dostane novy pocitac s domenou A a zaroven dostane pristupova prava do slozek na serveru v domene B, nevim zda existuje reseni, jak docili obnoveni clenstvi ve skupinach v takove situaci.

    Jen pro upresneni - jde o situaci, kdy firma A koupila firmu B a uzivatele dostali nove laptopy/desktopy od firmy A a maji vybaveny pristup do site firmy B a k pristupu ke zdrojum ve firme B stale pouzivaji jejich stare (potazmo nove pokud jde o nove zamestnance) domenove ucty - maji napr. namapovane slozky stylem: net use K: \\server\folder /user:domena_B\uzivatel

    Mel by nekdo nejaky typ jak resit obnoveni clenstvi ve vyse popsane situaci?

    Středa, 04.12.2024 16:33 | odpovědět
Přidat komentář

Vložit tag: strong em link

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách