6840

Служба каталогов Active Directory и использование групповых политик

Лабораторная работа

Информатика, кибернетика и программирование

Служба каталогов ActiveDirectory и использование групповых политик СЛУЖБА КАТАЛОГОВ Общие сведения о службе каталогов На заре компьютеризации все управление пользователями сводилось к администрированию одного единственного сервера. Со...

Русский

2013-01-08

239 KB

43 чел.

Служба каталогов Active Directory и использование групповых политик

1. СЛУЖБА КАТАЛОГОВ

1.1 Общие сведения о службе каталогов

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

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

Решением этой проблемы стало создание так называемых служб каталогов —  систем  централизованного  хранения  информации  о  пользователях. Международная  организация  по  стандартизации (ISO)  предложила  стандарт X.500,  который  описывал функционирование  такой  системы. Однако  протокол взаимодействия, описанный в рамках стандарта, оказался слишком перегруженным для сетей TCP/IP. По этой причине какое-то время службы каталога  создавались  производителями  с  использованием  различных  протоколов взаимодействия (NDS, NIS, NT4 domain). Такое разнообразие реализаций привело к тому, что независимые разработчики сетевых сервисов либо совсем не обеспечивали  совместимости  со  службами  каталогов,  либо  обеспечивали  совместимость с какой-то конкретной реализацией. Как следствие, каждый производитель службы каталога должен был обеспечить клиентов и базовым набором служб (например, собственным файл-сервером).

Ситуация  изменилась  только  тогда,  когда  Интернет-сообщество  опубликовало «облегченный»  вариант  стандарта X.500 —  протокол LDAP (Lightweight Directory Access Protocol, RFC 4510). Протокол обеспечивал простой доступ к каталогу в рамках TCP-соединения, касался также вопросов аутентификации  и  собственно  структуры  каталога.  Позже  стандарт  претерпел некоторое количество редакций и в настоящее время поддерживается практически любым сетевым приложением и реализован в любой службе каталога. Развитие протокола продолжается и сегодня. Уже используется версия 3 данного  протокола,  а  также  опубликован  целый  ряд  расширений (например, поддержка language tags, позволяющая хранить имя пользователя, записанное на нескольких языках, и отправлять клиенту имя на его родном языке).

Многие  современные  сетевые приложения  также обладают  встроенной поддержкой LDAP (почтовые клиенты способны производить поиск адреса по имени пользователя, web-серверы и СУБД могут извлекать  список пользователей из каталога LDAP, распределенные приложения могут хранить свои настройки в каталоге LDAP и т. п.)

После  того  как  все  данные  о  пользователях,  группах,  в  которые  они входят,  и  их  правах  доступа  переместились  в  централизованное  хранилище, разработчики стали задумываться и о решении другой проблемы современных компьютерных  систем —  о  постоянной  необходимости  пользователей  в  аутентификации. Производители стали выпускать системы с концепцией единого входа в сеть (так называемые системы SSO — single sign on), т. е. пользователь при однократном вводе пароля получал доступ ко всем ресурсам сети. На практике  это  работало  только  с  сервисами  самого производителя, поскольку слишком  различались  протоколы  сетевой  аутентификации  у  различных  приложений. Те способы решения проблемы, которые пытались предложить конкретные производители, не были универсальны. Решения от Microsoft позволяли хранить пароль пользователя не в виде хэша, а в восстанавливаемом виде (т. е.  практически  в  открытом), Novell  позволял  хранить  пароль  различными способами (зашифрованный  хэшем  пароля  секретный  ключ  для  сервисов Novell, NTLM-хэш для доступа к  сервисам Microsoft). Такие решения позволяли пользователю не вводить свой пароль лишний раз, но не были ни безопасными, ни универсальными.

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

Однако  использование  универсальных  механизмов  лишь  частично  решает  проблему  единой  аутентификации  при  входе  в  сеть. Необходим  также некоторый  безопасный  протокол,  который  аутентифицирует  клиента  перед сервером (сервисом), с учетом того, что сам сервер ничего о пользователе не знает и должен использовать в качестве посредника сервер службы каталогов.  

В  качестве  универсального  протокола  аутентификации  можно  использовать  инфраструктуру  открытых  ключей (например,  на  базе  сертификатов X.509) или протокол Kerberos.

Служба Active Directory состоит из целого набора сервисов, связанных между  собой.  Основой Active Directory  является  система  разрешения  имен, при  помощи  которой  рабочие  станции  способны  прозрачно  обнаруживать серверы домена, например LDAP-серверы. В существующей реализации сервиса  каталога  в  качестве  службы  разрешения  имен  выбрана  система DNS (в отличие  от  предыдущих  версий,  которые  использовали  систему  имен NetBIOS). Для хранения каталога LDAP, а также для обеспечения аутентификации по протоколу Kerberos в сети Microsoft выделяются специальные сервера,  которые  называются  контроллерами  домена.  В  целом  контроллер  домена —  это  выделенный  сервер,  предназначенный  для  обеспечения  сервисов LDAP и KDC (Key Distribution Center).

1.2. Структура каталога LDAP

1.2.1. Схема LDAP

Каталог LDAP имеет древовидную структуру. Узлы дерева называются объектами.  Объекты  делятся  на  листья  и  контейнеры.  Каждый  объект  содержит  набор  свойств (различную  информацию  об  объекте,  например  его имя, дата создания и т. п.). Список свойств каждого объекта зависит от класса этого объекта. По аналогии с объектно-ориентированным программированием классы выстраиваются в иерархическое отношение — предок-потомок. Класс-потомок содержит свойства своего предка, при этом поддерживается множественное наследование. Описание всех классов и их свойств хранится в самом каталоге LDAP и называется схемой каталога.

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

Схема LDAP-каталога хранится в самом каталоге. Для описания схемы Active Directory  существует  два  объекта: attributeSchema  для  атрибутов  и classSchema для классов (оба эти класса, как и все их атрибуты также описаны внутри схемы).

1.2.2. Система имен LDAP

Для  того  чтобы LDAP-клиент  имел  возможность  получать  данные  от LDAP-сервера, необходимо указать конкретный объект в каталоге. Для этого служат специальные атрибуты, для которых схемой задается требование уникальности в пределах одного контейнера. Такие  атрибуты называются относительным  различимым  именем  (relative distinguished name, rdn). Теперь  для того, чтобы идентифицировать объект в пределах дерева, достаточно указать относительные различимые имена всех объектов в цепочке, начиная от корня дерева. Полученная последовательность различимых имен называется полным различимым  именем (fully distinguished name, fdn). Для  обозначения полного различимого имени принята запись

<имя атр.1>=<знач. атр.1>,  

<имя атр.2>=<знач. атр.2>,..,  

<имя атр.N>=<знач. атр.N>

Например, контейнер, хранящий  схему каталога Active Directory (в домене example.com),  имеет  следующее  полное  различимое  имя: CN=Schema, CN=Configuration, DC=example, DC=com. Как видно из примера, атрибут, являющийся относительным различимым именем у каждого объекта может быть свой (здесь CN —  у  объектов-контейнеров Schema  и Configuration, DC —  у объектов example  и com). Указание  того,  какой  атрибут  может  выступать  в роли различимого имени, задается в схеме для каждого класса.

1.2.3. Инструментарий для работы с LDAP-каталогом

Для  работы  с  произвольными LDAP-каталогами  существует  огромное количество программ как бесплатных, так и коммерческих. Из встроенных средств можно использовать оснастку MMC ADSI Edit или же утилиты пакета ldap-utils (преимущество этих утилит в том, что они реализованы практически для каждой ОС).

1.3. Система единого входа в сеть на основе протокола Kerberos

1.3.1. Общие сведения о протоколе Kerberos

Протокол Kerberos  является  универсальным  протоколом  аутентификации, основанным на распределении симметричных ключей шифрования некоторым доверенным сервером. Протокол Kerberos является открытым стандартом и описан в документе RFC 1510.

С  помощью  протокола Kerberos  распределяются  криптографические ключи в некоторой области (realm), которая имеет строковый идентификатор, как правило, совпадающий с именем DNS-домена. Например, для компьютеров DNS-домена example.com  можно  определить  область Kerberos EXAMPLE.COM (имя области всегда заглавными буквами).  

Каждая учетная запись в системе Kerberos называется сущностью (principal), причем учетные записи существуют не только для пользователей, но и для  каждого  сервиса.  Имя  учетной  записи  имеет  следующий  вид: «user@REALM» (где user —  имя  пользователя,  а RELAM —  имя  области). Например, имя учетной записи пользователя root из домена «example.com»  — «root@EXAMPLE.COM».  

Учетные  записи  сервисов  имеют  вид <name1>/<name2>@REALM,  где name1 — как правило, имя сервиса, а name2 — полное DNS-имя компьютера. Например, «HTTP/ws-linux.exampel.com@EXAMPLE.COM». Важно отметить, что имена сущностей Kerberos чувствительны к регистру.

Протокол аутентификации Керберос основан на одном из протоколов аутентификации Нидхэма - Шредера. Основное отличие Керберос - в предположении о хорошей синхронизации все часов в сети.

Помимо рабочей станции А и предоставляющего услуги сервера В в работе протокола принимают участие еще сервер аутентификации (AS, Authentication Server) и сервер выдачи подтверждающих подлинность билетов (TGS, Ticket Granting Server). У сервера аутентификации есть общий секретный пароль для каждого пользователя. Задача TGS состоит в выдаче свидетельств, убеждающих другие сервера в том, что владелец билета действительно является тем, за кого себя выдает.

Рис. 1. Работа протокола Kerberos

В начале сеанса A запрашивает у AS ключ сеанса и билет для TGS (данные зашифрованы секретным ключом А). Далее на основе пароля А формируется секретный ключ Ка и данные извлекаются из зашифрованного сообщения (далее введенный пароль уничтожается).

Чтобы вступить в контакт с сервером В, А посылает TGS запрос выдать билет для общения с В. Билет Ktgs(A, Ks) зашифрован секретным ключом TGS сервера и используется для подтверждения личности отправителя. TGS отвечает ключом сеанса Kab. Одна версия этого ключа зашифрована ключом Ks (для А), а другая ключом Kb. Временной штамп t помешает атаке воспроизведением (Злоумышленник не знает ключ Ks и не сможет заменить временной штамп на более новый).

Далее устанавливается сеанс с В и В получает ключ сеанса Kab. Kb(A, Kab) является гарантией подлинности А. Однако, В лишь получает подтверждение подлинности А. Права доступа для А В определяет самостоятельно.

Для установления защищенного сеанса с другим сервером потребуется снова обратиться к TGS. В тоже время пароли ни разу не передавались по сети.

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

1.3.3. Реализация Kerberos в ОС Windows Server 2003

Клиент Kerberos встроен во все ОС Windows семейства NT5, а реализация KDC —  во  все  серверные  версии NT5.  

Служба KDC  активизируется  в  серверной  ОС  только  при  повышении роли сервера до контроллера домена AD. Как уже отмечалось, контроллер домена AD — это KDC и LDAP-серверы, плюс некоторые утилиты администрирования этих серверов. Сущность Kerberos создается параллельно с созданием учетной записи пользователя, при этом происходит прямое отображение имени пользователя в сущность Kerberos (пользователю user домена example.com будет сопоставлена сущность «user@EXAMPLE.COM»).  


2. Использование групповых политик

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

2.1. Оснастка Group Policy Object Editor

Оснастка Group Policy Object Editor (Редактор объектов групповой политики) используется для редактирования параметров объектов групповой политики (group policy objects, GPO). Оснастка Group Policy Object Editor предоставляет администратору больше возможностей по конфигурированию параметров групповой политики по сравнению с другими оснастками, предполагающими работу с групповой политикой, — оснастками Local Security Policy, Domain Controller Security Policy и Domain Security Policy. Указанные оснастки обеспечивают доступ только к ограниченному подмножеству параметров групповой политики, расположенных в контейнере Security Setting (Параметры безопасности) соответствующего объекта групповой политики. Оснастки Domain Controller Security Policy и Domain Security Policy устанавливаются на каждом контроллере домена. Оснастка Local Security Policy присутствует на каждом рядовом компьютере под управлением Windows 2000/XP или Windows Server 2003.

2.2. Привязка оснастки к объекту групповой политики

Оснастка Group Policy Object Editor может быть вызвана из оснасток Active Directory Users and Computers и Active Directory Sites and Services. Для этого в окне свойств объекта, ассоциированного с сайтом, доменом или подразделением (Organizational Unit, OU) необходимо перейти на вкладку Group Policy (рис. 2).

Рис. 2. Вкладка Group Policy окна свойств подразделения

Необходимо различать операцию привязки оснастки Group Policy Object Editor к некоторому объекту GPO и операцию привязки непосредственно самого объекта GPO к некоторому контейнеру каталога.

Примечание: Поскольку при поиске объектов групповой политики выполняются обращения к DNS, ошибки при запуске оснасток Group Policy Object Editor нередко объясняются неправильной работой службы DNS. Поэтому при появлении подобных ошибок всегда проверяйте конфигурацию DNS. Помните о том, что DNS — это динамическая система, и ресурсные записи становятся просроченными и требуют периодической перерегистрации.

2.3. Создание и удаление объектов групповой политики

Для создания нового объекта групповой политики достаточно щелкнуть на кнопке New (Создать) на вкладке Group Policy (см. рис. 2 ) в окне свойств некоторого контейнера. Система предложит администратору дать имя создаваемому объекту групповой политики. После этого системой будет создан объект групповой политики со значениями параметров по умолчанию.

Удаление объекта групповой политики, не привязанного к какому-либо контейнеру каталога, не вызывает особых трудностей. В случае, если подобная привязка существует, система потребует дать дополнительные указания:

  •  Remove the link from the list (Изъять ссылку из списка, не удаляя объекта). Выбирая этот режим, администратор фактически только удаляет привязку выбранного объекта групповой политики к некоторому контейнеру каталога. Непосредственно сам объект групповой политики остается неизменным, и администратор может использовать его впоследствии;
  •  Remove the link and delete the Group Policy Object permanently (Изъять ссылку и окончательно удалить объект групповой политики). Выбор данного режима приводит к удалению непосредственно самого объекта групповой политики. При этом также удаляются существующие привязки указанного объекта к контейнерам каталога.

2.4. Привязка объекта групповой политики к контейнеру Active Directory

Любой объект групповой политики может быть привязан к некоторому сайту, домену или подразделению (Organizational Unit, OU). Один объект групповой политики может быть привязан к множеству контейнеров. Для выполнения привязки необходимо щелкнуть на кнопке Add на вкладке Group Policy окна свойств контейнера. В окне Browse for a Group Policy Object все объекты групповой политики, существующие в домене, перечислены на вкладке All (Все).
Администратору достаточно выбрать необходимый объект групповой политики и щелкнуть по кнопке ОК.

Возможна и обратная операция. Администратор может найти контейнеры, к которым привязан выбранный объект групповой политики. Для этого в оснастке Group Policy Object Editor необходимо в контекстном меню корневого объекта оснастки выбрать пункт Properties (Свойства), чтобы открыть окно свойств объекта групповой политики. В окне свойств необходимо перейти на вкладку Links (рис. 3). Выбрав из раскрывающегося списка Domain нужный домен и щелкнув по кнопке Find Now (Найти), администратор получит список контейнеров, к которым к настоящий момент привязан рассматриваемый объект групповой политики.

Рис. 3. Просмотр привязок выбранного объекта групповой политики

2.5. Структура объекта групповой политики

Множество параметров, определяемых в рамках объекта групповой политики, разделено на две части. Одна часть параметров используется для конфигурирования компьютера (computer configuration), другая часть параметров используется для конфигурирования среды пользователя (user configuration). Конфигурирование компьютера предполагает определение значений для параметров, влияющих на формирование окружения любых пользователей, регистрирующихся на данном компьютере. Конфигурирование среды пользователя дает возможность управлять процессом формирования окружения конкретного пользователя, независимо от того, на каком компьютере он регистрируется в сети.
Независимо от типа конфигурирования, параметры групповой политики организованы в специальные категории. Каждая из категорий параметров групповой политики определяет отдельную область окружения пользователя. В свою очередь категории параметров групповой политики организованы в три контейнера в соответствии со своим назначением:

  •   Software Settings (Конфигурация программ). В контейнере размещаются категории параметров групповой политики, посредством которых можно управлять перечнем приложений, доступных пользователям;
  •   Windows Settings (Конфигурация Windows). В контейнере размешаются категории параметров групповой политики, определяющие настройки непосредственно самой операционной системы. Содержимое данного контейнера может быть различным, в зависимости от того, для кого определяются параметры групповой политики (для пользователя или компьютера);
  •   Administrative Templates (Административные шаблоны). Этот контейнер содержит категории параметров групповой политики, применяемых для управления содержимым системного реестра компьютера.

2.6. Административные шаблоны

Механизм административных шаблонов позволяет администратору посредством групповой политики конфигурировать системный реестр клиентских компьютеров. Для любой рабочей станции, подпадающей под действие некоторого объекта групповой политики, системный реестр будет сконфигурирован в соответствии с административным шаблоном, определенным в рамках данного объекта.
Административные шаблоны не задействуют весь реестр целиком, а только два его ключа: HKEY_LOCAL_MACHINE и HKEY_CURRENT_USER.

Хотя, как было замечено, административный шаблон может использоваться для конфигурирования любых ключей реестра, предпочтительным является использование ключей HKEY_LOCAL_MACHINE\software\Policies (для управления Параметрами компьютера) И HKEY_CURRENT_USER\Software\Policies (для управления средой пользователей). Данные ключи реестра очищаются системой автоматически, при каждом применении или отзыве объекта групповой политики. Как следствие, в случае, когда компьютер не подпадает под действие ни одного объекта групповой политики, для настройки системы используются стандартные значения параметров, определенных в соответствующих ключах реестра.

2.7. Сценарии

Под сценарием (scripts) понимается некоторая предопределенная последовательность команд, способных выполнятся в автоматическом режиме (т. е. без участия пользователя). Администраторы используют сценарии в ситуациях, когда необходимо многократно выполнять некоторую последовательность действий. Используя механизм групповых политик, администратор может определить последовательность операций, которые будут выполняться в момент включения или выключения компьютера, либо при регистрации пользователя в системе или при выходе из нее. Таким образом, можно выделить четыре группы сценариев:

  •  сценарии, выполняемые при инициализации системы (startup scripts);
  •  сценарии, выполняемые при регистрации пользователя в системе (logon scripts);
  •  сценарии, выполняемые при выключении компьютера (shutdown scripts);
  •  сценарии, выполняемые при выходе пользователя из системы (logoff scripts).

Интерпретация сценариев осуществляется сервером сценариев Windows Script Host. Этот стандартный компонент, входящий в состав Windows 2000/XP и Windows Server 2003, позволяет создавать сценарии, используя специализированные языки Visual Basic Scripting Edition, JScript. Для старых версий клиентов (Windows 9x/NT) сценарии должны представлять собой пакетные файлы (.bat-файлы), либо нужно установить на них сервер сценариев Windows Script Host (загружаемый свободно с сайта Microsoft).

2.8. Управление приложениями

Механизм групповой политики может использоваться как средство управления процессом развертывания приложений на Windows 2000/XP- и Windows Server 2003-клиентах. Администратор может определить перечень приложений, которые будут доступны пользователям. В зависимости от выбранного режима, в процессе применения объекта групповой политики на компьютере будут установлены все необходимые приложения. Возможны следующие режимы управления процессом развертывания приложений:

  •  публикация приложений;
  •  назначение приложений пользователям',
  •  назначение приложений компьютерам.

Механизм управления процессом развертывания приложений базируется на технологии Windows Installer. В составе большинства продуктов поставляются специальные инсталляционные пакеты (installation package), которые могут быть использованы для автоматической установки данного приложения.

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

2.9. Построение иерархии объектов групповой политики

Параметры, определенные в рамках объекта групповой политики, воздействуют только на те объекты каталога, к которым они применены. Чтобы определить множество объектов каталога, подпадающих под действие того или иного объекта групповой политики, необходимо выполнить привязку последнего к одному или нескольким контейнерам каталога. Для любого объекта групповой политики (за исключением локальных) разрешается привязка к любому из трех классов объектов каталога — сайту, домену или подразделению. Любые объекты, ассоциированные с учетными записями пользователей и компьютеров, расположенные внутри этих контейнеров, подпадают под действие привязанного объекта групповой политики.

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

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

2.10. Блокировка процесса наследования параметров объектов групповой политики

Администратор может управлять процессом наследования параметров объектов групповых политик. Для этого в окне оснастки Active Directory Users and Computers необходимо открыть окно свойств контейнера, к которому привязан объект групповой политики. На вкладке Group Policy (Групповая политика) необходимо установить флажок Block Policy inheritance (Блокировать наследование политики). При этом параметры групповой политики, определенные на уровне вышестоящих контейнеров, не будут распространяться на содержимое конфигурируемого контейнера.

2.11. Запрещение переопределения параметров объектов групповой политики

Для запрещения переопределения параметров объектов групповой политики в окне свойств контейнера необходимо перейти на вкладку Group Policy и щелкнуть по кнопке Options (Параметры). В открывшемся окне надо установить флажок No Override (He переопределять). При этом на содержимое дочернего контейнера будут распространяться параметры объекта групповой политики, привязанные к родительским контейнерам, даже в том случае, если аналогичные параметры переопределены непосредственно на уровне дочернего контейнера. При установленном флажке No Override наследуемые параметры имеют преимущество над аналогичными параметрами объекта групповой политики, привязанного к дочернему контейнеру, даже если для этого контейнера установлен флажок Block Policy inheritance.

2.12. Запрещение применения параметров объекта групповой политики

Администратор может запретить применение параметров любых объектов групповой политики к содержимому некоторого контейнера каталога. Для этого на вкладке Group Policy окна свойств контейнера необходимо щелкнуть по кнопке Options (Параметры) и в открывшемся окне установить флажок Disabled (Отключено).

2.13. Ограничение действия параметров групповой политики

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

Для этого необходимо на вкладке Security (Безопасность) окна свойств выбранного объекта групповой политики указать нужную группу безопасности и установить флажок Deny (Запретить) напротив разрешения Apply Group Policy (Применять групповую политику). Эта процедура называется фильтрацией групповых политик (group policy filtering).

2.14. Предоставление полномочий на доступ к объектам групповой политики

Администратор может делегировать некоторым пользователям часть обязанностей по управлению объектами групповой политики. Чтобы предоставить пользователю полномочия, необходимые для выполнения привязки объекта групповой политики на уровне определенного контейнера, администратор должен использовать мастер Delegate of Control Wizard (Мастер делегирования управления). При работе мастера надо делегировать пользователям полномочия, необходимые для выполнения задачи управления привязками объектов групповой политики (флажок Manage Group Policy links на странице мастера Tasks to Delegate). Кроме того, указанная категория пользователей должна иметь разрешение на чтение объекта групповой политики. По умолчанию подобное разрешение предоставляется всем аутентифицированным пользователям.

2.15. Определение действующих политик

Для работы с доменными групповыми политиками в системах Windows Server 2003 имеются появившиеся еще в Windows XP полезные утилиты командной строки:

  •   GPUpdate.exe — выполните эту команду, если вы изменяли групповые политики и хотите, чтобы они немедленно стали активными (сначала запустите ее с параметром /?). В Windows 2000 для этих целей использовалась команда secedit /refreshPolicy;

В системах Windows XP и Windows Server 2003 имеется удобный инструмент для работы с групповыми политиками, который особенно оценят администраторы крупных доменов с многоуровневой иерархией объектов GPO — это оснастка Resultant set of Policies (Результирующая политика).

Ход работы:

Для выполнения работы потребуются:

  •  виртуальная машина Windows 2003 сервер с установленной (и настроенной)  службой Active Directory;
  •  клиентская ОС WIndows (например, Windows XP).

Учетная запись администратора домена "Administrator", пароль "labadmin".

Имя домена - "production.org".

Учетная запись локального администратора клиентской ОС "Администратор", пароль "labadmin".

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

1. Используя учетную запись локального администратора, введите клиентскую ОС в домен (Мой компьютер → Свойства → Имя компьютера → Изменить)

2. На контроллере домена в оснастке Active Directory Users and Computers создайте учетную запись пользователя домена (и задайте пароль).

 

     Ограничьте время входа пользователя в домен и укажите дату окончания действия учетной записи..

3. Делегируйте созданному пользователю полномочия управления учетными записями не привилегированных пользователей и изменения их свойств.

Примечание: Для выполнения пунктов 4-7 не служба Active Directory не требуется.

4. На клиентском компьютере разрешите использвание удаленного подключения к рабочему столу (Мой компьютер → Свойства →  Удаленные сеансы → Разрешить удаленный доступ к этому компьютеру).

     

     С сервера подключитесь к рабочему столу клиента (AccessoriesCommunicationsRemote Desktop Connections).

Примечание: Для удаленного подключения к рабочему столу в операционных системах Windows XP, Windows 2003 и более поздних используется протокол RDP (Remote Desktop Protocol).

5. Под учетной записью администратора домена для одного из пользователей назначьте квоту дискового пространства (Вкладка Quota в свойствах логического диска).

6.  В свободном пространстве жесткого диска создайте простой том и подключите его как папку к диску С:.

7.   Создайте и настройте некоторую папку диска С: как зашифрованную (Advanced attributes в свойствах папки) и обеспечьте возможность ее использования созданным в п.2 пользователем. Проверьте, сможет ли данный пользователь получить доступ к файлам из зашифрованной папки.

8. В дереве каталога домена Active Directory создайте контейнерный объект-подразделение (OU, Organizational Unit) и переместите в него учетные записи ранее созданного вами пользователя. Переместите в данный контейнер также учетную запись клиентского компьютера.

9. Назначьте созданному контейнерному объекту групповую политику и измените свойства данного обеъкта GPO (PropertiesGroup PolicyNew).

     Запретите переопределение парметров данной групповой политики (Group Policy Object OptionsNo Override и Block Policy Inheritance)

10. Настройте груповую политику данного контейнерного объекта (требования к паролю: ограничения минимальной длины и сложности паролей),

     а также:

  •  Приветствие, которое будет выводиться при каждой регистрации пользователя;
  •  Профиль использования IPSec;
  •  Настройки Internet Explorer (proxy-server);
  •  Удалите команды Run (выполнить) и Update  из меню Start;
  •  Удалите папки MyPictures и MyMusic из меню Start;
  •  Удалите папку MyDocuments с рабочего стола;
  •  Запретите использование оснасток Add or Remove programs и Display в панели управления.

 

11.  Командой gpupdate /force обеспечьте немедленное применение внесенных в групповые политики изменений.

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


 

А также другие работы, которые могут Вас заинтересовать

77614. Изучение основных методов обеспечения безопасности процессов хранения АХОВ 1 MB
  Территория области – в различной степени волнистая равнина. Нижнее течение реки Дона делит ее на две части, приблизительно равные по площади, но очень различные по природным условиям. Особенно сложен рельеф север-ной половины, имеющий хорошо развитую гидрографическую сеть и овражно-балочную систему.
77615. ИССЛЕДОВАНИЕ СУЛЬФАТНОЙ КОРРОЗИИ ЦЕМЕНТНО-ПЕСЧАННЫХ ОБРАЗЦОВ МЕТОДОМ СТРУКТУРНОГО АНАЛИЗА 6.37 MB
  В исследовательской работе рассматриваются тампонажные растворы на основе цементного вяжущего с применением компонентов кварцевого песка и добавки 10-тиводного сульфата натрия. Использование данного состава могло бы существенно отличатся от дорогостоящего сульфатостойкого цемента.
77618. Управление пассивными операциями коммерческого банка 385.09 KB
  Цель данной дипломной работы – раскрыть сущность управления пассивными операциями коммерческого банка. Для осуществления данной цели необходимо выполнить ряд задач. изучить теоретические основы формирования пассивных операций коммерческого банка...
77619. Оценка конкурентоспособности ООО «Инком-Арт» и разработка бенчмаркингового авант-проекта по повышению конкурентоспособности на мебельном рынке 1.45 MB
  Завоевать рынок, превзойти конкурентов, создать лучший продукт или услугу и получить прибыль хотят все организации. Можно решать подобные задачи самостоятельно, а можно воспользоваться опытом успешных организаций.
77620. Автоматизоване робоче місце диспетчера автогосподарства при УМВС України 863 KB
  Метою розробки є створення програмного продукту автоматизації робочого місця диспетчера гаража в автогосподарстві. Розроблений проект реалізує функції процесу обслуговування диспетчера в автогосподарстві. Програмний засіб забезпечує швидку та ефективну роботу працівників автогосподарства.
77621. СОВЕРШЕНСТВОВАНИЕ ТОВАРНОЙ ПОЛИТИКИ СП «ФРОСТ И К» 1.25 MB
  В рамках развития рыночных отношений в Республике Беларусь, в период мощной экспансии европейских производителей перед предприятиями появился ряд вопросов, связанных с повышением рентабельности хозяйственной деятельности.