Является ли клиентская локальная система (SYSTEM) идентифицирована целевым/серверным компьютером? и в каком контексте?

Question

[1] говорит:

• «При настройке использовать конкретный счет в качестве идентификатора процесса, ASP.NET пытается делегировать эту учетную запись Если это локальная учетная запись, идентична (включая пароль). на локальную учетную запись на удаленном компьютере, делегирование возможно. Если такая учетная запись не существует на удаленном компьютере, она отображается как анонимная учетная запись Windows (NT AUTHORITY \ ANONYMOUS LOGON). Кроме того, делегирование также возможно, если учетная запись является учетной записью домена, которая имеет доступ к удаленной машине, и в этом случае она использует идентификатор сети домена этой учетной записи ».

[2] сообщает:

• "Имя учетной записи во всех локалей \ LocalSystem Имя, LocalSystem или ИмяКомпьютера \ LocalSystem также может быть использован.".
  • «служба предоставляет учетные данные компьютера удаленным серверам

Кроме того, предопределенный «NT AUTHORITY \ Локальная система» (или СИСТЕМА [3]) присутствует в любых Windowses
и должен был использоваться для идентификации (даже когда клиент (процесс) доступны из рабочей группы Windows), не должен не так ли? .

Хотя ряд ответов, напр, [3] говорит об обратном:

• «В Workgroups, то SID только имеет значение на локальной рабочей станции. При доступе к другой рабочей станции SID не передается только имя. «локальная система» не может получить доступ к любым другим системам "

Идентифицируется LocalSystem или не удаленной/целевой машине? и как?

• как имя_компьютера \ локальная система?
  или
• как NT AUHORITY \ LOCAL SYTEM?

Update:
Этот вопрос полностью в контексте среды разработки в Windows, рабочая группа ...
хотя все ответы отклонилась к домену Windows, ...

---

ЦИТИРОВАННОЙ:
[ 1]
ASP.NET Делегация
http://msdn.microsoft.com/en-us/library/aa291350.aspx
[2]
LocalSystem счета
http://msdn.microsoft.com/en-us/library/ms684190.aspx
[3] Ответ
sysadmin1138 на мой вопрос "Windows LocalSystem против системы"
https://serverfault.com/questions/168752/windows-localsystem-vs-system

---

Мои смежные вопросы:

• domained LocalSystem vs. non-domained LocalSystem account in Windows-es ?
• how to check group membership of an “NT AUTHORITY\” account ?
• Does access to server resources require client process to login to server machine?
• Windows workgroup LocalSystem vs. domain (AD) LocalSystem [closed]
• how to better set up machine for development both in workgroup and Windows domain? [closed]
• interoperating with Windows domain computer from workrgroup Windows [closed]
• the context of local user of AD-joined machine? Is it of domain machine account or of local machine account?
• RunAs under domain account from non-AD Windows [closed]
• how to better set up machine for development both in workgroup and Windows domain? [closed]
• how to share the same domain machine account with multi-boot workgroup Windows setup?

Answer 1

Есть две возможности в вашем сценарии, в зависимости от версии Windows, на локальном («клиент») машины и о том, как хорошо служба интегрируется с Windows Services API: - удаленные машины будет видеть запросы от «клиента» машины, как NT AUTHORITY \ ANONYMOUS - удаленные машины будут видеть запросы от «клиента» машины, как DOMAIN \ COMPUTER_ACCOUNT_NAME

удаленного машин будет видеть только запросы от своих собственных процессов как прибывающие из SYSTEM/LocalSystem.

Если вы хотите выяснить, какой контекст учетной записи вы видите из-за удаленных запросов, включите события аудита входа в систему (успех и сбой) в политике аудита на удаленной системе. Вы также можете найти дополнительную (и иногда полезную) информацию с помощью анализатора протоколов, например Microsoft Network Monitor, и захватить поток пакетов, отправленный с «клиента» на удаленный компьютер и обратно.

Редактировать: также см. my answer to the related/overlapping question here для соответствующих деталей.

Answer 2

System/LocalSystem и NETWORK SERVICE также будут аутентифицированы удаленно, как учетная запись компьютера, DOMAIN\MACHINENAME$. Существует еще одна встроенная учетная запись: LOCAL SERVICE, которая будет всегда аутентифицироваться удаленно, как ANONYMOUS LOGON (поэтому сбой большинства авторизаций).

Попытка понять эти понятия как SID и имена не имеет большого значения. Аутентификация - это рукопожатие SSPI, в конце которого аутентификатор будет запрашивать токен контекста аутентификатора и проверять доступ (выполнять авторизацию), а также имя аутентификатора также может запрашиваться из контекста безопасности. Если handhsake SSPI был удален (между двумя различными LSA), тогда имя QueryContextAttributes вернет в успешном сценарии аутентификации имя удаленной машины domain\machine$.Если это было рукопожатие с обратной связью, где задействован только один LSA, то тот же вызов возвращает NETWORK SERVICE или System. Существует также возможность подтверждения аутентификации «ANONYMOUS LOGON», например, случая рабочей группы, использования локальной учетной записи или попытки пересечения границ доверия домена, но в основном есть все ошибки :.