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
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.
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?