Отсутствует токен доступа к системной учетной записи
Я испытываю странные явления в отношении учетной записи Windows SYSTEM. Рассмотрим эти три разных способа запуска процесса как SYSTEM:
- Sysinternals PSExec
- Диспетчер задач
- Скрипт запуска GPO.
Процессы, запущенные этими методами, приводят к разному членству в группе токенов доступа!
Процессы, запущенные планировщиком задач, имеют полный набор групп в своем маркере доступа.
Процессы, запущенные PSExec/Startup Script, с другой стороны, имеют значительно сокращенный набор групп в своем маркере доступа - только эти четыре
BUILTIN\Administrators (S-1-5-32-544)
Everyone (S-1-1-0)
NT AUTHORITY\Authenticated Users (S-1-5-11)
Mandatory Label\System Mandatory Level (S-1-16-16384)
У кого-нибудь есть идея, почему это так?
Для контекста:
Служба BITS выдает сообщение об ошибке "пользователь не вошел в сеть" 0x800704DD при попытке добавить файл к передаче в процессах, запущенных с помощью сценария запуска или PSExec, - отлично работает с теми, которые были запущены с помощью планировщика задач.
Все тесты на Windows 10 1703; Членство в группах взято из whoami /all и Sysinternals Process Explorer
2 ответа
Это зависит от того, как настроена служба, более конкретно от типа SID службы.
Если тип SID службы равен "none", то служба просто получает простой токен SYSTEM, такой же, какой используется другими системными процессами, такими как services.exe а также winlogon.exe и так далее. Это наследственная ситуация; В Windows XP все сервисы имели такой токен, если только они не были настроены для работы под определенной учетной записью пользователя.
Если тип SID службы является "ограниченным" или "неограниченным", то для службы генерируется более конкретный токен, включая специальный идентификатор безопасности, специфичный для этой службы, например, NT SERVICE\Schedule для планировщика заданий. Это помогает обеспечить некоторую гранулярность между различными сервисами. В Windows 7 и более поздних версиях большинство встроенных служб являются "неограниченными". Служба групповой политики является исключением; это, вероятно, было упущением со стороны Microsoft. (Я бы подумал, что это был преднамеренный выбор для обратной совместимости, но это подрывается тем фактом, что в Windows 7 он всегда работает в процессе общего сервиса.)
Как вы уже заметили, также NT SERVICE идентификатор, токену присваивается ряд других идентификаторов. Насколько я понимаю, это не задокументировано, но и не удивительно; это делает сервисный токен более похожим на интерактивный токен, что может быть полезно. (Особенно важно, чтобы это было так для ограниченных токенов, которые в противном случае имели бы очень ограниченный доступ вообще.)
Как описано в самоответе, когда несколько служб совместно используются одним процессом, маркер процесса должен содержать каждый идентификатор безопасности, который нужен любой из служб. Таким образом, если служба групповой политики (или любая другая служба с типом SID "none") совместно использует процесс с "неограниченной" службой, она получает точно такой же токен, как если бы она сама была "неограниченной".
Поскольку более ранние версии Windows эффективно запускали службу групповой политики как "неограниченную" и поскольку даже Windows 10 делает это на машинах с очень ограниченной памятью, вероятно, было бы не слишком опасно переконфигурировать тип SID для службы групповой политики, если она абсолютно необходимо сделать это. Я не рекомендую это, кроме как, возможно, в качестве очень краткосрочного решения, отчасти потому, что все еще существует некоторый риск (особенно в отношении прямой совместимости), но главным образом потому, что при каждом обновлении до новой версии Windows 10 этот параметр, вероятно, будет вернулся.
Лучший обходной путь - запуск сценария запуска для запуска запланированной задачи или установка и запуск службы для выполнения любой необходимой работы от имени сценария запуска.
Я НАШЕЛ основную причину проблемы - по крайней мере, для сценария запуска.
Я посмотрел на стек вызовов и оказалось, что Скрипт запуска вызывается через:
svchost.exe (hosts gpsvc) > gpscript.exe > cmd.exe
Все три процесса имеют сокращенный набор членства в группах в своем маркере доступа. Оказывается, службы Windows 10 1703 svchost больше не группируются, если у вас более 3,5 ГБ памяти. https://docs.microsoft.com/en-us/windows/application-management/svchost-service-refactoring
Каждый сервис svchost получает свой собственный процесс - с различными членствами в группах в токене доступа (предыстория этого все еще неясна, вклад в это все еще очень ценится!). К счастью, есть отказ:
Решение:
Добавление значения реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\gpsvc\SvcHostSplitDisable=1 [DWORD]
поддерживает службу gpsvc в основном процессе svchost с полным набором членства в группах - даже если объем памяти превышает 3,5 ГБ. И поэтому gpscript.exe и Startup Script вызывается с полным набором членств.
Для меня все еще очень непонятно, почему процесс с одним и тем же пользователем может иметь другой набор членства в группах в своем маркере доступа - когда фактическое членство не изменилось. Буду признателен за любой вклад по этому вопросу.
К сожалению после всего этого: служба BITS по-прежнему не принимает передачи файлов и выдает "пользователь не вошел в сеть" 0x800704DD. Я открыл новый вопрос для этого https://stackoverflow.com/questions/51009804/how-to-start-a-bits-download-as-system-account-current-error-user-has-not-log