Типы пользователей в Active Directory

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

В Active Directory существуют два типа групп: группы распространения и группы безопасности. Группы распространения могут быть использованы для создания списков рассылки электронной почты, а группы безопасности — для задания разрешений на использование общих ресурсов.

Группы распространения

Группы распространения используются только приложениями электронной почты (например, Exchange) для отправки сообщений электронной почты группам пользователей. Группы распространения не используют систему безопасности, иначе говоря, они не могут быть включены в избирательные таблицы управления доступом (DACL). Если группа создается для контроля доступа к общим ресурсам, эта группа должна быть группой безопасности.

Группы безопасности

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

Назначать права пользователя группе безопасности в Active Directory.

Права пользователя, заданные для групп безопасности, определяют, что может делать член данной группы в области действий домена (или леса). Права пользователя автоматически задаются для групп безопасности во время установки Active Directory для помощи администраторам в определении роли административных пользователей в домене. Например, пользователь, добавленный в группу «Операторы архива» в Active Directory, получает возможность создавать архивы и восстанавливать файлы и каталоги на любом контроллере домена в домене.

Это происходит потому, что по умолчанию права пользователя Архивирование файлов и каталогов и Восстановление файлов и каталогов автоматически задаются для группы «Операторы архива». Члены этой группы наследуют права пользователя, заданные для всей группы. Дополнительные сведения о правах пользователей см. в разделе Права пользователей. Дополнительные сведения о правах пользователей, заданных для групп безопасности, см. в разделе Группы по умолчанию.

Можно задать права пользователей группе безопасности, используя групповую политику, для делегирования конкретных задач. При задании делегированных задач необходимо соблюдать осторожность. Неопытный пользователь, наделенный слишком большими правами в группе безопасности, потенциально может нанести серьезный урон сети. Дополнительные сведения см. в разделе Делегирование администрирования. Дополнительные сведения о задании прав пользователей в группах см. в разделе Назначение прав пользователя группе в службе каталогов Active Directory.

Назначать разрешения на использование ресурсов для групп безопасности.

Не следует путать разрешения с правами пользователей. Разрешения задаются для групп безопасности, использующих общие ресурсы. Разрешения определяют, кто может получить доступ к данному ресурсу и уровень доступа, например полный доступ. Некоторые разрешения, установленные для объектов домена, автоматически задаются для различных уровней доступа группам по умолчанию, таким как «Операторы учета» или «Операторы домена». Дополнительные сведения о разрешениях см. в разделе Управление доступом в Active Directory.

Группы безопасности перечислены в избирательных таблицах управления доступом, которые определяют разрешения на ресурсы и объекты. Администраторам следует назначать разрешения для ресурсов (общих файлов, принтеров, и т. д.) группам безопасности, а не отдельным пользователям. Разрешения назначаются группе один раз, вместо назначения прав каждому отдельному пользователю. Каждая учетная запись при добавлении к группе получает права, заданные данной группе в Active Directory, и разрешения, определенные для данной группы на ресурсе.

Группы безопасности могут использоваться в качестве адресатов электронной почты, как и группы распространения. Сообщение электронной почты, отправленное группе, отправляется всем членам группы.

(по конспекту):

локальная группа -- пользователи текущего домена
глобальная группа -- видимые для других доменов и могут содержать пользователей которым необходим доступ из других доменов

20. Роли сервера в домене.

Доменная модель сети, используемая компанией Microsoft, позволяет централизованно выполнять все административные работы, поэтому она рекомендуется как основная модель при создании сети. Модель рабочей группы (Workgroup) не позволяет централизовать работу администратора, так как требует выполнения основных действий по управлению правами доступа пользователей с консоли каждого компьютера сети. Ввиду этого все административные действия будут далее рассматриваться для доменной модели.

При инсталляции как Windows NT Workstation так и Windows NT Server при установке сетевых компонент программа Setup попросит ответить на вопрос, будет ли данный компьютер членом домена или рабочей группы.

Ответ на этот вопрос не так уж важен при установке Windows NT Workstation, так как после установки ОС компьютер может менять свою принадлежность к любой рабочей группе или любому домену без повторной инсталляции – для этого нужно только изменить установку в секции Network программы Control Panel и перезагрузить компьютер.

При инсталляции сервера Windows NT Server ответ на вопрос о его роли в домене очень важен, так как изменить эту роль можно только путем полной переустановки системы на компьютере.

Windows NT Server может выполнять в домене три роли:

· первичный контроллер домена – Primary Domain Controller (PDC);

· вторичный контроллер домена – BackupPrimary Domain Controller (BDC);

· сервер домена – компьютер, не выполняющий роль PDC или BDC, а работающий как файл-сервер, принт-сервер и т.п.

Если вы инсталлируете первый сервер домена, то его необходимо делать первичным контроллером домена. При этом необходимо задать имя домена и указать пароль для встроенного пользователя Administrator. Этот пароль нельзя терять, по крайней мере до тех пор, пока вы не добавите к группе администраторов новых пользователей. При потере пароля единственного администратора придется заново устанавливать сервер. Первичный контроллер в домене может быть только один.

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

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

Если сервер Windows NT Server был при инсталляции присоединен к какому-либо домену, то его нельзя как Windows NT Workstation, перенести в другой домен без переинсталляции – по-этому принадлежность сервера домену нужно определить до начала инсталляции.

Так же невозможно сделать PDC или BDC обычным сервером домена без переинсталляции операционной системы.

Роли же PDC и BDC можно изменять между компьютерами, на которых Windows NT Server инсталлирован в этих режимах, можно менять оперативно. За счет этого можно поменять компьютер, на котором работает PDC, без необходимости заново создавать базу учетной информации пользователей.

21 Доверительные отношения между доменами.

Доверительные отношения - это механизм, посредством которого пользователи и ресурсы одного домена могут аутентифицироваться контроллером домена в другом домене. Например, предположим, что пользователь Susan в домене Windows NT 4 Administration (Администрирование) хочет осуществлять доступ к определенному ресурсу в домене Windows NT 4 Manufacturing (Производство). При попытке доступа к ресурсу пользователя Susan этот ресурс должен проверить, что учетная запись этого пользователя разрешает такой доступ. Если установлены такие доверительные отношения, что домен Manufacturing доверяет домену Administration, то ресурс в домене Manufacturing обратится к своему локальному резервному контроллеру домена (BDC) или главному контроллеру домена (PDC), который, в свою очередь, обратится к PDC или BDC в домене Administration и проверит, что пользователь Susan имеет допустимую учетную запись и что эта учетная запись принадлежит группе, которой разрешен доступ к данному ресурсу.

Все доверительные отношения между доменами Windows NT (а также этих додоменов с доменами более ранних версий Windows) нетранзитивны, то есть каждое доверительное отношение устанавливается в одном направлении явным образом.

Чтобы два домена имели взаимные доверительные отношения, должны быть уста-

установлены два отдельных доверительных отношения - по одному для каждого на-

направления.

22 Механизм групповых политик в Active Directory

Групповая политика — это набор правил или настроек, в соответствии с которыми производится настройка рабочей среды Windows. Групповые политики создаются в домене и реплицируются в рамках домена. Объект групповой политики (Group Policy Object, GPO) состоит из двух физически раздельных составляющих: контейнера групповой политики (Group Policy Container, GPC) и шаблона групповой политики (Group Policy Template, GPT). Эти два компонента содержат в себе всю информацию о параметрах рабочей среды, которая включается в состав объекта групповой политики. Продуманное применение объектов GPO к объектам каталога Active Directory позволяет создавать эффективную и легко управляемую компьютерную рабочую среду на базе ОС Windows. Политики применяются сверху вниз по иерархии каталога Active Directory.

По умолчанию в иерархии каталога Active Directory создаются две групповые политики: Default Domain Policy (политика домена по умолчанию) и Default Domain Controller’s Policy (политика контроллера домена по умолчанию). Первая из них назначается домену, а вторая — контейнеру, в состав которого входит контроллер домена. Если вы хотите создать свой собственный объект GPO, вы должны обладать необходимыми полномочиями. По умолчанию правом создания новых GPO обладают группы Enterprise Administrators (Администратор предприятия) и Domain Administrators (Администраторы домена).

23 Механизмы работы пользовательских программ с объектами исполнительной системы.

Исполнительная система NT реализует два типа объектов: объекты исполнительной системы (executive object) и объекты ядра (kernel object). Объекты исполнительной системы представляются различными компонентами исполнительной системы NT. Они доступны программам пользовательского режима (защищенным подсистемам) посредством базовых сервисов NT и могут создаваться и использоваться как подсистемами, так и исполнительной системой NT.

Объекты ядра — это более примитивный набор объектов, реализованный ядром NT. Эти объекты невидимы коду пользовательского режима, а создаются и используются только внутри исполнительной системы NT. Объекты ядра обеспечивают фундаментальные функции, такие как возможность изменять планирование в системе, которые могут выполняться только самым низким уровнем ОС — ядром. Многие объекты исполнительной системы содержат (инкапсулируют) один или несколько объектов ядра. На данный момент мы будем иметь дело только с типами объектов, видимыми в режиме пользователя, которые перечислены в табл. 3-1 вместе с определяющими их компонентами исполнительной системы.

24 Защита объектов. Маркеры доступа.

После успешной проверки подлинности имени пользователя и пароля система создает так называемый маркер доступа (Access token). Маркер доступа представляет собой объект, который содержит кроме всего прочего SID пользователя, прошедшего аутентификацию, и SID групп, в которые этот пользователь входит.

Рисунок 2. Аутентификация.

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

Кроме SID пользователя и групп, маркер доступа содержит и другие элементы, (такие как список привилегий, например). В рамках данной статьи они рассматриваться не будут.

25 Защита объектов. Списки контроля доступа.

Как видно из структуры дескриптора безопасности, он содержит два поля, содержащих в своем названии 'ACL' (Access-Control List) - список контроля доступа. Таких списков два: Discretionary Access-Control List, (DACL) - список управления избирательным доступом и System Access-Control List (SACL) - системный список управления доступом. Их структура схожа, однако они выполняют совершенно разные функции. В данном разделе будет более подробно рассмотрен DACL, так как он имеет для нас наибольшее значение. Именно DACL формирует правила, кому разрешить доступ к объекту, а кому - запретить. Поэтому все, что будет сказано о списках контроля доступа и его элементах, в большей степени относится именно к DACL. SACL позволяет лишь управлять аудитом (об этом - ниже).

Каждый список контроля доступа (ACL) представляет собой набор элементов контроля доступа (Access Control Entries, или ACE). Чтобы не было путаницы в терминах, изобразим схематически (рисунок 3).

Рисунок 3. ACL и ACE

ACE бывает двух типов (разрешающий и запрещающий доступ) и обязательно содержит три поля:

• SID пользователя или группы, к которому применяется данное правило
• Вид доступа, на которое распространяется данное правило
• Тип ACE - разрешающий или запрещающий.

Таким образом, ACL, изображенный на рисунке 3, (если это не просто ACL, а DACL) устанавливает следующие правила: пользователю SID1 разрешить доступ на чтение объекта, но запретить доступ на запись, а пользователю SID2 - разрешить полный доступ к объекту.

Кроме того, к дескриптору безопасности применимы следующие правила:

• Если DACL отсутствует, то объект считается незащищенным, т.е. все имеют к нему неограниченный доступ.
• Если DACL существует, но не содержит ни одного ACE, то доступ к объекту закрыт для всех.

Поиск по сайту: