выполняется вход.
Как только учетные данные аутентифицированы, LSASS ищет в базе данных локальной политики разрешенный пользователю тип доступа – интерактивный, сетевой, пакетный или сервисный. Если тип запрошенного входа в систему не соответствует разрешенному, вход прекращается. LSASS удаляет только что созданный сеанс входа, освобождая его структуры данных, и сообщает Winlogon о неудаче. Winlogon в свою очередь сообщает об этом пользователю. Если же запрошенный тип входа в систему разрешается, LSASS добавляет любые дополнительные идентификаторы защиты (например, Everyone, Interactive и т. п.). Затем он проверяет в своей базе данных привилегии, назначенные всем идентификаторам данного пользователя, и включает эти привилегии в маркер доступа пользователя.
Собрав всю необходимую информацию, LSASS вызывает исполнительную систему для создания маркера доступа. Исполнительная система создает основной маркер доступа для интерактивного или сервисного сеанса и маркер олицетворения для сетевого сеанса. После успешного создания маркера доступа LSASS дублирует его, создавая описатель, который может быть передан Winlogon, а свой описатель закрывает. Если нужно, проводится аудит операции входа. Ha этом этапе LSASS сообщает Winlogon об успешном входе и возвращает описатель маркера доступа, LUID сеанса входа и информацию из профиля, полученную от пакета аутентификации (если она есть).
ЭКСПЕРИМЕНТ: перечисление активных сеансов входа
Пока существует хотя бы один маркер с данным LUID сеанса входа, Windows считает этот сеанс активным. C помощью утилиты Logon-Sessions
B информацию, сообщаемую по каждому сеансу, включаются SID и имя пользователя, сопоставленные с данным сеансом, а также пакет аутентификации и время входа. Заметьте, что пакет аутентификации Negotiate, отмеченный в сеансе входа 2, выполняет аутентификацию через Kerberos или NTLM в зависимости от того, какой из них больше подходит для данного запроса на аутентификацию.
LUID для сеанса показывается в строке «Logon Session» блока информации по каждому сеансу, и с помощью утилиты Handle (также доступной с
Далее Winlogon просматривает параметр реестра HKLMSOFTWAREMicrosoftWindows NTCurrent VersionWinlogonUserinit и создает процесс для запуска программ, указанных в строковом значении этого параметра (там могут присутствовать имена нескольких ЕХЕ-файлов, разделенные запятыми). Значение этого параметра по умолчанию приводит к запуску Useri-
nit.exe, который загружает профиль пользователя, а затем создает процесс для запуска программ, перечисленных в HKCUSOFTWAREMicrosoftWindows NTCurrent VersionWinlogonShell, если такой параметр есть. Если же этого параметра нет, Userinit.exe обращается к параметру HKLMSOFTWARE MicrosoftWindows NTCurrent VersionWinlogonShell, который по умолчанию задает Explorer.exe. После этого Userinit завершается – вот почему Process Explorer показывает Explorer.exe как процесс, не имеющий предка. Подробнее о том, что происходит в процессе входа, см. в главе 5.
Злонамеренный код вроде вирусов и червей создает все больше проблем. B Windows XP введен механизм Software Restriction Policies (Политики ограниченного использования программ), который позволяет администраторам контролировать образы и сценарии, выполняемые в их системах. Узел Software Restriction Policies в редакторе локальной политики безопасности (рис. 8-11) служит интерфейсом управления для политик выполнения кода на компьютере, хотя возможны и политики, индивидуальные для пользователей; в последнем случае применяются доменные политики групп.
Узел Software Restriction Policies (Политики ограниченного использования программ) содержит несколько глобальных параметров.
(o) Параметр Enforcement (Принудительный) определяет, как применяются политики ограничения – к библиотекам вроде DLL, только к пользователям или к пользователям и администраторам.
(o) Параметр Designated File Types (Назначенные типы файлов) регистрирует расширения файлов, которые считаются исполняемыми.
(o) Параметр Trusted Publishers (Доверенные издатели) контролирует, кто имеет право решать, каким издателям сертификатов можно доверять.
При настройке параметра для конкретного сценария или образа администратор может указать системе распознавать этот сценарий или образ по его пути, хэшу, зоне Интернета (как определено в Internet Explorer) или по криптографическому сертификату, а также сопоставить его с уровнем безопасности Disallowed (He разрешено) либо Unrestricted (Неограниченный).
Политики ограниченного использования программ применяются внутри различных компонентов, где файлы рассматриваются как содержащие исполняемый код. Некоторые из таких компонентов перечислены ниже.
(o) Windows-функция CreateProcess (WindowsSystem32Kernel32.dll) пользовательского режима применяет эти политики к исполняемым образам.
(o) Код загрузки DLL в Ntdll ( WindowsSystem32Ntdll.dll) применяет эти политики к DLL.
(o) Командная оболочка Windows (WindowsSystem32Cmd.exe) применяет эти политики к командным файлам.
(o) Компоненты Windows Scripting Host, запускающие сценарии, – WindowsSystem32Cscript.exe (для сценариев командной строки), Windows System32Wscript.exe (для UI-сценариев) и WindowsSystem32Scrobj.dll (для объектов- сценариев) – применяют эти политики к сценариям. Каждый из этих компонентов определяет, действуют ли политики ограничения, по значению параметра реестра HKLMSOFTWAREPoliciesMicro-softWindowsSafer CodeIdentifiersTransparentEnabled. Если он равен 1, то политики действуют. Далее каждый из компонентов проверяет, подпадает ли код, который он собирается выполнить, под действие одного из правил, указанных в подразделе раздела CodeIdentifiers, и, если да, следует ли разрешить выполнение. Если ни одно из правил к данному коду не относится, его выполнение зависит от политики по умолчанию, определяемой параметром DefaultLevel в разделе CodeIdentifiers.
Software Restriction Policies – мощное средство для предотвращения запуска неавторизованного кода и
