Определяется ли клиент LocalSystem (SYSTEM) целевым / серверным компьютером? и в каком контексте? - PullRequest
0 голосов
/ 22 сентября 2010

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

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

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

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

Также предопределено "NT AUTHORITY"\ LOCAL SYSTEM "(или SYSTEM [3]) присутствует в любых Windowses
и должен использоваться для идентификации (даже если клиент (процесс) доступен из Windows рабочей группы), не должен иметь?

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

  • 'В рабочих группах SID имеет значение только на локальной рабочей станции. При доступе к другой рабочей станции SIDне передается только имя. «Локальная система» не может получить доступ ни к каким другим системам '

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

  • как ComputerName \ LocalSystem?
    или
  • как NT AUHORITY \ ЛОКАЛЬНАЯ СИСТЕМА?

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


CITED:
[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'sответ на мой вопрос "Windows LocalSystem vs. System"
https://serverfault.com/questions/168752/windows-localsystem-vs-system


Мои похожие вопросы:

Ответы [ 2 ]

1 голос
/ 29 октября 2010

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

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

1 голос
/ 27 октября 2010

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...