Разница между учетной записью «Local System» и учетной записью «Network Service»?

Я написал службу Windows, которая порождает отдельный процесс. Этот процесс создает COM-объект. Если служба работает под учетной записью «Локальная система», все работает нормально, но если служба работает под учетной записью «Сетевая служба», запускается внешний процесс, но ему не удается создать объект COM. Ошибка, возвращаемая при создании COM-объекта, не является стандартной ошибкой COM (я думаю, что она специфична для создаваемого COM-объекта).

Итак, как мне определить, как различаются две учетные записи, «Локальная система» и «Сетевая служба»? Эти встроенные учетные записи кажутся очень загадочными, и никто не знает о них много.

4.02.2009 05:30:33
1 ОТВЕТ
РЕШЕНИЕ

Так как в функциональности стандартных учетных записей служб возникает много недоразумений, я постараюсь быстро их отключить.

Сначала фактические счета:

  • Учетная запись LocalService (предпочтительно)

    Ограниченная учетная запись службы, которая очень похожа на сетевую службу и предназначена для запуска стандартных служб с минимальными правами доступа. Однако, в отличие от сетевой службы, он получает доступ к сети как анонимный пользователь.

    • Имя: NT AUTHORITY\LocalService
    • учетная запись не имеет пароля (любая предоставленная вами информация о пароле игнорируется)
    • HKCU представляет учетную запись пользователя LocalService
    • имеет минимальные привилегии на локальном компьютере
    • представляет анонимные учетные данные в сети
    • SID : S-1-5-19
    • имеет собственный профиль в разделе реестра HKEY_USERS ( HKEY_USERS\S-1-5-19)

     

  • Учетная запись NetworkService

    Ограниченная учетная запись службы, предназначенная для запуска стандартных привилегированных служб. Эта учетная запись намного более ограничена, чем локальная система (или даже администратор), но все еще имеет право доступа к сети как к машине (см. Предостережение выше).

    • NT AUTHORITY\NetworkService
    • учетная запись не имеет пароля (любая предоставленная вами информация о пароле игнорируется)
    • HKCU представляет учетную запись пользователя NetworkService
    • имеет минимальные привилегии на локальном компьютере
    • представляет учетные данные компьютера (например MANGO$) на удаленных серверах
    • SID : S-1-5-20
    • имеет собственный профиль в разделе реестра HKEY_USERS ( HKEY_USERS\S-1-5-20)
    • Если вы пытаетесь запланировать задачу, используя ее, войдите NETWORK SERVICEв диалог выбора пользователя или группы

     

  • Учетная запись LocalSystem (опасно, не используйте!)

    Полностью доверенная учетная запись, в большей степени, чем учетная запись администратора. В одном окне нет ничего, что эта учетная запись не может сделать, и она имеет право доступа к сети как машина (для этого требуется Active Directory и предоставление разрешений учетной записи машины для чего-либо)

    • Имя: .\LocalSystem(также можно использовать LocalSystemили ComputerName\LocalSystem)
    • учетная запись не имеет пароля (любая предоставленная вами информация о пароле игнорируется)
    • SID : S-1-5-18
    • не имеет собственного профиля ( HKCUпредставляет пользователя по умолчанию )
    • имеет широкие привилегии на локальном компьютере
    • представляет учетные данные компьютера (например MANGO$) на удаленных серверах

     

Выше, когда речь идет о доступе к сети, это относится исключительно к SPNEGO (Negotiate), NTLM и Kerberos, а не к какому-либо другому механизму аутентификации. Например, обработка, выполняемая как, LocalServiceвсе еще может получить доступ к Интернету.

Общая проблема с запуском стандартной стандартной учетной записи состоит в том, что если вы изменяете какое-либо из разрешений по умолчанию, вы расширяете набор функций, которые может выполнять эта учетная запись. Таким образом, если вы предоставите DBO для базы данных, ваша служба, работающая как локальная служба или сетевая служба, сможет получить доступ не только к этой базе данных, но и ко всем остальным, работающим от имени этих учетных записей. Если каждый разработчик делает это, у компьютера будет служебная учетная запись, которая имеет полномочия делать практически все (в частности, расширенный набор всех различных дополнительных привилегий, предоставляемых этой учетной записи).

С точки зрения безопасности всегда предпочтительнее работать в качестве своей собственной учетной записи службы, у которой есть именно те разрешения, которые вам необходимы, чтобы делать то, что делает ваша служба, и ничего более. Однако стоимость такого подхода заключается в настройке учетной записи службы и управлении паролем. Это балансирование, которым должно управлять каждое приложение.

В вашем конкретном случае проблема, которую вы, вероятно, видите, заключается в том, что активация DCOM или COM + ограничена данным набором учетных записей. В Windows XP SP2, Windows Server 2003 и более поздних версиях разрешение на активацию было значительно ограничено. Вам следует использовать оснастку MMC «Службы компонентов», чтобы проверить ваш конкретный COM-объект и увидеть разрешения на активацию. Если у вас нет доступа к сети в качестве учетной записи компьютера, вам следует серьезно подумать об использовании локальной службы (а не локальной системы, которая в основном является операционной системой).


В Windows Server 2003 вы не можете запустить запланированное задание как

  • NT_AUTHORITY\LocalService (он же локальная учетная запись службы) или
  • NT AUTHORITY\NetworkService (он же учетная запись сетевой службы).

Эта возможность была добавлена ​​только в Task Scheduler 2.0 , который существует только в Windows Vista / Windows Server 2008 и более поздних версиях.

Служба, работающая как, NetworkServiceпредставляет учетные данные компьютера в сети. Это означает, что если ваш компьютер был вызван mango, он будет представлен как учетная запись компьютера MANGO$ :

введите описание изображения здесь

690
11.06.2019 15:04:56
Я думаю, что управляемые учетные записи служб устраняют некоторые трудности при настройке учетной записи и управлении паролем (или, скорее, передают его администратору домена или делегату.)
Carl G 13.08.2013 20:10:07
Привет, спасибо за объяснение. У меня есть один вопрос - используя локальную учетную запись системной / сетевой службы, можно ли добавлять / удалять записи для контейнеров в активном каталоге (при условии, что контейнер в активном каталоге предоставил полные разрешения компьютеру, на котором работают эти службы Windows). Обратите внимание, что все работает, когда я запустил службу как один из пользователей домена, но не как локальную системную / сетевую службу (для подробностей stackoverflow.com/questions/20943436/… ) С уважением
Dreamer 6.01.2014 05:37:02
Да, это должно быть Я отвечу на ваш вопрос напрямую, так как этот вопрос более абстрактный, и это конкретная реализация.
Peter Oehlert 6.01.2014 13:32:31
Обратите внимание, что «анонимный» пользователь не только не является участником «аутентифицированных пользователей», но и не является членом «всех» в Windows. В сетях Windows «анонимный» имеет доступ только к тем ресурсам, которые были явно предоставлены «анонимному» - по умолчанию ничего.
david 13.05.2016 11:03:07
@HakamFostok У меня не много ссылок. Если я правильно помню, Дэн Браун освещал некоторые из них в своей книге «Программирование безопасности Windows». В справке Windows и MSDN есть много справки, но у меня нет конкретной ссылки. В книге Джеффа Рихтера по окнам программирования, а также в Inside Windows (3-й или 4-й выпуск) Soloman & Russinovich также есть некоторые.
Peter Oehlert 30.04.2019 03:51:03