Authenticated users в русской windows

Вот уж не думал, что будет непросто найти перевод группы «Authenticated Users». Но всё-таки получилось! Ниже приведены названия специальных групп (не всех) и их перевод на русский язык (найденные экспериментально).

ВНИМАНИЕ! При поиске по фрагменту названия очень важно соблюдать регистр! Введя «СЕ» найдём группу «СЕТЬ», а вот введя «Сеть» — уже нет. Поэтому данные (по крайней мере по русскому переводу и по возможности на английском языке) приведены в соответствующем регистре.

Знаком * отмечены встроенные группы и идентификаторы. Некоторые группы не стали переводить, а оставили в английском варианте, например, LOCAL SERVICE.

* SYSTEM
* система (Windows 7)
* SYSTEM (Windows Server 2008)

* SERVICE
* СЛУЖБА

* LOCAL SERVICE
* LOCAL SERVICE (именно так!)

* NETWORK SERVICE
* NETWORK SERVICE (именно так!)

* NETWORK
* СЕТЬ

* BATCH
* ПАКЕТНЫЕ ФАЙЛЫ

* INTERACTIVE
* ИНТЕРАКТИВНЫЕ

* REMOTE INTERACTIVE LOGON
* REMOTE INTERACTIVE LOGON (именно так!)

* DIALUP
* УДАЛЕННЫЙ ДОСТУП

* EVERYONE
* Все

* ANONYMOUS LOGON
* АНОНИМНЫЙ ВХОД

* authenticated users
* Прошедшие проверку

* IUSR
* IUSR (именно так!)

* OWNER RIGHTS
* ПРАВА ВЛАДЕЛЬЦА

* CREATOR OWNER
* СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ

* CREATOR GROUP
* ГРУППА-СОЗДАТЕЛЬ

ADMINISTRATOR
Администратор

ADMINISTRATORS
Администраторы

DOMAIN ADMINS
Администраторы домена

USERS
Пользователи

DOMAIN USERS
Пользователи домена

GUEST
Гость

GUESTS
Гости

DOMAIN GUESTS
Гости домена

Конечно, это не полный список. Полный список будет зависеть от операционной системы, языка, включения в домен и других параметров/условий. Например, сюда не вошли:

* SELF
* Дайджест проверка подлинности
* Данная организация
* Другая организация
* КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ
* ОГРАНИЧЕННЫЕ
* ПОЛЬЗОВАТЕЛЬ СЕРВЕРА ТЕРМИНАЛОВ
* Проверка подлинности NTLM
* Проверка подлинности SChannel
? PROXY
ACCOUNT OPERATORS
BACKUP OPERATORS
DnsAdmins
DnsUpdateProxy
HelpServicesGroup
PRINT OPERATORS
REPLICATOR
SERVER OPERATORS
TelnetClients
Администраторы DHCP
Администраторы SQL
Администраторы WSUS
Администраторы предприятия
Администраторы схемы
Владельцы-создатели групповой политики
Доступ DCOM службы сертификации
Издатели сертификатов
Компьютеры домена
Компьютеры сервера терминалов
Контроллеры домена
Контроллеры домена — только чтение
Контроллеры домена предприятия — только чтение
Криптографические операторы
Операторы архива
Операторы настройки сети
Операторы печати
Операторы сервера
Операторы учета
Пользователи
Пользователи DCOM
Пользователи DHCP
Пользователи домена
Пользователи журналов производительности
Пользователи системного монитора
Пользователи удаленного рабочего стола
Пред-Windows 2000 доступ
Репликатор
Серверы RAS и IAS
Серверы лицензий сервера терминалов
Сертификат этой организации
Создатели отчетов WSUS

Время на прочтение
2 мин

Количество просмотров 32K

В целях поддержания надлежащего уровня контроля доступа, важно однозначно понимать, что каждый объект в списке управления доступом (ACL) представляет, в том числе встроенные в ОС Windows.

Существует множество встроенных учетных записей с малопонятными именами и неопределенными описаниями, что может привести к путанице в понимании разницы между ними. Очень частый вопрос: «В чем разница между группами Everyone и Authenticated Users?»

Самое важное

Группа Authenticated Users охватывает всех пользователей, вошедших в систему, используя учетную запись и пароль. Группа Everyone охватывает всех пользователей, вошедших в систему с учетной записью и паролем, а также встроенные, незащищённые паролем учетные записи, такие как Guest и LOCAL_SERVICE.

Больше деталей

Если описанное выше показалась вам упрощённым, то дальше чуть больше деталей.

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

Группа же Everyone включает всех членов группы Authenticated Users, а также гостевую учетную запись Guest и некоторые другие встроенные учетные записи, такие как likeSERVICE, LOCAL_SERVICE, NETWORK_SERVICE и др. Гостевая учётная запись Guest по умолчанию отключена, однако если она активна, то она дает возможность попасть в систему без ввода пароля.

Вопреки распространенному мнению, любой, кто вошел в систему анонимно, т.е. не прошедшие процедуру подтверждения подлинности, не будут включены в группу Everyone. Это имело место ранее, но изменено начиная с Windows 2003 и Windows XP (SP2).

Выводы

Когда дело доходит до распределения разрешений, существует один важный вопрос, на который мы должны быть в состоянии ответить: какие конкретные люди имеют доступ к данному ресурсу?

Большую часть разрешений, которые мы видим, даны не конкретным людям, а группам безопасности (и это — правильно), роль которых не всегда очевидна. В результате приходится тратить много времени для выяснения ответа на вопрос выше.

Решение есть. Когда ваш CEO спросит: «Кто имеет доступ к «Зарплатная ведомость.doc»?» вы сможете быстро, уверенно и абсолютно точно дать ответ, вместо предположений после недельных расследований.

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

Напомню, что по умолчанию права на политику имеет группа Authenticated Users (Прошедшие проверку). При использовании фильтра безопасности мы удаляем эту группу и добавляем только тех, для кого эта политика должна отработать.

Функция стандартная, много раз опробованная. Но на сей раз что то пошло не так 🙁

Политика была назначена на правильную область, в фильтре безопасности находились правильные пользователи, но политика упорно не хотела отрабатывать. Не было никаких ошибок и предупреждений, а gpresult и RSOP просто показывали отсутствие политики в списке примененных к пользователю. Как будто ее не было совсем.

Проверив все что можно и что нельзя, я решил удалить политику и создать ее заново. И вот тут, при настройке фильтра безопасности, я обратил внимание на сообщение, появляющееся при удалении группы Authenticated Users.

Как следует из сообщения, для того, чтобы пользовательская политика смогла успешно отработать на компьютере, у компьютера должно быть право чтения на эту политику. А в группу Authenticated Users входят  не только пользователи, но и компьютеры, и при ее удалении компьютер не сможет получить доступ к политике и применить ее.

Это связано с обновлением безопасности MS16-072 от 14 июня 2016 года. Обновление изменяет контекст безопасности, с помощью которого извлекаются политики пользователя. До установки обновления политики извлекаются в контексте безопасности пользователя, после — в контексте компьютера. Это делает невозможным несанкционированное повышение привилегий в том случае, если злоумышленник перехватил трафик между пользовательским компьютером и контроллером домена.

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

Самый простой вариант, это добавить в фильтр группу Domain Computers, что собственно я и сделал. После этого политика успешно применилась.

Какие из этой истории можно сделать выводы? Во первых, при назначении политики на пользователя и использовании фильтров безопасности добавляйте в список группу Domain Computers. Ну и во вторых, не ленитесь читать системные сообщения, в них может быть важная информация. Которая сэкономит вам кучу времени 🙂

Эффективное использование мощных идентификаторов

Администраторы, не использующие встроенных участников безопасности (well-known security principal), вряд ли представляют себе их сложность и широкие функциональные возможности. В Windows Server 2003 появились новые встроенные участники безопасности, и эта статья поможет освоить способы их применения для управления доступом к ресурсам Windows. Но прежде чем перейти к подробному описанию способов управления, хочу коротко пояснить, что представляют собой участники безопасности вообще и встроенные участники безопасности в частности. Затем мы подробно рассмотрим управление этими сложными элементами. Участник системы безопасности Windows — это аутентифицированный элемент, который использует ресурсы (например, файлы, принтеры), приложения или службы, размещенные на компьютерах Windows. Каждый участник безопасности имеет уникальный идентификатор, встроенный как SID.

Встроенные участники — отдельная категория участников безопасности. Они представляют собой особые сущности, определенные заранее и управляемые подсистемой безопасности Windows. Примерами могут служить учетные записи Everyone, Authenticated Users, System, Self и Creator Owner.

В отличие от типовых участников безопасности, этих участников нельзя переименовать или удалить. Невозможно также создать собственных встроенных участников безопасности; они одинаковы во всех системах Windows, хотя список встроенных участников безопасности в разных версиях слегка различается. Кроме того, встроенный участник безопасности имеет один и тот же SID в любой системе Windows. Например, SID S-1-5-10 всегда предоставляется участнику Self, а SID S-1-3-0 всегда представляет участника Creator Owner.

Обзор встроенных участников безопасности

В табл. 1 перечислены встроенные участники безопасности Windows 2003, Windows XP Service Pack 2 (SP2) и Windows 2000. В табл. 2 приведен список встроенных участников безопасности, введенных в Windows 2003; звездочкой отмечены участники, поддерживаемые XP SP2. Для каждого встроенного участника безопасности в таблице указан соответствующий SID. Список всех встроенных SID Windows приведен также в статье Microsoft «Well-known security identifiers in Windows operating systems» по адресу http://support.microsoft.com/?kbid=243330. Большинство встроенных участников безопасности, перечисленных в табл. 1 и 2, будут подробнее описаны ниже.

В Windows 2003 появились встроенные участники безопасности Local Service, Network Service, Digest Authentication, NTLM Authentication, Remote Interactive Logon, SChannel Authentication, Restricted Code, Other Organization и This Organization. Эти новые участники видны в Active Directory (AD), только если контроллер домена (DC), которому принадлежит роль эмулятора PDC, работает на Windows 2003. Для контроллеров доменов, созданных как на Windows 2003, так и на Windows 2000, необходимо сначала передать роль мастера данной операции контроллеру домена Windows 2003. Эта процедура документирована в статье Microsoft «Local Service and other well-known security principals do not appear on your Windows Server 2003 domain controller» по адресу http://support.microsoft.com/?kbid=827016. Данное ограничение не должно оказать заметного влияния на инфраструктуру AD, так как многие новые компоненты, использующие нового встроенного участника безопасности Windows 2003, требуют уровня однородного функционирования Windows 2003.

Большинство встроенных участников безопасности, перечисленные в табл.1 и 2 (например, Everyone, Authenticated Users), можно увидеть как встроенные группы участников безопасности. В отличие от типовых групп, операционная система (не администратор) автоматически управляет членством, которое зависит от ряда условий. Например, в XP и Windows 2000 операционная система автоматически вводит пользователя в группу Interactive, если данный пользователь работает локально за компьютером, на котором размещен ресурс, или если пользователь зарегистрировался на этом компьютере через соединение RDP. В Windows 2003 такой пользователь вводится в группу Remote Interactive Logon.

Встроенные группы участников безопасности можно рассматривать и как динамические группы, так как операционная система динамически определяет их членов. Их не следует путать с динамическими группами LDAP на базе запросов, которые были впервые представлены в Windows 2003 Authorization Manager (AzMan).

Интересная особенность встроенных участников безопасности — способ их репликации между экземплярами AD. Они могут применяться к тысячам объектов AD, но реплицируются только их имена, а не членство в группах. В результате нельзя использовать классический запрос AD и административный инструментарий для выяснения их членства в группах. Из-за способов использования встроенных участников безопасности хранить информацию об их членстве не требуется. Основная роль встроенных участников безопасности — обеспечить SID, который можно добавить в маркер доступа пользователя, когда тот регистрируется в системе или обращается к ресурсу. Присутствие конкретного встроенного участника безопасности дает пользователю определенные разрешения в системе или при обращениях к ресурсу. Просмотреть содержимое маркера доступа можно с помощью инструмента WhoAmI с ключом /all (WhoAmI поставляется c Windows 2003 и с Microsoft Windows 2000 Resource Kit) или такого бесплатного инструмента, как SecTok (который можно загрузить по адресу http://www.joeware.net), как показано на экране 1.

Администрирование встроенных участников безопасности

Встроенные участники безопасности существуют во всех операционных системах Windows, установленных как в домене, так и автономно. Однако в автономные системы вводятся не все встроенные участники безопасности. Кроме того, как объяснялось ранее, список встроенных участников безопасности в разных версиях операционных систем немного различается.

В домене Windows объекты AD, представляющие встроенных участников безопасности, хранятся в контейнере WellKnown Security Principals под контейнером Configuration. Для просмотра содержимого контейнера используется оснастка ADSIEdit консоли Microsoft Management Console (MMC) (экран 2). В автономной системе встроенные участники безопасности хранятся в локальной базе данных безопасности (Security Account Manager, SAM).

Встроенных участников безопасности можно добавить к другим группам и спискам управления доступом (ACL) объектов Windows. В AD можно даже делегировать разрешения встроенным участникам безопасности. Как ни странно, при первой попытке добавить встроенного участника безопасности в другую группу его не удается найти в оснастке Active Directory Users and Computers консоли MMC. Необходимо знать правильное имя встроенного участника безопасности; для поиска объекта нельзя задействовать инструментарий выбора объектов оснастки Active Directory Users and Computers. Дело в том, что в оснастке Active Directory Users and Computers сделан акцент на управление данными в контексте именования домена AD, а встроенные участники безопасности хранятся в контексте именования конфигурации AD. Та же проблема возникает при использовании оснастки MMC Local Users and Groups. В этом случае встроенные участники безопасности скрыты от пользователя.

В оснастке Active Directory Users and Computers встроенный участник безопасности отображается в контейнере ForeignSecurityPrincipals. Например, если ввести встроенного участника безопасности Authenticated Users в группу Print Operators, то элемент Authenticated Users будет добавлен в контейнер ForeignSecurityPrincipals (экран 3). Следует отметить, что в легкочитаемых именах большинства встроенных участников безопасности присутствует строка NT AUTHORITY. NT AUTHORITY — диспетчер безопасности во встроенном домене безопасности Windows, который существует в каждой системе Windows.

Встроенных участников безопасности можно добавлять в другие группы или в списки управления доступом (ACL) к ресурсам из командной строки. Это можно сделать с помощью команд Net Group и Net Localgroup. Например, чтобы добавить группу Interactive в локальную группу Backup Operators, следует ввести команду

net localgroup «Backup
Operators» Interactive /add

Добавить встроенный участник безопасности в список ACL ресурса можно с помощью утилиты командной строки subinacl.exe из комплекта ресурсов Microsoft Windows Server 2003 Resource Kit. Комплект можно загрузить по адресу http://www.microsoft.com/downloads/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b&displaylang=en.

Например, чтобы предоставить группе Local Service право чтения в разделе реестра MyApplication, следует ввести команду

subinacl /keyreg MyApplication
/grant=»Local Service»=r

Итак, повторюсь, встроенные участники безопасности Windows (специальная категория участников безопасности, заранее определенных и управляемых подсистемой безопасности Windows) представляют собой мощные инструменты для управления и поддержания безопасности на должном уровне. Выше уже было показано, как встроенные участники безопасности упрощают администрирование доступа к ресурсам Windows. Встроенные участники безопасности определяются операционной системой: их нельзя создать, переименовать или удалить, и они одинаковы во всех системах Windows. Далее будут подробно рассмотрены индивидуальные встроенные участники безопасности, указаны компоненты Windows, в которых они применяются, и даны рекомендации по их эффективному использованию.

Authenticated Users и Everyone

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

Встроенный участник безопасности группа Everyone представляет собой надмножество группы Authenticated Users и охватывает ее и учетную запись Guest. Членство в группе определяется сложными правилами. В табл. 3 показаны специфические члены групп Authenticated Users и Everyone. В службе Active Directory (AD) версий Windows XP и Windows 2000 учетная запись Anonymous автоматически имеет членство в группе Everyone, но не в Authenticated Users. В Windows Server 2003 AD и Windows XP Service Pack 2 (SP2) учетная запись Anonymous по умолчанию не является членом группы Everyone, но ее можно поместить туда, установив параметр политики безопасности Network Access: Let Everyone permissions apply to anonymous users. Этот режим еще можно активизировать, присвоив параметру реестра HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetControlLSAEveryoneIncludes Anonymous (REG_DWORD) значение 1. Учетная запись Anonymous не является членом групп Authenticated Users.

System, Local Service и Network Service

В Windows 2000 и более ранних версиях службы и приложения независимых поставщиков обычно выполняются в контексте безопасности встроенного участника безопасности System (также именуемого учетной записью LSA или Local System). System функционирует как учетная запись данного компьютера в сети и как таковая представлена в сети именем Domain namemachine name$. Имя учетной записи в локальной системе NT AUTHORITYSystem. Учетная запись не имеет пароля, которым должен управлять администратор: используются данные учетной записи компьютера, автоматически назначаемые и управляемые Windows.

Разрешения System сопоставимы с учетной записью root в UNIX. При запуске службы или приложения в контексте безопасности System данная служба или приложение располагает почти неограниченными разрешениями в системе Windows. Например, если служба регистрируется на контроллере домена (DC) с использованием встроенного участника безопасности System, то она получает права локальной системы на DC. Получив контроль над службой, злоумышленник может внести изменения в AD. Следует быть осторожным — действуя в соответствии с принципом минимальности достаточных разрешений, лучше избегать использования System.

Чтобы не нарушать принципы и избежать риска, связанного с System, в Windows 2003 и XP SP2 предусмотрено два альтернативных варианта учетных записей: Local Service и Network Service. Local Service предоставляет минимальный уровень разрешений службам, которым достаточно доступа только к локальным ресурсам. Службы Smart Card, Remote Registry и Telnet используют учетную запись Local Service. Служба, работающая от имени Local Service, обращается к сетевым ресурсам в нуль-сеансе с учетными данными Anonymous. Чтобы настроить службу на использование Local Service, следует ввести NT AUTHORITYLocalService во вкладке Log On диалогового окна Alerter Properties. Пароль не требуется.

Network Service обеспечивает минимальный уровень разрешений для служб, которым необходим доступ к другим компьютерам в сети. Как и служба с разрешениями System, служба Network Service обращается к сетевым ресурсам с данными учетной записи компьютера. Службам Domain Name System (DNS) и Remote Procedure Call (RPC) по умолчанию присваиваются разрешения Network Service. Чтобы настроить службу на использование Network Service, следует ввести NT AUTHORITYNetworkService на вкладке Log On диалогового окна Alerter Properties. Пароль не нужен.

This Organization и Other OrganizationWindows 2003 располагают встроенными участниками безопасности This Organization и Other Organization, которые относятся к новой функции безопасности при доверительных отношениях между лесами, именуемой селективной аутентификацией и брандмауэром аутентификации. Селективная аутентификация позволяет определить дополнительный уровень управления доступом к ресурсам между лесами. Например, селективную аутентификацию можно использовать для выполнения регистрации на компьютере, а затем предоставить или запретить доступ к объектам на данном компьютере.

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

С помощью мастера Trust Wizard или свойств доверительного отношения можно настроить доверительные отношения в лесу или внешние по отношению к лесу для селективной аутентификации. Для настройки селективной аутентификации из диалогового окна Properties доверительных отношений следует перейти на вкладку Authentication и активизировать Selective Authentication.

Режим селективной аутентификации может быть назначен, только если доверяющий домен или лес работают на функциональном уровне Windows 2003. Можно назначить селективную аутентификацию при настройке доверительных отношений для домена Windows NT 4.0, если нужно ограничить доступ к ресурсам домена Windows 2003.

Если лес или внешнее доверительное отношение используют селективную аутентификацию, а пользователь пытается обратиться к ресурсу в другом лесу (задействуя доверительные отношения между лесами), то Windows добавляет к маркеру доступа пользователя встроенного участника безопасности Other Organization. Пользователи, которые обращаются к ресурсам, применяя доверительное отношение между лесами, по умолчанию имеют в своем маркере доступа встроенного участника безопасности This Organization. Когда пользователь задействует доверительные отношения в лесу или внешнее отношение между лесами без селективной аутентификации, Windows добавляет This Organization к маркеру доступа данного пользователя. В этом случае членство в группе This Organization такое же, как в группе Authenticated Users.

Если в маркере доступа имеется встроенный участник безопасности Other Organization, то серверы ресурсов проверяют, действительно ли пользователь, запросивший доступ, имеет разрешение Allowed-to-Authenticate на сервере ресурсов. Разрешение Allowed-to-Authenticate можно установить из редактора ACL для объекта «компьютер». Если пользователь имеет разрешение Allowed-to-Authenticate, то аутентификация между лесами проходит успешно. На этапе аутентификации сервер ресурсов проверяет наличие определенных разрешений для Other Organization, а затем, соответственно, разрешает или запрещает доступ к ресурсам.

Restricted Code

Windows добавляет к маркеру доступа пользователя встроенного участника безопасности Restricted Code при выполнении команды RunAs с параметром Run this program with restricted access в Windows 2003 или параметром Protect my computer and data from unauthorized program activity в XP. Для учетных записей с большими разрешениями (например, administrator) RunAs — удобный способ переключиться в контекст безопасности пользователя с минимальными правами при запуске программы. Таким образом, снижается опасность запуска вредоносной программы в контексте безопасности с большими разрешениями.

Если маркер доступа пользователя располагает встроенным участником безопасности Restricted Code, то Windows отменяет все разрешения для пользователя, кроме Bypass Traverse Checking. В результате приложение не может получить доступ к профилю пользователя, и разрешается только доступ по Read к базам данных настроек в реестре HKEY_LOCAL_MACHINE и HKEY_CURRENT_USER.

Restricted Code — удобный способ применять минимальные разрешения, не запоминая имен двух пользовательских учетных записей и двух паролей. Вместо использования RunAs для переключения в контекст безопасности с минимальными разрешениями можно применить RunAs для перехода в ограниченный вариант текущего контекста безопасности учетной записи — без ввода данных второй учетной записи. Более подробно о RunAs и использовании в ней Restricted Code рассказано в статье Аарона Маргосиса «Running Restricted» по адресу http://blogs.msdn.com/aaron_margosis/archive/ 2004/09/10/227727.aspx.

Типы Logon и Authentication

В Windows 2003, XP и Windows 2000 имеются встроенные участники безопасности, которые операционные системы добавляют в маркеры доступа других встроенных участников безопасности в зависимости от типа регистрации участника. Эти встроенные участники безопасности типа регистрации — Batch, Dialup, Interactive, Network, Service и Terminal Server User. Terminal Server User предназначен для всех пользователей, зарегистрированных с использованием режима совместимости с приложениями Terminal Services 4.0

Windows 2003 и XP SP2 дополнены встроенным участником безопасности Remote Interactive Logon, который идентифицирует пользователей, регистрирующихся с помощью версий Terminal Services для Windows 2003 или XP либо через соединение Remote Desktop.

Windows 2003 также дополнена тремя встроенными участниками безопасности типа аутентификации — NTLM Authentication, SChannel Authentication и Digest Authentication. Эти участники отражают в маркере доступа участника протокол аутентификации, который использовался участником для аутентификации в Windows. Следует отметить, что Microsoft не предоставила участников для аутентификации Kerberos и Basic.

Для более детального управления авторизацией можно использовать встроенные участники безопасности как типа регистрации, так и типа аутентификации. Эти новые участники позволяют назначить пользователям различные уровни доступа к ресурсам в зависимости от протокола аутентификации (например, NTLM, Digest, SSL) и типа регистрации (т. е. консоли или через терминальные службы).

Self, Creator Owner и Creator Group

Несколько иерархических структур объектов Windows (в том числе AD, реестр и файловая система) обеспечивают наследование разрешений. Разрешения определяются в родительском объекте, а затем автоматически передаются дочерним объектам. Windows располагает встроенными участниками безопасности Self, Creator Owner и Creator Group для администрирования разрешений в этих иерархических структурах.

Как правило, все три участника вводятся в список управления доступом (ACL) родительского объекта, а затем дочерние объекты наследуют этих участников следующим образом.

• Дочерние объекты наследуют разрешения, назначенные для Creator Owner в родительском объекте таким образом, что учетная запись, которая создает дочерний объект, является владельцем объекта и явно получает специальные разрешения на дочерний объект. Например, если администратор AD устанавливает разрешение Write в свойствах определенного пользовательского объекта для Creator Owner в организационной единице (OU), то пользователь, который создает новый объект типа пользователь в OU, получает разрешение Write на этот объект.
• Creator Group функционирует аналогично Creator Owner, но вместо добавления разрешений дочернему объекту для Creator Owner следует назначать или отменять разрешения для Creator Group, которая затем переносит разрешения для первичной группы владельца объекта на дочерний объект.
• Self заполняет место для объекта. Например, администратор AD добавляет разрешение записи в атрибут postalAddress объекта «пользователь» для учетной записи Self в списке ACL этой организационной единицы. При создании нового объекта «пользователь» с именем Jan в этой OU пользователь Jan будет иметь разрешение Write для атрибута postalAddress (пользователю Jan разрешается обновлять данные о почтовом адресе в объекте типа «пользователь» AD). Следует обратить внимание, что те же разрешения Self на другой объект типа «пользователь» не позволят пользователю Jan редактировать атрибут postalAddress другого пользователя, так как разрешение для Self не связано с учетной записью Jan.

По умолчанию Windows предоставляет разрешение на чтение для Self на атрибут членства в группе. Поэтому все члены группы могут видеть других пользователей, принадлежащих к группе. AD также предоставляет группе Authenticated Users доступ на чтение к списку членов группы, и пользователи из Authenticated Users тоже видят эту информацию.

Мощный, но сложный инструмент

Мы познакомились с широкими возможностями встроенных участников безопасности и немного разобрались в трудностях, возникающих при управлении доступом к ресурсам Windows. Учитывая, что встроенные участники безопасности добавлены в Windows 2003, а также принимая во внимание растущее значение делегированного и самостоятельного администрирования, можно ожидать, что в будущем в Windows появится еще больше встроенных участников безопасности.

Жан де Клерк — Член Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасностью в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press). jan.declercq@hp.com