|
|
|
от Dan DiNicolo
|
|
|
Добро пожаловать в статью 16 моей серии. Статья этой недели посвящена вопросам делегирования административного контроля над Active Directory, а также вопросам внедрения групповых политик. Мы рассмотрим ACL (access control list – списки контроля доступа), вопросы владения объектами и наследования, а также создание и применение групповых политик. На следующей неделе мы продолжим рассмотрение групповых политик, а также рассмотрим вопросы управления программным обеспечением, леса Active Directory с множеством деревьев и внешние доверительные отношения. В статью включены следующие материалы:
Обзор безопасности объектов Active Directory Лучший способ начать обзор безопасности объектов в среде Active Directory – это изучить различные элементы безопасности, с которыми вы должны быть хорошо знакомы. Многие из концепций, изложенных здесь, мы рассмотрели в предыдущих статьях нашей серии, поэтому не будет сильно в них углубляться. Первая вещь, которую вы должны помнить, когда рассматриваете безопасность объекта – это концепция security principal (участника безопасности). Говоря проще, участник безопасности – это тип учетной записи, к которой могут быть применены различные разрешения. Участниками безопасности являются пользователи, группы безопасности и компьютеры, которые характеризуются тем, что они имеют идентификатор безопасности (SID), назначенный им. Каждому участнику безопасности назначается SID, пришедший на смену идентификатору в домене (также называвшемуся SID) и относительный идентификатор (RID), комбинация которых однозначно определяет каждого участника безопасности. Когда пользователь пытается получить доступ к ресурсу (к любому другому объекту в Active Directory), соответствующий SID (для самого пользователя, групп, в состав которых он входит и связанной учетной записи компьютера) сравнивается с ACL (списком контроля доступа) объекта. ACL перечисляет, кто и в какой мере имеет доступ к объекту, как показано на примете объекта домен win2000trainer.com:
ACL для объекта Active Directory (такого, как пользователь, группа, компьютер и т.д.) очень похожи на то, что вы уже хорошо знаете – на список разрешений NTFS. Заметьте, однако, что конкретные разрешения, которые вы найдете в списке (называемые запись контроля доступа – ACE), могут отличаться в зависимости от типа выбранного объекта. Есть два типа ACL, о которых вы должны знать – это DACL (избирательный список контроля доступа) и SACL (системный список контроля доступа). DACL является списком разрешений, которые участники безопасности имеют по отношению к объекту (как было показано на рисунке, расположенном выше), в то время как SACL является списком записей, установленным на объекте для целей аудита, как показано ниже:
Вы также должны быть осведомлены о концепции, называемой access token (маркер доступа). Маркер доступа содержит пользовательские и групповые SID и создается, когда пользователь регистрируется в домене. Этот маркер позднее сравнивается с ACL, когда пользователь предпринимает попытку получить доступ к сетевому ресурсу. Маркер доступа создается с привлечением информации, предоставляемой контроллером домена, который идентифицирует пользователя (пользовательский SID, а также SID для локальных и глобальных групп домена, в которые пользователь включен), а также сервером Глобального Каталога (который предоставляет информацию о SID универсальных групп). Разрешения объекта и ACL Хотя концепция разрешений и ACL уже обсуждалась ранее, мы должны немного углубить наши знания по данному вопросу. Прежде всего, каждый объект в Active Directory имеет связанный с ним ACL. Он контролирует, кто и что может делать с объектом. По умолчанию, ACL связанный с объектом, является скрытым, но может открываться в свойствах объекта, если вы выберете опцию view Advanced Features (видеть Дополнительные свойства) в меню View оснастки Active Directory Users and Computers:
После того, как это будет сделано, вы получите доступ к ACL с вкладки Security (безопасность) свойств объекта. Перечень возможных записей может быть различным в зависимости от типа объекта и контролирует, что пользователи могут и что не могут делать в отношении объекта. Из практики известно, что изменение ACL отдельного объекта не является хорошей идеей. Проще изменить ACL родительского объекта и тогда, по умолчанию, эти изменения будут унаследованы всеми дочерними объектами. Вы можете заметить, что DACL состоит из двух главных столбцов, в которых записи могут изменяться – Allow (разрешить) и Deny (запретить). Правило простое – эффективное (действующее) разрешение для пользователя, когда он получает доступ к объекту, является комбинацией всех разрешений, которыми обладает пользователь, Существует единственное исключение – разрешение Deny (то есть запрещение) всегда преобладает над Allow. Разрешение Deny используется в специальных случаях. Например, вы хотите дать всем пользователям в группе Help Desk возможность изменять информацию, относящуюся к объектам Учетная запись пользователя, но хотите явно запретить делать это одному из пользователей, который является членом данной группы и имеет те же права. Заметьте также, что ACL, который вы видите, когда рассматриваете разрешения на доступ к объекту – это стандартный список разрешений. Если вы нажмете на кнопку Advanced (дополнительно), вам дополнительно будет представлен список пользователей и групп и связанные с ними разрешений, как показано ниже:
Выбрав любую запись из списка и нажав кнопку View/Edit (просмотр/редактирование), вы получите доступ к еще более тонкому уровню настройки разрешений, который включает в себя, в частности, установки наследования, применяемые к объекту по умолчанию:
Владение объектом и наследование По умолчанию, объектом владеет персона, которая создала его. Кто имеет право создавать объекты, контролируется через ACL объекта, внутри которого они создаются. Например, пользователю требуются соответствующие разрешения для контейнера (такого как OU), в котором он хочет создать объект. Для того чтобы посмотреть, кто является владельцем объекта, откройте вкладку Security, свойств объекта и нажмите кнопку Advanced. Вкладка Owner (владелец) покажет вам, кто в настоящий момент является владельцем, и кому предоставлена возможность стать новым владельцем объекта. Заметьте, что право владения может быть только взято, но не дано. Active Directory позволяет нам более тонкий уровень настройки административного контроля, если нам потребуется сделать это. Так, мы можем делегировать контроль над объектом другим пользователям или группам в рамках тех полномочий, которые мы хотим им дать. Например, я могу поместить всех пользователей в OU, называемую Company Users, и затем делегировать право сброса паролей всем пользователям группы Help Desk. Это позволит членам группы Help Desk сбрасывать пароли, но не позволит изменять еще хоть что-нибудь в учетных записях пользователей OU Company Users. Также я могу делегировать полный контроль над HR OU одному пользователю, который будет ответственным за контроль ресурсов в HR. Этот пользователь тогда сможет создавать учетные записи пользователей, изменять их свойства и т.д., но только в HR OU. Мастер Delegation of Control Wizard (делегирования контроля) позволяет вам выбрать, кому вы хотите делегировать контроль. Например, вы решили делегировать контроль над OU Company Users персоналу группы Help Desk, как показано ниже:
Когда вы нажимаете кнопку Next, мастер спросит у вас, какой тип контроля вы собираетесь делегировать. Рисунок, расположенный ниже, показывает наиболее общие делегирования, основанные на конкретных задачах:
Однако если вы решите выполнить индивидуальную настройку делегирования, вы можете дать пользователю или группе полный контроль над OU, или сделать его более гранулированным, например, позволить группе только чтение и изменение почтового кода в свойствах учетной записи:
Вы также можете выбрать, хотите ли вы дать возможность контролировать все объекты или только некоторый тип объектов, как показано на рисунке, расположенном ниже:
Конечно, DACL объекта (и потенциально всех дочерних объектов) будет автоматически меняться в соответствии с установками, которые вы сделаете в мастере. Использование данного мастера настоятельно рекомендуется, как наиболее простой способ делегирования административного контроля в Active Directory. Помните, что по умолчанию, любое разрешение, которое устанавливается на объекте, автоматически наследуется всеми дочерними объектами. Если вы хотите, чтобы дочерние объекты не наследовали данных разрешений, просто уберите «птичку» в окошке выбора “Allow inheritable permissions parent to propagate to this object” (разрешить родительским разрешениям распространяться на этот объект) на вкладке Security. После этого вам будет предложено выбрать либо копировать существующие разрешения на данный объект, либо удалить все ввязанные разрешения из ACL. Создание и настройка инструментов администрирования Как упоминалось в предыдущих статьях, теперь есть возможность создавать индивидуальные консоли MMC (Microsoft Management Console), которые ограничивают круг административных инструментов, к которым пользователи могут иметь доступ. Например, вы можете создать индивидуальный инструмент, включающий в себя доступ к оснасткам AD Users and Computers, а также Event Viewer, как показано ниже:
Для того чтобы сделать это, откройте новое окно MMC (запустив команду mmc.exe из окна Run), выберите опцию Add/Remove Snap-ins (добавить/удалить оснастку) из меню Console и добавьте нужный инструмент. Консоль может быть создана в двух режимах – Author Mode (режим автора) и User Mode (режим пользователя). В пользовательском режиме пользователь не может делать изменений в консоли (что очень помогает, если вам нужна постоянная пользовательская среда). В авторском режиме пользователь может добавлять или удалять оснастки. Режим должен быть выбран перед сохранением инструмента при помощи настройки Options в меню Console.
Заметьте, что пользователь также может щелкнуть правой клавишей на сохраненной консоли и она откроется, по умолчанию, в авторском режиме. Это свойство может быть запрещено через групповую политику, но еще проще ограничить права пользователя, присвоив ему NTFS разрешение Read на доступ к файлу консоли. Заметьте, что консоли, которые вы создаете, на самом деле не содержат в себе инструменты. Для того чтобы пользователь мог получить доступ к административным инструментам в консоли, на вашем компьютере должен быть установлен Adminpak.msi (установщик для административных инструментов). После того, как вы создадите и настроите консоль MMC, она может легко распространяться через групповую политику или как присоединенный файл по e-mail. Другая возможность, которая несколько отличается от создания индивидуальной консоли MMC, это создание того, что принято называть Taskpads (панелями задач). Это так же административная консоль, хотя и упрощенная версия. Идея заключается в том, что вы можете создать панель задач для пользователей, имеющих ограниченные знания об администрировании, например, для начинающего служащего, который должен создавать учетные записи компьютеров. Панель задач создается правым щелчком мыши на соответствующем объекте (таком как OU) в консоли MMC и выбором опции New Taskpad View (увидеть новую панель задач). Соответствующий мастер проведет вас через процесс создания Новой панели задач. Панель задач также может быть создана при помощи специального сценария, такого как командный файл, запускаемого из интерфейса панели задач, если вы хотите, чтобы не имеющий достаточного опыта пользователь мог выполнить сложную задачу. Пример простой панели задач приведен ниже:
Обзор групповых политик Как уже описывалось в предыдущих статьях, групповые политики в Active Directory позволяют нам осуществлять высокий уровень гибкости в том, как пользователи и их рабочая среда Windows 2000 может контролироваться и управляться. То, что вы можете сделать при помощи групповых политик, включает в себя распространение программного обеспечения, обновление настроек, таких, как настройки прокси-сервера в Internet Explorer, запрещение пользователю пользоваться панелью управления и т.д. Вам просто необходимо ознакомиться с сотнями установок, которые могут быть выполнены в групповых политиках, но вовсе не обязательно помнить все (или даже большую часть) из них. Однако, вы должны быть уверены, что по крайней мере понимаете, зачем различные возможные установки существуют. Для лучшего ознакомления со всеми настройками групповых политик вы можете просмотреть их сами или воспользоваться официальным документом (grouppolwp.doc) который находится здесь. Главное назначение групповых политик – контроль пользовательской среды и осуществление ее изменений с наименьшими административными усилиями. Например, я могу удалить значок My Network Places с рабочих столов всех пользователей при помощи установки соответствующей политики, примененной к OU. Когда пользователь, чья учетная запись находится в данной OU, войдет в систему, этот значок не будет доступен для него, независимо от того, на каком компьютере он вошел в систему в пределах леса Active Directory (если это не будет противоречить политике, установленной на другом уровне, что мы обсудим несколько позднее). Хотя идея настроек групповой политики достаточно прозрачна, могут возникнуть ошибки при ее настройке из-за установок, которые сделаны в групповых политиках на других уровнях. Объекты Групповая Политика (GRO) могут быть применены на следующих уровнях: Local (локально) Site (на уровне сайта) Domain (на уровне домена) OU (на уровне OU, а также на уровне OU, вложенные в данную OU) Порядок, перечисленный выше, соответствует порядку, в котором установки политик применяются к объекту. Это означает то, что настройки политик разных уровней сливаются одна с другой (за исключением случая, когда используются настройки Block Inheritance (блокировать наследование) и No Override (не переписывать) применяются, что мы обсудим позднее), начиная сверху и вниз. Так, если в локальной групповой политике установлено, что у пользователя не будет доступа к команде Run, в групповой политике на уровне Сайта установлено, что у него нет доступа к Панели Управления, на уровне домена – что обои экрана должны представлять из себя эмблему фирмы, а на уровне OU – что система будет перенаправлять его домашнюю папку, то, когда пользователь войдет в систему, все эти вещи и будут происходить. Однако, в случае, если случится конфликт (например, если политика на уровне OU говорит, что пользователь имеет доступ к команде Run), тогда расположенная ниже по уровню политика получает приоритет (команда Run становится снова доступной). Локальные объекты Групповая Политика хранятся на локальных системах и только они могут существовать на компьютере с Windows 2000. Все другие GRO – это относится к сайтам, доменам и OU – хранятся в Active Directory. На самом деле GRO состоит из двух частей. Контейнер групповых политик храниться в базе данных AD (он хранит большинство настроек), в то время как некоторые дополнения, такие как сценарии входа, хранятся в шаблонах групповых политик, в папке Sysvol на контроллере домена. Место, в котором хранятся шаблоны политик – это директория %systemroot%\SYSVOL\sysvol\domain_name\Policies, и имя для шаблона совпадает с глобальным уникальным идентификатором (GUID) объекта Групповая политика. Пример содержания этой папки показан ниже:
Объект Групповая политика может быть создан с помощью оснастки MMC Group Policy (групповая политика), но обычно он создается в инструменте Active Directory Users and Computers. Запомните, что групповые политики могут создаваться и настраиваться только для локальных систем, сайтов, доменов и OU. Так вы не можете применить групповую политику к встроенным контейнерам, таким как Users или Computers. Для создания нового объекта Групповая Политика, щелкните правой кнопкой мыши на соответствующем контейнере в AD Users and Computers, выберите опцию Properties и откройте вкладку Group Policy. Для создания новой политики, нажмите кнопку New и дайте политике имя, как это показано на рисунке, расположенном ниже:
Как и предлагается в данном окне, вы также можете добавить уже существующую политику. Это полезно, особенно, если вы хотите применить одну и ту же политику к многим OU, что требует выполнения одинаковых установок. После того, как вы назвали политику, вам необходимо нажать на кнопку Edit, чтобы настроить установки политики:
Заметьте, что все настройки разбиты на две главные сферы, Computer Configuration (настройка компьютера) и User Configuration (настройка пользователя). Верхняя часть настроек относиться к настройке компьютера, в то время как нижняя – к настройке учетной записи пользователя. Так, если ваш компьютер находится в OU, называемой Desktop, установки для настройки компьютера могут быть выполнены в GRO, примененной к данной OU. Подобным образом, если ваша учетная запись пользователя расположена в OU Sales (продажи), установки для конфигурирования пользователя могут быть выполнены в политике, примененной к этой OU. Если какая-то из двух частей не настраивается в данной GRO, то вы можете отключить данную часть, что увеличит скорость применения групповых политик. Это осуществляется щелчком по кнопке Properties на вкладке Group Policy и выделением соответствующей опции в окне, приведенном ниже:
Заметьте, что несколько групповых политик может быть одновременно применено к одному и тому же контейнеру. Например, согласно рисунку, приведенному ниже, три различных GRO назначены OU Company Users:
В подобной ситуации возможен конфликт между установками, задаваемыми разными политиками. Когда несколько GRO существует на одном уровне, политики применяются последовательно, снизу вверх. Это означает, что политика, указанная в самой последней строке, будет применена прежде всех других. Установки, которые будут применяться позднее, могут переписывать установки примененные ранее. В примере, приведенном выше, User Policy 3 будет применена первой, затем последует политика User Policy 2 и самой последней будет применена политика User Policy. Таким образом, если политики применяются к объекту еще и на уровне домена и сайта, то их порядок применения будет таков: Site – Domain – OU (User Policy 3 – User Policy 2 – User Policy). Заметьте, что если какая-либо политика применяется на уровне OU, вложенной в OU Company Users, она будет применена после всех, перечисленных ранее. Так как тема, которую мы рассматриваем, достаточно сложна, я вынужден прерваться на этом и рассмотреть оставшиеся элементы групповых политик на следующей неделе. Будут рассмотрены такие вопросы, как назначение групповых политик, делегирование, установка наследования, и фильтрация политик. Также на следующей неделе мы изучим распространение программного обеспечения через групповые политики, внедрение нескольких лесов доменов и внешние доверительные отношения. Спасибо всем, кто поддерживает мою серию. Я жду ваши вопросы и комментарии. Прошу заметить, что я больше не отвечаю на технические вопросы по электронной почте. Вместо этого, вы можете послать ваш вопрос на доску объявлений, чтобы и другие могли получить возможность ознакомиться с ответом на него. Успехов в учебе на этой неделе. Дэн |
