После добавления учетной записи компьютера или пользователя в группу безопасности Active Directory, новые полномочия доступа к ресурсам или новые GPO применяются не сразу. Чтобы обновить членство в группах и применить назначенные права/политики, нужно перезагрузить компьютер или перелогиниться в систему (для пользователя). Это связано с тем, что членство в группах AD обновляется при создании билета Kerberos, которое происходит при загрузке системы или при аутентификации пользователя во время входа в систему.
Если вы не можете немедленно выполнить перезагрузку компьютера или logoff пользователя, можно обновить членство учетной записи в группах AD помощью утилиты
klist.exe
. Эта утилита позволяет сбросить билеты Kerberos.
Вы можете вывести список групп безопасности домена, в которых состоит текущий пользователь с помощью команды:
whoami /groups
или GPresult
gpresult /r /scope user
Список групп, в которых состоит пользователь указан в разделе “The user is a part of the following security groups”.
Обновить билет Kerberos и группы компьютера без перезагрузки
Список групп безопасности, в которых состоит данный компьютер можно вывести командой:
gpresult /r /scope computer
The computer is a part of the following security groups
Вы можете вывести список кэшированных билетов Kerberos, полученных компьютером, а также дату их получения и следующего обновления:
klist.exe -li 0x3e7
Теперь добавьте компьютер в новую группу безопасности AD (через оснастку ADUC или с помощью PowerShell команды:
Add-AdGroupMember -Identity corpAntivirusExclusionPC -Members wks-msit012$
)
Чтобы очистить кэш тикетов Kerberos компьютера и обновить членство компьютера в группах AD, выполните команду (для Windows 7 и Windows Server 2008R2)
klist -lh 0 -li 0x3e7 purge
Или для Windows 11/10/8 и Windows Server 2012+
klist –li 0x3e7 purge
Deleting all tickets: Ticket(s) purged!
Обновите настройки групповых политик командой gpupdate /force , после этого к компьютеру без перезагрузки будут применены все GPO, назначенные группе безопасности AD через Security Filtering.
Вы можете проверить время получения билетов Kerberos компьютера с помощью команды:
klist -li 0x3e7 tgt
klist -li 0:0x3e7 purge
вы получили ошибку вида (Error calling API LsaCallAuthenticationPackage):
Current LogonId is 0:0x5d2ed1
Targeted LogonId is 0:0x3e7
*** You must run this tool while being elevated, and you must have TCB or be a local admin.***
klist failed with 0xc0000001/-1073741823: {Operation Failed}
The requested operation was unsuccessful.
В этом случае нужно запустить командную строку от имени NT Authority\System и в уже в этой консоли сбросить кэш билетов Kerberos:
psexec -s -i -d cmd.exe
klist –li 0x3e7 purge
– сброс тикета компьютера
gpupdate /force
– обновление настроек GPO
Такой способ обновления членства в группах компьютера – единственный рабочий вариант обновления настроек GPO на клиентах, который подключаются к вашей сети через VPN, а пользователь входит под кэшированными учетными данными.
Klist: сброс тикета Kerberos для пользователя
Например, вы добавили пользователя в группу безопасности с правами доступа к сетевой папке. Пользователь не сможет отрыть данный сетевой каталог без выполнения logoff+logon.
Если нужно обновить список назначенных групп безопасности для пользователя, нужно сбросить его кэш билетов Kerberos. Откройте в сессии пользователю непривилегированную командную строку (не нужно запускать cmd в режиме Run as administrator). Выполните команду:
klist purge
Current LogonId is 0:0x5d2e96 Deleting all tickets: Ticket(s) purged!
Чтобы увидеть обновлённый список групп, нужно запустить новое окно командной строки с помощью runas (чтобы новый процесс был создан с новым токеном безопасности). Выведите список групп пользователя:
whoami /groups
Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
Чтобы пользователь смог подключиться к сетевой папке, доступ к которой ему предоставлен новой группой безопасности, нужно перезапустить оболочку прводника Windows с новым токеном.
- Откройте командную строку;
- Завершите процесс File Explorer пользователя:
taskkill /f /im explorer.exe - Запустите новый процесс explorer под вашей учетной записью. Можно использовать переменные окружения
%USERDOMAIN%\%USERNAME%или указать домен и имя пользователя вручную. Например, winitpro\kbuldogov:runas /user:winitpro\kbuldogov explorer.exe - Укажите пароль своей учетной записи;
- После этого оболочка проводника перезапустится с новым токеном и вы сможете получить доступ к сетевой папке с правами новой группы безопасности.
В предыдущем способе для обновления групп безопасности нужно явно указывать пароль пользователя. Если это невозможно, можно попробовать обходное решение.
Допустим, пользователь был добавлен в группу AD для получения доступа к сетевому каталогу. Попробуйте обратиться к нему по имени или FQDN (!!! это важно) (к примеру, \\msk-fs1.winitpro.loc\distr). Но не по IP адресу.
NAME
) и полного имени (
FQDN
) используются разные cifs тикеты. Если вы ранее использовали FQDN, то после сброса тикетов на клиенте командой
klist purge
, вы сможете получить доступ по NAME (при первом обращении будет выдан новый тикет с новыми группами). Старый тикет для FQDN при этом все еще находится в процесс explorer и не будет сброшен до его перезапуска (как описано выше).В этот момент для пользователя выдается новый тикет Kerberos. Вы можете проверить, что TGT тикет был обновлен:
klist tgt
(см. значение
Cached TGT Start Time
)
Сетевой каталог, к которому был предоставлен доступ через группу AD, должен открыться без перелогина пользователя.
Выполните команду
whoami /groups
чтобы убедиться, что пользователь получил новый TGT с обновленными группами безопасности не завершая сеанс .
Еще раз напомним, что данная возможность обновления групп безопасности будет работать только для сервисов, поддерживающих Kerberos. Для сервисов с NTLM аутентификацией нужна перезагрузка или ре-логин для обновления токена.
Было бы здорово, если бы сюда добавили как сделать эти же операции через Powershell.
Прямо в PoSh сессии выполняйте приведенные выше команды
Я видимо неверно выразил вою мысль.
Существуют ли штатные командлеты для выполнения описанных в статье операций?
А с чем связано указание полного имени в адресе, почему нельзя использовать сокращенное имя без домена?
Аутентификация Kerberos требует использования FQDN имени хоста.
А в связи с чем необходимо указывать полное имя для доступа к сетевому каталогу?
Т.е. чтобы пользоваться командой
klist purgeнадо изначально в корпоративной сети у пользователей делать ярлыки на сетевые ресурсы только с FQDN именами? В обслуживаемых вами сетях вы сами так делаете?Конечно нет, это в большей степени обходное решение, когда прямо сейчас логоф/перезагрузку делать нельзя, а доступом через группу AD воспользоваться уже нужно.
Конечно, да.
«klist» не является внутренней или внешней командой, исполняемой программой или пакетным файлом.
Добрый день. А как мне определить специальный идентификатор, указывающий на сессию локального компьютера (Local System)?
Это всегда 0x3e7
Есть несколько больших ошибок в этой статье. Если автор сам проделал все эти опыты, то он конечно молодец, а если скопировал откуда-то, то статья бесполезная, потому что совсем не раскрывает механизм выдачи билетов. Речь идёт про сброса kerberod ticket под user, под computer всё прекрасно всегда работало.
1. «Аутентификация Kerberos требует использования FQDN имени хоста.»
Однозначно это не так. Керберос требует обращения по имени, не по ip, именно по имени, и не важно по какому, по короткому Name, или по длинному FQDN. Это хорошо видно, когда, при первом обращении после логона или после сброса тикетов, тикеты появляются в klist, а при ip нет.
2. «Попробуйте обратиться к нему по FQDN (!!! это важно) имени (к примеру, \\msk-fs1.winitpro.loc\distr). В этот момент для пользователя выдается новый тикет Kerberos.»
Это не так. Как я указал выше kerberos ticket выдаётся при обращении к сетевому ресурсу при любом формате имени типа cifs. Здесь лишь срабатывает тот фокус, что вначале мы получаем тикет по Name, а после по FQDN. Точно так же работает наоборот, вначале по FQDN, а потом по Name, так как это два совершенно разных тикета.
Как это работает?
Сервер с шарой через DC, отдаёт клиенту cifs ticket. Причём при обращение для Name будет выдан один cifs ticket, а при обращении по FQDN будет выдан другой cifs ticket. Это два разные тикета и они будут висит параллельно и использоваться при разных запросах.
Допустим вы обратились вначале к 1му разрешенному ресурсу по Name, вам выдали для него 1й cifs ticket. Затем обратились ко 2му запрещённо ресурсу по Name, вам выдали ещё один, но уже http ticket, так как 1й cifs доступа не дал. Тут Windows думает, что нужен другой протокл, но это роли не играет. Дальше вы добавили права на 2й ресурс, прореплицировали по DC, сбросили тикеты на клиенте klist purge. Теперь обратились к 1му ресурсу по Name. Но список тикетов пуст. Теперь обратились к 2му ресурсу по Name. Но, упс, список тикетов всё равно пуст, так как новый клиенту выдаваться не будет. Но если пойдёте к 1му или 2му ресурсу по FQDN, то вам выдадут новый 2й cifs ticket. Вот по нему и будете ходить,но только по FQDN, а Name также не будет доступен.
Всё то же самое если вначале обратиться по FQDN, сбросить, а потом обращаться по Name. Весь фокус не в обновлении тикете по старому имени, а в выдаче другого тикете по новому имени. Но если вы запороли их оба, то есть обратились с самого начала и по Name и по FQDN, то новых тикетов взамен старых вам никто не даст, и чтобы вы не делали доступа не получите.
Итог.
Получить новые тикеты по той же форме имени без логоф невозможно до истечения срока жизни тикета, можно лишь схитрить и запросить тикет на другой форме имени.
Пожалуй соглашусь с выводом.
Я пробовал в тестовой среде как-то разворачивать AGPM сервер (расширенное управление групповыми политиками), и пробовал на клиенте пользоваться klist purge когда тестировал созданные роли для AGPM в домене, группами безопасности. Так вот, сброс билетов не помогает полноценно, т.е. все равно для полноценного применения новых прав роли требуется выполнить логофф\логон. Такие дела.