Программирование серверных приложений

Здесь я собираюсь объяснить, чем отличается работа службы с учетной записью LocalSystem от работы с учетной записью конкретного пользователя.
Учетная запись LocalSystem выделена самой ОС. ОС никогда не получает отказов в доступе к ресурсам. Служба, работающая с учетной записью LocalSystem, может манипулировать любыми каталогами или файлами, изменять системное время, запускать или останавливать другие службы, выключать машину и беспрепятственно выполнять любые другие, обычно запрещенные, операции.
Службу LocalSystem можно рассматривать ка;с часть высоконадежной вычислительной базы системы (Trusted Computing Base, ТСВ).
Естественно, что весь код привилегированного режима — драйверы аппаратных устройств, управление памятью, файловая система, мониторинг безопасности, диспетчеризация потоков и т. д. — является частью ТСВ системы. Служба, работающая з режиме ТСВ, обладает невероятной мощью, поэтому только у администраторов есть права, на установку служб.
Но если учетная запись LocalSystem облад/aei такой мощью, зачем нам запускать службу с учетной записью определенного пользователя? Да, службы с учетной записью LocalSystem действительно всесильны на локальной машине, но по умолчанию они не могут сделать всего, что нужно в сети. Например, служба с LocalSystem не можег получить доступ к совместно используемым каталогам, файлам или принтерам на другой машине, так как учетная запись LocalSystem локальней машины tie аутенгифицируется на удаленной машине. В Windows 2000 ситуация улучшилась: когда машина входит в домен, ее можно рассматривать как некоторого пользователя с его учетной записью и предоставлять ей собственные права доступа.
Если же ваша служба работает на машине, не входящей в домен, и ей требуется доступ к сетевым ресурсам, можно сделать следующее.
Запустить службу с учетной записью определенного пользователя, которому предоставлены права доступа к сетевым ресурсам. Имейте в виду, что при этом ограничиваются возможности службы па локальной машине.
Осуществлять доступ к ресурсам по протоколу, который не требует аутентификации. Например, служба с LocalSystem может взаимодействовать через сокеты, именованные каналы или почтовые ящики. Конечно, в этом случае требуется, чтобы удаленная машина поддерживала входящие запросы по этим протоколам. Такие соединения называются NULL-сеансами и могут управляться установкой значений NullSessionPipes и NullSessionShares в следующем подразделе реестра:
HKEY_LOCAL_MACHINE\SYST£M\CurrentControlSet\Services\ LanmanServer\Parameters
Вы также можете разрешить подключение ко всем каналам и разделяемым ресурсам на машине с использованием NULL-сеансов, установив в О значение RestrictNullSessionAccess в том же подразделе реестра. Хотя вы и можете это сделать, но лучше не надо, так как при этом в системе защиты образуется гигантская брешь. Осуществлять доступ к ресурсам, позаимствовав права определенного пользователя. Для этого можно вызвать одну из функций заимствования прав Windows. (Заимствование прав или «перевоплощение* обсуждается в четвертой части книги.) Служба с учетной записью LocalSystem может также позаимствовать права определенного пользователя, вызвав функцию Logon-User, указав для аутентификации домен, имя пользователя и пароль. Заметьте: выполнение LogonUser требует наличия привилегии ТС В (она также известна как привилегия «Act as Part of the Operating System» — работа в режиме ОС), по умолчанию предоставляемой только учетной записи LocalSystem, — как удобно!