Active Directory и доменная система имен

Служба каталога Active Directory Microsoft Windows Server 2003 при поиске ресурсов в сети полностью полагается на доменную систему имен (DNS). Без надежной инфраструктуры DNS контроллеры домена в сети не смогут делать реплики друг с друга, клиенты Microsoft Windows 2000 и Microsoft Windows XP Professional не смогут входить в сеть, а серверы, на которых выполняется приложение Microsoft Exchange Server 2000, не смогут посылать электронную почту. По существу, если ваша реализация службы DNS нестабильна, то сеть Windows Server 2003 не будет работать. Это значит, что для управления средой Active Directory вы должны иметь глубокое знание концепций DNS и ее реализации в Windows Server 2003.

Данная глава начинается с краткого обзора DNS как службы. Далее подробно рассказывается, почему Active Directory зависит от DNS, и как работает процесс разрешения имен. Затем речь идет о службе DNS в системах Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition. В операционной системе Windows Server 2003 доменная система имен имеет свойства, которые делают весьма привлекательным развертывание Active Directory.

Примечание. Версия Windows Server 2003, Web Edition не требует и не поддерживает службу Active Directory.

Репликация Active Directory и сайты

Каждая компания, реализующая службу каталога Active Directory Microsoft Windows Server 2003, развертывает несколько контроллеров домена. Они могут располагаться в одном центре обработки данных в главном офисе компании и связываться высокоскоростными сетевыми соединениями. Они могут быть распределены по всему миру и использовать для связи глобальные сети (WAN). Некоторые компании имеют единственный домен в лесу, другие компании - много доменов в нескольких доменных деревьях в общем лесу.

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

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

Проектирование структуры Active Directory

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

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

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

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

Установка Active Directory

Процесс установки службы каталога Active Directory на компьютере, выполняющем Microsoft Windows Server 2003, несложен. Простота обеспечивается за счет прекрасного мастера инсталляции Active Directory. Когда служба Active Directory устанавливается на сервер с Windows Server 2003, компьютер фактически становится контроллером домена. Если это первый контроллер домена в новом домене и лесу, то создается чистая база данных каталога, ожидающая поступления объектов службы каталога. Если это дополнительный контроллер домена в уже существующем домене, процесс репликации скоро размножит на этот новый контроллер домена все объекты службы каталога данного домена. Если это контроллер домена, имеющий модернизированную систему Microsoft Windows NT4, база данных учетных записей будет автоматически обновлена до Active Directory после того, как на этом контроллере домена будет установлен Windows Server 2003.

В этой главе приведена информация, необходимая для успешного выполнения Active Directory Installation Wizard (Мастер инсталляции Active Directory), а также обсуждаются два других метода установки Active Directory: инсталляция без помощи мастера и установка из восстановленных резервных файлов. В конце главы обсуждается процесс удаления Active Directory с контроллера домена.

Переход к Active Directory

В Главе 6 рассказывалось, какие ключевые решения вы должны были принять при установке службы каталога Active Directory на компьютере серверного класса. Для простоты понимания предполагалось, что ваша среда представляла «чистое поле», т.е. в ней ранее не существовало инфраструктуры службы каталога. В главе б подчеркивалась важность пространства имен Active Directory и пространства имен DNS. На самом деле «чистая» среда будет встречаться не очень часто. Скорее всего, организация, которая переходит к Active Directory Microsoft Windows Server 2003, уже имеет некоторые службы каталога. В этой главе показан переход к Active Directory Windows Server 2003 от существующей службы каталога Microsoft, точнее, переход от управления безопасными учетными записями (SAM) системы Microsoft Windows NT 4 или от Active Directory Microsoft Windows 2000. Сценарии перехода с технологий службы каталога, не принадлежащих Microsoft, типа Novell Directory Services (NDS) или NetWare 3 Bindery, или реализаций службы каталога на платформе UNIX, в данную главу не вошли.

Дополнительная информация. Веб-сайт компании Microsoft содержит много информации, касающейся перехода на Windows Server с других платформ. Для получения дополнительной информации о переходе из сред UNIX или Linux смотрите раздел веб-сайта Windows «Migrating to Windows from UNIX and Linux (Переход к Windows от UNIX и Linux)» по адресу http:// www.microsoft.com/windows2000/migrate/unix/default.asp. Для получения дополнительной информации о переходе от Novell системы Netware смотрите раздел «NetWare to Windows 2000 Server Migration Planning Guide (Руководство по планированию перехода с NetWare на Windows 2000 Server)» по адресу http:// www.microsoft.com/windows2000/techinfo/planning/ incremental/netmigrate.asp. Для получения полной информации о переходе к Windows Server 2000, а также по технологии серверов Windows, смотрите документ «Переход к Windows» по адресу http://www.microsoft.com/windows2000/migrate/.

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

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

Обратите внимание, что если нет специального ограничения, то ссылки на Windows 2000 Server включают Windows 2000 Server, Windows 2000 Advanced Server и Windows 2000 Datacenter Server.

Защита Active Directory

Одна из основных причин развертывания службы каталога Active Directory состоит в обеспечении безопасности корпоративной сети. Каждая компания хранит важнейшую для своего бизнеса информацию на файловых серверах в сети. Управление безопасным доступом к информации должно гарантировать, что доступ к данным получат только должным обраЗЬм уполномоченные пользователи. Почти все компании развертывают почтовые серверы типа Microsoft Exchange 2000 Server, и они должны гарантировать пользователям безопасный доступ к почтовым ящикам. Служба Active Directory Microsoft Windows Server 2003 обеспечивает такой уровень защиты.

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

Делегирование администрирования службы Active Directory

Как говорилось в предыдущих главах, служба Active Directory операционной системы Microsoft Windows Server 2003 больше не поддерживает единое неструктурированное пространство имен, которое использовалось в доменах Microsoft Windows NT. Вместо этого она обеспечивает иерархическое представление каталога, сначала через иерархию доменной системы имен (DNS) множества доменов, а затем через структуру организационных подразделений (OU) в пределах доменов. Эта иерархия создает важную административную возможность: делегирование административных разрешений. В доменах Windows NT такой возможности не было. Разрешения, полученные в одной части домена, действовали повсюду в домене. Теперь это полностью изменилось. Служба Active Directory Windows Server 2003 имеет мощные опции для управления разрешениями и делегирования административных задач в пределах домена.

Данная глава построена на обсуждении безопасности Active Directory, начатой в главе 8. Глава начинается с повторного рассмотрения защиты Active Directory с целью уточнения списков управления доступом (ACL) на объектах Active Directory. После этого в главе обсуждается делегирование прав. Для делегирования разрешений вы можете напрямую обращаться к спискам ACL индивидуальных объектов. Для назначения разрешений служба Active Directory Windows Server 2003 имеет.также Delegation Of Control Wizard (Мастер делегирования управления).

Управление объектами 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.

Введение в групповые политики

Одна из типичных тем разговора среди людей, оплачивающих установку инфраструктуры корпоративной информационной технологии (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.

Использование групповых политик для управления программным обеспечением

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

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

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

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

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

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

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

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

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

ющие правильное функционирование. Можно также использовать групповые политики для централизованного конфигурирования многих параметров настройки рабочих станций вашей компании.
Практический опыт. Индивидуальные предпочтения против централизованного управления компьютерными рабочими столами
В большинстве случаев управление рабочими столами пользователей требует равновесия между централизованным управлением компьютерами и удовлетворением потребностей пользователей, которые хотят иметь полный контроль над своими рабочими столами. Если реализовать все опции управления, обсуждаемые в этой главе, можно полностью блокировать пользовательские рабочие столы, чтобы пользователи гарантировано не смогли сделать никаких неправомочных изменений. Многие администраторы думают, что предоставление пользователям возможности изменять параметры настройки означает только то, что они сконфигурируют что-либо неправильно, и это приведет к увеличению объема работы для администратора. Многие пользователи, с другой стороны, во всех попытках управления их рабочими столами видят вторжение в их личное пространство. С точки зрения пользователя рабочая станция является частью индивидуальной рабочей среды, и любые попытки управления этой рабочей средой вызывают решительное сопротивление.
Решение о правильном балансе между централизованным управлением рабочими столами и контролем их со стороны конечного пользователя в разных компаниях различно. Некоторые компании уже имеют опыт использования системной политики в Microsoft Windows NT 4 или групповых политик в Active Directory Microsoft Windows 2000, и их конечные пользователи уже приучены к некоторому уровню блокирования рабочего стола. В таких компаниях можно вводить новые ограничения без особого беспокойства. Однако во многих компаниях раньше не существовало никаких ограничений, поэтому первая же попытка реализовать ограничение вызовет активное сопротивление.
Для большинства компаний наилучшим подходом к управлению рабочими столами является медленный старт и создание благоприятного первого впечатления. Это означает, что вы используете групповые политики для решения проблем, раздражающих конечных пользователей. Если вы покажете конечным пользователям, что управление рабочими столами фактически сделает их работу более легкой, они более охотно согласятся на дополнительное управление. С другой стороны, если первые результаты вызовут сотни звонков в сервисный отдел, то вы лишитесь поддержки для реализации любого управления рабочими столами. Другим важным компонентом для успешной реализации групповых политик является помощь со стороны управленческого аппарата. В боль-
шинстве компаний дирекция идет навстречу всему, что уменьшает стоимость управления рабочими станциями. Если вы сумеете доказать, что уменьшение стоимости работ является конечным результатом вашей реализации управления рабочими столами, то вы наверняка получите поддержку дирекции в улаживании жалоб, поступающих от конечных пользователей, не желающих, чтобы их рабочими столами управляли.

Мониторинг и обслуживание Active Directory

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

Восстановление службы каталога в случае сбоя

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

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

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

Групповые политики и проект OU

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

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

Хозяева операций

Active Directory разработана как система репликации с несколькими хозяевами. Для этого требуется, чтобы все контроллеры домена имели разрешения делать запись в базу данных каталога. Эта система удовлетворительно работает для большинства операций каталога, но для некоторых операций требуется наличие единственного официального (authoritative) сервера. Контроллеры домена, выполняющие определенные роли, известны как хозяева операций; все они выполняют роли FSMO (Flexible Single Master Operations — гибкие операции с одним хозяином). Существует пять ролей хозяев операций в Active Directory:

хозяин схемы;

хозяин именования доменов;

хозяин относительных идентификаторов RID;

хозяин эмулятора PDC (Primary Domain Controller — основной контроллер домена);

хозяин инфраструктуры.

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

Хозяин именования доменов

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

Домены добавляются к лесу одним из способов, которые требуют подключения удаленного вызова процедуры (RPC) к домену, исполняющему роль хозяина именования доменов. Наиболее распространенный метод создания нового домена состоит в выполнении Dcpromo.exe в командной строке, которая запускает мастер инсталляции Active Directory. Во время этого процесса вы получаете возможность установить первый контроллер домена в новый домен. Dcpromo.exe войдет в контакт с хозяином именования домена для того, чтобы сделать это изменение. Если хозяин операции именования доменов недоступен, то создание домена окончится неудачей. Добавить новый домен можно также с помощью утилиты Ntdsutil. Эта утилита создает объект перекрестной ссылки в контейнере разделов в разделе конфигурации каталога, который затем реплицируется на все контроллеры домена в лесу. Далее создание домена можно выполнять с помощью Dcpromo.exe без необходимости входить в контакт с хозяином именования доменов.

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

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

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

Хозяин инфраструктуры

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

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

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

Хозяин эмулятора PDC

Роль эмулятора PDC требуется для того, чтобы Windows Server 2003 мог сосуществовать с контроллерами домена, на которых выполняются более ранние версии, чем Windows 2000. В домене, работающем на функциональном уровне Windows 2000 mixed (смешанный), контроллер домена с Windows Server 2003 действует как основной контроллер домена (PDC) для всех низкоуровневых (Microsoft Windows NT версий 4 или 3.51) резервных контроллеров домена (BDC — Backup Domain Controller). В такой среде требуется эмулятор PDC для обработки изменений пароля, реплицирования изменений домена на BDC-домены и выполнения службы главного браузера домена (Domain Master Browser Service). Если эмулятор PDC недоступен, все события, связанные со службами, инициированными низкоуровневыми клиентами, окончатся неудачей.

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

Хозяин относительных идентификаторов

Хозяин относительных идентификаторов (RID) - это роль хозяина операций в пределах домена. Она используется для управления RID-пулом, предназначенным для создания новых участников безопасности в пределах домена, таких как пользователи, группы и компьютеры. Каждый контроллер домена производит блок относительных идентификаторов (RID), использующихся для построения идентификаторов защиты (SID), которые однозначно идентифицируют участников безопасности в домене. Блок доступных идентификаторов RID называется RID-пулом. Когда количество доступных RID-идентификаторов в RID-пуле на любом контроллере домена в домене начинает истощаться, делается запрос на другой RID-блок у хозяина RID-идентификаторов. Работа хозяина RID-идентификаторов заключается в выполнении таких запросов и обеспечении того, чтобы никакой RID-идентификатор не был выделен более одного раза. Этот процесс гарантирует каждой учетной записи в домене уникальную защитную особенность.

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

Хозяин RID

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

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

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

Хозяин схемы

Хозяин схемы является единственным контроллером домена, который имеет разрешение делать записи в схему каталога. Чтобы сделать любое изменение в схеме каталога, администратор (он должен быть членом группы безопасности Schema Admins — Администраторы схемы) должен связаться с хозяином схемы. Если модификация схемы предпринята на контроллере домена, не являющемся хозяином схемы, она окончится неудачей. После того как было сделано изменение, модификации схемы копируются на остальные контроллеры домена в лесу.

По умолчанию первый контроллер домена, установленный в лесу (контроллер домена для корневого домена леса) принимает роль хозяина схемы. Эта роль может быть передана другому контроллеру в любое время с помощью оснастки Active Directory Schema (Схема Active Directory) или с помощью утилиты командной строки Ntdsutil. Хозяин схемы идентифицирован значением атрибута fSMORoleOwner в контейнере схемы.

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

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

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

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

Хранилище данных каталога

Все данные базы данных службы Active Directory хранятся в отдельном файле Ntds.dit на контроллере домена. Этот файл данных по умолчанию находится в папке %SystemRoot%\NTDS, расположенной на контроллере домена. В нем хранится вся информация каталога, предназначенная для данного домена, а также данные, являющиеся общими для всех контроллеров домена в данной организации.

Вторая копия файла Ntds.dit находится в папке %SystemRoot%\ System32. Эта версия файла - поставляемая копия (копия, заданная по умолчанию) базы данных каталога, она используется для установки службы Active Directory. Этот файл копируется на сервер во время установки Microsoft Windows Server 2003, чтобы сервер можно было назначать контроллером домена без необходимости обращаться к инсталляционной среде. Во время выполнения мастера инсталляции Active Directory (Dcpromo.exe) файл Ntds.dit копируется из папки System32 в папку NTDS. Затем копия, сохраненная в папке NTDS, становится действующей копией хранилища данных каталога. Если это не первый контроллер домена в домене, то файл будет обновлен из других контроллеров домена через процесс репликации.

Идентификация учетных записей служб

Учетные записи служб - это специальные учетные записи пользователей, которые используются для оперирования службами, выполняющимися на компьютерах с системами Windows NT 4 и Windows Server 2003. Большинство служб работают под учетной записью Local System Authority (LSA) (Власти локальной системы). При модернизации домена ресурсов сначала нужно идентифицировать службы, сконфигурированные так, чтобы не выполняться под учетной записью LSA.

Модернизация учетных записей служб состоит из двух этапов. Сначала нужно идентифицировать учетные записи служб. После перемещения компьютеров, на которых выполняется система Windows NT 4, в целевой домен с Windows Server 2003 можно переносить учетные записи идентифицированных служб.

Чтобы идентифицировать учетные записи служб, работающих на исходных доменах с Windows NT 4, используя инструмент ADMT, выполните следующие действия:

Откройте Service Account Migration Wizard (Мастер модернизации учетных записей).

Выберите исходный и целевой домены.

В исходном домене выберите все компьютеры, на которых нужно найти учетные записи служб. Чтобы выполнить эту задачу, вы должны посмотреть документацию, касающуюся среды домена, которая существовала до модернизации. 4.  Завершите выполнение Service Account Migration Wizard.

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

Иерархическое пространство имен

DNS использует иерархическое пространство имен для поиска компьютеров. На рисунке 3-1 показан пример организации пространства имен. Корневой домен обозначается точкой («.»). Он представляет собой верхний уровень DNS, остальное пространство имен располагается ниже. На следующем уровне под корневым доменом располагаются домены первого уровня, включая семь основных (generic) доменных имен (com, edu, mil, net, org), около двухсот сокращений названий стран (са, uk, fr, br), семь новых доменов (biz, info, pro и т.д.), которые были введены в 2001 году.

Рис. 3-1. Иерархическое пространство имен DNS

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

Другим способом представления иерархического пространства имен является полностью определенное имя домена (FQDN — Fully Qualified Domain Name), например, www.NAmerica.Contoso.com. FQDN представ-

ляет собой полное имя, которое можно использовать для идентификации определенного компьютера в пределах всего пространство имен DNS. Чтобы понять, как FQDN идентифицирует компьютер в пространстве имен DNS, прочтите его справа налево. Справа находится точка («.»), которая идентифицирует корневой домен, она предшествует имени домена первого уровня. За ней следуют домен com первого уровня, домен Contoso второго уровня и поддомен NAmerica. Слева в имени FQDN находится www - имя определенного компьютера.

определяет то, как объекты сохраняются

Стандарт пространства имен Х.500 (namespace) определяет то, как объекты сохраняются в Active Directory. Пространство имен Х.500 представляет собой иерархическую структуру имен, которая идентифицирует уникальный путь к контейнеру службы каталога. Он обеспечивает также уникальный идентификатор для каждого объекта в этом контейнере. Используя имя в стандарте Х.500 или идентификатор объекта (OID -Object Identifier), все объекты во всех структурах службы каталога могут быть уникально идентифицированы. Служба каталога Active Directory основана на стандарте Х.500, и Microsoft включил в нее все основные (или оригинальные) заданные стандартом классы.

Этот пространство имен можно представлять или в точечной (dotted), т.е. числовой нотации, или в строковой (string). Например, идентификатор Х.500 OID, равный 2.5.4.10, является эквивалентом атрибута Organization-Name (Название организации) (с отображаемым LDAP-именем - «о»). Числовое представление класса этого объекта уникально

идентифицирует его в пределах иерархии Х.500, и таким образом объект становится уникальным. Объекты Active Directory могут быть также уникально идентифицированы с помощью строковой нотации Х.500, известной также как каталог взаимодействия открытых систем (OSI - Open Systems Interconnection). В строковой нотации пользовательский объект может быть представлен как:

cn=Karen Friske, cn=Users, dc=Contoso, dc=com

Чтобы удовлетворить требованию уникальности в пространстве имен Х.500, в контейнере Users (Пользователи) в домене Contoso.com может быть только одно имя Karen Friske. Однако могут существовать другие учетные записи пользователя Карен Фриск в организации Contoso. Имя Х.500 включает название контейнера, в котором найдена учетная запись пользователя (типа OU), и дает возможность названию учетной записи пользователя быть уникальной. Строковое представление пространства имен Х.500 определено в документе Request for Comments (RFC) 1779, который доступен на сайте http://www.faqs.org/rfcs/rfcl779.html.

Чтобы посмотреть идентификатор Х.500 OID, можно использовать или оснастку (snap-in) Active Directory Schema (Схема Active Directory), или оснастку ADSI Edit (Редактор ADSI). Чтобы посмотреть идентификатор Х.500 OID для атрибута Organization-Name, откройте контейнер схемы с помощью ADSI Edit и прокрутите вниз до названия атрибута: CN=Organization-Name. На рисунке 1-3 показан идентификатор attributelD (имя Х.500) атрибута http://Organization-Name.





Рис. 1 -3. Свойства атрибута Organization-Name, отображаемые с помощью ADSI Edit

Гетерогенные сетевые среды

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

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

сетевые операционные системы семейства Windows или Novell, выполняющиеся на серверных аппаратных средствах Intel или в гибридной среде с одним поставщиком NOS для службы каталога и другим - для серверов приложений и членов системы. Для традиционной модели обработки данных типа клиент-сервер, популярной в современных отделах корпоративных информационных технологий (IT), предпочтительны основные системы NOS. Выбирая версию этих операционных систем так, чтобы она удовлетворяла открытым стандартам, можно получить успешную гетерогенную среду обработки данных. Windows 2000 Active Directory, Windows Server 2003 Active Directory, Novell Directory Services в системе Novel Netware 5 и более поздние основаны на архитектуре открытого стандарта для инфраструктур службы каталога;



доменная система имен (DNS) под UNIX, протокол DHCP (Dynamic Host Configuration Protocol - протокол динамической конфигурации хоста), брандмауэр/прокси (firewall/proxy) или сервер NAT (Network Address Translation - преобразование сетевых адресов), выполняющийся на серверных аппаратных средствах RISC. Некоторые (или все) виды обеспечения интернет-взаимодействий на предприятии могут поддерживаться UNIX-серверами. Так как службы интернета выполнены в открытом стандарте, то нет никакого основания требовать, чтобы службы, поддерживающие доступ к интернету, имели определенный тип;

файлы под Linux или прикладной сервер, выполняющийся на сервере с младшей моделью Intel или RISC. Среда Linux, часто развертываемая в объеме, нужном для разработки или тестирования, предлагает возможный маршрут для обеспечения сетевых услуг, не являющихся критически важными и ответственными. Такая Linux-среда была бы доступна тем, кто использует Windows-приложения через протокол SMB (Server Message Block - блок серверных сообщений). Конечный пользователь не осознавал бы, что эти ресурсы находятся не на Windows-сервере.

Именование домена

При создании нового контроллера домена для нового домена нужно задать полное имя DNS и имя NetBIOS (см. рис. 6-9). При создании этих имен нужно соблюдать определенные правила.

Полное имя DNS должно содержать уникальное имя для нового домена, а при создании дочернего домена должен существовать родительский домен, и его имя должно быть включено в имя DNS. Например, если вы создаете новый домен NAmerica в дереве домена Contoso.com, то полное имя DNS, которое вы должны ввести, будет NAmerica.Contoso.com. При именовании домена доступные символы включают независимые от регистра буквы от А до Z, цифры от 0 до 9 и дефис (-). Каждый компонент DNS имени домена (секции, отделенные точкой [.]) не может быть длиннее 63-х байтов.

Рис. 6-9. Окно New Domain Name (Имя нового домена)

После того как вы указали имя DNS для домена, необходимо задать имя NetBIOS (см. рис. 6-10). Имя NetBIOS используется более ранними версиями системы Windows для идентификации имени домена. Лучше всего принять автоматическое имя NetBIOS, полученное из ранее введенного имени DNS. Единственное ограничение на имя NetBIOS состоит в том, что оно не должно превышать четырнадцать символов. Кроме того, имя NetBIOS должно быть уникальным.

Рис. 6-10. Окно NetBIOS Domain Name (Имя NetBIOS домена)

Именование объектов user в Active Directory

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

Табл. 10-2. Требования уникальности имени пользователя

Username (Имя пользователя)		Требование уникальности
First name, initials, last name (Имя, инициалы, фамилия)		Уникальность не требуется.
Display name (Отображаемое имя)		Уникальность не требуется.
Full name (Полное имя) - используется для заполнения атрибута сп учетной записи пользователя. По умолчанию полное имя создается из полей First Name, Initials и Last Name диалогового окна New Object-User (Новый объект-пользователь). Его можно изменить, используя Adsiedit.msc		Должно быть уникальным в пределах организационной единицы (OU).
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-суффикса к вашему лесу

Инфраструктура организации сети и проектирование сайта

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

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

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

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

Инсталляция без сопровождения

Для установки Active Directory вы можете запустить инсталляционный процесс в «тихом» режиме, без сопровождения, напечатав dcpromo.exe/ answer:answerfilе, где answerfile — имя файла ответов, который вы создали. В режиме «без сопровождения» файл сценария инсталляции передает значения для всех полей пользовательского ввода, которые вы заполняли бы при использовании мастера инсталляции Active Directory. Для любого ключа, который не определен в файле ответа, будет использоваться заданное по умолчанию значение этого ключа, или появится окно, чтобы вы могли ввести требуемое значение. Создание файла ответов для инсталляции без сопровождения будет описано позже в этой главе.

Инструмент 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 или /Ъфог, вы можете вызвать применение этих политик в любое время.

Инструмент Ntdsutil

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

Запустите инструмент Ntdsutil, напечатав в командной строке ntdsutil. Инструмент выдает приглашение к вводу команд Ntdsutil. Вы можете вводить разнообразные команды в зависимости от того, что вы хотите

сделать. Если вы напечатаете help в любой командной строке, то получите список всех команд, которые можно использовать в этом положении. На рисунке 15-2 показан список команд, доступных из окна Ntdsutil.

Рис. 15-2. Список команд, доступных из командной строки в утилите Ntdsutil

Далее вы увидите еще несколько примеров использования утилиты Ntdsuti для управления службой Active Directory. Более детальную информацию по использованию утилиты Ntdsutil смотрите в Help And Support Center.

После очищения каталога от ненужных объектов с помощью Ntdsutil нужно очистить также DNS-записи отказавшего контроллера домена. Удалите все DNS-записи из DNS, включая все записи, касающиеся контроллера домена, записи GC-сервера и записи эмулятора основного контроллера домена (PDC). (Две последних записи существуют только в том случае, если контроллер домена был сконфигурирован на выполнение этих ролей.) Если вы не очистите записи DNS, клиентьТ продолжат получать информацию DNS и будут соединяться с этим контроллером домена.

Нужно также удалить вышедший из строя контроллер домена из сайта и домена. Для этого используйте инструмент Active Directory Users And Computers (Пользователи и компьютеры Active Directory) и удалите объект, связанный с этим компьютером, из OU Domain Controllers (Контроллеры домена). В инструменте Active Directory Sites And Services (Сайты и службы Active Directory) удалите объект, связанный с этим компьютером, из контейнера Servers (Серверы) того сайта, в котором он был расположен.

Инструмент 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

Инструментальные средства управления групповыми политиками

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

Интеграция с инфраструктурой открытых ключей

В основе протокола Kerberos лежит опознавательная модель с общим секретом. Это обеспечивает превосходную защиту, но налагает одно важное ограничение на обеспечение доступа к сети Windows Server 2003. Это ограничение состоит в том, что каждый пользователь, который обращается к сети, должен иметь учетную запись в базе данных учетных записей службы KDC. Если пользователь не существует в базе данных, ему нельзя предоставить доступ к сети.

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

Инфраструктура открытых ключей (PKI - Public Key Infrastructure) стала основным средством для решения проблемы предоставления доступа к сети пользователям, не имеющим учетной записи пользователя. Система PKI отходит от модели аутентификации с общим секретом и заменяет ее опознавательной моделью, основанной на сертификате. В системе PKI пользователи аутентифицируются на основании того факта, что они имеют правильный сертификат. Система PKI основана на трех основных концепциях: открытые (public) и личные (private) ключи, цифровые сертификаты и сертификационные власти (СА - certificate authorities). PKI начинается с концепции, согласно которой каждый пользователь или компьютер, вовлеченный в информационный обмен, имеют два ключа: личный ключ и открытый ключ. Личный ключ известен только одному пользователю. Его можно сохранить на жестком диске компьютера, как часть роумингового (roaming) профиля, или на устройстве типа смарт-карты. Открытый ключ доступен любому, кто его попросит. Личные и открытые ключи связаны, но нет никакого способа извлечь личный ключ из открытого ключа. Эти ключи используются различными способами.

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

Другой способ применения состоит в использовании цифровой подписи и печати для сообщений, посылаемых между двумя пользователями. Цифровая подпись используется для гарантии подлинности отправителя сообщения и целостности сообщения. Чтобы создать цифровую подпись, все сообщение подвергается математическому хэшированию. Хэш является «сверткой сообщения», или цифровым дайджестом (digest), который зашифрован с помощью личного ключа отправителя сообщения. Зашифрованный хэш посылается вместе с сообщением как цифровая подпись. Когда адресат получает сообщение, к нему применяется тот же самый хэш, создавая второй дайджест сообщения. Затем используется открытый ключ отправителя для расшифровки цифровой подписи. Если дайджест сообщения получателя идентичен расшифрованной подписи, то целостность и подлинность сообщения подтверждены.

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

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



Сертификаты, необходимые для инфраструктуры PKI, выпускаются властями СА, которые являются сетевыми серверами, управляющими предоставлением и отменой удостоверений. Из-за важности PKI для интернета в настоящее время доступно множество СА-властей, включая популярные коммерческие СА типа Verisign и Thawte. Большинство интернет-клиентов, таких как Microsoft Internet Explorer, автоматически сконфигурированы доверять удостоверениям, выпущенным коммерческими властями С А. Вы можете установить свои собственные СА-вла-сти, используя Windows Server 2003. Сертификационная служба, поставляемая с Windows Server 2003, является СА-властью с полной функциональностью, которая может использоваться для выдачи удостоверений людям, работающим в пределах вашей компании, представляющим организации партнера.

Дополнительная информация. Планирование и развертывание инфраструктуры PKI требует значительных усилий. Windows Server 2003 обеспечивает опцию для создания PKI с использованием СА-властей предприятия, интегрированных в Active Directory. Развертывая СА-власти предприятия, можно сконфигурировать политики для автоматизации большинства административных усилий, связанных с выдачей и возобновлением удостоверений. Веб-сайт компании Microsoft и Help And Support Center (Центр справки и поддержки) в Windows Server 2003 содержат детальную информацию, необходимую для установки инфраструктуры PKI.

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



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

Windows Server 2003 обеспечивает два различных способа отображения сертификата на учетную запись пользователя.

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

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

Совет. Можно отображать сертификаты на учетные запкси пользователя через инструмент Active Directory Users And Computers или Менеджер информационного сервера интернета (IIS) от Microsoft. В Active Directory Users And Computers используйте опцию Name Mappings (Отображение имен^, которая становится доступной при щелчке правой кнопкой мыши на учетной записи пользователя.

Интеграция с существующей инфраструктурой DNS

Практически все большие компании уже имеют установленную инфраструктуру DNS. Во многих случаях DNS используется для разрешения имен серверов UNIX или для обеспечения потребности пользователей в услугах DNS для доступа в интернет. Иногда услуги DNS обеспечиваются DNS-серверами BIND, выполняющимися на UNIX-серверах. Поскольку существует зависимость Windows NT от имен NetBIOS и от

службы имен интернета для Windows (WINS), в противоположность именам хостов и DNS, многие Windows-администраторы мало касаются службы DNS. Ситуация изменилась с выпуском Active Directory систем Windows 2000 и Windows Server 2003. В главе 3 говорилось о том, что Windows Server 2003 требуется служба DNS для того, чтобы клиенты могли находить контроллеры домена. Поэтому критическим моментом при обсуждении проекта Active Directory становится вопрос о размещении службы DNS.

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

Есть два варианта интеграции для случая, когда должна поддерживаться текущая BIND инфраструктура DNS. Первый вариант состоит в том, чтобы использовать DNS-сервера не от Microsoft и располагать на этих серверах необходимую для Active Directory информацию зон DNS. Такая возможность, конечно, существует. Единственное требование для DNS - сервер должен поддерживать записи SRV. Вы, вероятно, захотите, чтобы серверы DNS также поддерживали динамические обновления (особенно, если вы планируете регистрировать все IP адреса клиентов в DNS) и дополнительные (incremental) зонные передачи. Если текущая инфраструктура использует BIND серверы DNS, серверы BIND 8.1.2 поддерживают записи SRV и динамические обновления. Сервер BIND 8.2.1 поддерживает дополнительные зонные передачи. Если вы используете одну из этих версий BIND, то вы можете продолжать использование DNS-серверов BIND. (Если вы используете DNS-серверы Lucent VitalQIP, то версии 5.2 и более поздние совместимы с BIND 8.2.2.)

Практический опыт. Выбор сервера DNS

Вопрос о том, использовать ли DNS- серверы системы Windows Server 2003 или DNS-серверы не от компании Microsoft, может вызвать горячую дискуссию и не привести к удовлетворительному результату. Большие компании в течение многих лет пользовались DNS-серверами BIND, DNS-администраторы грамотны, опытны и не хотят переходить к службе DNS на платформе Microsoft. Они выражают беспокойство по поводу стабильности, надежности и безопасности службы DNS на серверах Microsoft.

Один из подходов к решению этого вопроса состоит в следующем: на самом деле не имеет значения, чем обеспечивается DNS-служба. Пока DNS-серверы поддерживают записи SRV, Active Directory Windows Server 2003 может работать с любым сервером DNS. Критичным является то, что служба DNS всегда должна быть доступной. Если она перестанет работать в рабочее время, клиенты или серверы не смогут найти контроллера домена Active Directory. Поэтому вопрос можно поставить так: «Какой DNS-сервер обеспечит надежность, необходимую для работы Active Directory?».

Длинные дискуссии относительно надежности различных серверов, похоже, не отражают сути дела. Никакой сервер в единственном числе никогда не может быть полностью надежен, поэтому вопрос надо переформулировать так: «Какой DNS-сервер обеспечит наилучшие варианты для устранения выделенных точек отказа и распределения доступных служб между несколькими серверами?». Серверы Windows Server 2003 реализуют превосходные варианты для обеспечения надежности за счет нескольких серверов, особенно если используются интегрированные зоны Active Directory. С помощью этих зон каждый DNS-сервер может иметь перезаписываемую копию информации DNS. Интегрированные зоны Active Directory также реализуют безопасные обновления.

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



Второй вариант объединения DNS Windows Server 2003 с BIND состоит в развертывании обоих типов DNS. Многие компании используют DNS-серверы BIND как основной сервер имен для внутреннего пространства имен. Например, компания Contoso может использовать BIND при разрешении имен для Contoso.com. Если она решит развертывать Active Directory и использовать DNS-сервер на базе Windows Server 2003, существует множество вариантов. Если компания Contoso захочет использовать Contoso.com как DNS-имя Active Directory, она может переместить основную зону на DNS-сервер на базе Windows Server 2003 и поддерживать DNS сервер BIND в качестве дополнительного сервера имен. Или DNS-сервер на базе Windows Server 2003 мог бы стать дополнительным сервером имен к DNS-серверу BIND.

Примечание. Вы можете использовать DNS-серверы BIND и DNS-серверы на базе Windows Server 2003 для одного и того же пространства имен. Оба DNS-сервера могут работать как основной или дополнительный сервер имен, содержащие зонную информацию друг для друга. Однако если вы планируете использовать интегрированные зоны Active Directory, то DNS-зона BIND должна быть сконфигурирована как дополнительная зона. Интегрированная зона Active Directory не может быть дополнительной зоной.

Компания Contoso может развертывать Active Directory, используя доменные имена, отличные от тех, которые уже используются на DNS-серверах BIND. Например, имя Contoso.net может использоваться как DNS-имя Active Directory. В этом случае DNS-серверы на базе Windows Server 2003 могут быть сконфигурированы как официальные серверы для Contoso.net, а серверы BIND - как официальные серверы для Contoso.com. DNS-серверы на базе Windows Server 2003 могут быть сконфигурированы с условным ретранслятором на DNS-сервер BIND для Contoso.com. Домен Active Directory можно развернуть также с использованием AD.Contoso.com в качестве имени домена. В этом случае DNS-серверы BIND Contoso.com будут сконфигурированы с записью делегирования, направляющей любой поиск для домена AD.Contoso.com на DNS Windows Server 2003. Серверы DNS системы Windows Server 2003 могут быть сконфигурированы с ретранслятором, указывающим на DNS-сервер BIND.

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

Интеграция со смарт-картами

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

Смарт-карта содержит открытый и личный ключи пользователя плюс сертификат Х.509 v3. Все это применяется при использовании пользователем смарт-карты для аутентификации в Active Directory. Процесс входа в систему начинается в тот момент, когда пользователь вставляет смарт-карту в устройство чтения смарт-карт и вводит свой личный идентификационный номер (PIN — personal identification number). Это интерпретируется властями LSA на компьютере как последовательность Ctrl+Alt+Del, и процесс входа в систему начинается.

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

Когда сообщение достигает службы KDC, она проверяет сертификат клиента, чтобы убедиться в его правильности и в том, что СА-власти, выдавшие сертификат, являются доверенными властями. Служба KDC проверяет также цифровую подпись данных предварительной аутентификации, чтобы гарантировать подлинность отправителя сообщения и целостность сообщения. Если обе эти проверки дают положительный результат, служба KDC использует основное пользовательское имя (UPN), включенное в сертификат клиента, чтобы искать имя учетной записи в Active Directory. Если учетная запись пользователя правильна, то служба KDC подтверждает подлинность пользователя и посылает в ответ клиенту билет TGT, включающий ключ сеанса. Ключ сеанса зашифрован с помощью открытого ключа клиента, и клиент использует свой личный ключ для расшифровки информации. Затем этот ключ сеанса используется для всех подключений к службе KDC.

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

Интегрированная безопасность

Служба Active Directory работает рука об руку с подсистемой безопасности Windows Server 2003 при аутентификации безопасных пользователей и обеспечении защиты общедоступных сетевых ресурсов. Сетевая защита в сети Windows Server 2003 начинается с аутентификации во время регистрации. Операционная система Windows Server 2003 поддерживает два протокола для сетевой идентификации внутри и между доменами Windows Server 2003: протокол Kerberos v5 и протокол NT LAN Manager (NTLM). Протокол Kerberos является заданным по умолчанию аутентификационным протоколом для клиентов, вошедших в систему с клиентских компьютеров, работающих под управлением операционных систем Windows 2000 Professional или Microsoft Windows XP Professional. Пользователи, вошедшие в систему с клиентских компьютеров низкого уровня (Windows NT 4, Microsoft Windows 98 или более ранних операционных систем) используют для сетевой аутентификации протокол NTLM. Протокол NTLM также используется клиентами систем Windows XP Professional и Windows 2000, когда они входят на сервера, работающие под управлением Windows NT 4, или на автономные компьютеры с системами Windows 2000 или Windows Server 2003.

Служба Active Directory также является важной составляющей частью в модели управления доступом Windows Server 2003. Когда безопасный пользователь входит в домен Windows Server 2003, подсистема защиты вместе с Active Directory создает лексему доступа, которая содержит идентификатор защиты (SID - Security Identifier) учетной записи пользователя, а также идентификаторы SID всех групп, членом которых является данный пользователь. Идентификатор SID является атрибутом пользовательского объекта в Active Directory. Затем лексема доступа сравнивается с дескриптором защиты на ресурсе, и, если устанавливается соответствие, то пользователю предоставляется требуемый уровень доступа.

Интегрированные зоны Active Directory

Одно из самых больших преимуществ выполнения DNS в операционной системе Windows Server 2003 заключается в использовании интегрированных зон (integrated zones) Active Directory. Интегрированные зоны Active Directory дают множество преимуществ.

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

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

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

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

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

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

Когда зона сконфигурирована как интегрированная зона Active Directory, вы может просматривать информацию DNS в Active Directory

(см. рис. 3-6). Для этого запустите консоль управления Microsoft (MMC -Microsoft Management Console) и убедитесь, что оснастка Active Directory Users And Computers (Пользователи и компьютеры Active Directory) была добавлена к консоли. Выберите папку Active Directory Users And Computers (Пользователи и компьютеры Active Directory) из меню View (Вид), выберите Advanced Features (Дополнительные свойства). Откройте папку с именем домена, затем откройте папку System (Система), затем - папку Microsof tDNS. Зонная информация для всех интегрированных зон Active Directory перечислена в каждой зонной папке.



Рис. 3-6. Просмотр информации интегрированной зоны Active Directory

Практический опыт. Разрешение имен DNS без усовершенствованной службы DNS Windows Server 2003

Корпорация, состоящая из четырех различных компаний, каждая из которых была независимой до момента слияния, планировала развертывание Active Directory в системе Windows 2000 Advanced Server. Каждая компания настаивала на поддержке собственного пространства имен в пределах одного леса; это означало, что должен быть развернут лес с назначенным (dedicated) корневым доменом и четырьмя доменами компании (см. рис. 3-7). Все компании были расположены в разных городах в Канаде.



Рис. 3-7. Проект леса Active Directory с несколькими деревьями

Поскольку смежного пространства имен для всей компании не существовало, нормальный процесс делегирования дочерних доменов не применялся. Процесс конфигурирования ретрансляторов и корневых ссылок также оказался неэффективным, потому что не является достаточно отказоустойчивым. Например, если кому-то из Contoso.com требовалось найти ресурс в домене Fabrikam.com, клиент должен был запрашивать DNS-сервер Contoso. Поскольку сервер не был полномочным сервером для домена Fabrikam, он должен был разрешить имя, используя корневую ссылку или ретранслятор. Если DNS-сервер Contoso был сконфигурирован с ретранслятором на DNS-сервер в домене Fabrikam, имя могло быть разрешено. Однако эта запись ретранслятора не могла использоваться для разрешения компьютерных имен в домене TailspinToys.com или во внутренней сети. Использование системы DNS Windows 2000 предложило несколько путей решения этой проблемы (см. ниже), но ни один из них не был достаточно удовлетворительным.

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

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

Ни одно из этих решений не идеально. Операционная система Windows Server 2003 предлагает три варианта решения. В них используются условная переадресация, сокращенные зоны (stub zones) и разделы приложений каталога.

Интерфейс общего управления

Есть несколько способов, которыми вы можете получить выгоду от интеграции между Active Directory и операционной системой. Один из путей состоит в использовании интерфейса общего управления — консоли управления Microsoft (ММС — Microsoft Management Console). При взаимодействии с Active Directory через графический интерфейс пользователя ММС все инструментальные средства управления дают согласующееся друг с другом впечатление и ощущение от их использования. Для Active Directory эти средства включают Active Directory Users And Computers (Active Directory: пользователи и компьютеры), Active Directory Domains And Trusts (Active Directory: домены и доверительные отношения) и Active Directory Sites And Services (Active Directory: сайты и службы). Оснастки ММС функционируют так же, как все другие средства администрирования Windows Server 2003, например, оснастки DHCP и DNS.

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

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

Файл . zap является текстовым файлом, который содержит команды, предназначенные для установки приложения. В большинстве случаев .zap-файл будет содержать только следующие строки:

[Application]

FriendlyName = "applicationname"

SetupCommand = "\\servername\sharename\installapplication.exe""

Значение FriendlyName является именем, отображаемым в панели управления Add Or Remove Programs на компьютере клиента. Значение SetupCommand ~ путь к инсталляционному файлу для приложения. Можно использовать UNC-путь или отображенный диск для значения SetupCommand. Если приложение обеспечивает средства для настройки инсталляции с использованием параметров установки, можно включить эти параметры в значение SetupCommand, указывая его вслед за параметром, определяющим путь установки, заключенным в двойные кавычки. Например:

SetupCommand = "\\servername\sharename\se\up.exe" /parameter

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

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

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

Использование групповых политик для конфигурирования инсталлятора Windows

Поскольку большинство приложений, которые вы будете устанавливать с помощью групповых политик, будут использовать технологию инсталлятора Windows, вам, возможно, понадобится сконфигурировать установку приложений, имеющих Windows Installer. Active Directory Windows Server 2003 имеет несколько опций, предназначенных для этого. Большинство параметров настройки можно сконфигурировать, открыв объект GPO в редакторе объектов групповой политики и развернув Computer Configuration (Конфигурация компьютера). Далее выберите Administrative Templates (Административные шаблоны), потом выберите Windows Components (Компоненты Windows), затем - Windows Installer (Инсталлятор Windows) (см. рис. 12-12). Некоторые параметры настройки расположены в другом месте: User Configuration\ Administrative Templates\Windows Components\Windows Installer. В таблице 12-2 объясняется назначение этих опций.

Рис. 12-12. Конфигурирование параметров настройки инсталлятора Windows для компьютерных объектов

Табл. 12-2. Опции параметров настройки групповой политики для инсталлятора Windows

Параметр настройки		Объяснение
Disable Windows Installer (Отключение инсталлятора Windows) (Только конфигурация компьютера)		Используется для включения или отключения инсталляции программного обеспечения с помощью инсталлятора Windows. Если вы включите политику, то затем можно или полностью отключить инсталлятор Windows, или включить его для всех приложений, или отключать для тех приложений, которые не распределяются через групповые политики.
Always Install With Elevated Privileges (Всегда устанавливать с привилегиями) (Компьютерная и пользовательская конфигурация)		Используется для разрешения пользователям устанавливать приложения, которые требуют доступа к каталогам или ключам системного реестра, к которым пользователь обычно не может обращаться. Включение этой опции означает, что инсталлятор Windows будет использовать системные разрешения для установки программного обеспечения.
Prohibit Rollback (Запретить «откат») (Компьютерная и пользовательская конфигурация)		Используйте эту опцию для того, чтобы отключить заданное по умолчанию поведение инсталлятора Windows создающего файлы, которые могут использоваться для ««тката» неполной инсталляции.
Remove Browse Dialog Box For New Source (Удаление диалогового окна обзора для нового источника) (Только компьютерная конфигурация)		Используется для отключения кнопки Browse (Обзор), когда пользователь захочет установить новую функцию, используя инсталлятор Windows. Включение этой опции отключает кнопку Browse, т.е. пользователь может пользоваться только источниками, сконфигурированными администратором.
Prohibit Patching (Запретить использование «заплат») (Только компьютерная конфигурация)		Используется для запрета установки пользователями заплат к программам, использующим инсталлятор Windows. Включение этой опции обеспечивает усовершенствованную защиту, потому она не позволяет пользователям устанавливать заплаты, которые могли бы изменять системные файлы.
Disable IE Security Prompt For Windows Installer Scripts (Отключить IE подсказку защиты для сценариев инсталлятора Windows) (Только компьютерная конфигурация)		Используется для отключения предупреждений, которые получает клиент, устанавливая программное обеспечение через интерфейс браузера типа Microsoft Internet Explorer. Эту опцию можно использовать, если большая часть вашего программного обеспечения распределена через веб-сайт.
Enable User Control Over Installs (Включить контроль пользователя над инсталляцией) (Только компьютерная конфигурация)		Используется для увеличения степени контроля за инсталляцией приложения. Если опция включена, процесс инсталляции будет останавливаться на каждом экране, чтобы пользователь мог изменять параметры установки.
Enable User To Browse For Source While Elevated (Дать возможность пользователю просмотреть источники, если он имеет повышенные разрешения) (Только компьютерная конфигурация)		Используется для поиска альтернативных инсталляционных источников, если приложение устанавливается с повышенными разрешениями.
Enable User To Use Media Source While Elevated (Дать возможность пользователю использовать сменные носители информации, если он имеет повышенные разрешения) (Только компьютерная конфигурация)		Используется для разрешения использовать сменные носители информации в качестве инсталляционного источника, если приложение устанавливается с повышенными разрешениями.
Enable-User To Patch Elevated Products (Дать возможность пользователю применять заплаты, если имеются повышенные разрешения) (Только компьютерная конфигурация)		Используется для разрешения пользователю устанавливать заплаты, когда инсталляция выполняется с повышенными разрешениями.
Allow Admin To Install From Terminal Services Session (Разрешить администратору инсталляцию из сеанса службы терминала) (Только компьютерная конфигурация)		Используется для разрешения администраторам службы терминала устанавливать и конфигурировать программное обеспечение, используя сеанса службы терминала.
Cache Transforms In Secure Location On Workstation (Кэши-ровать файл преобразования в безопасном месте на рабочей станции) (Только компьютерная конфигурация)		Используется для кэширования файлов преобразования, используемых при инсталляции настраиваемых приложений на местной рабочей станции. Файл преобразования требуется для восстановления или повторения инсталляции программ.
Logging (Регистрация) (Только компьютерная конфигурация)		Используется для конфигурирования инсталлятора Windows на увеличение заданного по умолчанию уровня регистрации процесса инсталляции программ.
Prohibit User Installs (Запретить пользовательские инсталляции) (Только компьютерная конфигурация)		Используется для управления тем, будут ли установлены приложения, назначенные пользователю. Если опция включена, можно сконфигурировать параметры установки так, чтобы устанавливались только приложения, назначенные для компьютеров. Эта установка может быть полезна, если компьютер подсоединен к интернету или является общедоступным компьютером. Применяется только к клиентам, имеющим инсталлятор Windows v2.0 (или более позднюю версию).
Turn Off Creation Of System Restore Checkpoints (Выключите создание контрольных точек восстановления системы) (Только компьютерная конфигурация)		Используется для изменения заданного по умолчанию поведения на компьютерах с системой Windows XP Professional, где перед любой инсталляцией автоматически создается контрольная точка System Restore (Восстановление системы).
Search Order (Порядок поиска) (Только пользовательская конфигурация)		Используется для изменения заданного по умолчанию порядка поиска, при котором инсталлятор Windows ищет инсталляционные файлы. По умолчанию инсталлятор Windows будет просматривать сеть, затем — съемные носители информации, а затем - URL интернета.
Prevent Removable Media Source For Any Install (Запретить использование съемных носителей информации для инсталляции) (Только пользовательская конфигурация)		Используется для запрета^использова-ния инсталлятора Windows для установки приложений со съемных носителей информации.

Использование мастера инсталляции Active Directory

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

Чтобы запустить мастера инсталляции Active Directory, напечатайте dcpromo в диалоговом окне Run (Выполнить) или в командной строке. Появится стартовое окно мастера инсталляции Active Directory.

Использование мастера конфигурирования сервера

Чтобы установить Active Directory, используя мастера конфигурирования сервера (Configure Your Server Wizard), можно выбрать добавление новой роли в утилите Manage Your Server (Управление сервером) или Configure Your Server Wizard в папке Administrative Tools (Средства администрирования).

Чтобы установить Active Directory, используя Configure Your Server Wizard, выполните следующие действия.

В окне Manage Your Server щелкните на кнопке Add Or Remove A Role (Добавить или удалить роль) или выберите Configure Your Server Wizard в папке Administrative Tools. Запустится мастер конфигурирования сервера.

В окне Preliminary Steps (Предварительные шаги) щелкните на кнопке Next (Далее). Ждите некоторое время, пока мастер ищет параметры настройки Local Area Connections (Локальные подключения).

Чтобы установить Active Directory, службу сервера DNS и службу протокола динамической конфигурации хоста (DHCP), в окне Configuration Options (Опции конфигурации) выберите Typical Configuration For A First Server (Типичная конфигурация для первого сервера). Чтобы установить только Active Directory, выберите Custom Configuration (Выборочная конфигурация), а затем щелкните на кнопке Next (см. рис. 6-3). Последующее описание предполагает, что вы выбрали опцию Custom configuration.

Рис. 6-3. Окно Configuration Options (Опции конфигурации)

В окне Server Role (Роль сервера) выберите Domain Controller (Контроллер домена), затем щелкните на кнопке Next (см. рис. 6-4).

Рис. 6-4. Окно Server Role (Роль сервера)

В окне Summary Of Selections (Резюме выбранных опций) подтвердите выбор роли сервера и щелкните на кнопке Next. Для конфигурирования выбранных услуг появится окно Applying Selections (Применение выбранных опций).

При создании роли контроллера домена появляется окно Welcome (Приветствие) мастера инсталляции Active Directory (см. рис. 6-5). После этого будет выполняться тот же процесс, как если бы вы запустили мастера инсталляции Active Directory из командной строки или командой Run (Выполнить). Подробное описание ответов на вопросы мастера инсталляции Active Directory дано в следующем разделе. Завершите мастера инсталляции Active Directory, а затем щелкните на кнопке Finish (Готово). После того как служба Active Directory установлена и сконфигурирована, появится напоминание о том, что нужно перезапустить ваш сервер.

Рис. 6-5. Окно Welcome (Приветствие) мастера инсталляции Active Directory

Использование одного и того же пространства имен в качестве внутреннего и внешнего пространства

Некоторые компании захотят использовать одно и то же имя DNS и внутри, и снаружи. В этом случае компания должна зарегистрировать только одно DNS-имя в интернете. Например, на рисунке 5-5 показано, что компания Contoso могла бы использовать Contoso.com и внутри, и вне компании.

Рис. 5-5. Использование единственного пространства имен DNS

Предостережение. Независимо от того, используете ли вы одинаковые или различные внутреннее и внешнее пространства имен, ваш внутренний сервер DNS никогда не должен быть доступен внешним клиентам. Внутренний DNS-сервер будет содержать все записи контроллера домена, а также, по возможности, записи всех компьютеров в вашей сети (если вы включите динамическую службу DNS - DDNS). Доступными из интернета должны быть только те записи, которые касаются ресурсов, предназначенных для этого доступа. Для большинства компаний список ресурсов, доступных извне, состоит из адресов серверов SMTP, Web-серверов и нескольких других серверов. Использование одного пространства имен не подразумевает, что вы должны использовать один DNS-сервер или зонный файл для внутренних и внешних задач.

Главное преимущество использования единого внутреннего и внешнего пространства имен состоит в том, что оно обеспечивает согласование для конечного пользователя. Пользователь всегда использует одно имя домена для подключения к общей сети. Адрес SMTP пользователя и основное пользовательское имя (UPN) будут использовать одно и то же имя домена в качестве публичного веб-сайта. Когда пользователю нужно обратиться к доступным ресурсам, он может использовать одно имя и внутри, и снаружи (хотя он может обращаться к разным серверам). Другое преимущество использования единого пространства имен состоит в том, что надо регистрировать только одно DNS-имя.

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

Использование организационных единиц для делегирования административных прав

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

Организационные единицы имеют гибкую структуру назначения прав на доступ к объектам внутри OU. Во многих диалоговых окнах Windows и во вкладках Properties (Свойства) они называются разрешениями. Сама организационная единица OU имеет список управления доступом (ACL — Access Control List), в котором можно назначать права на доступ к этой OU. Каждый объект в OU и каждый атрибут объекта имеет ACL-список. Это означает, что вы можете очень точно контролировать административные права, данные кому-либо в этом подразделении. Например, вы можете дать группе Help Desk (Справочная) право изменять пароли пользователей в OU, не изменяя любые другие свойства учетных записей пользователя. Можно дать отделу Human Resources (Отдел кадров) право изменять личную информацию, касающуюся любой учетной записи пользователя в любом OU, но не давать им никаких прав на другие объекты.

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

установить разрешение Logon Locally (Локальный вход в систему) на уровне OU. Это разрешение будет установлено для всех компьютеров в данной OU. Другим примером группировки объектов в административных целях является ситуация, когда совокупность пользователей нуждается в одинаковой стандартной конфигурации рабочего стола компьютера и одинаковом наборе приложений. В этом случае пользователи объединяются в одну OU, и используется групповая политика (group policy) для конфигурирования рабочего стола и управления инсталляцией приложений.

В многих случаях объекты в OU будут управляться через групповую политику. Group Policy Object Editor (Редактор объектов групповой политики) представляет собой инструмент, который может использоваться для управления рабочей средой каждого пользователя. Групповые политики могут использоваться для блокировки пользовательских рабочих столов, для придания им стандартного вида, обеспечения сценариев входа в систему и выхода из нее, перенаправления папок. В таблице 2-3 дается краткий список типов параметров настройки, доступных в редакторе Group Policy Object Editor.

Табл. 2-3. Типы параметров настройки групповой политики

Типы параметров настройки		Пояснение
Administrative templates (Административные шаблоны)		Используется для управления параметрами, связанными с системным реестром, для конфигурирования параметров настройки приложений и пользовательского рабочего стола, включая доступ к компонентам операционной системы, к панели управления и конфигурацию автономных файлов.
Security (Безопасность)		Используется для управления локальным компьютером, доменом и параметрами настройки сетевой защиты, включая управление пользовательским доступом к сети, конфигурирование политик учетных записей и управление правами пользователей.
Software installation (Установка программного обеспечения)		Используется для централизованного управления установкой программного обеспечения.
Scripts (Сценарии)		Используется для определения сценариев, которые могут выполняться при запуске или выключении компьютера, при входе пользователя в систему и выходе из нее.
Типы параметров настройки		Пояснение
Folder redirection (Перенаправление папки)		Используется для хранения некоторых папок пользовательского профиля на сетевом сервере. Папки My Documents (Мои документы) выглядят так, будто они хранятся локально, но фактически они хранятся на сервере, где к ним можно обращаться с любого компьютера в сети.

Групповые политики чаще назначаются на уровне OU. Это облегчает задачу управления пользователями, так как можно назначить один объект групповой политики (GPO — Group Policy Object), например, политику инсталляции программного обеспечения организационной единице, которая затем распространится на всех пользователей или компьютеры в OU.

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

Использование различного внутреннего и внешнего пространства имен

Большинство компаний использует различные внутренние и внешние пространства имен. Например, компания могла бы использовать Contoso.com как внешнее пространство имен и имя Contoso.net или ADContoso.com для внутреннего пространства имен (см. рис. 5-6).

Примечание. Любое различие в именах домена означает, что внутри вы используете пространство имен, отличающееся от внешнего. Например, если вы используете Contoso.com как внешнее пространство имен, то Contoso.net, ADContoso.com и AD.Contoso.com — это разные пространства имен. AD.Contoso.com потребует конфигурации DNS, отличной от двух других, и все три пространства имен являются уникальными.

Рис. 5-6. Использование отдельных, внутреннего и внешнего, пространств имен

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

Использование сценариев для управления средой пользователя

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

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

Возможность назначать сценарии для запуска и завершения работы системы. В Active Directory можное назначать выполнение сценариев на момент запуска и выключения компьютеров. В системе Windows NT сделать это было очень трудно. Эти сценарии выполняются в контексте безопасности учетной записи LocalSystem.

Возможность назначать сценарии для пользовательского входа в систему и выхода из системы. Система Windows NT обеспечивала только сценарии входа в систему. В Active Directory можно также выполнять сценарии выхода из системы.

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

Наличие «родной» поддержки для сценариев Windows Script Host. В системе Windows NT большинство клиентов выполняли только пакетные файлы MS-DOS для реализации сценариев входа в систему. В системах Windows Server 2003, Windows XP и Windows 2000 клиенты обеспечивают родную поддержку для сценариев Windows Script Host (WSH). При конфигурировании пользовательских рабочих столов сценарии WSH оказываются гораздо более гибкими и мощными. С помощью WSH сценарии могут использоваться в более широких целях, чем простое отображение сетевых дисков. Служба Active Directory Windows Server 2003 поддерживает личные сценарии входа в систему, назначенные на индивидуальные учетные записи пользователя. Если в вашей сети имеются клиенты с системой Windows NT Workstation, используйте их для входа в систему. Клиенты с системами Windows 2000 и Windows XP Professional также могут обработать индивидуальные сценарии входа в систему. Если вы имеете индивидуальные сценарии входа в систему, назначенные учетным записям пользователя, они будут выполняться после выполнения сценариев запуска компьютера и пользовательских сценариев входа в систему, назначенных групповыми политиками.

Чтобы сконфигурировать сценарий для Active Directory, нужно его создать, а затем скопировать на контроллер домена. Сценарии можно хранить в любом месте на сервере, доступном для клиентов. Типичное место хранения сценариев - папка %systemroot %\SYSVOL\sysvol\ domainname\scripts. Она открыта для общего доступа под сетевым именем NETLOGON, и является заданным по умолчанию местом, в котором клиенты низкого уровня ищут сценарии входа в систему. Вы можете хранить сценарии входа в систему в папке %systemroot %\SYSVOL\ sysvol\domainname\GlobalPolicy GUID\Machine\Scripts или в папке %systemroot %\SYSVOL\sysvol\domainname\GlobalPolicy GUID\User\ Scripts. После копирования файлов сценария на сервер откройте объект GPO и найдите папку Scripts (Startup/Shutdown) (Сценарии (Запуск/ Завершение), расположенную в папке Computer Conf iguration\ Windows Settings, или папку Scripts (Logon/Logoff) (Сценарии (Вход в систему/ выход из системы)), расположенную в папке User Conf iguration\Windows Settings. Например, чтобы создать запись для сценария запуска, разверните цапку Scripts (Startup/Shutdown) и дважды щелкните на Startup. Затем можно добавлять любые сценарии запуска к объекту GPO. Active Directory Windows Server 2003 обеспечивает множество административных шаблонов, которые использоваться для конфигурирования сценариев на рабочих станциях клиентов. Большинство параметров настройки расположено в папке Computer Configuration\ Administrative Templates\System\Scripts, а некоторые - в nanKeUser Conf iguration\ Administrative Templates\System\Scripts. Опции конфигурации включают опцию, позволяющую выполнять сценарии запуска асинхронно, т.е. несколько сценариев запуска смогут выполняться одновременно. Можно выполнять сценарии входа в систему синхронно, т.е. все сценарии запуска завершаются, прежде чем появится рабочий стол пользователя. Вы можете также сконфигурировать максимальное время ожидания окончания выполнения всех сценариев. И, наконец, можно сконфигурировать, будут ли сценарии выполняться в фоновом режиме, чтобы быть незаметными, или они будут видимыми при выполнении.

Исследование существующей инфраструктуры DNS

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

Исследуя существующую инфраструктуру DNS, сделайте следующее.

Задокументируйте все DNS-имена доменов, используемые в настоящее время в пределах компании. Сюда входят имена, использующиеся в интернете, а также внутренние имена.

Задокументируйте все дополнительные имена, которые компания зарегистрировала в структурах власти интернета. Часто компания использует в интернете только имя .com, можно также зарегистрировать и другие имена домена высшего уровня типа .net или .org. Вы могли бы использовать одно из этих имен домена для вашего внутреннего пространства имен.

Задокументируйте существующую конфигурацию серверов DNS. Эта документация должна включать типы DNS-серверов, в настоящее время развернутых в сети (например DNS-серверы на базе Windows, BIND - Berkeley Internet Name Domain или Lucent VitalQIP). Кроме того, конфигурация DNS должна содержать информацию о ретрансляторах, о делегировании зон и о конфигурации основных и дополнительных серверов.

Изменение анонимного доступа к целевому домену

Если вы не выберете опцию Permissions Compatible With Pre-Windows 2000 Server Operating Systems (Разрешения, совместимые с операционными системами, предшествующими Windows 2000 Server ), при установке Active Directory можно добавить группу Everyone (Все) к группе Pre-Windows 2000 Compatible Access (Доступ, совместимый с операционными системами, предшествующими Windows 2000), напечатав net localgrowp "Pre-Windows 2000 Compatible Access" everyone /add в командной строке и нажав Enter.

После того как сделано изменение группового членства, нужна гарантия, что разрешения группы Everyone (Все) применяются к анонимным пользователям. Откройте инструмент Active Directory Users And Computers (Пользователи и компьютеры Active Directory), щелкните правой кнопкой мыши на контейнере Domain Controllers (Контроллеры домена) и выберите Properties (Свойства). На вкладке Group Policy (Групповая политика) отредактируйте объект Default Domain Controllers Policy (Заданная по умолчанию групповая политика). В поле Group Policy Object Editor (Редактор объектов групповой политики) раскройте опцию Default Domain Controllers Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options (Заданная по умолчанию политика контроллеров домена\Конфигурация компьюте-ра\Параметры настройки Windows\Параметры настройки защиты\Ло-кальные политики\Опции защиты) и дважды щелкните на Network Access: Let Everyone Permissions Apply To Anonymous Users (Сетевой доступ: Разрешения группы Все применять к анонимным пользователям). Отметьте опцию Define This Policy Setting (Определить настройки этой политики), выберите Enabled (Разрешено), а затем щелкните на ОК.

---

---