Книги, научные публикации Pages:     | 1 |   ...   | 4 | 5 | 6 | 7 | 8 |

С. Реймер, М. Малкер Active Directory для Windows Server 2003. Справочник администратора/Пер, с англ. Ч М.: СП ЭКОМ, 2004.Ч 512 с: ил. ...

-- [ Страница 6 ] --

Аудит использования административных разрешений Важным аспектом обеспечения безопасности службы Active Directory является создание тщательно спланированной конфигурации защиты всего домена. Этот план должен ясно и точно определить, какие разрешения должна иметь каждая административная группа. Другим существенным компонентом защиты домена является аудит использования этих разрешений.

Аудит служит достижению двух целей. Во-первых, он обеспечивает свидетельство изменений, которые были сделаны к каталогу. Если в каталоге были сделаны изменения, вы должны проследить, кто их сделал. Это особенно важно, если в информации домена произведены неправильные или злонамеренные изменения. Второй целью аудита является обеспечение дополнительной проверки административных прав, применяемых по всему домену. Периодически исследуя регистрационные журналы аудита, вы сможете определить, применяет ли административные права тот, кто не должен их иметь.

Включение аудита изменений, сделанных для объектов Active Directory, состоит из двух шагов.

Первый шаг состоит во включении аудита на уровне OU Domain Controllers (Контроллеры домена). Это делается с помощью инструмента администрирования Domain Controller Security Policy (Политика безопасности контроллера домена). На консоли Microsoft Management Console (ММС) выберите оснастку File>Add/ Remove (Файл>Добавление/Удаление), щелкните на кнопке Add (Добавить), а затем добавьте Group Policy Object Editor (Редактор объектов групповой политики). В Group Policy Wizard (Мастер групповой политики), щелкните на кнопке Browse (Просмотр), затем трижды щелкните на Domain Controllers.domainname.com (где domainname Ч имя домена, в котором вы включаете аудит). На рисунке 9-9 показана заданная по умолчанию конфигурация аудита в Active Directory Windows Server 2003.

Рис. 9-9. Конфигурирование аудита в организационных единицах Default Domain Controllers Если нужно производить аудит изменений для объектов Active Directory, вы должны гарантировать, что включена функция Audit Account Management (Аудит управления учетными записями). В этом случае все модификации, сделанные для объектов Active Directory, могут быть проверены. Вы можете делать аудит успешных изменений к Active Directory, а также неудавшихся попыток изменения Active Directory.

По умолчанию служба Active Directory Windows Server 2003 сконфигурирована для проведения аудита всех успешных действий по управлению учетными записями.

Разрешение аудита на уровне OU контроллера домена является первым шагом в предоставлении аудита. Это дает возможность сконфигурировать аудит для реальных объектов, расположенных в пределах данного домена. Чтобы разрешить аудит объекта Active Directory, обратитесь к окну Properties (Свойства) этого объекта через соответствующий инструмент Active Directory. Затем выберите вкладку Security (Безопасность), щелкните на Advanced (Дополнительно) и выберите вкладку Auditing (Аудит). На рисунке 9-10 показано окно инструмента Active Directory Users And Computers и заданная по умолчанию установка для аудита OU в Active Directory.

Рис. 9-10. Конфигурирование аудита объектов Active Directory Чтобы добавить больше записей для аудита, щелкните на кнопке Add (Добавить) и выберите пользователей или группы, действия которых вы хотите контролировать. В большинстве случаев вы должны выбрать группу Everyone, чтобы модификации, сделанные любым пользователем, подвергались аудиту. Затем вы можете выбрать, какие действия вы хотите подвергать аудиту. Вы можете делать аудит всех модификаций, сделанных для любого объекта в контейнере, для определенного типа объектов или для определенных свойств объектов. Вы можете допустить аудит всех успешных модификаций, всех неудавшихся попыток модификации или оба варианта.

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

Разрешение аудита делается просто. Управлять аудитом гораздо сложнее. Если вы разрешаете аудит всех модификаций каталога на уровне OU контроллера домена, то файл регистрации Security будет расти очень быстро. Почти все события будут законными изменениями, и не будут представлять для вас никакого интереса, кроме как отслеживание событий. Однако среди законных изменений может быть разбросано несколько изменений, о которых вы должны знать.

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

Дополнительная информация. Если вы хотите больше узнать о продукте Microsoft Operations Manager (MOM), посетите веб-сайт MOM обеспечивает большое количество функциональных возможностей, которые выходят далеко за пределы проблемы контроля журналов безопасности.

Делегирование административных задач В этой главе мы имеем дело с гарантией безопасности объектов Active Directory. Все сказанное до сих пор являлось подготовкой к данному разделу, который посвящен использованию опций защиты для делегирования административных задач. Поскольку все объекты в Active Directory имеют ACL-список, вы можете управлять административным доступом к любому свойству любого объекта. Это означает, что вы можете предоставлять другим администраторам Active Directory очень точные разрешения, чтобы они могли выполнять только делегированные им задачи.

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

Х Назначение полного управления одной OU. Довольно типична ситуация, когда компания имеет несколько офисов с локальным администратором в каждом офисе, который должен управлять всеми объектами локального офиса. Этот вариант может также использоваться компаниями, которые слили домены ресурсов Windows NT в OU одного домена Active Directory. Прежним администраторам доменов ресурсов можно дать полное управление всеми объектами, расположенными в определенной OU. Использование этой опции означает, что можно практически полностью децентрализовать администрирование вашей организации, имея единственный домен.

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

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

Компьютерной группе можно дать полное управление всеми компьютерными объектами в домене.

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

Можно использовать эти опции и любую их комбинацию в Active Directory Windows Server 2003.

Один из способов конфигурирования делегированных разрешений состоит в прямом обращении к списку ACL для объекта и конфигурировании разрешений. Это может быть достаточно сложным из-за большого числа доступных опций и реальной возможности сделать ошибку.

Чтобы сделать эту задачу более легкой, Active Directory Windows Server 2003 включает Delegation Of Control Wizard (Мастер делегирования управления).

Чтобы использовать Delegation Of Control Wizard, выполните следующие действия.

1. Откройте инструмент Active Directory Users And Computers и найдите родительский объект, которому нужно делегировать управление. В большинстве случаев делегировать управление можно на уровне OU, домена или контейнера, например, на уровне контейнеров Computers (Компьютеры) или Users (Пользователи). Щелкните правой кнопкой мыши на родительском объекте и выберите Delegate Control (Делегировать управление). Щелкните на кнопке Next (Далее).

2. На странице Users Or Groups (Пользователи или группы) выберите пользователей или группы, которым вы хотите делегировать управление. Щелкните на кнопке Add (Добавить), чтобы просмотреть Active Directory для поиска соответствующих пользователей или групп.

3. Затем выберите задачи, которые вы хотите делегировать. Окно (рис. 9-11) дает вам возможность выбрать задачи из списка обычных или создать собственную задачу для делегирования.

Рис. 9-11. Использование Delegation Of Control Wizard (Мастер делегирования управления) для выбора обычной задачи или создания собственной задачи для делегирования 4. Если вы выберите создание собственной задачи, можете задать тип объектов, которым вы хотите делегировать административные разрешения (рис. 9-12).

Рис. 9-12. Выбор типа объектов, которым будут делегированы разрешения 5. Можно выбрать уровни разрешений, которые вы хотите применить к объекту: полный контроль над объектом или доступ к определенным свойствам (рис. 9-13).

Рис. 9-13. Выбор специфических разрешений для делегирования Delegation Of Control Wizard значительно облегчает делегирование управления по сравнению с конфигурированием разрешений через ACL-списки. Однако эффект от применения обоих методов одинаков, т.е. ACL-списки объектов изменяются для обеспечения соответствующего уровня доступа.

Настройка инструментов для делегирования администрирования Служба Active Directory Windows Server 2003 обеспечивает мощные способы делегирования административных задач и назначения очень точных разрешений, которые пользователи должны иметь при необходимости выполнить специфические задачи. В дополнение к этим способам Active Directory облегчает развитие административных средств, которые соответствуют конкретной задаче пользователя. Например, если вы делегируете право устанавливать пароли для отдельной OU, вы можете воспользоваться простым инструментом администрирования, который может использоваться только для этой задачи. Windows Server 2003 имеет два способа создания специально настроенных инструментов. Вы можете настроить внешний вид средств обычных консолей ММС или создать панель задач (taskpad), которая является полностью настроенным инструментом администрирования.

Настройка консоли управления Microsoft Первый вариант разработки инструмента администрирования состоит в настройке консоли управления Microsoft (ММС - Microsoft Management Console) с помощью одной из заданных по умолчанию оснасток.

Предостережение. Простое создание настроенной ММС-консо-ли не предоставляет и не ограничивает права пользователя на выполнение административных задач. Перед созданием настроенного административного интерфейса нужно делегировать правильный уровень разрешений. Например, если вы даете пользователю право создания учетных записей пользователя на уровне домена, а затем создаете ММС-консоль, которая дает возможность пользователю рассматривать только одну OU, то он сможет создавать учетные записи пользователя в любой OU. Если пользователь загружает обычный инструмент администрирования Active Directory Users And Computers или садится за другой рабочий стол с другой ММС-консолью, он сможет создать учетную запись где угодно.

Для создания настроенной ММС-консоли откройте диалоговое окно Run (Выполнить) и напечатайте ттс. Будет открыта пустая ММС-консоль. Из меню File (Файл) добавьте нужную оснастку инструмента Active Directory. Если вы создаете собственную консоль ММС, используя оснастку Active Directory Users And Computers, разверните домен и найдете контейнерный объект, которому вы делегировали разрешения. В левой области окна щелкните правой кнопкой мыши на контейнерном объекте и выберите New Window From Here (Отсюда новое окно).

Откроется новое окно, в котором будут видны только контейнерный объект и все дочерние объекты. Затем вы можете переключиться назад к окну, которое отображает весь домен, и закрыть окно. Далее сохраните инструмент администрирования и предоставьте его пользователям, которые будут управлять только частью домена, видимого в ММС-консо-ли. Консоль ММС может быть предоставлена пользователю несколькими способами. Например, вы можете установить консоль ММС на рабочий стол пользователя или создать ярлык к инструменту администрирования на сетевом ресурсе.

Чтобы быть уверенным, что администраторы контейнера не изменят ММС-консвль, можно изменить опции ММС-консоли, выбирая Options в меню File. Вы можете сконфигурировать ММС консоль так, чтобы она сохранялась в режиме User Mode (Режим пользователя), и изменить разрешения на ММС, чтобы конечный пользователь не мог сохранять изменения ММС-консоли.

На рисунке 9-14 показан соответствующий интерфейс. Для уточнения деталей настройки ММС консолей смотрите Help And Support Center (Центр справки и поддержки).

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

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

Создание панели задач состоит из двух шагов. Сначала создается вид панели задач, а затем назначаются задачи, которые пользователь может выполнять на объектах. Чтобы создать панель задач, создайте настроенную ММС-консоль, содержащую административную оснастку, которую вы хотите использовать. Найдите контейнер, в который вы делегировали административные разрешения, затем щелкните правой кнопкой мыши и выберите New Taskpad View (Новый вид панели задач). Запустится мастер New Taskpad View Wizard. Мастер предоставит вам опции для выбора типа объектов, отображаемых на панели задач, и информации, отображаемой на экране.

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

На рисунке 9-15 показана панель задач, которая может использоваться администратором для установки паролей в определенной OU. Чтобы использовать этот инструмент, администратор просто выбирает учетную запись пользователя, а затем щелкает Reset Password (Заново установить пароль).

Рис. 9-15. Панель задач для сброса пользовательских паролей Планирование делегирования администрирования Active Directory Windows Server 2003 предоставляет средства, предназначенные для делегирования административных разрешений в вашем домене. Однако вместе с положительными сторонами делегирования разрешений вы получаете риск назначения неправильных разрешений.

Пользователям можно предоставить слишком большое количество разрешений, позволяющее им делать в Active Directory то, что им делать не положено. Пользователям можно предоставить слишком малое количество разрешений, не позволяющее делать то, что они должны делать.

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

Х Тщательно документируйте административные требования для всех потенциальных администраторов. В большинстве компаний вы обнаружите, что имеются различные группы, которые нуждаются в некоторых административных разрешениях в домене. Если компания использовала Windows NT, многие из этих пользователей могли быть членами группы Domain Admins. Документируя административные задачи, которые эти пользователи должны выполнять, вы обнаружите, что на самом деле они нуждаются в гораздо более низком уровне доступа. Часто единственный способ документирования уровня административных разрешений, в которых нуждается каждая группа, состоит в документировании всей административной работы, которую они делают каждый день.

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

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

Х Используйте Effective Permissions (Фактические разрешения) в окне Advanced Security Settings (Дополнительные параметры настройки защиты) для мониторинга и проверки разрешений, которые имеют пользователи. Окно Effective Permissions является отличным новым инструментом службы Active Directory Windows Server 2003, который может использоваться для определения точных разрешений пользователя или группы.

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

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

Резюме Возможность делегирования административных разрешений в Active Directory Windows Server 2003 дает большую гибкость в управлении вашим доменом. Оно основано на модели безопасности Active Directory, в которой все объекты и все атрибуты объектов имеют список ACL, контролирующий разрешения на доступ к объекту для различных участников безопасности.

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

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

Глава 10. Управление объектами Active Directory Обычные задачи, которые вы будете выполнять с помощью службы каталога Microsoft Active Directory системы Windows Server 2003, вовлекут вас в управление такими объектами Active Directory как пользователи и группы. Большинство компаний создает и реализует проект Active Directory один раз. После развертывания с большинством объектов Active Directory произойдут небольшие изменения. Однако работа с объектами user (пользователь) и объектами group (группа) является исключением из этого правила. По мере того как служащие присоединяются к компании или оставляют ее, администратор тратит время на управление пользователями и группами. Служба Active Directory содержит другие объекты, такие как printer (принтер), computer (компьютер) и shared folder (общие папки), которые также требуют частого администрирования.

В этой главе обсуждаются концепции и процедуры, которые используются для управления объектами Active Directory. В ней обсуждаются типы объектов, которые можно хранить в Active Directory и объясняется, как управлять этими объектами. Показан основной интерфейс, который вы будете использовать для работы с объектами, инструмент Active Directory Users And Computers (Пользователи и компьютеры Active Directory) и некоторые усовершенствования, которые сделаны для этого инструмента в Windows Server 2003.

Управление пользователями В службе Active Directory Windows Server 2003 существуют три объекта, которые используются для представления индивидуальных пользователей в каталоге. Два из них, объект user (пользователь) и объект inetOrgPerson, являются участниками безопасности, которые могут использоваться для назначения доступа к ресурсам вашей сети. Третий объект contact (контакт) не является участником безопасности и используется для электронной почты.

Объекты User Один из наиболее типичных объектов в любой базе данных Active Directory Ч объект user. Объект user, подобно любому другому объекту класса Active Directory, представляет собой совокупность атрибутов. Фактически, он может иметь более 250-ти атрибутов. Этим служба Active Directory Windows Server 2003 сильно отличается от службы каталога Microsoft Windows NT, в которой объекты user имеют очень мало атрибутов.

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

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

Когда вы создаете объект user, нужно заполнить некоторые из его атрибутов. Как показано на рисунке 10-1, при создании учетной записи пользователя требуется только шесть атрибутов, причем атрибуты сп и sAMAccountName конфигурируются на основе данных, которые вы вводите при создании учетной записи. Остальные атрибуты, включая идентификатор безопасности (SID), автоматически заполняются системой безопасности.

Рис. 10-1. Обязательные атрибуты учетной записи пользователя, отображаемые инструментом Adsiedit.msc При создании учетной записи пользователя вы можете назначить значения многим атрибутам объекта user. Некоторые из атрибутов нельзя увидеть через интерфейс пользователя (UI), например, атрибут Assistant (Помощник). Его можно заполнять, используя скрипт или инструмент Adsiedit.msc, который обращается к атрибуту напрямую. Можно заполнять скрытые атрибуты в процессе общего импорта информации каталога с использованием утилит командной строки Csvde или Ldifde. Детальную информацию по использованию этих утилит смотрите в Help And Support Center (Центр справки и поддержки). Заполнять невидимые в UI атрибуты необходимо, так как они используются для поиска и изменения объектов. В некоторых случаях скрытый атрибут доступен через диалоговое окно Find (Поиск). Например, в инструменте Active Directory Users And Computers (Пользователи и компьютеры Active Directory) для поиска всех пользователей, которые имеют один и тот же атрибут Assistant, используйте вкладку Advanced (Дополнительно) в диалоговом окне Find, чтобы создать запрос, основанный на атрибуте Assistant (см. рис. 10-2). В этом окне щелкните на кнопке Field (Поле), выберите User (Пользователь), а затем выберите атрибут, по которому вы хотите сделать поиск. Так можно найти многие скрытые атрибуты.

Рис. 10-2. Поиск учетных записей пользователя по атрибутам, которые не видны в пользовательском интерфейсе Дополнительная информация. Вы можете просматривать и изменять любой атрибут объекта user, используя инструменты Adsiedit.msc или Ldp.exe. Более эффективный способ состоит в использовании скриптов. От этого можно получить значительную выгоду, поскольку Active Directory написана так, чтобы разрешать и поощрять использование скриптов. Информацию об использовании скриптов для автоматизации задач управления службой Active Directory смотрите в центре TechNet Script Center по адресу TechNet Script Center содержит ресурсы для создания скриптов и типовые сценарии, используемые для расширения административных задач, которые иначе выполняются через консоли управления службой Active Directory. Смотрите также веб-сайт Microsoft Press Online по адресу www.microsoft.com/mspress/, где находится бонус-глава по созданию сценариев Introduction to ADSI Scripting Using VBScript (Введение в ADSI сценарии на языке VBScript), написанная Майком Малкером (Mike Mulcare).

Большинство административных задач, связанных с обычными пользователями, выполняются при помощи инструмента Active Directory Users And Computers. Чтобы создать с его помощью объект user, найдите контейнер, в котором вы хотите создать объект, щелкните правой кнопкой мыши и выберите New>User (Новый>Пользователь). При создании пользователя вы должны ввести Full Name (Полное имя) и User Logon Name (Пользовательское имя для входа в систему). Данные Full Name используются для заполнения атрибута сп пользователя, данные User Logon Name становятся значением sAMAccountName. После создания пользователя можно обращаться к свойствам объекта для заполнения дополнительных атрибутов пользователя, назначение которых вполне понятно. Наиболее важная вкладка, предназначенная для управления учетной записью пользователя Ч это вкладка Account (Учетная запись) (см. рис. 10-3). Пользовательские параметры настройки, доступные на вкладке Account, описаны в таблице 10-1.

Рис. 10-3. Вкладка Account для объекта user Табл. 10-1. Свойства учетной записи объекта User Параметры учетной записи Пояснение UserLogonName Идентифицирует основное имя (Пользовательское имя для пользователя (UPN) для данного входа в систему) пользователя.

User Logon Name Идентифицирует имя, применяющееся (Пользовательское имя для для входа в более ранние, чем Microsoft входа в систему) Windows 2000, системы, используя (использовалось до Windows формат domain\username.

2000) Logon Hours (Часы входа в Устанавливает часы, в которые систему) пользователь может входить в домен.

Log On To (Вход на) Перечисляет компьютеры (используя имена NetBIOS компьютеров), на которые пользователю разрешается вход.

Account Is Locked Out Указывает на то, что учетная запись (Учетная запись блокирована) была блокирована из-за слишком большого числа неудавшихся попыток входа в систему.

Account Options (Опции Обеспечивает настройку таких учетной записи) параметров, как политики пароля и опознавательные требования.

Account Expires (Учетная Определяет время окончания срока запись недействительна) действия учетной записи.

Именование объектов user в Active Directory Каждый объект в Active Directory должен иметь уникальное имя, но для объекта user это простое утверждение может стать довольно сложным, потому что объект user фактически имеет несколько возможных имен. В таблице 10-2 перечислены все имена, которые могут быть связаны с именем пользователя username, и область действия, в пределах которой это имя должно быть уникальным.

Табл. 10-2. Требования уникальности имени пользователя Username (Имя пользователя) Требование уникальности First name, initials, last name (Имя, Уникальность не требуется.

инициалы, фамилия) Display name (Отображаемое имя) Уникальность не требуется.

Full name (Полное имя) - используется Должно быть уникальным в для заполнения атрибута сп учетной пределах организационной записи пользователя. По умолчанию единицы (OU).

полное имя создается из полей First Name, Initials и Last Name диалогового окна New Object-User (Новый объект пользователь). Его можно изменить, используя Adsiedit.msc Username (Имя пользователя) Требование уникальности User principal name (Основное имя Должно быть уникальным в пользователя). UPN составлено из имени пределах леса.

входа в систему и DNS-имени домена или альтернативного UPN, если для леса были сконфигурированы дополнительные UPN-суффиксы.

User Logon Name (Pre-Windows 2000) Должно быть уникальным в (Пользовательское имя входа в систему, пределах домена.

используемое до Windows 2000) UPN является очень полезным именем для пользователя. Пользователь может перейти в любой домен леса и войти в систему, используя свое UPN-имя, вместо того чтобы при входе выбирать свой домашний цомен. По умолчанию UPN-суффикс является также DNS-именем для цомена. Вы можете изменять UPN-суффикс, например, использовать различные DNS-имена внутри и вне системы для отображения в интернете. В большинстве случаев SMTP-адрес электронной почты для всех пользователей соответствует внешнему имени DNS. Ваши пользователи, возможно, захотят входить в домен, используя свои адреса SMTP. Вы можете включить эту опцию, добавляя альтернативный UPN-суффикс к лесу и назначая его всем учетным записям пользователя. Чтобы создать дополнительный UPN-суффикс, откройте инструмент Active Directory Domains And Trusts (Домены и доверительные отношения Active Directory), щелкните правой кнопкой мыши на записи Active Directory Domains And Trusts, расположенной в верхней левой области окна, и выберите Properties (Свойства) (см. рис. 10-4). Напечатайте любой альтернативный UPN-суффикс, который вы желаете использовать.

Рис. 10-4. Добавление альтернативного UPN-суффикса к вашему лесу Объекты inetOrgPerson Одним из новых объектов Active Directory Windows Server 2003 является объект inetOrgPerson. Он является основной учетной записью пользователя, которая используется другими каталогами с применением облегченного протокола службы каталогов (Lightweight Directory Access Protocol Ч LDAP) и Х.500, совместимыми с требованиями документа Request for Comments (RFC) 2798.

Вводя объект inetOrgPerson, Microsoft облегчил интеграцию службы Active Directory с другими каталогами и упростил перемещение из каталогов в Active Directory.

Примечание. При обновлении леса Windows 2000 до Windows Server 2003 в схеме создается объект inetOrgPerson, когда вы выполняете команду Adprep.exe с ключом /forestprep. Утилиту Adprep.exe можно найти в папке \I386 на компакт-диске Windows Server 2003.

Объект inetOrgPerson может быть создан с помощью инструмента Active Directory Users And Computers. Для этого найдите контейнер, в котором вы хотите создать объект, щелкните на нем правой кнопкой мыши и выберите New>InetOrgPerson. При создании объекта inetOrgPerson вы должны ввести пользовательское имя входа в систему и полное имя. Объект inetOrgPerson является подклассом объекта user, т.е. он имеет все характеристики пользовательского класса, включая и то, что он действует как участник безопасности. Объекты inetOrgPerson управляются и используются теми же способами, как и объект user.

Учетные записи Contact Третий тип объектов, который может использоваться для представления пользователей в Active Directory, Ч это объект contact (контакт). Объекты contact отличаются от объектов user и inetOrgPerson тем, что они не является участниками безопасности (security principal). Обычно объекты contact используются только для информационных целей. Чтобы создать объект contact в инструменте Active Directory Users And Computers, найдите контейнер, в котором вы хотите создать объект, щелкните на нем правой кнопкой мыши и выберите New>Contact. При создании объекта contact вы должны ввести полное имя, можно также заполнить множество атрибутов объекта, включая номера телефона и адрес.

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

Предположим, что ваша компания слилась с другой компанией, которая уже развернула Active Directory. Можно создать доверительные отношения между двумя лесами так, чтобы совместно использовать сетевые ресурсы, но глобальный каталог (GC) каждого леса будет содержать только учетные записи этого леса. Однако ваша работа может требовать, чтобы все или некоторые учетные записи обоих лесов были видны пользователям. Для разрешения этого используется инструмент Microsoft Metadirectory Services (MMS), чтобы создать объекты contact для каждой учетной записи пользователя из другого леса и заполнить эти объекты соответствующей контактной информацией.

Дополнительная информация. Инструмент MMS доступен через Microsoft Consulting Services (Консультационная служба) или через существующего партнера MMS. Для получения дополнительной информации смотрите веб-страницу www.microsoft.com/windows2000 /technologies/directory / mms/'default, asp.

Другой вариант использования объекта contact возникает при реализации Microsoft Exchange Server, который, в отличие от более ранних версий, не имеет своей собственной службы каталога.

Вместо этого Exchange 2000 Server требует наличия Active Directory, и вся информация сервера хранится в каталоге Active Directory. В Exchange Server 5.5 и более ранних версиях вы можете создавать собственного получателя. Собственный получатель имеет адрес электронной почты, вы можете посылать ему почту, но у него нет почтового ящика на вашем Exchange-сервере. Если вы используете Exchange 2000 Server, то объект contact с поддержкой электронной почты заменит объект собственного получателя. Когда вы включаете почту для объекта contact, вы назначаете учетной записи адрес электронной почты, и он становится видимым для почтового клиента. Когда вы посылаете почту объекту contact, она доставляется по правильному адресу электронной почты.

Управление группами Основная функция Active Directory состоит в санкционировании доступа к сетевым ресурсам. В конечном счете, доступ к сетевым ресурсам основан на индивидуальных учетных записях пользователя. В большинстве случаев вы не захотите управлять доступом к. ресурсам с их помощью. В крупной компании это может привести к слишком большой загрузке администратора, кроме того, списки управления доступом (ACL) на сетевых ресурсах быстро стали бы неуправляемыми. Поскольку управление доступом к сетевым ресурсам с помощью индивидуальных учетных записей трудно поддается обработке, вы будете создавать объекты group для одновременного управления большими совокупностями пользователей.

Типы групп В системе Windows Server 2003 имеется два типа групп, называемых группами распространения (distribution group) и группами безопасности (security group). Когда вы создаете новый объект group, вам необходимо выбрать тип создаваемой группы (см. рис. 10-5).

Рис. 10-5. Создание новой группы в инструменте Active Directory Users And Computers Стандартным типом группы в Active Directory является группа безопасности. Группа безопасности является участником безопасности и может использоваться для назначения разрешений на сетевые ресурсы. Группа распространения не может быть участником безопасности, поэтому она не очень полезна. Вы используете данную группу, если установили Exchange 2000 Server и должны объединить пользователей вместе, чтобы можно было посылать электронную почту всей группе.

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

Примечание. Группа распределения похожа на список рассылки в Exchange Server 5.5, но не является точным эквивалентом списка рассылки Exchange 2000 Server. В Exchange Server 5.5 вы можете использовать список рассылки, чтобы собрать группу пользователей в почтовых целях, а также для назначения разрешений на общие папки Exchange-сервера. В Exchange 2000 Server вы должны использовать группу безопасности с поддержкой электронной почты, если нужно назначить разрешения на общую папку.

Вы можете преобразовывать группы распространения в группы безопасности и обратно, пока ваш домен работает на функциональном уровне Windows 2000 native (естественный). (Для получения дополнительной информации о функциональных уровнях см. табл. 2-1, 2-2 в гл. 2.) Если группа содержит учетные записи пользователей или контакты, то объекты user или contact не изменяются, когда изменяется тип группы.

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

Область действия группы В Active Directory Windows Server 2003 вы можете создавать группы с тремя различными областями действия: доменной локальной, глобальной и универсальной. В таблице 10- перечислены характеристики каждой области действия группы.

Примечание. Универсальные группы доступны только в том случае, если домен работает на функциональном уровне Windows 2000 native. Вложенные группы (nested groups} Ч это группы, которые являются членами других групп. Опции, предназначенные для вложения групп, зависят от функционального уровня домена. Например, вы можете вложить глобальную группу в доменную локальную группу на любом функн|иональном уровне, но вкладывать глобальную группу внутрь другой глобальной группы можно только в том случае, если домен работает на функциональном уровне Windows 2000 native, или более высоком.

Локальные группы домена являются полнофункциональными только в том случае, когда домен поднят на уровень Windows 2000 native. Если домен выполняется на смешанном (mixed) уровне Windows 2000, локальные группы домена работают точно так же, как локальные группы на контроллерах домена в Windows NT 4. Группа может использоваться для назначения разрешений на ресурсы только контроллеров домена, но не других компьютеров, расположенных в домене.

Если домен был переключен на естественный функциональный уровень Windows 2000, то локальные группы домена могут использоваться для предоставления разрешений ресурсам, расположенным на любом сервере с Windows 2000 или с Windows Server 2003.

Табл. 10-3. Область действия групп Active Directory Область Членство группы Область действия действия группы включает группы включает Domain Local Учетные записи Используется для (Локальная пользователя из любого назначения доступа к Доменная) домена леса ресурсам только в локальном домене.

Глобальные группы или Используется на всех универсальные группы из серверах Windows любого домена леса или Windows Server 2003.

Учетные записи пользователя или глобальные и универсальные группы из любого домена доверенного леса Вложенные локальные группы домена из локального домена Global Учетные записи Используется для (Глобальная) пользователя из домена, в назначения доступа к котором данная группа ресурсам, создана расположенным во всех доменах леса, или между доверенными лесами.

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

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

Глобальные группы из Используется только на любого домена леса или из серверах Windows доверенного леса или Windows Server 2003.

Вложенные универсальные группы из любого домена в лесе или из доверенного леса Планирование. Вы используете группы по-разному, в зависимости от того, какие серверы развернуты в вашей среде. Если ваш домен содержит только серверы с Windows 2000 и Windows Server 2003, используйте локальные группы домена для назначения разрешений на все ресурсы, расположенные на этих серверах. Однако вы также можете использовать локальные группы на серверах-членах домена. Обратите внимание, что необходимо использовать локальные группы на серверах Windows NT. В любом случае локальные группы могут содержать глобальные группы из любого домена в лесе. Если вы создаете локальные группы на серверах с Windows 2000 или с Windows Server 2003, группы могут содержать универсальные группы из любого домена леса или из доверенного леса.

Функциональные возможности глобальных групп в Active Directory Windows Server 2003 и Active Directory Windows 2000 остаются согласующимися между собой. Если домен был переключен на функциональный уровень Windows 2000 native, вы можете вкладывать глобальные группы из того же самого домена внутрь других глобальных групп. Если ваш домен работает на функциональном уровне Windows 2000 mixed или native, вы можете использовать эту опцию, чтобы преодолеть ограничение числа пользователей в пять тысяч на группу. Если группа очень большая, можно создать несколько подгрупп и вложить их в одну группу. Вложение групп может быть полезным и в других обстоятельствах. Например, ваша компания содержит несколько уникальных деловых подразделений, в каждом из которых есть менеджеры и исполнители. Вы можете создать глобальную группу Managers для каждого подразделения, а затем вложить эти глобальные группы в единую для компании группу менеджеров.

Универсальные группы являются наиболее гибкими группами в Active Directory, но эта гибкость дается не бесплатно. Они могут содержать любого члена домена леса и использоваться для назначения разрешений на ресурсы, расположенные в любом домене леса. Для этого список членства для всех универсальных групп должен храниться в глобальном каталоге (GC) как отдельный атрибут. Если ваш домен работает на функциональном уровне Windows 2000 native, то каждый раз после добавления к универсальной группе нового члена весь список членов должен копироваться на другие контроллеры домена. Для универсальной группы с тысячами пользователей это может привести к значительной репликации. Однако если домен был поднят на функциональный уровень Windows Server 2003, то контроллеры домена, на которых выполняется Windows Server 2003, будут реплицировать только изменения в списке членства.

Использование универсальных групп создает и другие осложнения. Поскольку они используются в любом месте леса, а члены группы могут находится также в любой части леса, то GC-сервер должен быть доступен всякий раз, когда пользователь входит в домен, иначе вход не будет выполнен. Эта проблема решена в Active Directory Windows Server 2003. Если домен переключен на функциональный уровень Windows Server 2003, вы можете сконфигурировать все контроллеры домена сайта так, чтобы они кэшировали универсальное групповое членство, когда пользователь входит в домен. Если GC сервер недоступен, локальный контроллер домена может использовать кэшированное универсальное групповое членство для подтверждения подлинности пользователя. Если пользователь ранее не входил на локальный контроллер домена, то эта информация будет недоступна, и пользователь не сможет войти в систему.

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

Active Directory Windows Server 2003 содержит большое количество встроенных учетных записей групп в контейнере Users (Пользователи) и Builtin (Встроенный). Эти группы имеют разнообразные цели и заданные по умолчанию разрешения в пределах домена. Только две группы при установке домена содержат некоторых членов - локальная группа домена Administrators (Администраторы) и глобальная группа Domain Admins (Администраторы домена). Учетная запись Administrator, под которой создавался домен, добавляется к обеим группам, а группа Domain Admins добавляется к группе Administrators. Если домен является первым доменом в лесе, то учетная запись Administrator также добавляется к глобальной группе Enterprise Admins (Администраторы предприятия) и к глобальной группе Schema Admins (Администраторы схемы).

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

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

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

Х Добавьте пользователей к глобальным или универсальным группам.

Х Добавьте глобальные или универсальные группы к локальным группам домена.

Х Назначьте доступ к ресурсам, используя локальные группы домена.

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

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

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

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

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

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

Часто пользователям требуется различный уровень доступа к совместно используемым папкам.

Например, компания имеет общую папку Human Resource (Кадры), где хранится вся информация о полисах служащих. Все пользователи должны иметь возможность читать информацию, хранящуюся в папке, но только члены отдела кадров могут изменять эту информацию. В этом случае создаются две доменные локальные группы для общей папки. Одной группе назначается разрешение Read Only (Только для чтения), другой - Full Control (Полное управление) или Modify (Изменение). Затем глобальная группа Human Resources может быть добавлена к доменной локальной группе, которой было назначено разрешение Full Control, а все другие глобальные группы, которые нуждаются только в доступе Read Only, - к доменной локальной группе Read Only.

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

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

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

Как показано на рисунке 10-6, вы можете создать глобальную группу в каждом домене, а затем добавить эту глобальную группу к доменной локальной группе того домена, в котором расположен ресурс.

Примечание. Windows NT использует глобальные и локальные группы, но не использует доменные локальные группы. Если в домене имеются серверы-члены домена с системой Windows NT, вы должны использовать локальные группы на каждом сервере. Если у вас имеются серверы с системами Windows 2000 или Windows Server 2003, и ваш домен работает на функциональном уровне Windows 2000 native, вы должны по возможности использовать доменные локальные группы, которые в этом случае охватывают несколько серверов. Если вы используете доменные локальные группы вместо локальных групп, вы можете переместить ресурс между серверами и использовать для назначения разрешений ту же самую доменную локальную группу.

Рис. 10-6. Конфигурирование доступа к ресурсу с помощью глобальных и доменных локальных групп с несколькими доменами Одним из основных вопросов при создании проекта группы безопасности является вопрос о том, когда использовать глобальные группы, а когда - универсальные. В некоторых случаях у вас нет выбора. Например, в Exchange 2000 Server группы, поддерживающие электронную почту, заменяют списки рассылки, используемые в Exchange Server 5.5 для группировки получателей электронной почты и назначения доступа к общим папкам. Если вы используете группы, поддерживающие электронную почту для Exchange 2000 Server, вы должны использовать уни- версальную группу. При переходе от Exchange Server 5.5 к Exchange 2000 Server следует заменить каждый список рассылки из Exchange Server 5.5 универсальной группой, поддерживающей электронную почту. Если имеется более одного домена, обязательно используйте универсальные группы для групп, поддерживающих электронную почту.

В большинстве случаев наилучшей практикой при создании проекта универсальной группы в Active Directory Windows 2000 являлась минимизация использования универсальных групп, особенно если имелись сайты, связанные медленными сетевыми подключениями. Причина этого была связана с проблемами репликации GC-каталога. Эта рекомендация все еще верна для леса, работающего на функциональном уровне Windows 2000. Если ваш лес Windows Server 2003 был переключен на уровень Windows Server 2003 или Windows Server 2003 interim (временный), то проблема, связанная с репликацией, больше не существует. Кроме того, опция, включающая кэширование GC-каталога, уменьшает потребность в развертывании GC-серверов в каждом сайте.

Поэтому решение, касающееся использования универсальных или глобальных групп, не особо критично для Active Directory Windows Server 2003. В большинстве случаев можно использовать глобальные и универсальные группы почти взаимозаменяемо.

Управление компьютерами Еще один тип объектов Active Directory - это объект computer (компьютер). В Active Directory имеется два типа таких объектов. Первый - это объект domain controller (контроллер домена), который создается при назначении сервера контроллером домена. По умолчанию объекты domain controller расположены в OU Domain Controllers. Вы можете перемещать контроллеры домена из этой OU, но делать это следует с осторожностью. Многие параметры настройки безопасности контроллера домена сконфигурированы в OU Domain Controllers, и перемещение контроллера домена из этого контейнера может серьезно изменить настройку безопасности.

Второй тип объектов computer - это объекты, представляющие все прочие компьютеры, которые являются членами домена. Учетные записи этих компьютеров создаются в Active Directory в заданном по умолчанию контейнере Computers. Обычно объекты computer из этого контейнера перемещаются в определенные OU, чтобы вы могли управлять компьютерами разными способами.

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

Примечание. Все компьютеры, на которых выполняются системы Windows NT, Windows 2000, Microsoft Windows XP Professional и Windows Server 2003, должны иметь компьютерную учетную запись в домене. Компьютеры, на которых выполняются системы Microsoft Windows 95 или Microsoft Windows 98, не имеют учетных записей.

Вы будете редко управлять компьютерными объектами в Active Directory напрямую. Если щелкнуть правой кнопкой мыши на компьютерной учетной записи в Active Directory, вы увидите, что имеется совсем немного опций управления. Одна из опций - переустановка учетной записи компьютера. Используйте ее осторожно, потому что при переустановке нарушается связь компьютера с определенным доменом, и компьютер должен заново присоединяться к домену.

Очень полезная опция позволяет любому компьютеру из Active Directory обратиться к приложению Computer Management (Управление компьютером). Найдите компьютер в инструменте Active Directory Users And Computers, щелкните правой кнопкой мыши на значке нужной рабочей станции или сервера и выберите Manage (Управление). Откроется ММС-консоль Computer Management, содержащая параметры выбранной вами рабочей станции или сервера.

Примечание. Тот факт, что вы не будете сильно заняты администрированием компьютерных объектов в Active Directory, вовсе не подразумевает, что вы не будете использовать Active Directory для управления компьютерами. Главы 11, 12 и 13 рассматривают с групповые политики, обеспечивающие мощныее инструментальные средства управления компьютерами.

Управление объектами printer Третья группа объектов Active Directory состоит из объектов printer. Вы можете создать объект printer путем опубликования принтера в Active Directory, при этом сохраняются такие атрибуты принтера, как место его расположения, а также свойства принтера (скорость печати, возможность цветной печати и другие). Основанием для публикации объектов printer в Active Directory является облегчение для пользователей поиска и соединения с сетевыми принтерами.

Публикация принтеров в Active Directory По умолчанию любой принтер, установленный на сервере с Windows 2000 или Windows Server 2003, к которому разрешен общий доступ, автоматически публикуется в Active Directory. Если этого не требуется, можно очистить опцию List In The Directory (Зарегистрировать в каталоге) в окне Properties (Свойства) принтера. Однако если принтер расположен на сервере с системой Windows NT или другой операционной системой, вы должны вручную опубликовать принтер в Active Directory. Чтобы выполнить это, найдите объект container, в котором вы хотите опубликовать объект printer, щелкните на нем правой кнопкой мыши и выберите New (Новый)>Printer (Принтер). Затем напечатайте UNC-путь на общедоступный компьютер.

Совет. Если вы используете серверы печати Windows NT и не хотите модернизировать их до Windows 2000 или Windows Server 2003, нужно вручную опубликовать все принтеры на серверах печати Windows NT в Active Directory. Компания Microsoft создала сценарий с именем Pubprn.vbs, предназначенный для автоматизации процесса публикации. Этот сценарий расположен в папке %systemroot %\system32.

Публикация принтера в Active Directory нужна для поиска пользователями объектов printer в Active Directory. После публикации принтера информация о нем автоматически регистрируется в окне Properties (Свойства) принтера, доступного из инструмента Active Directory Users And Computers. Эта информация нужна пользователю, который ищет определенный принтер, например, цветной принтер, который печатает, по крайней мере, шесть страниц в минуту. Если эта информация хранится в Active Directory, клиент может использовать опцию A Printer On The Network (Сетевой принтер) операции Search (Поиск), выбранной из меню Start (Пуск), чтобы найти все принтеры, удовлетворяющие этим требованиям. На рисунке 10-7 показано окно на рабочей станции с системой Windows ХР Professional. Как только сетевой принтер найден, пользователь может щелкнуть правой кнопкой мыши на принтере и выбрать Connect (Подключить), чтобы установить принтер на машине клиента.

Если объекты printer опубликованы в Active Directory, для управления ими используется редактор Group Policy Object Editor (см. рис. 10-8).

Две опции, которые вы можете конфигурировать, используя групповые политики, управляют удалением принтера. Они касаются автоматического удаления объектов printer ТАЗ Active Directory, если объект printer устаревает. Например, если принтер удален из сервера печати, или если он больше недоступен на сервере для совместного пользования, удаление принтера удалит объект printer. По умолчанию один из контроллеров домена Active Directory пробует входить в контакт с каж- дым сервером печати каждые 8 часов, чтобы подтвердить правильность информации о принтере.

Если сервер печати не отвечает, объект printer удаляется из Active Directory. При каждом запуске сервера печати Windows 2000, или более поздней версии, он автоматически повторно регистрирует общие принтеры на сервере в Active Directory. Вы можете сконфигурировать параметры удаления принтера, используя редактор Group Policy Object Editor.

Рис. 10-7. Поиск принтеров в Active Directory Рис. 10-8. Конфигурирование параметров настройки принтера с помощью редактора Group Policy Object Editor Одна из наиболее интересных опций Active Directory, предназначенная для управления объектами printer Ч это опция, позволяющая автоматически показывать местоположение принтера для пользователей, выполняющих поиск принтера. Во многих компаниях, имеющих несколько офисов, есть служащие, которые путешествуют между ними. Большинство компаний имеет комнаты для собраний, которые находятся в различных частях здания. Всякий раз, когда пользователи перемещаются из одной части компании в другую, они должны иметь возможность печатать. Если пользователь не знает, где находятся принтеры, предназначенные для печати в данном месте, то поиск ближайшего принтера может занять некоторое время.

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

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

1. Откройте инструмент Active Directory Sites And Services и найдите объект subnet (подсеть), в котором включите мониторинг местоположения принтеров. Щелкните правой кнопкой мыши на объекте subnet и выберите Properties (Свойства). Щелкните на вкладке Location (Местоположение) и введите значение location (место расположения) для этой подсети.

Запись места расположения должна иметь формат: location/sublocation (Общее расположение/детализированное расположение) (например, Главный офис/Третий этаж).

2. Используйте редактор Group Policy Object Editor для включения политики Pre-Popula-te Printer Search Location Text (Предварительно заполнить текст, указывающий место расположения принтера при поиске) для выбранного контейнера. В большинстве случаев это делается на уровне домена.

3. На вашем сервере печати обратитесь к окну Properties для каждого принтера. На вкладке General (Общее) вы можете заполнить место расположения принтера. Если первые два шага этой процедуры завершены, можете щелкнуть на Browse (Просмотр), чтобы найти место расположения принтера. Можно добавить больше деталей к описанию места расположения принтера, чтобы оно было лучше определено (например, Главный офис/Третий этаж/Внешняя комната для собраний 5).

4. После того как вы включили мониторинг места расположения принтеров, пользователи могут легко находить ближайший к ним принтер. Когда пользователь запускает Add Printer Wizard (Мастер добавления принтера) и ищет принтер в каталоге, атрибут Location (Место расположения) заполняется в соответствии с текущим сайтом пользователя. На рисунке 10-9 показано окно клиента Windows ХР Professional. Пользователь может щелкнуть Browse для нахождения более точного места расположения принтера.

Рис. 10-9. Поиск объекта printer в Active Directory с помощью атрибута Location Управление опубликованными общими папками Еще один объект, который можно публиковать в Active Directory - это объект shared folder (общая папка). Чтобы опубликовать общую папку в Active Directory, найдите нужный контейнер.

Щелкните правой кнопкой мыши на контейнере и выберите New (HoBbm)>Shared Folder (Общая папка). Затем напечатайте имя объекта Active Directory, а также UNC-путь для общей папки.

После того как в Active Directory будет создан объект shared folder, пользователи могут просматривать и искать его в Active Directory. Найдя объект shared folder, пользователи щелчком правой кнопкой мыши на объекте могут отобразить диск на общую папку.

Основное преимущество публикации общей папки в Active Directory состоит в том, что пользователи могут искать общие ресурсы, основываясь на разнообразных свойствах. Когда вы создаете объект shared folder, вы можете дать описание общей папки (см. рис. 10-10). После создания общей папки откройте окно Properties (Свойства) для указания ключевых слов, связанных с общей папкой. Когда клиентам потребуется найти общую папку, они могут сделать поиск в Active Directory, используя параметр, основанный на имени объекта, ключевых словах или описании.

Рис. 10-10. Публикация общей папки в Active Directory Ограничение, связанное с публикацией общих папок в Active Directory, состоит в том, что, если общая папка переместится на другой сервер, то все клиенты, имеющие диски, отображенные на эту общую папку, обнаружат, что отображение больше не работает. Это произойдет, потому что при отображении клиентского диска на общую папку в Active Directory используется UNC-путь к ресурсу. Например, вы можете создать и опубликовать общую папку по имени Saleslnfo, которая указывает на \\Server1\SalesInfo. Когда пользователь находит эту общую папку в Active Directory и отображает диск, то для отображения диска используется синтаксис \\Serverl\SalesInfo. Если папка переместится, отображение диска перестанет действовать, даже если вы сделаете изменения в Active Directory так, чтобы объект указывал на новое место расположения.

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

Х Функциональность Drag and drop. Наиболее популярной новой функцией Active Directory Windows Server 2003 является перетаскивание объектов в пределах инструментов администрирования Active Directory. Теперь вы можете перемещать пользователя из одной OU в другую путем перетаскивания значка учетной записи пользователя. Вы можете добавить существующего пользователя к группе перемещением значка учетной записи пользователя в учетную запись группы.

Х Одновременное редактирование нескольких элементов. Еще одна новая функция Ч возможность редактировать несколько объектов одновременно. В Active Directory Windows 2000 вы можете изменять только один объект за раз. С помощью инструмента администрирования Active Directory Users And Computers Windows Server 2003 можно изменять одновременно большое число объектов. Предположим, что все пользователи отдела Marketing (Маркетинг) переезжают в другое офисное здание, и вы должны заменить адрес для всех учетных записей пользователей. Используйте средство поиска, чтобы найти учетные записи пользователей, у которых атрибут Department установлен на значение Marketing. Затем выделите все учетные записи в окне результатов поиска, щелкните на них правой кнопкой мыши и выберите Properties (Свойства). Теперь вы можете изменять общие атрибуты для всех учетных записей одновременно. Ваш домен должен работать на функциональном уровне Windows Server 2003, чтобы позволить одновременное редактирование нескольких элементов.

Х Сохранение запросов. В больших организациях с тысячами пользователей администраторы всегда находят объекты Active Directory с помощью поиска, а не просмотра. Опция сохранения запросов означает, что вы можете однажды создать запрос на поиск, а затем сохранить его для повторного использования в другое время. Возможно, вы захотите выполнять ежемесячную проверку, чтобы узнать, какие учетные записи пользователя не использовались для входа в домен в последние 30 дней. Щелкните правой кнопкой мыши на контейнере Saved Query (Сохраненные запросы) и выберите New (Новый)>

Х Инструменты командной строки Active Directory Windows Server 2003 включают множество новых средств, предназначенных для управления объектами Active Directory:

утилиты Dsadd и Dsmod (для добавления или изменения объектов Active Directory соответственно), Dsrm (для удаления объектов Active Directory), Dsmove (для перемещения объектов из одного контейнера в другой), Dsquery (для поиска списка объектов) и Dsget (для отображения атрибутов объекта). Смотрите Help And Support Center (Центр справки и поддержки) для получения детальной информации о том, как использовать эти инструменты.

Резюме В этой главе приведен краткий обзор стандартных объектов Active Directory Windows Server и процедур, позволяющих ими управлять. Наибольшие административные усилия вы потратите на управление этими объектами. В частности, вы будете управлять учетными записями пользователей и групп по мере притока и оттока служащих из вашей компании или по мере создания новых групп для защиты сетевых ресурсов. Одно из осложнений, с которыми вы столкнетесь, - у вас может быть три различных объекта, представляющих индивидуальных пользователей: объекты user, inetOrgPerson и contact. Кроме того, имеется два типа групп и три области действия, с которыми вам придется работать. Ваше время будет также занято управлением такими объектами как computer, printer или shared folder.

Глава 11. Введение в групповые политики Одна из типичных тем разговора среди людей, оплачивающих установку инфраструктуры корпоративной информационной технологии (IT-Inf ormation Technology), - это общая стоимость компьютеров. Известно, что цена начальной закупки компьютера составляет лишь небольшую часть стоимости управления и содержания этого компьютера в последующие годы эксплуатации.

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

Групповые политики в Microsoft Active Directory Windows Server 2003 предлагают инструменты для понижения стоимости управления компьютерами клиентов. Используя групповые политики, вы можете сконфигурировать их в службе каталога Active Directory, а затем применить к отдельным (или всем) компьютерам вашей организации Эта глава содержит введение в групповые политики и поясняет, как их конфигурировать в Active Directory Windows Server 2003. Главы 12 и 13 посвящены использованию групповых политик для выполнения определенных задач, таких как управление рабочими столами пользователей и установка программного обеспечения.

Примечание. Групповые политики эффективны для компьютеров с операционной системой Microsoft Windows 2000 и старше: Windows 2000 Server, Windows Server 2003, Windows 2000 и Windows XP Professional. Их нельзя использовать для управления компьютерами-клиентами, на которых выполняются системы Microsoft Windows NT, Windows 95 или Windows 98. Если вы уже знакомы с групповыми политиками Active Directory в Windows 2000, то заметите, что большинство концепций в обеих версиях Active Directory одинаковы, но в Active Directory Windows Server 2003 имеется больше доступных опций. Многие из новых параметров настройки имеют отношение к Windows XP Professional и игнорируются клиентами Windows 2000.

Краткий обзор групповых политик Групповые политики Active Directory Windows Server 2003 обеспечивают мощные инструментальные средства, предназначенные для управления пользовательскими рабочими столами. В таблице 11-1 показано многое из того, что можно делать с помощью групповых политик.

Табл. 11-1. Опции групповых политик Опция конфигурации Объяснение Инсталляция программ Используется для установки программного и управление обеспечения на компьютерах и его обслуживания с помощью установки заплат или обновлений. Используется также для деинсталляции пакетов программ. Программное обеспечение может быть назначено и на пользователей, и на компьютеры.

Сценарии Используется для выполнения сценариев при запуске и выключении компьютера, а также при входе и выходе из системы. Сценарии могут быть файлами MS-DOS.bat или файлами Windows Script Host.

Перенаправление папки Используется для перенаправления некоторых частей рабочей среды пользователя, таких как My Documents (Мои документы), меню Start (Пуск) или Desktop (Рабочий стол), к сетевому ресурсу, на котором может быть сделана резервная копия. Это перенаправление прозрачно для пользователя.

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

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

Существует два типа групповых политик. Первый тип Ч это локальная групповая политика на компьютере с системами Windows 2000, Windows XP и Windows Server 2003. Локальная групповая политика может быть только одна, и это единственная групповая политика, доступная на компьютере, не являющемся членом домена. Она применяется также на всех компьютерах, которые являются частью домена. Многие из локальных политик те же самые, что и групповые политики домена, но из-за того, что локальная групповая политика применяется первой, групповые политики Active Directory часто отменяют многие параметры ее настройки.

Примечание. Локальный объект групповой политики (GPO -Group Policy Object) хранится на локальном компьютере в папке %systemroot%\System32\GroupPolicy.

Второй тип групповой политики - э|го групповая политика Active Directory. Ее объекты хранятся в Active Directory, и каждая политика разными способами управляет компьютерами домена. Когда формируется домен Active Directory Windows Server 2003, создаются две групповые политики Active Directory: Default Domain Policy (Заданная по умолчанию политика домена) и Default Domain Controllers Policy (Заданная по умолчанию политика контроллеров домена). Default Domain Policy устанавливает политики учетных записей и паролей и используется для конфигурирования общих для домена параметров настройки. Политика Default Domain Controllers Policy применяется в организационных единицах (OU) контроллеров домена и используется для усиления некоторых параметров настройки защиты для контроллеров домена. В дополнение к этой политике можно создавать столько групповых политик, сколько потребуется, и связывать их с различными местами в структуре Active Directory. Групповые политики могут быть связаны с контейнером сайта, контейнером домена или любым контейнером OU вашей организации.

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

Объекты GPO, основанные на Active Directory, фактически состоят из двух различных объектов.

Один из них Ч это объект контейнера групповой политики (GPC), к которому можно обратиться с помощью инструмента Active Directory Users And Computers через контейнер System (Система)\Policies (Политики). Если вы не видите системный контейнер, выберите Advanced Features (Дополнительные свойства) из меню View (Вид) (см. рис. 11-1). Объект GPC содержит следующую информацию.

Х Информация о версии. Поддерживается как объектом GPC, так и шаблоном групповой политики (GPT - Group Policy Template) и используется для проверки синхронизации этих объектов.

Х Список компонентов. Используется для указания того, параметры настройки какой групповой политики (компьютера, пользователя или обеих) сконфигурированы в этом объекте GPO.

Х Информация о состояния. Используется для указания того, является ли объект GPO действующим, или он заблокирован.

Подробности, касающиеся объекта GPC, отражаются в свойствах объекта в инструменте ADSI Edit, но модифицировать их можно только через редактор групповой политики Group Policy Editor.

Рис. 11-1. Поиск объектов GPC в Active Directory Совет. На рисунке 11-1 показано, что глобально уникальные идентификаторы (GUID), которые используются для идентификации объектов GPC в Active Directory, не всегда удобны. Для определения отображаемого имени каждого из GPC-объектов используйте утилиту ADSIedit.msc. Найдите GPC в Active Directory, используя ADSI Edit, а затем рассмотрите атрибут display Name.

Второй объект, который входит в групповую политику, Ч это объект GPT, содержащий большинство фактических параметров настройки для групповой политики и хранящийся в папке Sysvol на каждом контрол- лере домена. Этот объект включает папки и информацию о содержимом (см. табл. 11-2).

Табл. 11-2. Содержание шаблона групповой политики Место расположения Содержание папки Adm Содержит файлы.adm, использующиеся для конфигурирования административных шаблонов.

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

User Содержит параметры настройки системного реестра, применяемые политиками к данному пользователю. Параметры настройки хранятся в файле Registry.pol.

User\Applications Содержит сценарии рекламы приложений для всех приложений, развернутых для пользователей.

Machine Содержит все параметры настройки системного реестра, применяемые политикой к компьютеру.

Параметры настройки хранятся в файле Registry.pol.

Machine\ Applications Содержит сценарии рекламы приложений для всех приложений, развернутых для компьютеров.

{GUID} Содержит файл Gpt.ini, в котором находится номер версии GPO.

Оба GPO-компонента реплицируются на все контроллеры домена в домене. Объект каталога (GPC) реплицируется как часть обычной репликации Active Directory. Объект Sysvol (GPT) реплицируется службой репликации файлов (File Replication service - FRS).

Примечание. Если вы создали новый объект GPO или изменили существующий, политики должны реплицироваться на все контроллеры домена в домене. Используйте монитор репликации Replication Monitor для проверки статуса репликации. (Replication Monitor является инструментом Active Directory, который устанавливается, когда вы дважды щелкаете на файле Suptools.msi, расположенном в папке \Support\Tools на компакт-диске Windows Server 2003.) Откройте Replication Monitor и добавьте контроллеры домена к списку Monitored Servers (Кон-троллируемые серверы). Затем щелкните правой кнопкой мыши на имени контроллера домена и выберите Show Group Policy Object Status (Показать состояние объекта групповой политики). На рисунке 11-2 показано, как выглядит реплицируемая информация.

Рис. 11 -2. Просмотр статуса объекта групповой политики с помощью монитора репликации Replication Monitor Реализация групповых политик Когда вы создаете новый объект GPO или модифицируете существующий, изменения по умолчанию делаются на эмуляторе основного контроллера домена (PDC). В большинстве случаев нужно принять это для уменьшения вероятности того, что несколько администраторов сделают несовместимые изменения параметров настройки групповой политики. Однако если эмулятор PDC недоступен в то время, когда нужно сделать изменения, вам необходимо выбрать контроллера домена, с которым можно будет соединиться (см. рис. 11-3). (Вы можете модифицировать то, какой контроллер домена будет изменен, обращаясь к тому же самому окну через меню View (Вид)>БС Options (Выбор DC) в редакторе объектов групповой политики.) Если вы выберете соединение с контроллером домена, имеющим лексему Operations Master (Хозяин операций) для эмулятора PDC, то соединитесь с эмулятором PDC. Вы можете также делать изменения на контроллере домена, с которым связаны в текущий момент, или на любом другом контроллере домена.

Рис. 11 -3. Выбор контроллера домена, на котором будут сделаны изменения объекта GPO Создание объектов GPO Существует два способа создания новых объектов GPO. Первый способ заключается в использовании инструмента Active Directory для поиска контейнера, в котором нужно создать новый объект GPO. Затем нужно щелкнуть правой кнопкой мыши на контейнерном объекте и выбрать Properties (Свойства). Выберите вкладку Group Policy (Групповая политика) (см. рис. 11 4). Чтобы создать новый объект GPO, который будет связан с этим контейнером, щелкните на New (Новый).

Рис. 11 -4. Создание нового объекта GPO, связанного с OU Второй способ Ч это создание собственной консоли ММС (Microsoft Management Console) и добавление к ней оснастки Group Policy Object Editor (Редактор объектов групповой политики).

При выборе этой оснастки необходимо указать объект GPO, который вы планируете изменить. По умолчанию оснастка загрузит Local Computer Policy (Локальная компьютерная политика).

Щелкните на кнопке Browse (Просмотр), чтобы загрузить любой объект GPO из вашего домена или сайта. Используйте этот инструмент для изменения локального объекта GPO для любого компьютера, на котором у вас есть административные права (см. рис. 11-5).

Рис. 11 -5. Выбор GPO-объекта при изменении политики путем добавления оснастки Group Policy Object Editor к ММС-консоли Чтобы создать новый объект GPO с помощью Welcome To The Group Policy Wizard (Мастер групповой политики), перейдите в нужное место вашего домена и щелкните на кнопке Create New Group Policy Object (Создать новый объект групповой политики).

Независимо от того, какой инструмент используется при создании нового объекта GPO, создается новая групповая политика и связывается с объектом, в котором вы создаете GPO. На рисунке 11- показан недавно созданный объект GPO. Позже объект GPO можно изменить в соответствии с вашими требованиями.

Администрирование объектов групповой политики Как только объект GPO создан, вы можете изменять его конфигурацию. Большинство этих модификаций будет осуществляться на вкладке Group Policy окна Properties (Свойства) контейнерного объекта, с которым связан объект GPO (см. рис. 11-4). В таблице 11-3 объясняются опции конфигурации, доступные в этом окне.

Рис. 11-6. Создание нового GPO-объекта загружает заданные по умолчанию параметры настройки групповой политики Табл. 11 -3. Конфигурирование параметров настройки GPO Опция интерфейса Пояснение Add (Добавить) Используется для связи предварительно созданного объекта GPO с контейнерным объектом. Когда вы щелкнете на кнопке Add, появится окно, подобное окну на рисунке 11*5. Вы можете найти любой объект GPO в вашей организации и связать его с этим контейнером.

Edit (Редактирование) Используется для модификации опций конфигурации объекта GPO, изменяя содержание GPO. Когда вы щелкнете на кнопке Edit, появится соответствующее окно (см. рис. 11-6).

Options (Опции) Используется для конфигурирования опции No Override (He подменять) и для отключения объекта GPO. Они будут подробно обсуждаться в разделе Наследование групповой политики и применение далее в этой главе.

Опция интерфейса Пояснение Delete (Удалить) Используется для удаления объекта GP При выборе этой опции вы можете или по ностью удалить GPO из Active Directory, и.

удалить только связи с данным контейне ным объектом.

Properties (Свойства) Используется для конфигурирования то] применяется ли этот объект GPO к компы терам и пользователям или к обоим. Кро:

того, используется для конфигурирован:

опций защиты объекта GPO. Эти опции ко фигурирования будут подробно обсуждать в разделе Фильтрация применения групп вой политики далее в этой главе.

Наследование групповой политики и ее применение Объекты GPO могут быть связаны с объектами сайтов, доменов и объектами OU в Active Directory. Групповые политики связываются только с этими контейнерами и не могут связываться с контейнерами Users или Computers.

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

1. Local group policy (Локальная групповая политика). Первой всегда применяется локальная групповая политика.

2. Site-level group policies (Групповые политики уровня сайта). Эти групповые политики связаны с объектом сайта в Active Directory.

3. Domain-level group policies (Групповые политики уровня домена). Эти групповые политики связаны с объектом домена в Active Directory.

4. OU-level group policies (Групповые политики уровня OU). Если домен содержит несколько уровней OU, вначале применяются групповые политики более высоких уровней OU, а затем Ч OU низшего уровня.

Иногда на любом из уровней Active Directory может применяться свыше одной групповой политики. В этом случае порядок их применения определяется порядком, в котором объекты GPO перечислены в административном окне снизу вверх. На рисунке 11-7 показаны три групповые политики, применяемые к OU. Сначала будет применяться Scripts Policy (Политика сценариев), затем - Desktop Policy (Политика рабочих столов), а далее - Office Installation Policy (Политика инсталляции офиса).

Рис. 11-7. Несколько групповых политик, связанных с одним и тем же контейнером, применяются в порядке расположения в списке, снизу вверх Порядок применения групповых политик важен, если они изменяют одни и те же параметры настройки. Например, если объект GPO уровня домена удаляет команду Run со всех компьютеров, а объект GPO организационной единицы более низкого уровня добавляет команду Run, то команда Run будет доступна на всех компьютерах OU. Такой конфликт возникает, если две политики изменяют одну и ту же установку. Иуш объект GPO более высокого уровня может быть сконфигурирован для удаления команды Run, а объект GPO более низкого уровня Ч для удаления значка конфигурации с панели управления. Поскольку нет никакого конфликта между этими параметрами настройки, применятся обе настройки.

Большинство параметров настройки объекта GPO включает три опции конфигурации: Enabled (Включен), Disabled (Заблокирован) и Not Configured (He сконфигурировано). Если установлена опция Enabled, то независимо от того, какая групповая политика сконфигурирована, она будет применена. Если установлена опция Disabled, то независимо от того, какая групповая политика сконфигурирована, она будет заблокирована. Если установка была включена в объекте GPO, который применялся ранее, она все равно будет изменена на Disabled. Например, вы можете включить установку по удалению команды Run в объект GPO, связанный с OU высокого уровня.

Затем вы блокируете установку по удалению команды Run в OU более низкого уровня, после чего команда Run будет доступна для всех пользователей в OU низшего уровня. Если установлено Not Configured, параметры настройки политики не изменятся, и будут поддерживаться установки, унаследованные от более высокого уровня.

Изменение заданного по умолчанию способа применения групповых политик По умолчанию все групповые политики для учетных записей компьютеров и пользователей применяются в порядке Локальный/Сайт/Домен/ Организационная единица (Local/Site/Domain/Organizational Unit -LSDOU). В пределах контейнера каждый пользователь и компьютер будут затронуты групповой политикой. Однако в некоторых случаях этого происходить не должно, и вы можете сконфигурировать исключения к заданному по умолчанию способу применения групповых политик.

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

Структура большинства крупных предприятий слишком сложна для того, чтобы использовать заданное по умолчанию наследование. Например, вы можете создать проект OU, основанный на деловых подразделениях, потому что большинство пользователей одного и того же подразделения нуждаются в одинаковых параметрах настройки рабочего стола и в одинаковом наборе приложений. Однако некоторые пользователи могут быть частью группы, пересекающей границы отдела для участия в постоянных или специфических проектах. Остальные отделы могут иметь свои требования к набору программ, так что пользователю необходим доступ к обоим наборам приложений. Такие сложные конфигурации являются стандартными для большинства предприятий, поэтому Active Directory Windows Server 2003 обеспечивает возможность изменения заданного по умолчанию способа применения групповых политик.

Модификация способа наследования групповых политик Есть два способа изменить заданное по умолчанию наследование групповой политики. Первый вариант состоит в блокировании наследования политики на контейнерном уровне. Для этого щелкните правой кнопкой мыши на контейнере, в котором вы хотите изменить наследование, и выберите Properties (Свойства). Щелкните на вкладке Group Policy (Групповая политика) и отметьте флажок Block Policy Inheritance (Блокировать наследование политики) (см. рис. 11-8).

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

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

Рис. 11 -8. Блокирование наследования групповой политики на уровне 0U Предостережение. Одно из ограничений блокировки наследования групповых политик состоит в том, что после выбора блокировки все наследование групповой политики будет блокировано. Нет никакого способа выборочно блокировать наследование только определенных групповых политик.

Второй способ изменять заданное по умолчанию наследование групповых политик состоит в использовании опции No Override (He подменять). Эта опция используется для предписания применения групповой политики даже в тех контейнерах, в которых установлена опция блоки- ровки наследования групповой политики. Чтобы сконфигурировать групповую политику, не подлежащую отмене, найдите контейнерный объект, с которым связана данная групповая политика, а затем откройте окно Properties (Свойства) этого контейнера. Выберите вкладку Group Policy, выберите политику группы, щелкните на кнопке Options и выберите опцию No Override (см. рис. 11-9).

Рис. 11-9. Конфигурирование опции No Override для групповой политики Опция No Override может быть полезна, когда ваша групповая политика применяется ко всем пользователям независимо от того, где они расположены. Например, вы можете использовать групповые политики для управления антивирусным программным обеспечением на всех компьютерах-клиентах вашей организации. В этом случае нужно выбрать контейнер высокого уровня, содержащий все компьютеры вашего домена, и применить политику на этом уровне. Затем сконфигурируйте групповую политику опцией No Override, чтобы параметры настройки применялись ко всем компьютерам клиентам.

Опция No Override устанавливается в том месте, где объект GPO связывается с контейнером, а не в самом объекте GPO. Если вы связываете объект GPO с несколькими местами вашего домена и конфигурируете одну из связей с применением опции No Override, другие связи не будут сконфигурированы с этой опцией автоматически. Опция No Override устанавливается применительно к одному объекту GPO, т.е. ее установка на одном объекте GPO, связанном с OU, не затрагивает опцию No Override для других объектов GPO, связанных с этой же OU.

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

Фильтрация применения групповой политики Третий способ изменения наследования групповых политик состоит в фильтрации применений групповых политик с помощью групп Active Directory. По умолчанию при создании групповой политики она применяется ко всем пользователям и компьютерам в контейнере. Рассмотрите вкладку Security (Безопасность) для недавно созданной групповой политики. Как показано на рисунке 11-10, вкладка Security для всех объектов GPO сконфигурирована так, что группа Authenticated Users (Удостоверенные пользователи) имеет разрешения Read (Чтение) и Apply Group Policy (Применение групповой политики). Поэтому все удостоверенные пользователи, включая и компьютеры, и пользователей, будут затронуты этой политикой.

Можно изменить воздействие групповой политики на компьютер или пользователя, модифицируя установку разрешения Apply Group Policy для учетных записей. Для этого сначала удалите группу Authenticated Users с вкладки Security или очистите флажок Apply Group Policy. Затем добавьте соответствующие учетные записи к списку управления доступом (ACL) и предоставьте им разрешения Read и Apply Group Policy. Можете изменить разрешения, добавляя какого-либо участника безопасности, но наилучшая практика состоит в том, чтобы всегда использовать группы Active Directory вместо учетных записей индивидуальных пользователей или компьютеров.

Рис. 11-10. Конфигурирование вкладки Security(Безопасность) в окне Properties (Свойства) объекта GPO для изменения области применения объекта GPO Совет. Можно использовать группы для фильтрации применения групповых политик, но нельзя применять групповые политики к группам. Например, если вы связываете групповую политику с контейнером, который содержит глобальную группу, но не содержит учетные записи пользователей, являющихся членами глобальной группы, групповые политики будут неэффективны. Пользовательские и компьютерные учетные записи должны находиться в контейнерном объекте, чтобы применялась групповая политика.

Опция, предназначенная для применения групповых политик к выбранной группе, полезна во множестве различных сценариев. Например, вы планируете установить специфический пакет программ для группы пользователей, учетные записи которых рассеяны в различных OU по всему домену. Чтобы инсталлировать приложение, используя групповые политики, свяжите объект GPO с контейнерным объектом, который содержит учетные записи пользователей, а затем измените защиту GPO-объекта так, чтобы групповая политика применялась только к указанной группе.

Другим примером является ситуация, когда имеется объект GPO, который назначен определенной OU, но вы не хотите, чтобы этот объект применялся ко всем пользователям этой OU. В этом случае вы можете, во-первых, создать группу, содержащую учетные записи пользователей, которым требуется данная групповая политика, и сконфигурировать разрешение Apply Group Policy только для этой группы. Во-вторых, вы можете создать группу, которая содержит все учетные записи пользователей, которым не требуется данная групповая политика, и использовать установку Deny (Запретить) на разрешении Apply Group Policy (Применить групповую политику) для гарантии того, что групповая политика не будет применяться к этим пользователям.

Совет. Если вы удаляете разрешение Apply Group Policy для группы, вы должны также удалить Read Access (Доступ для чтения). Если этого не сделать, то групповая политика будет читаться каждый раз при запуске компьютера и входе в систему членов группы, даже если она не применяется, и это окажет вредное воздействие на процессы запуска системы.

Совет. Active Directory Windows Server 2003 обеспечивает опцию фильтрации применения групповых политик, основанную на фильтрах Windows Management Instrumentation (Аппаратура управления Windows) (WMI). Фильтры WMI, написанные на языке WMI-запросов, могут использоваться для более точного определения групповых политик, применяемых к компьютеру.

Например, можно использовать эту опцию для указания того, что пакет программ должен устанавливаться только на компьютере, имеющем более 200 Мб доступного дискового пространства, или на компьютере, имеющем более 64 Мб оперативной памяти. Подробности смотрите в Центре справки и поддержки (Help And Support Center) и в комплекте WMI Software Development Kit на веб-сайте Microsoft по адресу // msdn.microsoft.com/ library/default.asp?url=/library/en-us/wmidsk/wmi/ wmi_start_page.asp.

Применение групповых политик к пользователям и компьютерам Можно сконфигурировать групповую политику так, чтобы она применялась только к компьютерам или только к пользователям, а не к тем и другим. Чтобы сделать это, обратитесь к окну Properties (Свойства) объекта GPO (см. рис. 11-11), в котором можно отключить или компьютерные параметры настройки конфигурации, или пользовательские.

Рис. 11-11. Отключение компьютерных параметров настройки конфигурации для объекта GPO Совет. Использования большинства опций, обсуждаемых в этом разделе и изменяющих заданное по умолчанию применение групповых политик, следует избегать, так как это может привести к сложной конфигурации групповых политик, с которой трудно работать. Опция, позволяющая применять групповые политики только к пользователям или только к компьютерам, используется чаще. В большинстве случаев групповые политики конфигурируются либо для тех, либо для других, но не для обоих одновременно.

Отключение групповых политик Еще одна опция, которую можно использовать для изменения области приложения групповых политик, состоит в отключении групповой политики. Чтобы сделать это, обратитесь к окну Properties (Свойства) объекта GPO и выберите Options (Опции) (см. рис. 11-9). Путем отключения групповой политики можно предотвращать ее применение без необходимости изменять другие параметры настройки. Например, у вас есть групповая политика, которую требуется применять лишь время от времени, или групповая политика, которая находится в экспериментальной стадии.

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

Обработка групповой политики Теперь, когда вы знаете, как создавать объекты GPO и связывать их с контейнерами в пределах Active Directory Windows Server 2003, следующий шаг состоит в понимании того, как на самом деле групповые политики применяются к компьютерам. Когда компьютер запускается и пользователь входит в систему, происходит применение групповых политик следующим образом.

1. Во время запуска компьютера клиента считывается системный реестр и определяется сайт, в котором расположен компьютер. Компьютер посылает запрос DNS-серверу, запрашивая IP-адреса контроллеров домена, расположенных в этом сайте.

2. Получив ответ DNS-сервера, компьютер клиента соединяется с контроллером домена в своем сайте. В процессе опознания, проводимом контроллером домена, компьютер клиента запрашивает список всех GPO-объектов, которые применяются к компьютеру.

3. Контроллер домена присылает клиенту список всех GPO-объектов в том порядке, в котором политики должны применяться. Затем компьютер извлекает объект GPO с контроллера домена и применяет политику. Порядок, в котором применяются групповые политики, основан на LSDOU-конфигурации.

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

Совет. Групповые политики применяются к клиентам с операционной системой Windows XP асинхронно, а с системой Windows 2000 - синхронно, т.е. все компьютерные политики полностью применяются до того, как появится пользовательский экран входа в систему, а все пользовательские политики - до того, как по- явится рабочий стол пользователя. Асинхронное применение политик означает, что загрузка системы Windows XP и вход пользователей в систему происходит более быстро.

Вы можете использовать групповые политики для модификации применения других групповых политик. Опции конфигурации устанавливаются в папках UserConfiguration\Administrative Templates\System\ Group Policy или Computer Configuration\Administrative Templates\ System\Group Policy. На рисунке 11-12 показаны опции, имеющиеся в ветви Computer Configuration дерева папок.

Рис. 11-12. Опции конфигурации групповой политики Групповые политики применяются при запуске компьютера при входе пользователя в систему.

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

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

Чтобы определить, используется ли медленное сетевое подключение, компьютер посылает пакет утилиты ping с нулевым байтом контроллеру домена. Если время ответа составляет меньше десяти миллисекунд, то сеть считается быстрой, и применяются все групповые политики. Если время ответа составляет больше десяти миллисекунд, компьютер про-званивает контроллер домена три раза с помощью утилиты ping с двух-килобайтными пакетами. Компьютер усредняет времена ответов и использует это усредненное значение для определения сетевой скорости связи. Ecjfti пропускная способность сетевого подключения составляет большее 500 Кб/с, то по умолчанию применяются все групповые политики. Если компьютер обнаруживает сетевое подключение, скорость которого меньше 500 Кб/с, то применяются только политики с параметрами настройки защиты и административными шаблонами.

Можно изменить заданное по умолчанию определение медленной связи. Оно может быть сконфигурировано для компьютеров в папке Computer Conf iguration\Administrative Templates\System\Group Policy. Щелкните правой кнопкой мыши на Group Policy Slow Link Detection (Обнаружение медленной связи для групповых политик) и выберите Properties (Свойства) (см. рис. 11-13). Для изменения значения скорости передачи для медленной связи выберите Enabled (Включено), а затем введите значение, которое вы хотите использовать.

Рис. 11-13. Конфигурирование параметров медленной связи Если компьютер обнаруживает медленное сетевое подключение, то по умолчанию обрабатываются только компоненты защиты и административных шаблонов, и нет никакого способа выключить эти параметры настройки. Однако вы можете сконфигурировать другие параметры так, чтобы они обрабатывались даже по медленному сетевому подключению. Папка Computer Conf iguration\Administrative Templates\System\Group Policy содержит и другие опции.

Например, вы решите применить обработку политики обслуживания программы Internet Explorer по медленному сетевому подключению. Щелкните правой кнопкой мыши на этой установке в папке Group Policy (Групповая политика) и выберите Properties. Затем щелкните Enabled (Включено) и выберите, как вы хотите применять эту политику (см. рис. 11-14).

Рис. 11-14. Конфигурирование обработки политики обслуживания программы Internet Explorer по медленным сетевым подключениям Чтобы применять эту политику независимо от сетевой пропускной способности, выберите Allow Processing Across A Slow Network Connection (Разрешить обработку по медленному сетевому подключению). Другие параметры настройки задают, будут ли параметры настройки обрабатываться каждый раз, когда обновляется групповая политика, и будет ли политика применяться в случае, если она не была изменена.

Второй способ изменения применения объекта GPO на компьютере состоит в использовании опции loojpback. Эта опция изменяет заданное по умолчанию применение групповых политик, при котором сначала устанавливается компьютерная политика, а затем политика пользователя, переписывая все параметры настройки, противоречащие компьютерной политике. Вы можете установить политику loopback, чтобы компьютерная политика применялась последней и переписывала все политики, примененные к пользователю. Групповая политика loopback устанавливается с помощью опции User group Policy Loopback Processing Mode (Режим Loopback для пользовательских групповых политик) в контейнере Computer Configuration\Administrative Templates\System\ Group Policy (см. рис. 11-15).

Рис. 11-15. Конфигурирование обработки loopback для групповых политик Когда вы разрешаете обработку loopback, вам предоставляются две дополнительные опции конфигурации. Первая опция Merge (Соединить) означает, что сначала применяется компьютерная групповая политика, затем Ч пользовательская групповая политика, а затем компьютерная групповая политика применяется снова. Некоторые из пользовательских параметров настройки могут не изменяться компьютерной политикой. Переписываются только противоречивые параметры настройки. Вторая опция Replace (Заменить) означает, что будет обработана только компьютерная политика.

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

Делегирование администрирования объектов GPO Как говорилось в главе 9, одним из основных преимуществ Active Directory является функция делегирования многих административных задач в пределах организации. Управление групповыми политиками не является исключением - вы можете делегировать управление этим важным административным инструментом.

Имеются три опции, позволяющие делегировать администрирование групповыми политиками. С помощью первой опции можно делегировать разрешение создавать, удалять и изменять объекты GPO. По умолчанию это право имеют только члены групп Domain Admins (Администраторы домена) и Group Policy Creator Owners (Владельцы-создатели групповой политики). Группа Group Policy Creator Owners имеет дополнительное ограничение, состоящее в том, что члены этой группы имеют разрешение изменять параметры настройки только той групповой политики, которую они создавали сами. Если вы создаете в своей организации специальную группу администраторов, которые будут управлять групповой политикой, вы можете добавить этих администраторов к одной из групп. Вы можете предоставить право создавать и удалять групповые политики любой другой группе, но предоставить разрешения создавать или удалять объекты GPO сложнее, чем большинство сценариев делегирования разрешений. Вы должны дать пользователю разрешение создавать в Active Directory объекты GPO и разрешение записывать данные в папку %systemroot%\Sysvol\domainname\ Policies, в которой хранятся объекты GPT. Вы можете дать пользователям или группам разрешение изменять определенные объекты GPO, предоставляя им разрешения Read (Чтение) и Write (Запись) для объектов GPO.

Вторая опция позволяет делегирбвать права управления связями групповой политики. Эта опция не разрешает изменять какой-либо объект GPO, но позволяет добавлять или удалять связи объектов GPO с контейнерным объектом. Самый простой способ состоит в использовании Delegation Of Control Wizard (Мастер делегирования управления). В инструменте Active Directory Users And Computers (Пользователи и компьютеры Active Directory) щелкните правой кнопкой мыши на объекте, для управления которым вы хотите назначить другого пользователя или группу, а затем щелкните Delegate Control (Делегировать управление), чтобы запустить мастер. При запуске мастера на уровне OU одной из стандартных задач делегирования является разрешение на управление связями групповой политики (см. рис. 11-16).

Третий способ делегирования состоит в предоставлении пользователям права генерировать информацию Resultant Set of Policy (RSoP) (Ре- зультирующий набор политик). Используйте Delegation Of Control Wizard для предоставления права генерировать инструмент RSoP в режиме регистрации или планирования (см. рис. 11-16).

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

Рис. 11-16. Делегирование разрешений на управление связями групповой политики Реализация групповых политик, действующих в нескольких доменах и лесах Вы можете использовать групповые политики Windows Server 2003 для предписания применения политик, действующих в нескольких доменах и доверенных лесах. В обоих случаях имеются некоторые проблемы, с которыми вы столкнетесь перед осуществлением такой групповой политики.

После создания объекта GPO в Active Directory Windows Server 2003 вы можете связать его с любым сайтом, доменом или OU. Основное ограничение состоит в том, что объекты GPO хранятся только на контроллерах домена в том домене, где был создан объект GPO. Если вы захотите связать объект GPO с контейнером, расположенным в другом домене, вы столкнетесь с проблемами защиты и использованием пропускной способности сети. К примеру, все компьютеры в OU должны иметь возмож- ность соединяться с контроллером домена, расположенном в исходном домене GPO, для загрузки групповой политики. Если один из контроллеров домена находится в том же сайте, где и компьютеры-клиенты, это не очень сильно отразится на пропускной способности сети. Однако если все контроллеры домена, имеющие копию GPO объекта, находятся в другом сайте, соединенным медленным WAN-подключением, то применение групповой политики будет происходить очень медленно и может серьезно воздействовать на пропускную способность. Кроме того, если пользователи, принадлежащие одному домену, должны применять групповую политику, созданную в другом домене, то пользователи и компьютеры, принадлежащие домену адресату, должны иметь разрешение Read к объектам GPC в Active Directory и к объектам GPT в папке Sysvol. В большинстве случаев наилучшей практикой является создание объектов GPO в каждом домене вместо совместного использования одного объекта GPO в нескольких доменах.

Те же проблемы возникают при использовании групповых политик, действующих в нескольких лесах. В Active Directory Windows Server 2003 имеется опция, предназначенная для совместного использования групповых политик доверенными лесами. Она полезна в том случае, когда пользователи путешествуют между различными офисами компании, находящимися в отдельных лесах. В этом случае к пользователю, вошедшему на компьютер в другом лесу, могут применяться групповые политики его домашнего домена. Другие функциональные возможности, доступные нескольким лесам, включают следующее.

Х Ресурсы, используемые для распределения программного обеспечения, могут находиться в различных лесах.

Х Сценарии входа в систему могут располагаться на контроллере домена другого леса и читаться оттуда.

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

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

Инструментальные средства управления групповыми политиками Групповые политики обеспечивают большое количество возможностей и гибкость для управления компьютерами клиента и серверами. До сих пор в этой главе рассказывалось только об одном из инструментов управления групповыми политиками - редакторе Group Policy Object Editor. В этом разделе будут представлены другие средства.

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

Инструмент RSoP может использоваться в двух режимах: в режиме регистрации и планирования.

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

Чтобы использовать инструмент RSoP, создайте собственную ММС-консоль и добавьте оснастку Resultant Set of Policy (Результирующий набор политик). Затем щелкните правой кнопкой мыши на Resultant Set Of Policy и выберите Generate RSoP Data (Сгенерировать данные RsoP). Resultant Set Of Policy Wizard даст вам возможность выполнить инструмент в одном из двух режимов. В режиме регистрации вы выбираете компьютер и пользователя. Затем инструмент вычисляет все параметры настройки групповых политик, которые применяются к ним. Вместе с каждой установкой инструмент определяет, какой объект GPO поставляет фактическую информацию для этой установки.

В режиме планирования вы выбираете пользователя, компьютер, или то и другое;

контейнерный объект для пользовательской или компьютерной учетной записи, или для обоих (см. рис. 11-17).

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

Рис. 11-17. Выбор объектов пользователя и компьютера в режиме планирования в инструменте RSoP Инструмент GPResult GPResult - это инструмент командной строки, обеспечивающий часть функциональных возможностей инструмента RSoP. Если вы выполните команду Gpresult без каких-либо параметров, то получите информацию о групповой политике для компьютера, на котором вы выполнили команду, и для того пользователя, который вошел в систему. Информация включает групповые политики, применяющиеся к компьютерам, пользователям и группам, к которым принадлежит каэядый объект. Команда может выполняться в подробном режиме, т.е. результаты будут включать все фактические параметры настройки групповой политики, а также привилегии, которые имеет пользователь. Инструмент можно также выполнять с одного компьютера для анализа фактической групповой политики другого пользователя или компьютера. Инструмент GPResult установлен на всех компьютерах, на которых выполняются системы Windows XP Professional и Windows Server 2003. Полную информацию по инструменту GPResult смотрите в Центре справки и поддержки (Help And Support Center).

Инструмент GPUpdate Инструмент командной строки GPUpdate заменяет команду Secedit/ refreshpolicy, которая имеется в Active Directory Windows 2000. Она ис- пользуется для принудительного выполнения обновления групповых политик для компьютера или пользователя. Если вы напечатаете gpupdate в командной строке, то обновятся и компьютерная, и пользовательская групповые политики на местном компьютере. Инструмент используется также для обновления групповых политик на других компьютерах. Одно из преимуществ команды Gpupdate состоит в том, что эта команда может использоваться для выхода пользователей из системы или даже для перезапуска компьютера после обновления групповой политики, что полезно при обновлении групповых политик, которые применяются только при входе пользователя в систему или при перезапуске компьютера. Например, политики распределения программного обеспечения и политики переназначения папок применяются только при запуске компьютера или входе в систему. Используя параметры /logoff или /ЪФОГ, ВЫ можете вызвать применение этих политик в любое время.

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

Поэтому компания Microsoft разработала новый инструмент Ч консоль управления групповой политикой (GPMC - Group Policy Management Console) (см. рис. 11-18).

Рис. 11-18. GPMC является инструментом, предназначенным для управления всеми групповыми политиками Примечание. Во время написания этой книги компания Microsoft объявила, что инструмент GPMC будет доступен бесплатно вскоре после отправки покупателям Windows Server 2003.

Этот раздел основан на бета-версии 2 инструмента GPMC. Часть функциональных возможностей в заключительном выпуске может отличаться от тех, которые показаны здесь.

GPMC является отдельным инструментом, который используется для управления всеми конфигурациями групповых политик всей организации. В таблице 11-4 показаны все функциональные возможности инструмента GPMC.

Табл. 11 -4. Опции конфигурирования инструмента GPMC Функциональные Опции конфигурирования возможности GPO Settings Используются для конфигурирования всех (Параметры параметров настройки GPO.

настройки GPO) GPO Links (Связи Используются для просмотра и изменения всех GPO) мест, где объект GPO связан с контейнерными объектами.

GPO Delegation Используется для просмотра и изменения (Делегирование GPO) делегирования создания, удаления и модификации связей GPO объектов и разрешений на генерацию данных RSoP.

Security Filtering Используется для просмотра и модификации (Фильтрация защиты) всей фильтрации, основанной на группах безопасности.

RSoP Planning (RSoP Назван как Group Policy Modeling планирование) (Моделирование групповой политики), но использует мастер режима планирования в инструменте RSoP.

RSoP Logging (RSoP Назван как Group Policy Results (Результаты регистрация) групповой политики) , но использует мастер режиме регистрации в инструменте RSoP.

Modify Inheritance Используется для установки параметров (Изменить настройки No Override (He подменять) и Block наследование) Inheritance (Блокировка наследования).

Search (Поиск) Используется для поиска любых типов объектов, связанных с групповой политикой. Например, можное найти все объекты GPO, в которых включена опция Folder Redirection (Переназначение папки).

Backup And Restore Используется для резервного копирования и GPOs (Резервное восстановления индивидуальных объектов GPO копирование и или всех объектов GPO в домене. Без этого восстановление инструмента единственным способом резервного объектов GPO) копирования и восстановления объектов GPO является копирование данных состояния системы на контроллере домена.

Scripting Interface Инструмент GPMC представляет несколько (Интерфейс создания СОМ-объектов, которые могут использоваться сценариев) для написания сценариев управления групповыми политиками. Для получения дополнительной информации обратитесь в веб-сайту Microsoft по адресу www.microsoft.com/windowsserver2003/gpmc/ default.mspx.

Как видите, GPMC представляет собой мощный инструмент управления групповыми политиками в среде предприятия.

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

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

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

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

Другая проблема проектирования связана с тем, где вы хотите развернуть групповую политику.

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

Резюме Эта глава объясняет опции конфигурации групповых политик в Active Directory Windows Server 2003, создавая предпосылки для понимания последующих глав. В ней обсуждаются вопросы создания и управления групповыми политиками с помощью инструментов, поставляемых вместе с Windows Server 2003, вопросы наследования групповых политик и применения их к компьютерам клиентов. Вы можете использовать заданную по умолчанию модель наследования групповой политики, установленной высоко в иерархии OU, и получить параметры настройки GPO для многих объектов домена. Вы можете также изменить заданное по умолчанию наследование параметров настройки групповой политики, блокируя или фильтруя наследование. Главы 12 и посвящены тому, что вы фактически можете делать с групповой политикой. Глава 12 показывает, как использовать групповые политики при распространении программного обеспечения на компьютеры-клиенты, глава 13 Ч как использовать групповые политики для управления разнообразными опциями конфигурации рабочего стола.

Глава 12. Использование групповых политик для управления программным обеспечением В главе 11 был сделан краткий обзор основных функций групповых политик и способов развертывания и управления групповыми политиками в Adive Directory Microsoft Windows Server 2003. В этой главе обсуждается использование групповых политик для управления программным обеспечением на компьютерах клиентов, в главе 13 Ч пути управления рабочими столами пользователей.

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

Стандартному клиентскому компьютеру требуются также приложения для сжатия файлов и антивирусное программное обеспечение.

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

Использование групповых политик для управления программным обеспечением может значительно уменьшить усилия, которые требуются для управления пользовательскими рабочими столами. Фактически серьезное уменьшение затрат, получаемое от развертывания службы каталога Active Directory и групповых политик, находится в области управления программным обеспечением.

Управление программным обеспечением в корпоративной среде предполагает гораздо больше дел, чем его простое развертывание. Многие компании имеют четко определенный процесс управления жизненным циклом программ, который включает покупку (или создание) и испытание приложения в маленькой группе пользователей, затем крупномасштабное развертывание приложения, его обслуживание и, наконец, удаление. Групповые политики в Active Directory решают эти задачи более эффективно.

Pages:     | 1 |   ...   | 4 | 5 | 6 | 7 | 8 |    Книги, научные публикации