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

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

Внедрение и интеграция

В данной главе мы рассмотрим новые возможности Active Directory с нескольких точек зрения: внедрения этой службы, ее интеграции с другими каталогами, перехода с предыдущей версии (либо обновление с Windows NT 4.0, либо просто установка Active Directory с нуля). Прежде всего, необходимо отметить, что новые возможности Active Directory на базе Windows 2003 по большей части не совместимы с Active Directory на базе Windows 2000. Например, возможности переименовать домен или восстановить ранее деактивированный объект в схеме могут быть использованы только тогда, когда каталог находится на максимально возможном функциональном уровне: уровень домена - Windows Server 2003 и уровень леса - Windows Server 2003. Чтобы получить доступ к этим и другим возможностям, следует перевести лес на максимально функциональный уровень. Рассмотрим, что собой представляют эти самые функциональные уровни.

Функциональные уровни

Администратор вручную повышает функциональный уровень

Замечу, что такая классификация была специально введена для обеспечения совместимости на уровне обратно-несовместимых возможностей. Даже если установить Active Directory с нуля, не выполняя никаких обновлений и не заботясь об интеграции, то есть просто установить новый сервер, а на него - первый контроллер в лесе, то получится система, которая изначально попадает на самый низкий уровень. Другими словами, уровень домена - Windows 2000 Mixed (смешанный) и уровень леса - Windows 2000. Таким образом, в этом режиме установленная система полностью соответствует всем тем возможностям, которые есть в Windows 2000 Active Directory. Чтобы перейти на более высокий уровень, необходимо выполнение определенных условий, например, домен может быть переведен на уровень Windows Server 2003 только после того, как все контроллеры этого домена будут переведены на эту операционную систему. Если говорить о переходе с Windows 2000, то, естественно, процесс перехода заключается в поэтапном обновлении существующих контроллеров. Невозможно все контроллеры разом перевести с Windows 2000 на Windows 2003, это можно делать только по очереди. Пока процесс перевода контроллеров не завершен, функциональный уровень домена остается на уровне Windows 2000 Mixed. Как только будут переведены все контролеры, можно перейти на следующий уровень. Администратор переключает функциональный уровень с помощью специальной консоли Active Directory Domains Trusts. Администратор не в состоянии понизить уровень, он может только перевести его на более высокую ступень, на котором система останется. После того, как администратор перевел домен на новый функциональный уровень, в Active Directory появляются определенные новые возможности.

Рассмотрим эти возможности для простоты изложения в режиме чистый лес - Windows 2003 и все домены - Windows 2003. Другими словами, максимально возможные уровни и, соответственно, максимальный спектр новых возможностей. Первое, на чем стоит остановиться - это функция, которая называется Application Partitions (по-русски - Разделы Приложений).

Разделы для приложений

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

Windows 2003 позволяет дифференцировать и отделить информацию, которая принадлежит сетевым приложениям от остального каталога путем создания разделов для приложений. Например, информация, которую хранит сервер DNS, может быть распределена не на все контроллеры, которые есть в домене, а только на те, которые были явно указаны. Фактически, это и означает создание разделов. Сначала можно создать раздел "каталоги", как бы отделяя его от общей структуры, а потом указать, что этот раздел в качестве реплики должен храниться на поименных контроллерах. Это же касается любого другого приложения. За счет такого механизма администратор, управляющий системой, может наиболее оптимально отделить и хранить информацию о каталоге и о приложениях. Например, если заведомо известно, что какое-то приложение будет использовать каталог только на данном конкретном контроллере (не будет обращаться к другим контроллерам), то можно таким способом свести хранилище каталога только к этому контроллеру за счет создания уникального раздела для этого приложения.

Следующей возможностью является поддержка класса объектов InetOrgPerson (RFC 2798). Она появилась только в Windows 2003, а Windows 2000 этот класс объектов не поддерживает. InetOrgPerson нужен для интеграции с другими LDAP-каталогами (Novell, Netscape). Active Directory умеет работать с этим классом, создавать объекты этого класса, возможна также прозрачная и плавная миграция объектов типа InetOrgPerson из других каталогов Active Directory. Соответственно, становится возможным перенос приложений, написанных для других LDAP-каталогов. Если приложения используют данный класс, то их можно безболезненно, прозрачно портировать на Active Directory, сохраняя всю функциональность.

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

Переименование домена. Утилита rendom.exe

Рассмотрим домен Contoso, подчиненный домену Sales в дереве WorldWideImporters.com. Его можно переименовать и назвать Contoso.Fabrikam.com. Это не просто переименование, это перенесение домена из одного дерева в другое, то есть достаточно нетривиальная процедура. Логично предположить, что переименование домена может привести к созданию нового дерева. Можно переименовать домен Contoso, который был подчинен домену Sales, и назвать его Contoso.com. Тогда домен станет родоначальником другого дерева в этом же лесе. Именно поэтому процесс переименования домена можно считать весьма сложной и нетривиальной процедурой.

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

Вместе с Windows 2003 поставляется утилита, которая называется Rendom, буквально от слов Rename Domain. Утилита Rendom.exe - это утилита командной строки, которая может использоваться для переименования домена. Правда, этот процесс состоит из шести этапов. Подробную информацию о нем можно отыскать в службе справки Windows 2003, специальных технических документах для Microsoft .NET, на сайте MSDN. Там подробно описано, как моделировать, проектировать и проводить процесс переименования домена, с использованием утилиты rendom. В любом случае, это сложный, многоэтапный процесс, требующий тщательной подготовки: слишком много связок и указателей, имен и прочих взаимозависимостей, которые формируются при создании доменов. Просто взять и одним махом все это перенести - невозможно.

В плане внедрения Active Directory появился режим установки контроллера домена со съемного носителя. Что имеется в виду? Очень часто встречается ситуация, когда предприятие внедряет Active Directory в удаленных офисах: связь с удаленным офисом слабая, плохие линии связи между головными офисами и филиалами. Тем не менее нужно в филиале установить новый контроллер доменов. Когда создается новый контроллер в уже существующем домене, утилита DCPromo связывается с существующими, работающими контроллерами и перекачивает себе всю базу данных и реплики, которые можно собрать с контроллера её домена. Если эта база занимает несколько десятков или сотен килобайт, то есть пустая (она по-умолчанию занимает несколько сот килобайт), то проблем нет. Но если говорить о работающей системе, в которой база может занимать десятки или сотни мегабайт, то её перекачка может оказаться просто невыполнимой задачей. Поэтому в этой ситуации можно решить проблему очень простым способом. С помощью Windows NT Back-up сделать архив в режиме "system state", то есть выбрать в консоли Windows NT Back-up опцию Back-up->SystemState. После этого весь созданный Back-up записать на носитель, например, на CD или DVD, взять этот диск и приехать с ним в удаленный офис, там восстановить всю информацию из архива с помощью той же самой Windows NT Back-up. Только нужно сделать восстановление не по умолчанию, а в другой каталог, чтобы сами файлы были просто выложены на диск. Естественно, не нужно заменять ту системную информацию, которая есть на существующем компьютере. Далее следует запустить утилиту DCPromo с ключом "/adv" и указать путь к тому хранилищу, где находится распакованный файл. После этого процесс инсталляции нового контроллера будет создавать свою реплику на основании информации со съемного носителя. При этом все равно потребуется связь с головным офисом, потому что помимо перекачки реплики, требуется еще установление определенных отношений с существующим доменом. Поэтому связь должна быть, но требования к ней существенно снижены: подойдет даже очень слабая линия. В приведенном сценарии 95% информации, которые нужно было перекачивать на новый контроллер, были перенесены на системный носитель, а линию связи между головным офисом и филиалом не пришлось перегружать.

Важно отметить, что у заказчиков по-прежнему очень часто используется Windows NT 4.0. Windows 2003 позволяет перейти с существующих каталогов (с NT 4 или с Windows 2000) быстрее, более безболезненно и эффективно. Этой цели служит утилита Active Directory Migration Tool (ADMT) . ADMT поможет с миграцией с Windows NT на Windows 2003, а также с Windows 2000 на Windows 2003 в том случае, если потребуется какая-то реструктуризация доменов, перенесение учетных записей и т.д.

Мастера Active Directory Migration Tool (ADMT) v.2

Active Directory Migration Tool представляет собой набор программ-мастеров. Каждый мастер выполняет определенную задачу (см. картинку выше). Важно, что большинство программ-мастеров имеет режим, который называется "Test migration settings and migrate later" - моделирование процесса без реального выполнения операций. Другими словами, процесс миграции эмулируется, и администратор может посмотреть, каков будет результат и как все будет происходить. Реальные действия в этом режиме не выполняются. В случае, когда результаты работы тестового режима удовлетворительны, можно попросить Active Directory Migration Tool выполнить полноценную миграцию.

Администрирование

Данная глава посвящена инструментальному администрированию. В принципе, нельзя сказать, что здесь появилось много новых очень полезных возможностей. Однако кое-что все-таки есть. Например, поддержка Drag&Drop: до выхода Windows 2003 поддержки Drag&Drop не было. Теперь можно кликнуть на объект "пользователь" и перетащить его мышкой в новый контейнер. Это очень удобно. Жаль, что такого механизма в предыдущих версиях не было.

Появилась дополнительная консоль для хранения запросов к каталогу. Известно, что Active Directory - это LDAP-каталог. Значит, к LDAP-каталогам можно делать запросы на стандартном языке запросов. Если эти запросы делать и не запоминать, то это является дополнительной нагрузкой на администратора: каждый раз ему нужно запрос писать заново или копировать его из какого-то документа. Для упрощения данного процесса предлагается раздел, который называется Saved Queries. В нем собственно и сохраняются те запросы, которые администратор или пользователь ввели в консоли.

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

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

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

Утилиты командной строки

В этом нет, на самом деле, никакого противоречия. Дело в том, что очень много операций, которые приходится выполнять администратору, удобнее делать в виде командных файлов. Например, когда речь идет о модификации у одинаковых или похожих объектов какого-то атрибута, это часто удобнее сделать в командной строке, написав соответствующий скрипт. Если необходимо изменить какой-то параметр, например, телефоны пользователей, которые прописаны в учетной записи (у всех в подразделении может поменяться телефон), можно зайти в каждую учетную запись и изменить телефон. Если это делать через графический интерфейс, то придется произвести как минимум сто операций по изменению объекта "Учетная запись". Можно же взять одну простую команду, которая называется DSMod (модификация объекта), сформировать строчку для записи новой информации, после чего написать скрипт с условиями поиска и выполнить всё в виде одной команды. Для таких операций (а в повседневной работе администратора их множество) следует использовать утилиты командной строки и скрипты.

Репликация

Вопросы репликации очень актуальны при внедрении Active Directory, проектировании и планировании инфраструктуры.

В Windows 2000 есть определенные ограничения по количеству сайтов, в которых можно было бы автоматически сгенерировать топологию. Существует служба, которая называется Inter-Site Topology Generator (ISTG) . Когда создаются два или три, а лучше пять или даже десять сайтов, служба ISTG автоматически генерирует топологию репликаций между сайтами, сама выбирает узловые серверы, сама определяет, как будет выполняться сценарий этой репликации. Всё хорошо, но если сайтов порядка двухсот, то служба ISTG не справляется с объемом информации и зацикливается. Поэтому для Windows 2000 есть совершенно четкая рекомендация - количество сайтов не должно быть более двухсот, если необходимо, чтобы топология репликации между сайтами генерировалась автоматически. Если же сайтов больше - автоматическую генерацию надо отключить и настраивать все это вручную.

Проблема, казалось бы, не очевидна, но с ней люди реально сталкиваются, когда доходит до внедрения Active Directory на многосайтные системы. Windows Server 2003 снимает этот вопрос. В этой системе реализован абсолютно новый Inter-Site Topology Generator, который работает принципиально по-другому и генерирует топологию, используя новый алгоритм. Количество сайтов, которое может теперь автоматически генерироваться (топология которых может генерироваться автоматически с помощью службы ISTG), только на тестах было несколько тысяч. Неизвестно, кому может потребоваться столько сайтов, но, тем не менее, можно забыть о каком-либо ограничении только за счет модификации механизма ISTG.

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

Есть еще одно ограничение в том, как Active Directory в Windows 2000 реплицирует группы. Речь идет о группе безопасности. Когда дело касается назначения прав для доступа к каким-то объектам, обычно правильная практика администрирования подразумевает, что права назначаются группам. Пользователи либо включаются в группу, либо исключаются. Группа - это точно такой же объект в Active Directory, как и все остальные объекты. Объект же имеет атрибуты. Особенность группы заключается в том, что список членов группы - это не несколько атрибутов, это один атрибут с большим количеством значений, так называемый "Multi Value Attribute" (на самом деле, это один атрибут, у которого много значений). Механизм репликации Active Directory детализирован до уровня атрибута. Если объект модифицируется, то система будет реплицировать эти изменения ровно для тех атрибутов, которые изменились, а не для всего объекта целиком. Теперь вернемся к группе, у которой есть атрибут, состоящий, например, из ста значений. Если в группу входит сто человек, значит у этого атрибута сто значений. А если 5 тысяч? Ограничение заключается в следующем: если членство в группе составляет 5 тысяч объектов, то репликация такого объекта становилась невозможна. Как только появится 5001 член группы, сразу же разрушается процесс репликации этой группы на Windows 2000. Есть даже документированный способ атаки, когда администратор, обиженный на кого-то, может разрушить процесс репликации в системе, просто написав скрипт, который циклическим образом поместит в какую-то группу 5 тыс. членов. После чего возникают проблемы с репликацией каталога. Windows Server 2003 Active Directory вводит дополнительный механизм, который называется "Репликация присоединенных значений" ("Linked Value Replication").

В этом случае механизм предназначен исключительно для репликации атрибутов, у которых есть много значений. То есть теперь, при использовании этого механизма членство в группе реплицируется на уровне отдельных членов. Если включить нового человека в группу, то репликация будет вестись не всего списка, как атрибут, а только значения за счет механизма Linked Value Replication.

Еще одна проблема, связанная с репликацией, имела отношение к глобальному каталогу. Трудность заключалась в том, как ведет себя глобальный каталог, когда администратор модифицирует, так называемый, Partial Attribute Set (PAS) - список атрибутов, которые должны быть помещены в глобальный каталог.

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

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

Windows Server 2003 снимает эту проблему. Репликация и синхронизация глобального каталога будет проводиться исключительно в объеме добавленного атрибута. То есть когда проводится операция добавления атрибута к PAS, происходит просто сбор информации у тех объектов, у которых этот атрибут есть. А затем он [атрибут] добавляется к глобальному каталогу. Полной синхронизации не происходит.

Еще одна дополнительная функция, касающаяся глобального каталога - это механизм кэширования универсальных групп. Напомню, группы в Active Directory бывают трех типов: локальные, глобальные и универсальные. Локальные и глобальные хранятся вместе с репликой на контроллере, универсальные группы хранятся в глобальном каталоге. Когда сотрудник удаленного офиса хочет войти в сеть, система провести регистрацию пользователя в сети и создать его контекст безопасности. Для этого ей необходимо узнать, в какие группы входит пользователь. Узнать о локальных и глобальных группах Windows 2000 может на своем ближайшем контроллере, но по устройству сети, глобальный каталог находится в головном офисе. Проверить членство пользователя в универсальных группах можно только, сделав запрос к глобальному каталогу. Поэтому на момент регистрации необходимо послать запрос в головной офис. Если связь оборвана и глобальный каталог не доступен, то пользователю будет отказано в регистрации (по умолчанию в этой ситуации). Если в реестре поставить значение "игнорировать ошибки, связанные с членством в универсальных группах", в системе безопасности образуется дыра.

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

Доверие между лесами

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

Доверие между лесами

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

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

Можно сделать цепочку, например, из трех лесов A, B, C. A доверяет В, а В доверяет С. Из этого не следует, что между лесом А и С тоже установились доверительные отношения. Это как в Windows NT 4: не транзитивные отношения в том смысле, что они не транзитивны между лесами. Но между доменами, которые связывают два леса, отношения являются транзитивными.

Управление групповыми политиками

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

Механизм групповых политик позволяет назначать политики контейнерам, то есть организационным подразделениям, сайтам и доменам. Групповую политику нельзя назначить конкретному пользователю. При этом, поскольку структура контейнеров в Active Directory иерархична, можно на разных уровнях назначать разные групповые политики. Следовательно, работают механизмы наследования. У администратора есть определенные функции по блокировке наследования или, наоборот, по принудительному применению политики наследования. Администратор имеет возможность фильтровать применение групповых политик через права доступа. В любом случае, большое количество задач решается с помощью не меньшего количества инструментов. Для каждой задачи есть определенный инструмент. Таким образом, чтобы управлять групповыми политиками в Windows 2000, требуется знать порядка шести инструментов и использовать их для различных задач.

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

Помимо того, что Group Policy Management Console является консолидированным графическим инструментарием, она еще и добавляет ряд новых функций к управлению групповыми политиками. Например, функции архивирования и восстановления групповых политик, функции копирования групповых политик между доменами одного леса и импорт/экспорт групповых политик.

Group Policy Management Console, как составная часть Windows Server 2003, отсутствует. Ее нужно скачивать с web-сервера Microsoft (http://www.microsoft.com/downloads ). Установить консоль можно либо на Windows Server 2003, либо на Windows XP при наличии Service Pack 1 и.NET Framework. Таким образом, с помощью Group Policy Management Console можно управлять групповыми политиками, даже не находясь непосредственно на контроллере домена. Можно установить консоль прямо на рабочую станцию Windows XP и с этой рабочей станции централизованно управлять всеми групповыми политиками леса. Кроме того, в составе Group Policy Management Console есть два мастера, которые позволяют анализировать и моделировать процесс применения групповых политик. Первый называется "Мастер результатов применения групповых политик" и он показывает, какие политики применялись к данному конкретному компьютеру, какие значения изменились и с каких политик эти значения были получены. Если что-то не применилось, мастер показывает, почему это не применилось.

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

Процесс такого моделирования выполняется с помощью консоли, которая расположена в Group Policy Management Console и называется Process Modeling. Моделирование не требует подключения к исследуемому компьютеру. Оно работает только с информацией, которая хранится в Active Directory. Достаточно просто иметь доступ к контроллеру Windows Server 2003 Active Directory. Можно, например, представить, что случится, если пользователь войдет в какую-то группу безопасности, можно условно поместить пользователя в какой-то контейнер и посмотреть, что произойдет.

Есть еще некоторые новые возможности Group Policy Management Console - это архивирование и восстановление групповых политик. Сами объекты можно сохранить в виде файла в определенном каталоге. Потом их можно восстановить обратно в случае какой-то проблемы или при экспериментах с доменом, Active Directory или групповыми политиками. Важно, что восстановить групповую политику можно только в том же домене, в котором она была заархивирована. Восстанавливается только объект групповой политики сам по себе: то, что было к нему дополнительно привязано, нельзя поместить в архив, соответственно, восстановить тоже.

Перейдем теперь к Windows Management Instrumentations (WMI). Это технология, которая сейчас является основной в управлении системами. WMI используется практически везде: любая служба так или иначе задействует WMI.

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

Политика ограничения на использование программ

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

Для реализации этого механизма используется принцип: базовый уровень, плюс исключение. Соответственно, базовые уровни могут быть двух типов для разных сценариев. Первый базовый уровень называется "Disallowed": все программы по-умолчанию запрещены, кроме тех, которые разрешены в исключениях, в дополнительных правилах. Второй называется Unrestricted: разрешены все программы, но в списке дополнительных правил указаны исключения, то есть черный список программ, которые нельзя запускать.

Правила могут быть четырех типов (ранжированы по приоритету): Certificate (максимальный приоритет), Hash, Path и Zone. Приоритет актуален, когда есть несколько политик, определяющих одно и то же приложение разными правилами. Например, одна политика разрешает запускать все программы, которые расположены в каталоге "ABCD", а другая политика запрещает запускать программы, имеющие такой-то хэш. Если окажется, что эта программа, которую запрещено запускать, находится в разрешенном каталоге ABCD, то сильнее окажется правило запрета, потому что правило по хэшу "побеждает" правило по пути. Именно для этого используется приоритет.

Заключение

Можно резюмировать, что с появлением Windows Server 2003 добавилось не так уж и много полезных возможностей для работы с Active Directory. Тем не менее, некоторые из них очень полезны и могут сэкономить время и нервы системному администратору. Это, прежде всего, Group Policy Management Console и утилиты командной строки. Остальные изменения зачастую устраняют недоработки предыдущих версий системы (обновленные механизмы и алгоритмы), однако все равно необходимо знать, где именно возможности Active Directory расширены и как ими пользоваться...

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

DNS - это служба локатора (locator service), используемая Active Directory (и многими другими компонентами Windows). Active Directory делает свои службы доступными в сети, публикуя их в DNS . Когда устанавливается контроллер домена (или к нему добавляются службы), он использует динамические обновления для регистрации своих служб в DNS как записей SRV. После этого клиенты могут находить службы через простые DNS -запросы. По умолчанию служба Microsoft DNS работает на каждом контроллере домена под управлением Windows Server 2003.

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

Анализ существующей инфраструктуры

Определение географической модели организации

• Локальная модель

  Региональная модель

  Национальная модель

  Международная модель

• Дочерние компании

Создание карты территориального размещения организации

Сбор сведений о информационных потоках в организации

Анализ текущей модели администрирования

Анализ топологии существующей сети

Планирование структуры AD

Первый шаг в проектировании структуры AD - определение лесов и доменов.

Применение одного домена

• Упрощение управления пользователями и группами

  Нет необходимости планировать доверительные отношения

  Для делегирования прав применяются OU

Применение нескольких доменов

• Возможность реализации разных политик безопасности

  Децентрализованное управление

  Оптимизация трафика

  Разные пространства имен

  Размещение хозяина схемы в отдельный домен

Применение одного домена

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

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

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

Домены Active Directory масштабируемы в гораздо большей мере, чем домены Windows NT. Поэтому исчезает существенное препятствие, не позволявшее применять однодоменные сети на основе Windows NT, в которых диспетчер учетных записей безопасности (Security Accounts Manager, SAM) поддерживал только до 40 000 объектов в домене. В отличие от Windows NT в домен Active Directory может входить более миллиона объектов.

Использование нескольких доменов

В каждом домене требуется хотя бы один контроллер

Групповая политика и управление доступом действует на уровне домена

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

Административные права, действующие между доменами, выдаются только для Администраторов предприятия

Необходимо создавать доверяемые каналы

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

Применение нескольких деревьев в лесу

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

Два дерева, представляющие собой два пространства имен

Недостатки:

Разное пространство имен, поддержка больше DNS -имен

Проблемы связанные с применением нескольких доменов

Возможности LDAP клиентов

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

Недостатки такого варианта:

Поскольку у каждого дерева должно быть отдельное пространство имен DNS , ИТ-отделу придется поддерживать больше DNS -имен, чем в случае однодоменной модели.

Чем больше деревьев, тем больше доменов, поскольку каждое дерево должно содержать минимум один домен. Следовательно, возникнут все проблемы, связанные с применением нескольких доменов.

Возможно, что LDAP -клиенты (Lightweight Directory Access Protocol), разработанные не Microsoft, не смогут выполнять поиск по глобальному каталогу и вместо этого им придется вести LDAP -поиск по каждому дереву отдельно. В результате увеличится время отклика для таких клиентов.

С учетом этих недостатков имеет смысл подумать об альтернативном решении: объединить пространства имен и использовать одно дерево с разными доменами вместо нескольких деревьев.

Отдельные пространства имен, в одном дереве

Применение нескольких лесов

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

Леса представляют собой крайние границы зон безопасности. Между лесами невозможно административное управление или пользовательский доступ, если на то нет явного разрешения в конфигурации. Для этого предназначен новый тип доверия, введенный в Windows Server 2003, - доверие к лесу (forest trust), применяемое при управлении отношениями между двумя лесами.

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

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

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

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

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

Недостатки структуры из нескольких лесов

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

Архитектура с несколькими лесами имеет следующие недостатки.

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

Сотрудникам, которым требуется входить на компьютеры, включенные во внешние леса, должны указывать при входе основное имя пользователя (user principal name, UPN) по умолчанию. От таких сотрудников требуется более высокий уровень подготовки.

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

Администраторам приходится хранить несколько схем.

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

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

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

Соглашение о именовании

Чтобы найти сетевой ресурс, необходимо знать имя объекта или его одно из его свойств. Active Directory поддерживает несколько типов имен:

Относительные составные имена

Составные имена

Основные имена пользователей

Канонические имена

Решив, какую структуру доменов и лесов нужно создать, переключите свое внимание на именование элементов, входящих в эту структуру.

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

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

Относительные составные имена

Относительное составное имя (RDN) объекта уникально идентифицирует объект, но только в его родительском контейнере. Таким образом, оно уникально идентифицирует объект относительно других объектов в том же самом контейнере. Например, здесь:

CN=wjglenn,CN=Users,OC=kd,DC=ru относительным составным именем объекта является CN=wjglenn . RDN родительской организационной единицы (OU) - Users. У большинства объектов RDN - то же, что и атрибут Common Name.

Active Directory автоматически создает RDN по информации, указываемой при создании объекта, и не допускает, чтобы в одном и том же родительском контейнере существовали два объекта с одинаковыми RDN.

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

DC - тэг Domain Component, который идентифицирует часть DNS -имени домена вроде СОМ или ORG.

OU - тэг Organizational Unit, который идентифицирует организационную единицу, являющуюся контейнером.

CN - тэг Common Name, который идентифицирует простое имя, присвоенное объекту Active Directory.

Составные имена

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

Вот типичный пример составного имени: CN=wjglenn,CN=Users,DC=kd,DC=ru

Это DN означает, что объект пользователя wjglenn содержится в контейнере Users, в свою очередь содержащемся в домене kd.ru. Если объект wjglenn переместят в другой контейнер, его DN изменится и будет отражать новое местоположение в иерархии. DN гарантированно уникальны в лесу - по аналогии с тем, как полное доменное имя (fully qualified domain name, FQDN) уникально идентифицирует местонахождение объекта в иерархии DNS . Существование двух объектов с одинаковыми DN невозможно.

Канонические имена

Каноническое имя объекта используется во многом также, как и составное. Просто у него другой синтаксис. Составному имени, приведенному в предыдущем разделе, соответствовало бы следующее каноническое имя: kd.ru/Users/wjglenn

Как видите, в синтаксисе составных и канонических имен два основных отличия. Первое - каноническое имя формируется от корня к объекту, а второе - в каноническом имени не используются тэги LDAP -атрибутов (например CN и DC).

Основные имена пользователей

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

Идентификаторы защиты

При выработке стратегии именования две роли хозяев операций представляют интерес:

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

• Один домен в каждом лесу, обрабатывает добавление и удаление доменов и генерирует уникальный идентификатор защиты (SID)

Хозяин RID

• Генерирует последовательности для каждого из контроллеров домена. Действует в пределах домена. Генерирует для каждого контроллера домена пул по 500 RID.

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

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

Однако при выработке стратегии именования представляют интерес две роли хозяев операций: именования доменов (domain naming master) и RID (relative ID master). Два сервера, выполняющих эти роли, должны быть доступны, когда создаются и именуются новые участники системы безопасности (security principals).

Определение стратегии именования

Следует учитывать требования и DNS и AD

Поддерживается иерархия, длина имени до 64 символов

Подключение к внешним сетям

Совместимость с NetBios-именами

Плоская модель, длина имени не более 16 символов

Существует возможность назначать разные NetBios и DNS имена, но такой подход не допустим.

При выработке стратегии именования необходимо учитывать требования к именованию, предъявляемые как Active Directory, так и DNS . Клиенты используют DNS для разрешения IP-адресов серверов, на которых выполняются важные сетевые сервисы Active Directory. Следовательно, Active Directory и DNS неразрывно связаны.

В DNS имена образуют иерархию и формируются путем «движения» от родительских доменов к дочерним. Так, у домена kd.ru может быть дочерний домен sales.kd.com, у того в свою очередь - дочерний домен europe.sales.kd.ru. Имя каждого домена соответствует пути, идентифицирующему домен в иерархии DNS , т. е. пути к корневому домену (корневой домен обозначается точкой).

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

Все имена доменов Active Directory идентифицируются по DNS , но можно использовать и NetBIOS-имена (Network Basic Input/Output System) - унаследованную систему именования, которая применялась в старых версиях Windows и по-прежнему поддерживается в Windows Server 2003. Windows автоматически генерирует NetBIOS-имена для каждой службы, выполняемой на компьютере, добавляя к имени компьютера дополнительный символ. Доменам также присваиваются NetBIOS-имена.

Правила именования доменов

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

Используйте только символы, разрешенные стандартами Интернета: а-z, 0-9 и дефис (-). Хотя реализация DNS в Windows Server 2003 поддерживает и другие символы, применение стандартных символов гарантирует возможность взаимодействия с другими реализациями DNS .

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

В качестве основы имени корневого домена берите только зарегистрированные доменные имена. Даже если вы не используете в качестве имени корня леса зарегистрированное DNS -имя, это поможет избежать путаницы. Например, у компании может быть зарегистрирован домен kd.ru. Если вы не используете kd.ru в качестве имени корневого домена вашего леса, все равно формируйте имя, производное от kd.ru (скажем, sales.kd.ru).

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

Для большей безопасности создайте отдельные внутреннее и внешнее пространства имен, чтобы предотвратить несанкционированный доступ к закрытым ресурсам. И создавайте внутреннее имя на основе внешнего (например kd.ru и local.kd.ru).

Имена участников системы безопасности

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

При добавлении учетной записи администратор задает:

Имя используемое для входа в сеть

Имя домена, содержащего учетную запись

Прочие атрибуты (имя, фамилия, телефон..)

Имена могут содержать любые символы Unicode, за исключением следующих: #, +, «, \, <, >

Объекты участников системы безопасности (security principal objects) - это объекты Active Directory, которым назначены идентификаторы защиты и которые указываются при входе в сеть и предоставлении доступа к ресурсам домена. Администратор должен давать объектам участников системы безопасности (учетным записям пользователей, компьютеров и групп) имена, уникальные в рамках домена. Следовательно, вы должны выработать стратегию именования, которая позволит это делать.

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

имя, которое пользователь должен указывать при входе в сеть;

имя домена, содержащего учетную запись пользователя;

прочие атрибуты, такие как имя, фамилия, номер телефона и т. д.

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

Правила имен участников системы безопасности

Длина имен учетных записей пользователей не более 20 символов

Имена учетных записей компьютеров не более 15 символов

Длина имен учетных записей групп не более 63 символов

Нельзя использовать только точки, пробелы и знак @

Имена участников системы безопасности не могут состоять только из точек, пробелов и знаков @. Любые точки или пробелы в начале имени пользователя отбрасываются.

Допускается применение одного и того же имени участника системы безопасности в разных доменах. Так, можно создать пользователя wjglenn в доменах hr.kd.ru и sales.kd.ru. Это не приведет к проблемам, поскольку составное, относительное составное и каноническое имена каждого объекта автоматически генерируются Active Directory и все равно позволяют глобально идентифицировать этот объект.

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

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

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

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

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

Цели создания OU

Делегирование прав администрирования - Существует чтобы облегчить жизнь администраторам

Ограничение видимости объектов

Управление применением групповой политикой

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

Архитектура основанная на объектах

Архитектура основанная на объектах

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

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

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

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

Архитектура основанная на задачах

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

Верхний уровень структуры OU

Верхний уровень структуры OU

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

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

Типы административных задач. Структура верхнего уровня, основанная на административных задачах, относительно постоянна. Какие бы реорганизации не происходили в компании, основные типы административных задач вряд ли сильно изменятся.

Типы объектов. Как и структура, основанная на задачах, структура, в которой OU верхнего уровня соответствуют типам объектов, обеспечивает устойчивость архитектуры к изменениям.

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

Нижний уровень OU

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

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

Задачи решаемые с помощью OU

Применение OU для ограничения видимости объектов

В некоторых организациях определенные объекты должны быть скрыты от определенных администраторов или пользователей. Даже если вы запретите изменение атрибутов объекта, пользователи, имеющие доступ к контейнеру с таким объектом, все равно смогут видеть, существует ли этот объект. Однако вы можете скрыть объекты, поместив их в OU и ограничив круг пользователей, которые имеют разрешение Список содержимого (List Contents) для этой OU. Тогда объекты, помещенные в контейнер, будут невидимы пользователям, не имеющим этого разрешения.

Применение OU для управления групповой политикой

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

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

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

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

Создавайте дополнительные OU, чтобы обойтись без фильтрации для изъятия группы пользователей из OU, связанной с GPO.

Контейнеры и OU по умолчанию

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

Контейнер Домен (Domain). Корневой контейнер в иерархии Active Directory. Административные разрешения, применяемые к этому контейнеру, могут влиять на дочерние контейнеры и объекты всего домена. Не делегируйте полномочия на управление этим контейнером - им должны управлять администраторы служб.

Контейнер Встроенный (Built-in). Содержит учетные записи администраторов служб, используемые по умолчанию.

Контейнер Пользователи (Users). Применяемое по умолчанию хранилище учетных записей новых пользователей и групп, создаваемых в домене. Также не следует изменять разрешения на доступ к этому контейнеру, действующие по умолчанию. Если требуется делегировать управление определенными пользователями, создайте новые OU и перенесите в них объекты пользователей. Кроме того, с контейнером Пользователи (Users) нельзя связать GPO. Чтобы применить групповую политику к пользователям, вы также должны создать OU и перенести в них пользователей.

Контейнер Компьютеры (Computers). Применяемое по умолчанию хранилище новых учетных записей компьютеров, создаваемых в домене. Как и в случае контейнера Пользователи (Users), чтобы назначить разрешения или GPO компьютерам, следует создать OU.

OU Контроллеры домена (Domain Controllers). Здесь по умолчанию хранятся учетные записи компьютеров - контроллеров домена. К этому OU по умолчанию применяется ряд политик. Чтобы обеспечить единообразие применения этих политик ко всем контроллерам домена, рекомендуется не переносить объекты-компьютеры, являющиеся контроллерами домена, из этого OU. По умолчанию этим OU управляют администраторы служб. Не делегируйте управление этим OU пользователям, которые не являются администраторами служб.

Стандартные модели структуры OU

Существует пять базовых моделей структуры OU:

На основе местоположения

На основе структуры организации

На основе функций

Смешанная - сначала по местоположению, затем по структуре организации

Смешанная - сначала по структуре, затем по местоположению

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

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

Модель по месту положения

Модель по месту положения

Преимущества:

OU Устойчивы к изменениям

Для центрального 1Т-отдела легко реализовать общедоменные политики

Легко определять положение ресурсов

Легко создавать новые OU при расширении компании

Недостатки:

Предполагает наличие в каждом филиале администратора

Архитектура не соответствует бизнес-структуре или административной структуре

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

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

Модель на основе структуры организации

Модель на основе структуры организации

Преимущества:

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

Поддерживает слияния и расширения

Удобна администраторам

Недостатки:

Уязвима при реорганизации, т.к. может потребоваться изменение верхнего уровня структуры ОU

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

Модель на основе функций

Модель на основе функций

Преимущества:

Устойчивость при реорганизациях

Недостаток:

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

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

Смешанная модель - по положению

Смешанная модель - по положению

Преимущества:

Поддерживает рост числа подразделений

Позволяет создавать зоны безопасности

Недостатки:

При реорганизации административного персонала, необходимо пересмотреть структуру

Необходимо взаимодействие между администраторами, работающими в разных отделах одного филиала

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

Смешанная модель - по структуре

Смешанная модель - по структуре

Преимущества:

Надежная защита на уровне отделов и подразделений

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

Недостатки:

Уязвимость при реорганизациях

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

Планирование стратегии управления учетными записями

Типы учетных записей

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

Компьютер. Всякий раз, когда в домен добавляется компьютер под управлением Microsoft Windows NT, Windows 2000, Windows XP или Windows Server 2003, для него создается учетная запись компьютера. Учетные записи компьютеров служат для аутентификации компьютеров, которые обращаются к сети и ресурсам домена.

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

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

InetOrgPerson. Учетная запись InetOrgPerson работает во многом аналогично учетной записи пользователя за исключением того, что учетные записи InetOrgPerson совместимы с другими службами каталогов, основанными на LDAP (Lightweight Directory Access Protocol). Это обеспечивает совместимость между Active Directory и другими системами.

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

Планирование учетных записей компьютеров

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

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

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

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

Планирование учетных записей пользователей

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

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

Типы учетных записей пользователей

В Windows Server 2003 существует два основных типа учетных записей пользователей.

Локальные учетные записи пользователей. Создаются в базе данных защиты локального компьютера и управляют доступом к ресурсам этого компьютера. Локальные учетные записи пользователей предназначены для управления доступом к изолированным компьютерам или к компьютерам, входящим в рабочую группу. Когда вы только что установили операционную систему на сервер, используются локальные учетные записи, управление которыми осуществляется через консоль Управление компьютером (Computer Management) в узле Локальные пользователи и группы (Local Users and Groups). Если вы сделаете сервер контроллером домена, инструмент Управление компьютером запретит доступ к этому узлу, и вместо него будет использоваться инструмент Active Directory - пользователи и компьютеры (Active Directory Users and Computers) (учетные записи пользователей на контроллерах домена хранятся в Active Directory).

Доменные учетные записи пользователей. Создаются в Active Directory и дают возможность пользователям входить в домен и обращаться к любым ресурсам сети. Вы можете создать доменную учетную запись пользователя с помощью Active Directory - пользователи и компьютеры (Active Directory Users and Computers). Такие учетные записи пользователей реплицируются на все контроллеры в домене, поэтому после репликации любой контроллер домена сможет аутентифицировать пользователя.

Встроенные учетные записи пользователей.

Windows автоматически создает несколько учетных записей пользователей, называемых встроенными. И на локальных компьютерах, и в доменах создается две ключевых учетных записи: и Гость (Guest) .

Учетная запись Администратор обладает наибольшими возможностями, поскольку она автоматически включается в группу Администраторы (Administrators) . Члены этой группы имеют высший уровень прав по управлению компьютером, им предоставляются почти все пользовательские права. Учетная запись Администратор уровня домена дает максимум возможностей по управлению доменом в целом; по умолчанию она включается в группу Администраторы домена (Domain Admins) [а администратор корневого домена леса, кроме того, входит в группы и ]. Учетную запись Администратор нельзя удалить, но ее можно переименовать (и это следует сделать для большей безопасности). Также следует задать для этой учетной записи непустой пароль и не передавать его другим пользователям.

Учетная запись Гость (Guest) - еще одна базовая встроенная учетная запись пользователя. Она предназначена для того, чтобы администратор мог задать единый набор разрешений для любых пользователей, которые иногда входят в сеть, но не имеют обычной учетной записи. Учетная запись Гость позволяет это сделать, так как автоматически включается в локальную группу Гости (Guests) . В среде, где есть домен, эта учетная запись также включается в группу Гости домена (Domain Guests) . По умолчанию учетная запись Гость отключена. И действительно, ее следует использовать только в сетях, не требующих особой защиты. Эту учетную запись нельзя удалить, но можно отключить и/или переименовать.

Правила именования учетных записей

Каждый пользователь должен иметь уникальное имя (логин) в домене

Длина имени не должна превышать 20 символов (из-за совместимости с предыдущими версиями Windows)

Имена не чувствительны к регистру букв

Имена не должны содержать символов: »/\:; = , + *?< >

Должна поддерживаться гибкая система именования

Учитывайте совместимость именования для других приложений (например для электронной почты)

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

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

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

Планирование политики управления паролями

Смена пароля не чаще чем 1 раз сутки

Длина пароля на должна быть короче 7 символов

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

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

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

Стратегия аутентификации

Планирование групп

Типы групп

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

Используются для объединения в одну административную единицу

Используются ОС

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

Используются приложениями (не ОС) для задач не связанных с защитой

Области действия групп

Глобальные группы

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

Локальные группы домена

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

Могут включать пользователей и глобальные группы в пределах леса

Универсальные группы

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

Существуют вне границ доменов

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

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

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

Вложение групп и их именование

Способ упорядочить пользователей

Глубина вложений должна быть минимальной (желательно 1 уровень вложенности)

Требования при именовании такие схожи с требованиями для пользователей, но длина до 64 символов

Active Directory позволяет вкладывать группы (т. е. помещать одни группы в другие). Вложение групп - эффективный способ упорядочения пользователей. При вложении групп стремитесь к тому, чтобы уровень вложения был минимальным. В сущности, лучше ограничиться одним уровнем вложения. Чем глубже вложение, тем сложнее поддерживать структуру разрешений.

Взаимодействие групп и пользователей

Избегайте выдачи разрешений учетным записям

Создавайте локальные группы домена

Для упорядочивания пользователей используйте глобальные группы

Помещайте глобальные группы в локальные группы домена

Не включайте пользователей в универсальные группы

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

Планирование групповой политики

Групповая политика - набор параметров конфигурации пользователей и компьютеров. Называется объектом групповой политики (GPO)

Существует два типа параметров групповой политики:

Конфигурация компьютера

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

Конфигурация пользователя

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

Не зависимо от типа есть три категории:

Параметры программ

Параметры Windows

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

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

Групповая политика - набор параметров конфигурации пользователей и компьютеров, который можно связать с компьютерами, сайтами, доменами и OU в Active Directory. Такой набор параметров групповой политики называется объектом групповой политики (Group Policy Object, GPO).

Любой компьютер под управлением Windows 2000, Windows ХР или Windows Server 2003 (независимо от того, входит он в Active Directory или нет) содержит один локальный GPO, в котором заданы политики, применяемые к этому компьютеру. Если компьютер входит в Active Directory, к нему можно применить несколько дополнительных GPO, не являющихся локальными.

Существует два основных типа параметров групповой политики.

Параметры программ

Параметры применяемые для установки ПО на клиентских ПК (поддерживаются ОС Windows 2000 и более новые)

Используются два компонента:

Служба установки Windows

• Установка и обновление ПО в соответствии с инструкциями в установочных пакетах

Установочные пакеты Windows

• Исполняемые файлы сценариев со всеми инструкциями (msi)

Узел Параметры программ (Software Settings) содержит параметры, которые можно использовать для развертывания ПО на клиентских компьютерах, к которым применяется групповая политика. Для этого клиентские компьютеры должны работать под управлением Windows 2000 Professional, Windows 2000 Server, Windows XP Professional, Windows XP 64-Bit Edition или Windows Server 2003 и быть членами домена. Вы можете задать, для каких пользователей или на какие компьютеры будет установлено ПО, при необходимости указать обновления и даже удалить ПО. Для поддержки этой функции нужны два взаимодействующих компонента.

Служба установки Windows (Windows Installer service) - служба, которая развертывает и обновляет ПО в соответствии с инструкциями в установочных пакетах Windows (Windows Installer packages)

Установочные пакеты Windows (Windows Installer Packages) - исполняемые файлы сценариев со всеми инструкциями, нужными Windows Installer для установки, обновления или восстановления ПО. Файлы Windows Installer Package имеют расширение msi.

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

Существует два способа развертывания ПО с помощью групповой политики: публикация (publishing) и назначение (assigning) . Когда приложение назначается пользователю, создается ярлык, доступный пользователю и показываемый в меню Пуск (Start) или на рабочем столе этого пользователя. Это называется предложением (advertising) приложения пользователю. Когда пользователь щелкает ярлык (или открывает файл, связанный с программой), запускается программа установки. Когда приложение назначается компьютеру, приложение устанавливается при первом запуске компьютера после назначения.

Если вы публикуете приложение, оно становится доступным пользователям, которые могут установить его, когда пожелают. Приложения можно публиковать только для пользователей - сделать это для компьютера нельзя. Приложение становится доступным в апплете Установка и удаление программ (Add/Remove Programs) панели управления (Control Panel) и устанавливается по запросу пользователя, если тот откроет файл, связанный с программой.

Параметры Windows

Сценарии (Scripts). При настройке конфигурации компьютера можно задать сценарии, которые выполняются при его включении или выключении. При настройке конфигурации для пользователя можно задать сценарии, выполняемые при входе или выходе пользователя. Сценарии можно писать на любое языке сценариев с поддержкой ActiveX, в том числе на VBScript, JScript, Perl , языке командных файлов MS -DOS и др.

Параметры безопасности (Security Settings). Это параметры безопасности, задаваемые для компьютеров и пользователей.

Настройка Internet Explorer (Internet Explorer Maintenance). Этот узел доступен только для пользователей. Он служит для управления работой Internet Explorer на клиентских компьютерах.

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

Перенаправление папок (Folder Redirection). И эти параметры доступны только для конфигураций пользователей. Они позволяют переопределить специальные папки Windows [такие как Мои документы (My Documents), Главное меню (Start Menu) и Application Data], изменив их местонахождение по умолчанию на сетевой каталог. Благодаря этому можно централизованно управлять папками пользователей.

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

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

Узел	Конфигурация компьютера	Конфигурация пользователя	Описание
Панель управления	Неприменимы	X	Определяет средства панели управления, доступные пользователю
Рабочий стол	Неприменимы	X	Задает внешний вид рабочего стола пользователя
Сеть	X	X	Управляет параметрами Автономные файлы и Сеть и удаленный доступ к сети
Принтеры	X	Неприменимы	Параметры принтеров
Панель задач и меню «Пуск»	Неприменимы	X	Параметры конфигурации для меню пуск и панели задач пользователя
Система	X	X	Управление входом/выходом, запуск/остановка
Компоненты Windows	X	X	Управление встроенными компонентами Windows

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

Локальный GPO - обрабатывается локальный GPO компьютера и применяются все параметры защиты, заданные в этом GPO.

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

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

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

Наследование групповой политики

Дочерние контейнеры наследуют групповую политику от родительских контейнеров

Есть возможность переопределить унаследованные параметры

В GPO можно задавать активность/неактивность и не определенность параметров

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

Дополнительные механизмы наследования:

• Не перекрывать

  Блокировать наследование политик

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

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

Если GPO определены и для родителя, и для потомка и если заданные в них параметры совместимы, эти параметры комбинируются. Например, если в родительской OU задана определенная длина пароля, а в дочерней OU - некая политика блокировки учетных записей, будут использоваться оба этих параметра. Если параметры несовместимы, то по умолчанию с дочерним контейнером связывается значение параметра, переопределяющее значение параметра, который связан с родительским контейнером.

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

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

Не перекрывать (No Override). Когда вы связываете GPO с контейнером, можно выбрать Не перекрывать, чтобы параметры, заданные в этом GPO, не переопределялись параметрами в GPO, связанных с дочерними контейнерами. Это гарантирует, что для дочерних контейнеров будет применяться заданная вами политика.

Блокировать наследование политики (Block Policy Inheritance). При выборе этого параметра контейнер не наследует параметры GPO, заданные для родительского контейнера. Однако, если для родительского контейнера указан параметр Не перекрывать, дочерний контейнер не может заблокировать наследование от своего родителя.

Планирование структуры GPO

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

Связывание GPO с доменом

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

Связывание GPO с сайтом

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

Связывание GPO с OU

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

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

Windows 95/98/Ме не поддерживают групповую политику.

Windows NT 4.0 и более ранних версий не поддерживает групповую политику.

Windows 2000 Professional и Server поддерживают многие параметры групповой политики, доступные в Windows Server 2003, но не все. Неподдерживаемые параметры игнорируются.

Windows XP Professional, Windows XP 64-bit Edition и Windows Server 2003 полностью поддерживают групповую политику.

Планирование сайтов

Планирование сайтов

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

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

Сайты не входят в пространство имен Active Directory- Пользователь, просматривающий логическое пространство имен, видит компьютеры и пользователей, сгруппированных в домены и OU, но сайты при этом не показываются. Однако имена сайтов используются в записях DNS (Domain Name System), поэтому у сайтов должны быть допустимые DNS -имена.

Если вы не конфигурируете в Active Directory собственные сайты, все контроллеры доменов автоматически входят в один сайт по умолчанию с именем Default-First-Site-Name, который создается при создании первого домена.

В целом, сайты служат для управления трафиком по WAN -каналам. А конкретнее, сайты используются для управления: трафиком входа на рабочие станции; трафиком репликации; распределенной файловой системой (Distributed File System, DPS) ; Сведения о TCP/IP-подсетях филиалов

Наблюдает за сетевыми соединениями и задает цены связей между сайтами.

Планирование контроллеров доменов

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

Как определить, нужен ли контроллер домена для данного участка

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

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

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

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

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

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

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

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

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

Как определить количество необходимых контроллеров доменов

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

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

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

Если данный домен сайта охватывает от 1000 до 10 000 пользователей, в нем требуется установить не менее двух контроллеров.

Для каждых дополнительных 5000 пользователей следует добавлять по одному контроллеру. Например, если на сайт входят 20 000 пользователей домена, в этом домене следует установить четыре контроллера.

Как разместить контроллеры корневого домена леса

Первый домен, создаваемый в новом лесу, называется корневым доменом леса и занимает особое место среди доменов леса. Корневой домен леса закладывает основу структуры леса и пространства имен. Кроме того, данные о группах Администраторы предприятия (Enterprise Admins) и Администраторы схемы (Schema Admins) уровня леса так-же хранятся в корневом домене леса.

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

Планирование серверов - хозяев операций

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

В Windows Server 2003 две роли хозяев операций уровня леса.

Хозяин схемы (Schema Master). Первый контроллер домена в лесу принимает роль хозяина схемы и отвечает за поддержку и распространение схемы на остальную часть леса. Он поддерживает список всех возможных классов объектов и атрибутов, определяющих объекты, которые находятся в Active Directory- Если схему нужно обновлять или изменять, - как, например, в случае установки приложения, которое должно модифицировать классы или атрибуты схемы, - то делать это следует на хозяине схемы [т. е. должен быть доступен контроллер домена (DC), имеющий роль хозяина схемы] одному из членов группы Администраторы схемы (Schema Admins) . Если DC, являющийся хозяином схемы, недоступен, а вы должны внести изменения в схему, можно передать эту роль другому DC.

Хозяин именования доменов (Domain Naming Master). Протоколирует добавление и удаление доменов в лесу и жизненно необходим для поддержания целостности доменов. Хозяин именования доменов запрашивается при добавлении к лесу новых доменов. Если хозяин именования доменов недоступен, добавление новых доменов невозможно; однако при необходимости эта роль может быть передана другому контроллеру. Здесь есть одна тонкость, о которой важно помнить в среде с несколькими доменами: хозяин именования доменов должен быть еще и сервером глобального каталога. Дело вот в чем. Чтобы проверить, является ли уникальным домен, создаваемый в лесу, хозяин именования доменов запрашивает глобальный каталог. Эти две роли автоматически назначаются первому контроллеру домена в лесу. В однодоменной среде (или в лесу с нескольким доменами, в котором все контролле-ры корневого домена леса хранят глобальный каталог) вы должны оставить обе роли хозяев операций уровня леса первому контроллеру, созданному в корневом домене леса.

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

Роли хозяев операций уровня домена

В Windows Server 2003 три роли хозяев операций уровня домена.

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

Хозяин RID отвечает за выделение диапазонов относительных идентификаторов (RID) всем контроллерам в домене. Идентификатор защиты (security identifier, SID) - уникальный идентификатор каждого объекта в домене. SID в Windows Server 2003 состоит из двух частей. Первая часть общая для всех объектов в домене; для создания уникального SID к этой части добавляется уникальный RID. Вместе они уникально идентифицируют объект в домене и указывают, где он был создан.

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

Планирование серверов глобального каталога

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

Раздел схемы. Хранит определения всех объектов, которые можно создать в лесу, а также их атрибутов. В лесу существует только один раздел схемы. Его копия реплицируется на все контроллеры доменов, входящие в лес.

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

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

Другая функция глобального каталога, полезная независимо от того, сколько доме-нов в вашей сети, - участие в процессе аутентификации при входе пользователя в сеть. Когда пользователь входит в сеть, указывая имя участника системы безопасности (user principal name, UPN) вида [email protected] , оно сначала сверяется с содержимым глобального каталога. Это позволяет входить в сеть с компьютеров в доменах, отличных от того, где хранится нужная пользовательская учетная запись. Кроме того, это позволяет входить в сеть, когда контроллер домена недоступен, например из-за того, что не работает WAN -канал.

Планирование числа пользователей контроллеров доменов

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

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

Определение требований к процессорам

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

Если пользователей меньше 500, контроллеру домена под управлением Windows Server 2003 достаточно одного процессора с тактовой частотой 850 МГц или выше.

Если количество пользователей находится в пределах от 500 до 1500, контроллеру домена под управлением Windows Server 2003 требуется два процессора с тактовой частотой 850 МГц или выше.

Если пользователей больше 1500, контроллеру домена под управлением Windows Server 2003 нужно четыре процессора с тактовой частотой 850 МГц или выше.

Определение требований к дисковому пространству

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

На диске, на который устанавливается ОС Windows Server 2003, должно быть примерно 2 Гб свободного дискового пространства.

Определив минимальный объем дискового пространства, необходимый контроллерам доменов, вы должны выделить дополнительное дисковое пространство на тех контроллерах домена, на которых будет храниться глобальный каталог. Если в лесу только один домен, назначение контроллеру домена роли сервера глобального каталога не приведет к увеличению размера БД. Однако, если в лесу более одного домена, для каждого дополнительного домена размер глобального каталога увеличивается приблизительно на 50% от размера базы данных этого домена.

Определение требований к памяти

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

Если пользователей меньше 500, контроллеру домена требуется 512 Мб памяти.

Если количество пользователей находится в пределах от 500 до 1000, контроллеру домена требуется 1 Гб памяти.

Если пользователей больше 1000, контроллеру домена требуется 2 Гб памяти.

Планирование стратегии репликации

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

Процесс репликации

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

Внутрисайтовая и межсайтовая репликация

Внутрисайтовая (между контроллерами домена одного сайта) и межсайтовая репликация (между контроллерами домена, относящимися к разным сайтам) выполняется по-разному.

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

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

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

SMTP применяется при репликации между сайтами, не связанными постоянными соединениями (необходимыми для работы RPC). Одно из ограничений при использовании SMTP - он не позволяет реплицировать информацию раздела домена (domain partition information) на DC, входящие в домен. Поскольку SMTP применяется только при репликации между сайтами, проблем с репликацией информации раздела домена внутри домена не возникает (в этом случае автоматически используется RPC). То есть SMTP полезен лишь при репликации схемы и глобального каталога.

Как выполняется репликация

Каждый контроллер домена в сайте представляется объектом-сервером. У каждого объекта-сервера есть дочерний объект NTDS Settings, управляющий репликацией данных контроллера домена внутри сайта, а у каждого объекта NTDS Settings - объект-соединение, в котором хранятся атрибуты соединения и который представляет коммуникационный канал, применяемый при репликации данных с одного контроллера домена на другой. Для репликации нужно, чтобы на обеих сторонах было по объекту-соединению.

Сервис Knowledge Consistency Checker (КСС) автоматически создает набор объек-тов-соединений для репликации с одного контроллера домена на другой. Однако при необходимости можно создать объекты-соединения вручную.

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

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

Мосты связей сайтов (site-link bridges) - логические соединения, использующие связи сайтов в качестве транспорта. Когда транзитивность связей включена, между всеми сайтами автоматически создаются логические мосты связей сайтов. А когда транзитивность связей отключена, вы должны создавать такие мосты вручную. На рис. показана простая группа из четырех сайтов, соединенных связями по принципу карусели. Если транзитивность связей для этих сайтов отключена, вам придется вручную создать мосты связей сайтов, чтобы сделать возможной репликацию между всеми сайтами. В основном такие мосты служат для того, чтобы при отключенной транзитивности связей у каждого сайта был путь репликации к другим сайтам. Рассуждайте следующим образом. Когда транзитивность связей включена, между всеми связями сайтов имеются мосты, поэтому все сайты могут обмениваться данными репликации друг с другом. А когда транзитивность отключена, вы должны самостоятельно создать мосты, поскольку связаны только те сайты, между которыми вручную сконфигурированы связи. Мосты связей сайтов передают трафик репликации между соответствующими сайтами по цепочке из нескольких связей.

Назначение цен связям сайтов

Всем связям сайтов назначается цена, которая определяет, насколько данный путь лучше или хуже других связей. По умолчанию все связи имеют цену 100. Если одну связь сделать дороже другой, то при репликации (и при работе других приложений и служб, например Domain Controller Locator ) предпочтение будет отдаваться связи с меньшей ценой.

Серверы - плацдармы

Серверы - плацдармы

После создания связей сайтов КСС автоматически назначает один или несколько контроллеров в каждом домене на роль серверов-плацдармов (bridgehead servers) , или серверов репликации между сайтами.

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

Соединения репликации, создаваемые КСС, случайным образом распределяются между всеми серверами сайта, которые могут быть плацдармами репликации между сайтами, - это делается для распределения нагрузки по поддержке репликации. Обычно КСС распределяет соединения, только когда создаются новые объекты-соединения. Однако в Windows Server 2003 Resource Kit имеется утилита Active Directory Load Balancing (ADLB) , которую можно использовать для перераспределения ролей серверов-плацдармов в любое другое время (например, при добавлении новых контроллеров домена).

Дополнительные задачи при проектировании домена

Планирование DNS

Планирование WINS

Планирование инфраструктуры сети и маршрутизации

Планирование подключения к Интернету

Планирование стратегии удаленного доступа

Итоги

Были рассмотрены вопросы связанные с технологией построение службы каталогов на базе AD реализованной в ОС Windows Server 2003

Основные сведения о доменах Active Directory

Короче говоря, AD позволяет использовать единую точку администрирования для всех публикуемых ресурсов. В основе AD используется стандарт именования X.500, система доменных имён – Domain Name System (DNS) для определения местоположения, и в качестве основного протокола используется Lightweight Directory Access Protocol (LDAP).

AD объединяет логическую и физическую структуру сети. Логическая структура AD состоит из следующих элементов:

• организационное подразделение (organizational unit) – подгруппа компьютеров, как правило, отражающая структуру компании;
• домен (domain) – группа компьютеров, совместно использующих общую базу данных каталога;
• дерево доменов (domain tree) – один или несколько доменов, совместно использующих непрерывное пространство имен;
• лес доменов (domain forest) – одно или несколько деревьев, совместно использующих информацию каталога.

К физической структуре относятся следующие элементы:

• подсеть (subnet) – сетевая группа с заданной областью IP-адресов и сетевой маской;
• сайт (site) – одна или несколько подсетей. Сайт используется для настройки доступа к каталогу и для репликации.

В каталоге хранятся сведения трех типов: данные домена, данные схемы и данные конфигурации. AD использует только контроллеры доменов. Данные домена реплицируются на все контроллеры домена. Все контроллеры домена равноправны, т.е. все вносимые изменения с любого контроллера домена будут реплицированы на все остальные контроллеры домена. Схема и данные конфигурации реплицируются во все домены дерева или леса. Кроме того, все объекты индивидуального домена и часть свойств объектов леса реплицируются в глобальный каталог (GC). Это означает, что контроллер домена хранит и реплицирует схему для дерева или леса, информацию о конфигурации для всех доменов дерева или леса и все объекты каталога и свойства для собственного домена.

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

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

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

В каждом лесе AD существуют следующие роли:

• Хозяин схемы (schema master) – управляет обновлениями и изменениями схемы каталога. Для обновления схемы каталога необходим доступ к хозяину схемы. Чтобы определить, какой сервер в данное время является хозяином схемы в домене, нужно в окне командной строки набрать команду dsquery server -hasfsmo schema
• Хозяин именования доменов (domain naming master) – управляет добавлением и удалением доменов в лесу. Чтобы добавить или удалить домен требуется доступ к хозяину именования доменов. Чтобы определить, какой сервер в данное время является хозяином именования доменов, в окне командной строки введите dsquery server -hasismo name

Эти роли, общие для всего леса в целом и являются в нем уникальными.

В каждом домене AD обязательно существуют следующие роли:

• Хозяин относительных идентификаторов (relative ID master) – выделяет относительные идентификаторы контроллерам доменов. Каждый раз при создании объекта пользователя, группы, или компьютера, контроллеры назначают объекту уникальный идентификатор безопасности, состоящий из идентификатора безопасности домена и уникального идентификатора, который был выделен хозяином относительных идентификаторов. Чтобы определить, какой сервер в данное время является хозяином относительных идентификаторов домена, в командной строке введите dsquery server -hasfsmo rid
• Эмулятор PDC (PDC emulator) – в смешанном или промежуточном режиме домена действует как главный контроллер домена Windows NT. Он аутентифицирует вход в Windows, обрабатывает изменения пароля и реплицирует обновления на BDC, если они есть. Чтобы определить, какой сервер в данное время является эмулятором PDC домена, в командной строке введите dsquery server -hasfsmo pdc
• Хозяин инфраструктуры (infrastructure master) – обновляет ссылки объектов, сравнивая данные своего каталога с данными GC. Если данные устарели, он запрашивает из GC обновления и реплицирует их на остальные контроллеры домена. Чтобы определить, какой сервер в данное время является хозяином инфраструктуры домена, в командной строке введите dsquery server -hasfsmo infr

Эти роли, общие для всего домена и должны быть в нем уникальны.

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

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

Инсталляция контроллера домена (DC) на базе Windows Server 2003 с помощью мастера установки Active Directory

Установка контроллера домена производится с помощью мастера Active Directory Installation Wizard. Чтобы повысить статус сервера до контроллера домена необходимо убедиться в выполнении всех необходимых для этого требований:

1. На сервере должен быть хотя бы один раздел NTFS для размещения системного тома SYSVOL.
2. Сервер должен иметь доступ к DNS серверу. Желательно установить службу DNS на этом же сервере. Если используется отдельный сервер, то необходимо убедиться, что он поддерживает ресурсные записи Service Location (RFC 2052) и протокол Dynamic Updates (RFC 2136).
3. Необходимо иметь учётную запись с правами локального администратора на сервере.

Рассмотрим подробно повышение роли сервера до контроллера домена Active Directory по шагам:

1. Чтобы запустить мастер повышения статуса сервера необходимо в меню Start (Пуск) выбрать Run… (Выполнить…), ввести dcpromo и нажать OK.
2. После запуска мастера установки Active Directory нажмите Next (Далее).
3. На странице Domain Controller Type (Тип контроллера домена) выберите вариант Domain controller for a new domain (Контроллер домена в новом домене). Нажмите Next .

   
   

4. На странице Create New Domain (Создать новый домен) выберите вариант Domain in a new forest (Новый домен в новом лесу). Нажмите Next .
5. На странице New Domain Name (Новое имя домена) введите полное (FQDN) DNS-имя для создаваемого нового домена леса Active Directory (например, mydomain.local). Не рекомендуется использовать одиночное (single label) имя домена (например, mydomain). Нажмите Next .
6. Проверьте NetBIOS-имя на странице NetBIOS Domain Name (NetBIOS-имя домена). Хотя домены Active Directory обозначаются в соответствии со стандартами именования DNS, необходимо так же задать NetBIOS-имя. NetBIOS-имена по возможности должны совпадать с первой меткой DNS-имени домена. Если первая метка DNS-имени домена Active Directory отличается от его NetBIOS-имени, в качестве полного доменного имени используется DNS-имя, а не NetBIOS-имя. Нажмите Next .
7. На странице Database and Log Folders (Папки базы данных и журналов) введите путь, по которому будут располагаться папки базы данных и журналов, или нажмите кнопку Browse (Обзор), чтобы указать другое расположение. Убедитесь, что на диске достаточно места для размещения базы данных каталога и файлов журналов, чтобы избежать проблем при установке или удалении Active Directory. Мастеру установки Active Directory необходимо 250 МБ дискового пространства для установки базы данных Active Directory и 50 МБ для файлов журналов. Нажмите Next .
8. На странице Shared System Volume (Общий доступ к системному тому) укажите расположение, в которое следует установить папку SYSVOL, или нажмите кнопку Browse (Обзор), чтобы выбрать расположение. Папка SYSVOL должна находиться на томе NTFS, так как в ней находятся файлы, реплицируемые между контроллерами домена в домене или лесу. Эти файлы содержат сценарии, системные политики для Windows NT 4.0 и более ранних версий, общие папки NETLOGON и SYSVOL и параметры групповой политики. Нажмите Next .
9. На странице DNS Registration Diagnostics (Диагностика регистрации DNS) проверьте правильность установки параметров. Если в окне Diagnostic Results (Результаты диагностики) отображается сообщение об ошибках диагностики, нажмите кнопку Help (Справка) для получения дополнительных инструкций по устранению ошибки. Нажмите Next .
10. На странице Permissions (Разрешения) выберите требуемый уровень совместимости приложений с операционными системами pre-Windows 2000, Windows 2000 или Windows Server 2003. Нажмите Next .
11. На странице Directory Services Restore Mode Administrator Password (Пароль администратора для режима восстановления) введите и подтвердите пароль для учетной записи администратора режима восстановления Active Directory для данного сервера. Этот пароль необходим для восстановления резервной копии состояния системы данного контроллера домена в режиме восстановления Active Directory. Нажмите Next .
12. Проверьте сведения на странице Summary (Сводка) и нажмите Next .
13. После завершения установки нажмите кнопку Finish (Готово). Для перезагрузки компьютера нажмите кнопку Restart Now (Перезагрузить сейчас), чтобы изменения вступили в силу.

Основы управления доменом Active Directory

Ряд средств в оснастках Microsoft Management Console (MMC) упрощает работу с Active Directory.

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

Для запуска оснастки Active Directory Users and Computers (Active Directory – пользователи и компьютеры) выберите одноименную команду в меню Administrative Tools (Администрирование).

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

Получив доступ к домену вы увидите стандартный набор папок:

• Saved Queries (Сохраненныезапросы) – сохраненные критерии поиска, позволяющие оперативно повторить выполненный ранее поиск в Active Directory;
• Builtin – список встроенных учетных записей пользователей;
• Computers – контейнер по умолчанию для учетных записей компьютеров;
• Domain Controllers – контейнер по умолчанию для контроллеров домена;
• ForeignSecurityPrincipals – содержит информацию об объектах из доверенного внешнего домена. Обычно эти объекты создаются при добавлении в группу текущего домена объекта из внешнего домена;
• Users – контейнер по умолчанию для пользователей.

Некоторые папки консоли по умолчанию не отображаются. Чтобы вывести их на экран, выберите в меню View (Вид) команду Advanced Features (Дополнительные функции). Вот эти дополнительные папки:

• LostAndFound – потерявшие владельца, объекты каталога;
• NTDS Quotas – данные о квотировании службы каталогов;
• Program Data – сохраненные в службе каталогов данные для приложений Microsoft;
• System – встроенные параметры системы.

Вы можете самостоятельно добавлять папки для организационных подразделений в дерево AD.

OU

Рассмотрим пример создания учётной записи пользователя домена. Чтобы создать учётную запись пользователя щелкните правой кнопкой контейнер, в который вы хотите поместить учетную запись пользователя, выберите в контекстном меню New (Создать), а затем – User (Пользователь). Откроется окно мастера New Object – User (Новый объект – Пользователь):

1. Введите имя, инициал и фамилию пользователя в соответствующих полях. Эти данные потребуются для создания отображаемого имени пользователя.
2. Отредактируйте полное имя. Оно должно быть уникальным в домене и иметь длину не более 64 символов.
3. Введите имя для входа. С помощью раскрывающегося списка выберите домен, с которым будет связана учетная запись.
4. При необходимости измените имя пользователя для входа в системы с ОС Windows NT 4.0 или более ранними версиями. По умолчанию в качестве имени для входа в системы с предыдущими версиями Windows используются первые 20 символов полного имени пользователя. Это имя также должно быть уникальным в домене.
5. Щёлкните Next (Далее). Укажите пароль для пользователя. Его параметры должны соответствовать вашей политике паролей;
   Confirm Password (Подтверждение) – поле, используемое для подтверждения правильности введенного пароля;
   User must change password at next logon (Требовать смену пароля при следующем входе в систему) – если этот флажок установлен, пользователю придется изменить пароль при следующем входе в систему;
   User cannot change password (Запретить смену пароля пользователем) – если этот флажок установлен, пользователь не может изменить пароль;
   Password never expires (Срок действия пароля не ограничен) – если этот флажок установлен, время действия пароля для этой учетной записи не ограничено (этот параметр перекрывает доменную политику учетных записей);
   Account is disabled (Отключить учетную запись) – если этот флажок установлен, учетная запись не действует (параметр удобен для временного запрета использования кем-либо этой учетной записи).

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

Сценарии входа определяют команды, выполняемые при каждом входе в систему. Они позволяют настроить системное время, сетевые принтеры, пути к сетевым дискам и т.д. Сценарии применяются для разового запуска команд, при этом параметры среды, задаваемые сценариями, не сохраняются для последующего использования. Сценариями входа могут быть файлы сервера сценариев Windows с расширениями.VBS, .JS и другие, пакетные файлы с расширением.ВАТ, командные файлы с расширением.CMD, программы с расширением.ЕХЕ.

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

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

• создавать централизованно управляемые специальные папки, например My Documents (Мои документы);
• управлять доступом к компонентам Windows, системным и сетевым ресурсам, инструментам панели управления, рабочему столу и меню Start (Пуск);
• настроить сценарии пользователей и компьютеров на выполнение задачи в заданное время;
• настраивать политики паролей и блокировки учетных записей, аудита, присвоения пользовательских прав и безопасности.

Помимо задач управления пользовательскими учётными записями и группами существует масса других задач управления доменом. Для этого служат другие оснастки и приложения.

Оснастка Active Directory Domains and Trusts (Active Directory – домены и доверие) служит для работы с доменами, деревьями доменов и лесами доменов.

Оснастка Active Directory Sites and Services (Active Directory – сайты и службы) позволяет управлять сайтами и подсетями, а так же межсайтовой репликацией.

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

• Dsadd – добавляет в Active Directory компьютеры, контакты, группы, организационные подразделения и пользователей. Для получения справочной информации введите dsadd /? , например dsadd computer/?
• Dsmod – изменяет свойства компьютеров, контактов, групп, организационных подразделений, пользователей и серверов, зарегистрированных в Active Directory. Для получения справочной информации введите dsmod /? , например dsmod server /?
• Dsmove – перемещает одиночный объект в новое расположение в пределах домена или переименовывает объект без перемещения.
• Dsget – отображает свойства компьютеров, контактов, групп, организационных подразделений, пользователей, сайтов, подсетей и серверов, зарегистрированных в Active Directory. Для получения справочной информации введите dsget /? , например dsget subnet /?
• Dsquery – осуществляет поиск компьютеров, контактов, групп, организационных подразделений, пользователей, сайтов, подсетей и серверов в Active Directory по заданным критериям.
• Dsrm – удаляет объект из Active Directory.
• Ntdsutil – позволяет просматривать информацию о сайте, домене или сервере, управлять хозяевами операций (operations masters) и обслуживать базу данных Active Directory.

Так же существуют средства поддержки Active Directory:

• Ldp – Осуществляет в Active Directory Administration операции по протоколу LDAP.
• Replmon – Управляет репликацией и отображает ее результаты в графическом интерфейсе.
• Dsacls – Управляет списками ACL (списками управления доступом) для объектов Active Directory.
• Dfsutil – Управляет распределенной файловой системой (Distributed File System, DFS) и отображает сведения о её работе.
• Dnscmd – Управляет свойствами серверов, зон и записей ресурсов DNS.
• Movetree – Перемещает объекты из одного домена в другой.
• Repadmin – Управляет репликацией и отображает её результаты в окне командной строки.
• Sdcbeck – Анализирует распространение, репликацию и наследование списков управления доступом.
• Sidwalker – Задает списки управления доступом для объектов, в прошлом принадлежавших перемещенным, удаленным или потерянным учетным записям.
• Netdom – Позволяет управлять доменами и доверительными отношениями из командной строки.

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

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

• "ПУСК" ? "Насройка" ? "Панель управления" ? "Администрирование" ? "Active Directory - пользователи и компьютеры";
• Или в меню: "ПУСК" ? "Выпонить" введите команду dsa.msc .

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

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

На данном этапе нас интересует папка "Users" (Пользователи). Нажимаем на ней правой кнопкой мышки и выбираем "Создать" ? "Пользователь"

Перед нами окно для создания пового пользователя. Задаем необходимые параметры и переходим дальше.

Если все было сделано правильно, то программа выдаст сообщение о создании нового пользователя.

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

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

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

Вкладка "Член групп": тут можно включить нашего пользователя в различные группы.

Вкладка "Удаленное управление" позволяет разрешить/запретить пользователю подключаться к домену через удаленное соединение.

Еще одна интереная вкладка "Учетная запись", тут можно поменять имя пользователя и задать различные параметры для пароля.

Добавление компьютера в домен

Для подключения компьютера к домену все готово. Компьютеры, работающие под управлением Windows 2000/XP, при подключении к серверу будут добавляться автоматически в группу Computers. Для этого на каждом клиенте нужно выбрать «Мой Компьютер» ? «Свойства» ? «Имя компьютера .

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

Если в вашей сети есть ПК, работающие под Windows 98, то они подключаются как клиенты Active Directory; в этом случае учетные записи компьютера не создаются. Для их работы необходимо установить программу dsclient.exe, которая имеется на установочном диске Win2k3.

Итак задаем имя домена и нажимаем ОК.

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

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

Если все хорошо, то мы увидим окно об успешном подключению к домену.

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

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

На этом пока все, продолжение в следующих статьях...{odnaknopka}

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

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

Лабораторная работа № 6. Создание домена Windows Server 2003 Цели работы: научиться создавать домен Windows Server 2003; научиться устанавливать службу каталога Active Directory; изучить структуру службы каталога Active Directory. Задание 1. Установить на сервере службу катало...

Лабораторная работа № 6 .

« Создание домена Windows Server 2003 »

Цели работы:

1. научиться создавать домен Windows Server 2003;
2. научиться устанавливать службу каталога Active Directory ;
3. изучить структуру службы каталога Active Directory .

Задание 1. Установить на сервере службу каталога Active Directory , создать домен mydomain. ru.

Задание 2 . Просмотреть созданный домен одним из способов.

Задание 3. Проверить работу службы DNS с помощью оснастки DNS.

Задание 4. Удалить службу Active Directory .

А также другие работы, которые могут Вас заинтересовать
71939.		Декабризм, и его значение в истории России	365 KB
	Движение декабристов является событием, длительное время приковывающим внимание историков. Это связано с тем, что события более чем 170-летней давности оказали значительное влияние на последующее развитие России; декабристы были первыми русскими революционерами, которые организовали открытое восстание против царизма.
71940.		ЗАКОНОДАТЕЛЬНЫЕ И ИНЫЕ НОРМАТИВНЫЕ ПРАВОВЫЕ АКТЫ, УСТАНАВЛИВАЮЩИЕ ПОРЯДОК РАССЛЕДОВАНИЯ И УЧЕТА НЕСЧАСТНЫХ СЛУЧАЕВ НА ПРОИЗВОДСТВЕ	91 KB
	Формы документов необходимых для расследования и учета несчастных случаев на производстве утвержденные Минтрудом России следующие: извещение о групповом несчастном случае тяжелом несчастном случае несчастном случае со смертельным исходом; акт о несчастном случае...
71941.		Пыль. Средства индивидуальной защиты от пыли	179.5 KB
	Для этой цели используется классификация пыли по ее дисперсности и способу образования. Характер действия пыли на организм зависит от физико-химических свойств пылевых частиц. Ядовитые пыли свинца ртути мышьяка и т. растворяясь в биологических средах действуют как введенный в организм...
71942.		Пенсии по случаю потери кормильца	24.33 KB
	Пенсии по случаю потери кормильца - это ежемесячные денежные выплаты алиментарного характера из фонда социальной защиты населения или государственного бюджета назначаемые нетрудоспособным членам семьи умершего кормильца состоявшим на его иждивении в размерах соизмеримых с заработком кормильца.
71943.		Альберт Великий	41.55 KB
	После распада Римской Империи, сельское хозяйство на её западных территориях, занятых варварами пришло в упадок. Были утрачены знания и технологии Империи, площадь пахотных земель значительно сократилась.
71944.		Александр Васильевич Советов	149.42 KB
	Александр Васильевич Советов возглавлял Вольное Экономическое общество (ВЭО), в котором его первый отдел объединял агрономов, экономистов и естествоиспытателей, таких как Д.И. Менделеев, К.А. Тимирязев, а с 1875 года - Докучаев.
71945.		ДЕМОГРАФИЧЕСКАЯ ПОЛИТИКА	111.5 KB
	Она призвана воздействовать на формирование желательного для общества режима воспроизводства населения сохранения или изменения тенденций в области динамики численности и структуры населения темпов их изменений динамики рождаемости смертности семейного состава расселения внутренней...
71947.		Понятие сети ССП и ее базовые принципы	180.57 KB
	Пользователи получили доступ к услугам, о которых 10–15 лет назад и не задумывались. E-mail, Интернет, сотовый телефон стали обычными атрибутами повседневной жизни. За короткое время мы так привыкли к практически ежедневному появлению всевозможных новинок, что сами начали выдвигать требования по предоставлению новых услуг и приложений.