Я работаю с контроллером домена Windows Server 2012 R2, который используется в основном как файловый сервер. Клиенты в этой сети в основном не являются пользователями домена, но вместо этого используют учетные записи пользователей домена для аутентификации сопоставления сетевого диска с общими ресурсами файлового сервера.
Эти учетные записи пользователей домена, в свою очередь, предоставляют разные уровни разрешений доступа NTFS для разных папок в общих папках файлового сервера. Для этого права доступа NTFS устанавливаются на уровне группы пользователей домена, и пользователи домена временно добавляются в эти группы или удаляются из них по мере необходимости.
Я замечаю, что когда пользователь добавляется в группу, которая предоставляет ему дополнительные права доступа (или действительно, когда они удаляются из группы и, таким образом, теряют права доступа), эти изменения привилегий не вступают в силу до тех пор, пока клиентский компьютер (наблюдаемый в Windows 7 Professional) был перезапущен (и поэтому, предположительно, кэшированный токен доступа для соответствующего подключенного диска был обновлен).
Как администратору было бы полезно принудительно обновлять эти токены доступа, как только пользователь был добавлен в группу или удален из нее, чтобы его новые права доступа вступали в силу немедленно, без необходимости перезагружать компьютер.
Возможно ли принудительное исполнение? И если да, то как?
Однозначный ответ - нет. Я не знаю окончательного способа обновить токен доступа Kerberos без выхода из системы / входа в систему или перезагрузки. Идентификатор безопасности новой группы необходимо добавить в маркер, и это делается только при этих событиях.
Вы можете попробовать использовать klist purge как можно предположить из многих статей в сети, но мои попытки это сделать не увенчались успехом.
klist purge действительно работает для подавляющего большинства вещей, особенно для изменения прав на общие папки. С этим нужно быть осторожнее. Поскольку это зависит от сеанса, выполнение этого из учетной записи другого пользователя - даже в той же системе - не сработает. Вы бы хотели запустить это в контексте вошедшего в систему пользователя. Я бы лично использовал это только, когда сидел за чьим-то столом (при условии, что это для ситуаций службы поддержки), поэтому это легко проверить.