Отсутствующие группы токена доступа к системной учетной записи
У меня странное явление, связанное с системной учетной записью Windows. Рассмотрим эти три разных способа запустить процесс как СИСТЕМНЫЙ:
- 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
Я НАШЕЛ чертову основную причину проблемы - по крайней мере, для сценария запуска.
Я посмотрел на стек вызовов и выяснил, что запускается сценарий запуска:
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 и сценарий запуска вызываются с полным набором членства.
Для меня все еще очень неясно, почему процесс с одним и тем же пользователем может иметь другой набор членства в группах в их токене доступа - когда фактическое членство не изменилось. Буду признателен за любой вклад по этому поводу.
К сожалению, после всего этого: служба BITS по-прежнему не принимает передачи файлов и выдает сообщение «пользователь не вошел в сеть» 0x800704DD. Я открыл для этого новый вопрос https://stackoverflow.com/questions/51009804/how-to-start-a-bits-download-as-system-account-current-error-user-has-not-log
Это зависит от того, как настроена служба, в частности от типа 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, настройка, вероятно, будет вернулся.
Лучшим обходным решением было бы, чтобы сценарий запуска запускал запланированную задачу или устанавливал и запускал службу для выполнения необходимой работы от имени сценария запуска.