Книги, научные публикации Pages:     | 1 | 2 | 3 | 4 | 5 |   ...   | 8 | -- [ Страница 1 ] --

РУССКИ Федор Зубанов Active Directory подход профессионала Издание 2-е, исправленное Москва 2003

. Р У С С К А Я ШИШ УДК 004 ББК 32.973.81-018.2 391 Зубанов Ф. В.

391 Active Directory: подход профессионала. Ч 2-е изд., испр. Ч М.: Издательско-торговый дом Русская Редакция, 2003. 544 с.: ил.

ISBN 5-7502-OJ 18-Х В книге обобщен богатый опыт Microsoft Consulting Services в обла сти проектирования, развертывания и эксплуатации службы катало гов Active Directoryо в самых разных организациях. Основной упор сделан на методике выявления проблем в работе Active Directoryо и способах их устранения. На конкретных примерах разбираются вопросы настройки сетевых служб, репликации и групповых правил.

Особое внимание уделяется специфике проектирования Active Diiec tory* в крупных и очень крупных организациях.

Книга состоит из вступления, 6 глав и словаря терминов.

Это издание адресовано системным администраторам и специалис там в области проектирования корпоративных вычислительных систем на базе Windows 2000.

УДК ББК 32.973-81-018. Использованные а примерах и упражнениях названия компаний и продуктов, персонажи и события янля.отся вымышленными. Любые совпадения с реальны ми компаниями, продуктами, людьми и событиями являются случайными.

Active Directory. ActiveX,.(Script, Microsoft, Microsoft Press, MSDN, MS-DOS, PowerPoint, Visual Basic, Visual C++, Visual InterDev. Visual SourceSafe, Visual Studio, Win32, Windows и Windows NT являются либо товарными знаками, либо охра няемыми товарными знаками корпорации Microsoft в США и/или других стра нах. MySQL являемся охраняемым товарным знаком компании MySQL АН. 13се другие токарные знаки являются собственностью соответствующих фирм.

й Зубанов Ф. В., 2002- й Издательско-торговый дом ISBN 5-7502-0118-Х Русская Редакция, Оглавление Об этой книге XIII Структура книги XIV Чего здесь нет XVII Принятые соглашения XVII Проектируем AD, или Мелочей не бывает Что в имени тебе моем? Бизнес определяет имена Имена DNS и имена Active Directory Покажем корень миру Алгоритм именования DNS Именование объектов Active Directory Именование пользователей Именование компьютеров Имена подразделений Одоменивание Один за всех Критерии создания домена Когда одного домена достаточно Преимущества однодоменной модели... все за одного Преимущества многодоменной модели (дерева) Посадим деревья и вырастет лес Преимущества модели с несколькими деревьями Преимущества модели с одним лесом Модель с несколькими лесами Мигрируем с доменной структуры Windows NT Миграция единственного домена Миграция доменной структуры с одним мастер-доменом Миграция доменной структуры с несколькими мастерами Миграция нескольких доменов с попарным доверием Группы и стратегия их использования Рекомендации по использованию универсальных групп Рекомендации по использованию глобальных групп Рекомендации по использованию локальных групп домена Использование особых объединений Административные группы Если ОП создают, значит, это кому-нибудь нужно Модели организационных подразделений Географическая иерархия Организационная иерархия IV Active Directory: подход профессионала Объектная иерархия Проектная иерархия Административная иерархия Так кому нужны организационные подразделения? Нужны ли подразделения пользователям? Подразделения нужны администраторам! Делегирование административных полномочий Разбиваем на сайты Так какой же все-таки критерии? Сколько может быть сайтов? Сколько нужно контроллеров и где их размещать Менее 10 пользователей От 10 до 50 пользователей От 50 пользователей Надежная связь между сайтами Топология сетей Межсайтовые связи Объекты связи Серверы-форпосты Отказоустойчивые схемы Мастера операций и Глобальный каталог. Оптимальное размещение Мастер схемы Мастер доменных имен Имитатор РОС Мастер RID Мастер инфраструктуры Глобальные каталоги Примеры размещения ' Конфигурация контроллеров доменов для удаленных филиалов Политика изменения схемы Когда и как модифицируют схему Применение политики модификации схемы Active Directory, межсетевые экраны и Интернет Подключение доменов через VPN Подключение доменов с использованием IPSec Авторизация ресурсов в DMZ Пример планирования Постановка задачи Предложенная архитектура Леса Домены Сайты Контроллеры доменов Организационные подразделения Группы безопасности Сервер Web и доступ к нему Заключение.. Оглавление Установка Active Directory Что делать с DNS Мой первый DNS Так он работает? А что если наблюдаются проблемы? Выводы DNS уже есть. Ну, и что с ним делать? Поговорим о версиях DNS.- DNS Windows 2000 или BIND версии лучше 8.2.2 BIND версии хуже 8.2.2 А если сервер DNS расположен за межсетевым экраном? Строим лес доменов Все домены в одном сайте Каждый домен в своем сайте Один домен разбит на несколько сайтов Проблема лостровов Использование плоских имен корневого домена DNS в крупной компании Ну очень крупная компания Так нужна ли служба WINS? Краткий экскурс в историю NetBIOS Как разрешаются имена NetBIOS А нужен ли NetBIOS? Краткие советы по установке серверов WINS Как правильно настроить DHCP Что дает авторизация Зачем нужны суперобласти DHCP сервер в сегментированной сети Динамическая регистрация имен в DNS Какие параметры определять в сети Windows Последовательность применения параметров Как использовать идентификатор пользовательского класса Как проконтролировать работу DHCP DCPROMO и все, что с этим связано Требования, предъявляемые DCPROMO Файлы, создаваемые при работе DCPROMO Файлы базы Active Directory SYSVOL : Журналы регистрации Служба синхронизации времени Автоматическая установка контроллера Новое дерево в новом лесу Дополнительный контроллер в домене -. Новый дочерний домен Новое дерево в лесу Понижение контроллера домена до уровня сервера Описание параметров и значений умолчания VI Active Directory: подход профессионала Анализируем журналы DCPromci.log DCPromoUl.log Netsetup.log DCPromos.log Как подобрать компьютер? Требования к процессору Требования к оперативной памяти Конфигурация жестких дисков Как проверить работоспособность контроллера домена А если он все-таки не работает?, Попробуем выяснить причину Некорректные параметры TCP/IP или ошибки в сети Некорректная работа службы DNS Проблемы с оборудованием, в первую очередь с дисковой подсистемой. Проблемы с репликацией Aclive Directory Проблемы с репликацией FRS Некорректная групповая политика А может, все переустановить? Все работает. Что делать? Обновление контроллера домена Windows NT 4.0 до Windows 2000 Кое-что о Windows NT 4.0 Обеспечение безопасной миграции Две стратегии миграции Мигрируем домен Windows NT Обновление первичного контроллера домена Откат назад в случае сбоя Совместная работа контроллеров разных версий Алгоритмы установки контроллера домена Алгоритм установки нового контроллера ' Алгоритм обновления контроллера Windows NT 4.0 Заключение Репликация Active Directory Немного о том, как работает репликация Обновления в Active Directory USN Штамп Удаление объекта Процесс репликации от А до Я Создание объекта Модификация объекта Демпфирование распространения изменений Разрешение конфликтов Топология репликации Какой транспорт предпочесть? Синхронная и асинхронная передача ВнутрисайтовыЙ транспорт Особенности транспорта SMTP Оглавление Управление пакетом репликации Автоматическая генерация топологии Простая топология для одного контекста имен Сложная топология для одного контекста имен Топология для нескольких контекстов имен КСС и его возможности Генератор межсайтовой топологии Репликация глобальных каталогов Репликация критических событий Тиражирование паролей Диагностика репликации Выяснение списка партнеров по репликации Active Directory Sites and Services Repadmin /showreps Replication Monitor Контроль состояния партнеров по репликации DsaStat Dcdiag Repadmin Общая информация о параметрах репликации Поиск и устранение проблем репликации Запрет доступа (Access Denied) Вероятная причина Решение Неизвестная служба аутентификации (Authentication service is Unknown) Контроллер домена не может установить связь репликации Связь репликации существует Неверное имя учетной записи цели (Target account name is incorrect) Отсутствие объекта trusted Domain He совпадает набор SPN Недоступен сервер RFC (RFC Server Not Available) Ошибка поиска в DNS (DNS Lookup failure) Служба каталогов перегружена (Directory service too busy) Причина Разрешение Разница во времени (Ошибка LDAP 82) Причина Устранение Внутренняя ошибка системы репликации Причины Устранение Отсутствие конечной точки (No more end-point) Ошибка LDAP 49 Сообщения, не являющиеся ошибками Active Directory replication has been pre-empted Replication posted, waiting Last attempt @... was not successful Заключение.. VHI Active Directory: подход профессионала Групповая политика Общие сведения Клиент, сервер или кто важнее Типы групповых правил Структура и обработка групповой политики Устройство объекта групповой попитики Хранение параметров групповой политики Версии и ревизии Клиентские расширения Обработка по медленным каналам связи Периодическое фоновое применение Применение неизмененной политики Параметры клиентских расширений Применение групповых правил Изменение последовательности Блокировка наследования Принудительное наследование Перемычки Деактивизация правил Х Фильтрация " История применения правил Где создавать и редактировать правила? Делегирование полномочий Делегирование прав на создание и модификацию ОГП Делегирование полномочий на привязку ОГП к объектам Active Directory.. Типы правил Правила установки ПО для компьютеров Установки Windows для компьютеров - сценарии Параметры Windows для компьютеров: правила безопасности Правила учетных записей Локальные правила Правила журнала регистрации Параметры Windows для компьютеров: правила групп с ограниченным членством Параметры Windows для компьютеров: правила системных служб Параметры Windows для компьютеров: правила реестра Параметры Windows для компьютеров: правила файловой системы Параметры Windows для компьютеров: правила открытых ключей Параметры Windows для компьютеров: правила IPSecurity Административные шаблоны для компьютеров Правила установки ПО для пользователей Параметры Windows для пользователей: настройка Internet Explorer Параметры Windows для пользователей: сценарии Параметры Windows для пользователей: правила безопасности Параметры Windows для пользователей: служба удаленной установки Параметры Windows для пользователей: перенаправление папок Административные шаблоны для пользователей Планирование групповой политики Оглавление IX Начальство хочет, вы - желаете, От простого к сложному Советы по применению Один домен Несколько доменов Поиск и устранение проблем Средства поиска проблем GPRESULT GPOTOOL ADDIAG SECEDIT FAZAM2000 Журналирование Журнал событий приложений Журналы политики для пользователей Журналы установки приложений Общие проблемы групповой политики Зависание компьютера при регистрации пользователя или запуске компьютера Определенная политика не обрабатывается полностью или частично.... Обрабатывается не тот ОГП Политика вообще не применяется Заключение Active Directory и файловая система Служба репликации файловой системы."... Как распространяются изменения Инициация тиражирования Избыточность Когда удобно использовать репликацию FRS Работа службы FRS в подробностях Выходная репликация Входная репликация Таблицы службы FRS Объекты Active Directory, используемые FRS Настройка FRS Изменение интервалов опроса Active Directory Установка фильтров Управление расписанием репликации Рекомендации по оптимизации FRS Журналирование Топология репликации Подготовительный каталог Размер журнала NTFS Использование FRS и удаленных хранилищ Использование резервного копирования для начальной конфигурации реплик Не превышайте Поиск и устранение проблем FRS Active Directory: подход профессионала Журналы Журнал регистрации File Replication System Журналы NTFRS Связь между монитором производительности и сообщениями в журнале.. NTFRSUTL Восстановление реплицируемых файлов Неавторитетное восстановление Авторитетное восстановление Восстановление конфигурации FRS, Оптимизация процессов восстановления Сокращение числа серверов, создающих подготовительные файлы Сокращение числа реплицируемых файлов на время выполнения процесса W-join Разрешение выполнения только одного подключения вектора версий на входном партнере Распределенная файловая система Немного о DFS Таблица РКТ Взаимодействие клиента с сервером DFS Репликация DFS Сайты и DFS Предельные возможности и ограничения Ограничения доступа Полезные советы Работа DFS без NetBIOS Резервное копирование пространства имен DFS Использование DfsCmd Использование DfsUtil Делегирование полномочий по управлению DFS Делегирование полномочий модификации конфигурации DFS Делегирование полномочий настройки репликации томов DFS Делегирование полномочий по управлению томами DFS и разграничению доступа Поиск и устранение проблем DFS DfsUtil /list /view /pktinfo Аргументы управления конфигурацией. Аргументы отладочного режима Наиболее общие проблемы и их разрешение Обновление сервера до новой аерсии Изменение имени хоста DFS Удаление последнего корня DFS Перемещение хоста DFS в другой сайт Проблемы доступа к пространству имен DFS Невозможность администрирования DFS Оглавление XI Удаление конфигурационной информации DFS Удаление доменных корней Удаление корней отдельно стоящих DFS Заключение Поиск и устранение проблем Алгоритм поиска и устранения проблем Active Directory Резервное копирование Active Directory Чем нужно копировать Что нужно копировать Кто может копировать Файлы, игнорируемые при резервном копировании Актуальность резервной копии Никогда не ставьте время на контроллере больше текущего Восстановление Active Directory Восстановление через переустановку Принудительное назначение мастеров операций с помощью Ntdsutil Восстановление из резервной копии Неавторитетное восстановление Проверка восстановления с помощью Ntdsutil Восстановление на другую технику Если система загрузилась Если система загружается только в безопасном режиме Если система не загружается Авторитетное восстановление Авторитетное восстановление с помощью Ntdsutil Обеспечение правильности авторитетного восстановления Влияние авторитетного восстановления Влияние на доверительные отношения и учетные записи компьютеров... Влияние на членство в группах Восстановление Глобального каталога Восстановление мастеров операций Кто может быть мастером операций? Восстановление мастера схемы Восстановление мастера доменных имен Восстановление мастера RID Восстановление имитатора РОС Восстановление мастера инфраструктуры Проверка целостности и восстановление базы Мягкое восстановление журналов базы Проверка целостности базы Семантический анализ базы Ремонт базы Перенос базы Active Directory Выяснение местоположения файлов Перенос файлов базы Перенос файлов журналов Если надо переустановить домен в лесу XII Active Directory: подход профессионала Постановка задачи Общая последовательность действий Определение правил переноса Последовательность действий с первого взгляда Перенос пользователей и групп в деталях Проверка результата План аварийного восстановления Если в лесу все перестало работать Общая последовательность действий Предварительные шаги Документирование текущей структуры леса Разработка процедуры отката назад Выявление лучшего кандидата на восстановление Выключение всех контроллеров доменов Восстановление Восстановление корневого домена Восстановление остальных доменов Добавление дополнительных контроллеров Заключительные шаги Заключение - Словарь терминов Предметный указатель Список литературы Об авторе Об этой книге Скоро будет уже четыре года, как вышла система Windows 2000. а вместе с ней Ч служба каталогов Active Directory. Уже стихли словес ные баталии о том, чем она лучше или хуже Novell NDS. уже не разда ются осторожные реплики, дескать, подождать надо, пока другие не попробуют да сервисный пакет не выйдет, а то и два. Уже прочитана уйма литературы на эту тему, благо ее на русском языке издано пре достаточно. И вот результат: крупные и средние российские компа нии массово стали переходить на Windows 2000 и Active Directory.

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

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

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

С момента выхода Windows 2000 я помогал компаниям внедрять Active Directory. Шишек за это время было набито немало: в каждой органи зации своя специфика и свои требования, все обладают разным уров нем готовности к этому шагу. Это требовало искать обходные пуги и нетривиальные решения. Но подобные процессы имели место и в дру гих странах. В итоге в Microsoft накопился значительный опыт внедре ния, Хучитывающий знания и достижения сотен консультантов Microsoft Consulting Services. Часть згой информации опубликована на Web-сай те Microsoft, в базе знаний Microsoft, также доступной в Интернете XIV Active Directory: подход профессионала и на дисках по подписке, часть Ч на курсах по отладке Active Directory.

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

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

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

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

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

это все я уже объяснял в книге Microsoft Windows 2000. Планирование, развертывание, управление (2-е изд. М.: Русская Редакция. Ч 2000 г.). которую можно с полным основанием считать первой частью настоящей. Но если там акцент делался на описании новых возможностей Windows 2000 и на том, как их использовать, то здесь на том, как функции Active Directory7 использовать с максималь ной эффективностью и бороться с возникающими проблемами. В первой книге вы знакомились со стандартными инструментами, вхо дящими в комплект ОС, Ч- здесь же описывается практическая работа с дополнительными программами и утилитами постаатяемыми либо в составе Windows 2000 Server Resource Kit, либо в составе Widows Support Tools.

Я постарался избегать по возможности сухой теории и специальной терминологии. Я хотел вам просто рассказать самое главное, что знаю на эту тему. Но не расслабляйтесь: за шутками порой скрывается очень важная информация, которую надо знать, как таблицу умножения. Хотя я беру за основу английскую версию ОС, употребляю я при этом рус ские термины. Меня коробит, когда русский человек начинает выдавать перлы вроде бриджхед сервера или сайт линки. У всех терминов есть русские эквиваленты, которыми рекомендую пользоваться.

За год, прошедший с момента выхода первого издания, книга широ ко разошлась по стране. Для многих она стала настольной книгой Об_зтой_книге XV и первым источником при поиске решения каких-либо проблем. Во второе издание были внесены небольшие, но очень существенные изменения и дополнения в первую главу, посвященную планированию Active Directory. Эти изменения касаются вопросов построения безо пасной доменной архитектуры и базируются на опыте реальных про ектов последних двух лет. Помимо этого, местами введены замечания об особенностях планирования AD для Windows 2003. Наконец, были устранены замеченные мною и читателями досадные опечатки, Структура книги Шесть глав, из которых состоит книга, я намеренно не стал нумеро вать: определенно сказать, какую читать первой, а какую Ч последней, нельзя, Главы перекликаются: из одной ссылки идут ко всем осталь ным. Там, где этого мало, я делаю ссылки на другие книги и в первую очередь на уже упоминавшуюся "Microsoft Windows 2000. Планиро вание, развертывание, управление.

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

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

Название Установка Active Directory может сбить с толку. С одной стороны, те, кто ее уже установил, решат, что читать об этом незачем.

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

про граммой DCPROMO. Эта глава не о том, как из сервера сделать контрол лер домена, а о том, как не допустить ошибок на предварительной ста дии и как избавиться от ошибок, если они все-таки возникли при уста новке.

От правильной настройки служб DNS, WINS и DHCP зависит, как будет работать система. Способов конфигурирования так много, что выбрать XVI Active DjrectgryMtOflxgfl профессионала самый верный Ч не очень простая задача. Но вот контроллер домена установлен. Как понять, что псе сделано правильно и выявить потен циальные проблемы? Ответ на этот вопрос дан в этой главе. Плюс к этому Ч полезные сведения о конфигурировании системы в нестан дартных условиях работы.

Так же. как Active Directory немыслима без репликации, так и книга немыслима без главы Репликация Active Directory. Масса про блем с Active Director) возникает из-за некорректно работающей реп ликации. Чтобы их понять, надо, с одной стороны, разобраться в ме ханизмах репликации, а с другой Ч знать и уметь использовать инст рументы диагностики. Именью поэтому теорию данного процесса я раскрыл гораздо полнее, чем в других книгах, А изучив теорию, вы без труда справитесь с той информацией, которую предоставляют средства диагностики. А тому, с чем не справитесь, найдете объясне ние в этой главе.

Но репликация службы каталогов Ч не единственный вид репликации в Windows 2000. Active Directory тесно связана с файловой системой:

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

От того, насколько эти компоненты согласованы с данными в Active Directory, зависит стабильность и защищенность системы. А согласо ванием занимается служба репликации файловой системы. Вот о ней и идет речь в главе *Active Directory и файловая система. Как не странно, но этим вопросом многие просто пренебрегают, полагая, что тут все ясно, оно всегда работает. Увы, это не так. Эта тема менее всего отражена в литературе, а зря! Проблемы с репликацией файлов могла причинить столько проблем, что их с лихвой хватит, чтобы омрачить радость от нормальной работы остальных служб. Поэтом)* основной лейтмотив этой главы Ч диагностика проблем.

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

Одним из звеньев, связывающих объекты Active Directory и пользова телей, является групповая полигика. К сожалению, еще далеко не все представляют, как можно и нужно применять групповые правила, как применять принципы наследования и блокировки, что такое фильтры Об зтой_ книге XVII и т. п. Этому посвящена глава Групповая политика. Хорошо, когда политика применяется. Хуже, когда возникают проблемы. Их поиск Ч одна из самых неприятных и запутанных операций в Windows 2000.

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

Глава Поиск и устранение проблем Ч не фармакологический справочник. Здесь нет списка симптомов болезни и перечня лекарств от нее. О том, как искать причины конкретной ошибки и устранять ее, рассказано в остальных главах. А что же тогда здесь? Ч спросите вы.

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

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

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

Чего здесь нет В этой книге вы НЕ найдете:

Х описания модели безопасности Active Directory;

Х описания инфраструктуры открытых ключей и ее диагностики;

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

ф описания процесса установки Windows 2000 и конфигурирования служб, не имеющих прямого отношения к Active Directory: не сто ит утяжелять книгу сопутствующим товаром*;

Х рекомендаций по управлению проектом внедрения Active Directory:

эта тема слишком объемна и требует отдельного освещения;

Х советов по организации сопровождения и поддержки корпоратив ной вычислительной системы на базе Active Directory: это предмет такой дисциплины, как Microsoft Operations Framework (MOF), и требует систематизированного подхода.

Короче, здесь нет ни слова о том, что не относится к Windows 2000 и Active Directory.

XVIII Active Directory: подход профессионала Принятые соглашения Для удобства чтения в книге приняты следующие обозначения:

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

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

Ссылки на дополнительную литературу приведены в [квадратных скобках].

Тексты сценариев и листинги файлов выделены монои/рин-ым шрифтом, Описания синтаксиса команд ОС или дополнительных утилит выде лены моноширинным шрифтом полужирного начертания.

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

Проектируем AD, или Мелочей не бывает Прежде чем установить Active Directory', ее нужно спроектировать.

В прошлом, когда использовалась служба каталогов Windows NT, про ектирование было столь же необходимо, как и сейчас. Вот только цена ошибки была гораздо ниже. Существовало четыре типовых схемы связей между доменами, которые использовались полностью либо в некоторой комбинации [9]. Если какой-то из доменов был спроекти рован неверно, его можно было совершенно безболезненно для ос тальных лубить и сделать по-новому. В Active Directory все домены объединены в лес. Ошиблись при проектировании корневого домена Ч придется переделывать весь лес, а это может обойтись,дорого. Не меньше может стоить и ошибка в одном из промежуточных доменов, Я уж не говорю о том, что неверная топология репликации и плани ровка сайтов могут доставить вам сплошные хлопоты и неоправдан ные затраты на приобретение дополнительного оборудования. Разби ение на подразделения, выполненное не в соответствии с админист ративными потребностями, а по желанию руководства, может превра тить процесс администрирования в ад для технических специалистов и повлечет неоправданный рост численности технического персонала.

Суммируя сказанное, можно констатировать, что неправильное пла нирование компонентов Active Directory чревато:

Х неоправданными расходами на оборудование:

Х неоправданными расходами на технических специалистов;

Х повышенной трудоемкостью работ;

Х нестабильной работой системы:

Active Directory: подход профессионала + потерей данных;

Х утечкой конфиденциальной информации;

ф вашим увольнением.

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

+ стратегию именования;

Х стратегию и тактик}' деления на домены:

Х принципы построения структуры подразделений;

+ правила разбиения на сайты;

4> принципы размещения сетевых сервисов, Глобальных каталогов (ГК) и других служб Active Directory;

ф политику' модификации схемы.

Что в имени тебе моем?..

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

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

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

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

Проектируем AD, или Мелочей не бывает Критерии выбора имени леса таковы:

Х отражение названия компании в доменном имени;

Х присутствие организации в Интернете;

ф планы по приобретению других компаний;

+ сложность имени.

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

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

А раз так, выбранное имя должно быть зарегистрировано в ICAAN.

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

Называя корень Active Director}', подумайте, какую долю бизнеса ком пании будет охватывать доменная структура. Допустим, компания за нимается производством молока и соков, причем это произошло в ре зультате слияния двух независимых компаний, и каждая имеет в зна чительной степени независимое управление и политику ИТ. Если в названии корневого домена будет слово молоко, это вызовет скры тое раздражение производителей сока, и, наоборот, назвав домен соч ным* именем, вы рискуете вызвать гнев молочников. Имя должно быть нейтральным или совмещать в себе признаки обеих организа ций. Например, это может быть название совместной зарегистриро ванной торговой марки или объединенное имя компаний, что-то вроде milkandjuce.ru. Правда, в последнем случае есть угроза нажить себе врагов после приобретения компанией фирмы по производству газированных напитков.

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

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

Active Directory: подход профессионала Имена DNS и имена Active Directory Давайте вспомним о разнице между именами DNS и Active Directory.

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

Active Directory хранит сведения о своих объектах (пользователях, компьютерах, подразделениях и т. п.), тиражирует их между контрол лерами доменов и предоставляет своим клиентам в ответ на запросы.

Для каждого домена Active Directory есть данные (записи типа SRV.

имена доменов и хостов, CNAME-записи партнеров по репликации), которые хранятся в зонах DNS. Каждому имени домена Active Direc tory соответствует такое же имя зоны DNS. А вот обратное Ч для каж дой зоны DNS обязательно имеется соответствующий домен Active Directory Ч неверно.

Mycorp.ru Контроллер домена ^msdcs. mycorp.ru Mycorp.ru msk.mycorp.ru unixhosts.int.com Сервер DNS Контроллер домена MSK.Mycorp.ru Для каждого домена AD существует зона в DNS, но не наоборот Покажем корень миру Как упомянуто выше, к названию леса (то есть корневого домена в ле су) надо подходить чрезвычайно внимательно. Особо остановлюсь на ситуации с плоским именем корня. Практика показывает, что боль шинство организаций выбирает для корня имена вида xxx.yyy.zzz, то есть имя, соответствующее системе именований DNS, в котором есть по крайней мере одна точка. Это такие имена, как mybank.ru, согрлпу corp.net и пр. Однако в ряде организаций сильны традиции имен NetBIOS. Они стремятся дать корневому домену плоское* имя, то есть Проектируем АР, или Мелочей не бывает состоящее из одной части, например mycorp или ad. Свое решение специалисты этих компаний аргументируют так: Так короче. А где сказано, что это запрещено? И ведь в самом деле это не запрещено.

Более того, в большинстве случаев это не вызывает никаких проблем, Но.,. Проблема возникает, как только контроллеры дочерних доменов или серверы-члены корневого домена оказываются в другой подсе ти, такой, что NetBIOS-имена между этими подсетями не разрешают ся. Зга проблема приводит к невозможности нормального функцио нирования Active Directory. Именно поэтому я настоятельно рекомен дую избегать таких имен. Но уж если вы столь упрямы, что желаете использовать их во что бы то ни стало, то обратитесь к главе Уста новка Active Directory, где описано, как правильно сконфигурировать контроллеры доменов и серверы для работы с плоскими именами доменов.

Между именем корня леса доменов Active Directory и внешнем име нем DNS компании могут быть разные взаимосвязи. Все возможные варианты сводятся к трем:

Х доменное имя и имя в Интернете совпадают;

+ доменное имя является дочерним для имени в Интернете;

Х доменное имя не имеет ничего общего с представленным в Ин тернете.

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

Если имя леса Active Directory совпадает с зарегистрированным вне шним именем DNS:

ф пользователи осуществляют доступ как ко внешним, так и внутрен ним ресурсам по одному доменному имени;

Х нельзя открывать внутренние ресурсы для внешнего мира;

вне шний сервер DNS не должен хранить имен, используемых Active Directory;

ф для разрешения внешних имен из внутренней сети используйте передачу неразрешенных вызовов на внешний сервер DNS;

Х ресурсы, доступные извне, должны храниться в демилитаризован ной зоне (DMZ), аутентификация доступа к ним Ч выполняться через RADIUS-сервер, а не контроллер домена;

ф на прокси-сервере надо сконфигурировать список исключений;

ф при использовании протокола трансляции сетевых: адресов (NAT) внутренний сервер DNS должен содержать свои записи о ресур сах, доступных как извне, так и изнутри;

упрашзение этими адре сами Ч забота администратора.

Active Directory: подход профессионала Если имя леса Active Directory является дочерним по отношению к внешнем}' имени DNS:

Х только внутренний сернер DNS содержит информацию об Active Director)';

+ на внешнем сервере DNS создается делегирование зоны, соответ ствующей зоне домена Active Directory;

Х пользователи применяют разные имена для доступа к внешним и внутренним ресурсам;

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

+ полные имена ресурсов длиннее, чем в предыдущем случае.

При различных именах леса Active Directory и внешнего имени DNS:

+ управление безопасностью внутренней сети проще за счет полно стью различных пространств имен;

Х внутренние имена не видны снаружи;

Х тиражировать информацию с внешнего сервера DNS на внутрен ний не обязательно;

+ инфраструктура DNS может оставаться без изменений;

+ внутреннее имя не обязательно регистрировать в ICAAN.

Дополнительную информацию по именованию см. в [8].

Алгоритм именования DNS Если суммировать сказанное в этом разделе с материалами раздела, посвященного DNS главы Установка Active Directory*, можно составить такой алгоритм стратегии именования, как показано на рисунке ниже.

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

Именование пользователей Когда речь идет об объектах типа User, следует отдельно говорить о таких атрибутах, как:

ф Сп Ч общее имя;

Х Display-Name Ч имя отображаемое в каталоге;

ф SamAccoimtName Ч имя, используемое при регистрации в домене Windows NT;

Проектируем АР, или Мелочей не бывает Создать четыре \ ресурсных зоны на \ существующем сервере I HIM делегировать их на сервер DNS / 20QO Зарегистрировать имя в ICAAN и создать на внешнем и внутреннем серверах зоны с одним именем Серверы DNS разделить Зарегистрировать другое имя межсетевым экраном.

Делегировать зону на /I- в ICMN для корня леса, создать / сервер Windows на существующем сервере DNS V DNS и сделать ее вторичную зону с этим именем \jaipHeeo и для АР f Зарегистрировать имя в I Зарегистрировать имя в ICAAN >.

( и делегировать зону на внутренний \ и создать две различные зоны Icepeep DNS Windows 2000. Серверы DNsJ на двух серверах, разделенных \.разделигь межсетевым экраном./ межсетевым экраном. Внутренний / р будет обслуживать К>./ Стратегия использования доменных имен DNS + UserPrincipalName (UPN) Ч имя, используемое при регистрации в домене Windows 2000.

Общее имя совпадает с именем, отображаемым в каталоге, и представ ляется почти так. как мы привыкли обращаться друг к другу: имя, фамилия и кусочек отчества. Формат общего имени такой: <имя> пробел<часть отчесгва>точка, пробел<фамилия>. Максимальная дли на имени совместно с фамилией составляет 57 символов при отсут ствии отчества и 55 Ч при максимальной длине отчества, равной символам. Предельная длина общего имени Ч 64 символа. В качестве символов имени допустимы символы UNICODE, т, е. пользователей вполне можно называть по-русски.

Active Directory: подход профессионала Имя, применяемое при регистрации в домене Windows NT, обычно служит и для регистрации домене Windows 2000. В диалоговом окне регистрации пользователь вводит именно это имя, пароль и имя до мена. Если же он введет данные в формате имя@имя.домена, то он введет имя UPN. Первая часть UPN и имя регистрации в домене Win dows NT по умолчанию совпадают, но могут быть и разными. Для простоты далее мы будем полагать, что они совпадают, и назовем их просто именем регистрации.

В качестве имени регистрации используется несколько схем. Наибо лее употребительная основывается на имени и фамилии пользователя записанных латинскими буквами. В этой схеме несколько вариаций:

+ <первая буква имени><фамилия><номер*>;

ф <имя><первая буква фамилиях номер*>;

+ <часть имениХчасть фамилиях Звездочка означает, что номер используется в случае наличия полных тезок на предприятии. Иногда вместо номера применяется иная ла тинская транслитерация, например, Petrov, Petroff, Petrow.

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

Именование компьютеров В именовании компьютеров наблюдается полный разнобой. Одно, прав да, объединяет все схемы наименований: администраторы стараются давать принципиально разные имена серверам и рабочим станциям.

В качестве примера удачного именования серверов можно привести;

XXX-YYY-NN где:

+ XXX соответствует территориальному расположению сервера;

это может быть код региона, записанный в Конституции РФ, аббреви атура, соответствующая определенному городу (MSK, NSK, SPB) или любой иной код, понятный администраторам;

+ YYY Ч тип сервера, например, SRV Ч сервер общего назначения, DC Ч контроллер домена, MSG Ч почтовый сервер, PXY Ч про кси-сервер, WWW Ч Web-сервер и т. п.;

+ NN Ч порядковый номер сервера данного типа в данном регионе.

Проектируем АР, или Мелочей не бывает Если структура Active Directory такова, что каждому региону (или каж дой площадке) соответствует свой домен, то из имени можно исклю чить первый префикс, так как из полного имени сервера и так будет понятно, где расположен сервер.

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

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

Удачная схема именования имеет следующий формат:

XXXYYYYYYYNN где:

ф XXX - тип операционной системы (W2K, WXP, W98);

+ YYYYYYYY Ч имя регистрации пользователя;

Х NN Ч порядковый номер, если у пользователя несколько компью теров.

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

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

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

Имена подразделений Специальных требований к именам подразделений нет. Они могут содер жать символы UNICODE и быть довольно длинными Ч до 64 символов.

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

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

Одоменивание Специалисты по Windows NT считали, что создать доменную струк туру очень просто: существовало четыре модели;

с одним доменом, с одним мастер-доменом, с несколькими мастер-доменами и модель 10 Active Directory: подход профессионала полностью доверительных отношений. Выбор модели определялся р.

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

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

Х Домен Ч это элемент каталога, имеющий свое собственное про странство имен. Внутри домена действуют правила безопасности, не распространяемые за его пределы.

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

Х Между доменами могут устанавливаться отношения доверия. Тип доверительных отношен ий транзитивный, т. е. если домен А дове ряет домену Б. а домен Ь доверяет домену В. то домен А доверие']' домену В. Транзитивные доверительные отношения двунаправлены.

Х Домены объединяются в деревья. Самый первый домен в дереве называется корневым. Дочерние домены наследуют пространстве.

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

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

Замечание Между лесами Windows 2003 можно устанавливать тран зитивные доверительные отношения.

Проектируем АР, или Мелочей не бывает Один за всех...

Как вы помните, один домен способен поддерживать до 10 миллионов объектен каталога. По крайней мере так утверждают пособия по Active Directory. He могу не сказать, что на момент написания книги мне было известно о домене, в котором было 34 миллиона объектов. Даже если предположить, что из всех этих объектов только 1 миллион прихо дится на пользователей, а все остальные на компьютеры, группы, подразделения и т. п., то, повторяя небезызвестного Хрюна, так и хо чется сказать: Внушает... А ведь и в самом деле, почему бы не оста новиться на одном домене для любого предприятия? Вы можете на звать в России хоть одну организацию с миллионом сотрудников?

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

Критерии создания домена Первый критерий Ч соображения административной политики.

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

Второй критерий Ч безопси'1-юсть. Вспомните определение домена: имен но в нем звучит этот термин! Домен можно рассматривать как некое го сударство, правительство которого проводит определенную политику по его защите. Это, например, правила работы с паролями, аутентификации (читай "паспортный режим) и т. п. Все граждане государства (пользова тели) обязаны строго соблюдать установленные правила и подвергаться наказаниям при их нарушении (например, блокировка учетной записи).

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

Когда одного домена достаточно Опираясь на эти критерии, легко сообразить, когда можно обойтись одним доменом.

12 ' Active Directory: подход профессионала Пусть в компании существует некоторая организационная структура:

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

Надо задуматься и над тем, как часто сотрудники переходят из под разделения 11 подразделение, как часто меняется организационная структура предприятия. Помните: домены не переименуешь, не пере несешь в новое место. Нельзя переместить домен из одного участка леса в другой. А перенос пользователей между доменами Ч.процеду ра далеко не элементарная.

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

+ по крайней мере 10% пропускной способности канала доступно для репликации;

Х все контроллеры доменок являются серверами ГК;

Х н течение года добавляется 20% и увольняется 15% пользователей;

Х каждому пользователю предоставлен отдельный компьютер;

+ используются зоны DNS интегрированные с Active Directory.

Зависимость размера глобального домена от пропускной способности каналов Пропускная способность самого Максимальное число'пользователей медленного канала (Кб/с) в домене 20, 30 14. 19,2 40 28,8 50 38,4 75 56,0 100 Наконец, сколько администраторов и где они находятся? Если у вас жесткая централизованная модель управления сетью, то наличие одного Проектируем АР, или Мелочей не бывает домена Ч это идеальное решение. Если же сеть не только распределе на географически, но и администрирование децентрализовано, то сто ит задуматься о потенциальных конфликтах администраторов в доме не. Помните, люди весьма изобретательны, когда пытаются отстоять то, что у них пытаются отобрать.

Итак, только один домен создается, если:

Х размер организации таков, что может управляться одним доменом (рекомендуется менее 1-2 миллионов пользонателей);

ф используется централизованная структура управления сетью с хорошо детализированной политикой;

Х допустимо применение единой политики безопасности (пароли, блокировка учетных записей, Kerberos, файловая система с шиф рованием, IPSecurity, инфраструктура открытых ключей);

4 географическая распределенность такова, что отсутствуют некаче ственные или перегруженные каналы между отдельными участками;

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

ф нет нужды в использовании более одного доменного имени.

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

Преимущества однодоменной модели Преимущества однодоменной модели Active Directory таковы.

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

Х Более дешевое решение Для поддержания работоспособности одного домена требуется меньше контроллеров домена. Учитывая требования к контроллерам (см. главу "Установка Active Directory*), это немалые средства.

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

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

+ Предельная емкость такая же, как у целого леса доменов ГК мо жет хранить не более 4 миллиардов объектов. С другой стороны, 14 Active Directory: подход профессионала он содержит краткие сведения обо всех объектах в лесу независи мо от количества доменов в лесу. Значит, и для одного домена, и для нескольких этот предел неизменен.

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

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

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

Проблема безопасности тесно связана и с полномочиями админи страторов. Если взять адмш [истраторов единственного домена (а зна чит, и корневого домена в лесу), то по умолчанию они включены в такие группы, как Domain Admins, Schema Admins, Enterprise Admins.

Последние две наделены олромными полномочиями в рамках леса.

Нужны ли такие всем администраторам? Ясно, нет. Всесильных* ад минов в системе быть не должно. Чтобы не было у администратора даже возможности самостоятельно включить себя в группу с абсолют ной властью, целесообразно создавать минимум два домена: корне вой, в котором нет пользователей, но есть учетная запись админист ратора предприятия, и другой Ч где хранятся как учетные записи пользователей, так и все администраторы домена.

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

Пустой корневой домен играет и еще одну важную роль. Это своего рода хранитель имени* организации. Так как корневой домен дает Проектируем АО, или Мелочей не бывает 1_ имя всему лесу, то никакие изменения в нижележащей доменной структуре не отражаются в имени леса. Можно добавлять новые до мены в лес при приобретении или слиянии с другими предприятия ми, удалять домены при продаже части бизнеса Ч имя организации останется прежним.

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

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

Второй критерий создания домена Ч модель администрирования.

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

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

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

Поэтому, рассматривая данный критерий создания домена, подумайте, стоит ли это делать? Может лучше все учетные записи пользователей и компьютеров в регионе разместить в организационном подразделении, а локальным администраторам делегировать определенные права по 2- Active Directory: подход профессионала управлению подразделением? Этот же подход следует применить и в том случае, когда домен в регионе должен быть создан в соответствии с другими критериями. Все равно не отдавайте ключи от всех дверей в доме, Управляйте таким доменом из центра, а региональным админи страторам позвольте заниматься поддержкой пользователей.

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

Полномочия различных категорий администраторов' Администраторы леса2 домена3 ОП Присвоение (Take Ownership) любого объекта в Active Directory / Создание пользовательских учетных записей / / / Удаление пользовательских учетных записей / / / Сброс паролей пользователей / / / Создание групп / / / Удаление групп / / / Изменение членства в группах / / / Создание объектов Типа принтер и управление ими / / / Создание, сетевых папок общего доступа и управление ими (па контроллерах домена) / / Установка программного обеспечения на контроллеры домена / / Создание учетных записей компьютеров и управление ими / / / Создание нового домена в лесу / Установка контроллеров домена / / Резервное копирование и восстановление контроллеров домена / / / Управление Групповыми Политиками / / Установка System Management Server / / Настройка доверительных отношений между доменами / Управление Сайтами и Подсетями / Создание политик Admission Control Service (ACS) / Ч см. след. стр.

Проектируем АР, или Мелочей не бывает Администраторы леса домена ОП Авторизация сервера DHCP / Авторизация сервера RIS / Организация printer location cracking / Инсталляция MSMQ Routing Server / Конфигурирование связей / / Х/ MSMQ site links / Установка Удостоверяющего центра предприятия / Установка Подотчетного Удостоверяющего центра / Установка Simple Certificate Enrollment Protocol (SCEP) Add-on для службы Certificate Services / Выполнение сервиса MSMQ Replication при работе MSMQ в смешанном режиме (на некоторых серверах установлены MSMQ 1.0 на Windows NT4) / Запуск MSMQ Upgrade wizard / Для администраторов предприятия и домена указаны полномочия по умолчанию, для ад министраторов ОП Ч рекомендуемые.

- Область полномочий Ч лес Область полномочий Ч домен.

Область полномочий Ч ОП.

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

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

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

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

18 Active Directory: подход профессионала + минимум 10% пропускной способности канала доступно для реп ликации;

ф все контроллеры доменов являются серверами ГК;

Х в течение года добавляется 20% и увольняется 15% пользователей;

ф у каждого пользователя отдельный компьютер;

+ используются зоны DNS интегрированные с Active Directory.

Аналогично тому, как мы это сделали для одного домена, подведем итог. Итак, несколько доменов могут быть созданы когда:

ф размер организации таков, что не может управляться одним до меном (более 1-2 миллионов пользователей);

ф используется децентрализованная структура управления сетью с несколькими ИТ-отделами, действующими достаточно независи мо друг от друга;

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

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

ф ' географическая распределенность такова, что имеются некачествен ные или перегруженные каналы между отдельными участками;

ф само предприятие нестабильно;

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

Зависимость размера глобального домена от пропускной способности каналов Пропускная способность Максимальное число самого медленного Максимальное число пользователей пользователей в лесу в региональном домене канала (Кб/с) 15 9,6 25 15 50 14, 25 19,2 50 28,8 75 45 100 38, 100 56,0 100 ООП Проектируем AD, или Мелочей не бывает Область ответственности администраторов -центра Медленный Приобретена канал связи компании Наличие в регионе команды ИГ, которой вы Вынос пользователей f. администраторов из корневого домена Область ответственности администраторов региона Критерии разбиения па несколько доменов Преимущества многодоменной модели (дерева) Преимущества многодоменной модели Active Director)' таковы.

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

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

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

Объем этих данных несоизмеримо мал в сравнении с внутри до менной репликацией.

20 Active Directory: подход профессионала Посадим деревья и вырастет лес Обсуждая причины создания нескольких доменов, мы полагали, что речь идет о дереве, в котором все дочерние домены наследуют имя корневого. Однако не всегда такое приемлемо. Часто организация состоит из ряда ассоциированных с ним предприятий. Каждое такое предприятие занимается независимым бизнесом, имеет свое руковод ство и политику. Возможно также, что имя этого предприятия извес тно широкому кругу лиц и безотносительно к связи с головной орга низацией. Так, с крупной телекоммуникационной корпорацией могут быть ассоциированы компании по доставке писем и грузов, обще ственного питания, строительно-монтажная и т. п. Их тесная связь с телекоммуникационной корпорацией определяется тем, что большую часть своего бизнеса они выполняют по ее заказам. Раз так, то для удобства обработки заказов и организации совместного планирова ния и подготовки отчетности нужно обеспечивать интеграцию ин формационных структур этих предприятий с предприятием-лкор мильцем*. Под этим подразумевается и доступ к единой системе пла нирования ресурсов, единая почтовая система и система документо оборота, возможность доступа к определенным файловым ресурсам и т. п. Понятно, что речь не может идти о полном слиянии, так как эти компании довольно много работают и на сторонние фирмы и сохраняют свою независимость как юридические лица.

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

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

Проектируем AD, или Мелочей не бывает Obedy.ru Mycorp.ru StaR.obetty.ru Crm.msk.mycorp.ru Для уменьшения пути доверия между деревьями используют сокращения Преимущества модели с несколькими деревьями Преимущества модели Active Directory с несколькими деревьями та ковы.

Х Возможность использовать разные -пространства имен Имя каждого дерева уникально в рамках леса.

Х Децентрализованное управление Ассоциированные предприятия ряда компаний обладают независимостью как юридические лица и имеют собственные ИТ-службы.

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

4- Использование единой схемы и ГК Несмотря на различие, органи зации, входящие в разные деревья, используют единые приложе ния, интегрированные с Active Directory, и единую адресную кни гу (например, в Microsoft Exchange 2000).

22 Active Directory: подход профессионала Преимущества модели с одним лесом Рассмотренные выше модели построения доменной структуры отно сятся к так называемой модели Active Directory с одним лесом доме нов, В 99 % случаев следует придерживаться именно этой -модели.

Объяснение данного факта простое;

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

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

В случае Microsoft Exchange 2000/2003 этот каталог будет взят за основу. Для других почтовых систем он может быть указан в каче стве LDАР-каталога. Любой почтовый клиент, понимающий прото кол LDAP, использует существующий ГК в качестве адресной книги.

Х Наличие единого глобального каталога также может быть исполь зовано и различными серверами приложений такими, например, как IBM Web Sphere. Они могут обратиться к глобальному катало гу для авторизации пользователей. Это может стать первым шагом на пути к созданию единой точки входа в гетерогенную систему (single sign-on).

ф Одним из важнейших достоинств единого леса является простота и эффективность отслеживания единой политики безопасности.

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

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

Проектируем АР, или Мелочей не бывает Х Наличие единого леса позволяет централизованно внедрить сис тему мониторинга, которая будет в реальном масштабе времени следить за контроллерами доменов и иным оборудованием. При чем такая система, как Microsoft Operations Manager (MOM 2000), позволит не только контролировать состояние обслуживаемых систем и своевременно сообщать оператору обо всех сбоях, но и автоматически отрабатывать процедуры по устранению неисправ ностей. Одной из особенностей MOM является возможность веде ния базы знаний о возникавших проблемах. Такая база позволяет легко организовать преемственность административного персона ла, когда увольнение одного не станет узким местом при разре шении проблем. Стоит упомянуть, что MOM имеет специальные наборы настроек, позволяющих интеллектуально управлять состо янием Active Directory. DNS, Windows 2000/2003 и остальных служб.

При необходимости MOM может быть использован для управле ния и серверами приложений (SQL, Exchange и пр.), причем не только на платформе Microsoft.

+ Наличие единого леса Active Directory значительно упрощает про цесс внедрения корпоративных стандартов на рабочие места пользователей. Использование групповых политик в рамках леса позволяет управлять приложениями, установленными на настоль ных и мобильных компьютерах, выполнять своевременное их об новление, применять определенные настройки отдельных прило жений, регулирующие доступ к ресурсам, централизованно управ лять сценариями регистрации и пр. Так, например, групповая по литика может для нсех пользователей определить расположение сервера Software Update Service (SUS) в корпоративной сети пред приятия, который используется для распространения всевозмож ных исправлений для операционной системы и связанных с ней приложений.

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

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

24 Active Directory: подход профессионала Х Постоянно повышающиеся требования к защите информации предполагают использование более эффективных средств обеспе чения зашиты. Одним из таких средств является внедрение инф раструктуры открытых ключей (PKI) на базе сертификатов Х. v.3. Внедрение этой инфраструктуры позволит использовать стан дартизованные средства шифрования и защиты информации, сер тифицированные соответствующими органами Российской Феде рации. Так, в частности, и дополнение к встроенным средствам защиты можно будет использовать цифровые смарт-карты для идентификации личности на компьютерах руководителей, а так же для выполнения критичных административных операций. Кро ме того, станет возможно использование электронной цифровой подписи (ЭЦП) в системах документооборота и почты. Несмотря на то, что внедрение инфраструктуры PKI возможно и для несколь ких лесов, в одном лесу использование системы будет наиболее прозрачным для пользователей.

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

Модель с несколькими лесами Напоследок рассмотрим модель с несколькими лесами. Какая ж это модель? Ч спросите вы. Ч Это просто два разных каталога Active Directory. Так-то оно так. Только ведь никому в голову не приходило в Windows NT говорить о двух доменах как о несвязанных структу рах. Так и тут. Раз могут существовать отдельные леса, значит, они могут взаимодействовать и использоваться для каких-либо целей.

Начнем с того, что модель с разными лесами использовать не реко мендуется. Она практически неуправляема, требует больших затрат на скоординированное администрирование и имеет ограниченное при менение. Ну, например, представим, что две крупные компании, каж дая из которых уже имеет свою структуру Active Directory, свое имя на рынке, свои приложения, интегрированные с AD. решили объеди ниться. Слить два леса нельзя. Даже если б было можно, то как посту пить со схемами? Они же разные! Единственный способ Ч установить прямые нетранзитивные доверительные отношения между теми до менами в каждом из предприятий, для которых нужен доступ к ресур сам друг друга.

Замечание Установить транзитивные доверительные отношения можно только между лесами, работающими в естественном режиме Windows 2003 Проектируем АО, или Мелочей не бывает Отсутствие у лесов общего ГК также не позволит им использовать единую адресную книгу в почтовой системе (если, конечно, в этой системе нет собственного каталога почтовых пользователей). Един ственный выход Ч задействовать службы синхронизации каталогов, например Microsoft Identity Integration Server (MIIS) 2003.

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

Явное доверие Основной лес Предприятие А Предприятие Б Примеры использования нескольких лесов:

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

Х Не требуется общая схема Это связано либо с тестовыми раз работками, либо с использованием различного ПО, интегрирован ного с Active Directory.

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

26 Active Directory: подход профессионала + Отношения с партнером или контрагентом Они не настолько близки, чтобы объединять сети, либо инфраструктуры Active Direc tory для обоих предприятий уже существуют.

Х Центральному отделу ИТне удалось договориться с региональной службой При отсутствии взаимодоверия и невозможности вне дрения единой политики следует пойти на разделение лесов.

Мигрируем с доменной структуры Windows NT Уяснив, как разбивать сеть на домены, обсудим доменную тактику и стратегию при миграции домена Windows NT. Для этого переберем все четыре модели объединения доменов Windows NT.

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

О технических аспектах миграции см. главу Установка Accive Directory*.

Миграция единственного домена Если в организации был лишь один домен Windows NT, то потенци ально есть два пути миграции:

+ в один домен Windows 2000;

ф в два домена Windows 2000.

Когда пойти первым? Ответ прост: см. выше критерии создания толь ко одного домена. Очевидно, в большинстве случаев вы придете имен но к решению 1 в 1. Уж если одного домена старого типа было доста точно для управления пользователями и ресурсами, то домена Win dows 2000 хватит и подавно.

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

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

Проектируем AD, или Мелочей не бывает Домен Windows Пути миграции одного домена Миграция доменной структуры с одним мастер-доменом Схема с одним мастер-доменом типична для большинства организа ций. Разделение учетных записей и ресурсов удобно с администра тивной точки зрения в доменах Windows NT. Доменам на базе Win dows 2000 такое разделение несвойственно, хотя это возможно. С уче том сказанного можно предложить следующие варианты миграции.

+ Мастер-домен Windows NT преобразуется в один домен Windows 2000. Все ресурсные домены аннулируются, а их ресурсы переме щаются в единственный домен.

Х Мастер-домен преобразуется в корневой домен Active Directory.

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

Х Создается пустой корневой домен. Мастер-домен преобразуется в дочерний. Ресурсные домены преобразуются в дочерние к нему или удаляются с переносом ресурсов в родительский домен. Учет ные записи пользователей никуда не переносятся.

Наиболее распространен первый способ миграции. Он выполняется обычно в два этапа. Сначала мастер-домен обновляется до Windows 2000.

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

Х прозрачность для пользователей: NetBIOS-имя домена может не изменяться, все ресурсы остаются постоянно доступными;

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

Х постепенность миграции: перенос ресурсов можно выполнять длительное время.

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

Например, это может быть территориальное или административное разделение. Миграция выполняется в три этапа. На первом мастер домен обновляется до корневого домена Windows 2000. Этот этап прозрачен для пользователей, так как с точки зрения аутентификации в домене, на первый взгляд, все остается по-прежнему.

На втором ресурсные домены обновляются до доменов Windows 2000:

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

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

Миграция кончается, когда все пользователи переносятся из корневого домена, в нем удаляются все глобальные группы, оставшиеся от старых времен, и остаются лишь административные группы предприятия (Sche ma Admins, Enterprise Admins) и административные группы домена.

Преимущества данного способа миграции таковы:

Х постепенность миграции: перенос ресурсов можно выполнять в течение длительного периода времени;

Х сокращение трафика репликации;

разделение на сайты спо собствует этому;

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

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

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

На первом этапе создается пустой корневой домен. Далее к нему в качестве дочернего присоединяется мигрировавший мастер-домен.

Этот этап прозрачен для пользователей.

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

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

Active Directory;

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

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

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

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

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

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

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

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

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

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

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

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

Active Directory.1 подход профессионала Группы и стратегия их использования Прежде чем говорить о планировании групп, кратко напомню о ви дах групп в Windows 2000.

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

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

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

Информация о членстве в универсальных группах не тиражируется на серверы ГК.

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

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

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

Возможно вы читали, что в группе не может быть более 5 000 членов.

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

А что же, спросите вы, делать, если надо включить почти всех пользо вателей в универсальную группу? Мало того, что их много, так ведь они постоянно меняются: приходят, увольняются!.

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

Рассмотрим пример. Пусть в лесу Active Directory пять доменов и в каждом 800-1 500 пользователей. Вы планируете все учетные записи рассортировать по их статусу на предприятии: постоянные работни ки, контракторы или временные сотрудники, сотрудники предприя тий-партнеров. Чтобы выполнить сортировку, поступим так.

В каждом домене создаем по три глобальные группы: FTDomainName для постоянных сотрудников, TempDomainName для контракторов, VDomainName для партнеров. Дхпее создаем три универсальные груп пы: FTEmployee, TempEmployee. Vernployee Ч и включим в них соот ветствующие глобальные группы. Наконец, можно создать универсаль ную группу AllUsers и включить в нее три ранее созданных универ сальных группы.

Несмотря на то, что в итоге в группу AllUsers попадет более 5 пользователей, она в себе содержит только 3 членов. Три другие уни версальные группы содержат по 5 членов. А максимальное число чле нов описанных глобальных групп не превышает 1 500 человек, и то при условии, что в каком-то домене все сотрудники принадлежат только к одной категории. Очевидно, что с точки зрения универсальных групп, членство в них неизменно, поэтому репликация выполняется только при их создании и первичном наполнении другими группами.

AIIEmployees включает:

FTBnployees, rempEmployees, VEmployees Пример наполнения универсальных групп 34 Active Directory: подход^профессионала Для чего могут понадобиться эти универсальные группы? Ну, напри мер, для фильтрации групповой политики или разграничения досту па к корпоративным файловым ресурсам в масштабах всего предпри ятия. Правда, в последнем случае не обойтись без локальных групп домена. Но об этом чуть позже.

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

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

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

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

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

ф MGMT для руководства;

Х SECRETARY для секретариата;

Х SALES для отдела продаж;

Х MKTG для отдела маркетинга;

Х STORE для склада;

Х IT для службы ИТ;

Х АССТ для бухгалтерии;

ф PROJECT для тех, кто включен в проект;

+ и ALL Ч группу, включающую в себя все перечисленные группы, кроме PROJECT.

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

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

Рассматривая всевозможные виды доступа к файловым ресурсам, мож но выделить три наиболее распространенных: полный доступ "(F).

чтение/запись+исполнение (CHG). чтение+исполнение (R). В соответ ствии с этой классификацией можно рекомендовать создание трех локальных групп для каждого файлового ресурса. Название группы может состоять из имени ресурса и обозначения вида доступа. Напри мер, для каталога Public можно создать локальные группы:

Х Public_F;

Х Public_CNG;

Х Pubiic_R.

Теперь для предоставления доступа к такому ресурсу достаточно вклю чить соответствующие глобальные группы в локальные с необходи мым типом доступа. Допустим, в рассматриваемом выше примере все работники предприятия должны иметь доступ только на чтение, а со трудники отделов продаж и маркетинга Ч еще и на запись. Полный доступ должен иметь ИТ-персонал. Тогда в группу Public_R включаем группу ALL, в Public_CNG Ч группы MKTG и SALES, а в Public^F Ч груп пу IT. Это распределение, но с одним отличием Ч бухгалтерия выне сена в отдельный домен, в котором и существует глобальная группа АССТ, Ч показано на рисунке ниже.

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

36 Active Directory: подход профессионала Список контроля доступа:

Public_R: Read Only PuMicCNG: Modify Public F:Full Control \\Server\Pub1ic Локальная группа Public R, члены:

MYCORP\ALL, ACCOUNT\ACCT Локальная группа Локальная группа Pub'ic_CNG, члены:

Public_F, члены:

MYCbRP\MKTG, MYCORP\IT Домен mycorp.ru Глобальные группы: MGMT, IT, SECRETARY, SALES, MKTG, STORE, PROJECT ALL Домен account.mycorp.ru Глобальная группа АССТ Пример предоставления доступа к ресурсу через членство в группах Внимание Всякий раз, предоставляя локальной группе доступ к какому-либо ресурсу, документируйте это событие и фиксируйте имя группы, название ресурса и нид доступа. Это облегчит вам жизнь.

Кто должен заниматься включением пользователей в группы досту па? Ответ неоднозначен. Если это маленькая организация, то с такой работой могут справиться сотрудники службы ИТ. Если же это ком пания, в которой много отделов, обладающих своими ресурсами, то лучше всеуэ назначить владельцев ресурсов. У каждого ресурса, пре доставленного в совместное пользование, должно быть не менее двух владельцев: основной и запасной. Им должно быть делегировано право включать пользователей в свои группы. Причем это можно сделать через Web-интерфейс и сценарии ADSI. Если какому-то пользовате лю требуется доступ к ресурсу, он открывает страницу Web и запра шивает нужный доступ. Сценарий ADSI определяет ответственного и посылает ему уведомление, например по почте. Ответственный, по лучив письмо, заходит на сгенеренную по такому случаю страницу Web и предоставляет/запрещает доступ.

Проектируем АР. или Мелочей не бывает Использование особых объединений Говоря о предоставлении доступа к ресурсам через членство в груп пах, нельзя не упомянуть особые объединения (special identities). Их можно для удобства считать группами, хотя это и не так: в них нельзя включить учетные записи пользователей, однако они включаются туда автоматически в зависимости от обстоятельств. Эти объединения не представлены в списке групп в Active Directory, но служат для разгра ничения доступа к ресурсам.

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

ф Authenticated Users Ч почти то же, что и Everyone, но не содер жит анонимных пользователей (гостей), Х В категорию Network Users входят пользователи, осуществляю щие в данный момент доступ к определенному ресурсу по сети.

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

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

Административные группы Теперь о том, как лучше использовать административные группы.

Начнем со встроенной локальной группы Administrators. По умолча нию в нее включены глобальные группы Domain Admins, Enterprise Admins (в естественном режиме работы домена это универсальная группа) и учетная запись Administrator. Так как это локальная группа, она служит для предоставления прав доступа к ресурсам домена. Если рассматриваемый домен не является корневым и вы не хотите, чтобы администраторы предприятия имели к вам отношение, исключите группу Enterprise Admins из локальной группы Administrators.

Внимание Не стройте иллюзий относительно своей независимос ти после исключения группы Enterprise Admins из группы Adminis trators. Если администраторам предприятия понадобится выполнить какие-то действия в вашем домене, они всегда это смогут сделать. Для этого им достаточно стать владельцами "ваших ресурсов. При пра вильно настроенном аудите эта операция будет отслежена в журнале.

38 Active Directory: подход профессионала Группа Enterprise Admins диет практически неограниченную власть.

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

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

Членство в административных группах должно жестко регламенти роваться. Одним из средств регламентирования является групповое правило Restricted Groups, ограничивающее членство в указываемых группах. В политике жестко прописано, кто может быть членом груп пы. Если кто-то добавит себя в одну из групп с ограниченным член ством, то по истечении срока обновления правил (5 минут для кон троллеров домена) он будет исключен из этой группы.

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

Х обеспечивалась непрерывность администрирования;

Х отсутствовали избыточные полномочия.

Таким образом, от групп мы переходим к рассмотрению организаци онных подразделений (ОП).

Если ОП создают, значит, это кому-нибудь нужно Организационные подразделения Ч это контейнеры в Active Directory, в которых Moiyr находиться такие объекты, как пользователи, компь ютеры, группы, принтеры, совместно используемые ресурсы, прило жения и другие ОП. Отличительной особенностью ОП является воз можность применения к ним групповой политики (кроме политики безопасности, применяемой ко всему домену). С другой стороны, ОП Ч это объект Active Directory, и, как к любому объекту, к нему и ко все Проектируем ДР. или Мелочей не бывает му, что в нем лежит, можно задать права доступа. Так что ОП Ч вещь довольно ценная.

Когда же использовать ОП? Ответов множество. Вот главные.

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

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

ф Для рассортировки объектов Можно отдельно разместить принтеры, пользователей, компьютеры и т. д.

+ Для ограничения числа объектов в контейнерах Хотя объ ем контейнера не ограничен, просматривать содержимое больших ОП неудобно Ч проще в один ОП поместить несколько меньших по объему.

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

Вы. конечно, поняли, что структура ОП планируется по определенным правилам. Вот они.

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

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

+ Иерархия ОП должна иметь смысл и быть понятной. Создавать ОП только ради него самого бессмысленно. Смысл же определяется ответом на вопросы: кто будет управлять и кто будет видеть ОП?

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

40 Active Directory: подход профессионала Модели организационных подразделений Эти правила привели к разработке нескольких моделей ОП.

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

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

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

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

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

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

Недосгаток модели в том. что она не отражает бизнес-потребностей предприятия.

Организационная иерархия Пользуется симпатией начальства, потому что отражает организаци онную структуру компании. На вершине иерархии Ч руководство, па втором уровне Ч дирекции, на третьем Ч отделы внутри дирек ций и т. д. Всякий раз, когда руководителю требуется указать сотруд ник}* на его место, он может открыть, скажем, Microsoft Visio. кото рый автоматически выведет на экран графическое представление структуры Active Director}7, а значит, и фактическую оргструктуру.

Опять же, когда возникает ситуация из разряда А подать сюда Ляп кина-Тяпкина!*, задается поиск этого субъекта в каталоге, А из имени субъекта следует, в каком отделе он работает. Вот и причина любви!

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

Объектная иерархия Эту модель я бы назвал по-военному прямолинейной. Есть классы объектов, вот их и дифференцируем. Компьютеры Ч- в одну кучу, Проектируем АР, или Мелочей не бывает пользователей Ч в другую, принтеры Ч в третью и т. д. Резон для такого деления есть, и не один:

Х ресурсами легче управлять, поскольку они все рассортированы-, + легче создавать общие списки контроля доступа к различным клас сам объектов;

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

Представим структуру ОП, построенную на объектной модели: на первом уровне ОП Принтеры, Пользователи, Рабочие станции и Сер веры, на втором идет детализация по какому-либо признаку, напри мер, Принтеры 1 этажа, Принтеры 2 этажа, Пользователи 1 этажа, Пользователи 2 этажа и т. д.

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

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

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

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

Поэтому она может иметь очень ограниченное применение.

Административная иерархия Предмет любви ИТ-сотрудников, так как именно им она обеспечива ет максимум комфорта;

ОП создаются на основании того, как легче управлять пользователями, компьютерами и пр. Например, если из вестно. что все различия пользователей в домене в том. с какими приложениями они работают, то составляются списки пользователей каждого приложения. Из общего списка выбирается подмножество Active Directory: подход профессионала "I/ приложений, нужных максимальному числу пользователей. Для это го приложения создается групповая политика, назначаемая корнево му ОП. Затем выбираются приложения, нужные меньшему числу поль зователей, и соответствующие групповые правила применяются к ОП второго уровня. Наконец, создается ОП нижнего уровня и заполняет ся пользователями, которым нужны специфические приложения. Рас смотрим пример.

Согласно корпоративному стандарту организации используется почто вый клиент Microsoft Outlook, а в качестве офисных приложений Microsoft Word и Excel. Кроме того, сотрудники бухгалтерии должны работать с ЮБухгалтерией и клиентской частью SAP. Последняя так же требуется сотрудникам отдела кадров и аналитического отдела.

Дополнительно к этому сотрудникам аналитического отдела нужны Microsoft Visio и Microsoft Project.

Вот как реализовать такую структуру ОП по административной модели:

+ верхний уровень: ОП, названное SAP, в которое включены сотруд ники отдела кадров;

Х второй уровень: ОП 1C (сотрудники бухгалтерии) и Анализ (со трудники аналитического отдела);

+ остальные пользователи не входят ни в какие ОП.

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

ОГП1 - установка офисных приложений ОГЛ2 - установка клиента SAP ОГПЗ - установка !С:Бухгалтерии ОГП4 - установка Visio и Project 5др 1 Сотрудники (Ж Сотрудники 1C Анализ ) Сотрудники бухгалтерии аналитического отдела Все остальные сотрудники Иллюстрация примера административной модели ОП Проектируем AD, или Мелочей не бывает Тот же пример, но реализованный через организационную модель Срашшм ее с другими моделями. Если следовать географической модели, то в данном случае все пользователи располагаются в одном ОП. Это значит, что для применения различных групповых правил понадобится фильтрация. Для этого будет нужно предварительно со здать группы, включить в них пользователей из каждого подразделе ния, а затем для каждой из групповой политик (разве кроме офисной) определить фильтры.

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

Так кому нужны организационные подразделения?

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

Все зависит от вашего ответа на вопрос: для кого создается структура ОП? Если отбросить ответ -ни для кого*, остаются такие варианты:

Х для себя (т. е. для администратора);

Х для начальства;

Х для пользователей.

44 Active Directory: подход профессионала Ну, начальству структура ОП ни к чему. Увы, убедить его в этом долж ны вы. Сделать это трудно, но надо.

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

Нужны ли подразделения пользователям?

Пользователь повседневно работает:

4 с документами (поиск, редактирование, сохранение, печать);

+ с почтой (поиск в адресной книге, редактирование/чтение писем);

Х со специализированными приложениями;

+ с сетевыми ресурсами (пииск);

Х и предоставляет локальные ресурсы в совместное использование (если разрешено).

Начнем по порядку. Прежде чем документ открыть, его надо найти.

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

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

И все же допустим, что познания нашего пользователя столь глубоки, что в списке Look in он выбирает команду Browse. Но даже тогда, чтобы добраться до каталога : ему надо раскрыть My Network Places, Entire Network, Directory и найти имя своего домена! Вот только тут он впервые увидит ОП. Я уж не говорю о том, что далее ему придется отыскать в каталоге ресурс и только после этого начать поиск. Итак, считаем данное событие маловероятным.

Процесс редактирования документов не связан с доступом к каталогу и ОП в нем.

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

Проектируем АО, или Мелочей не бывает Вывод документа на печать невозможен без доступа к каталогу. Но это знаете вы, технические специалисты, А пользователь об этом не зна ет, поэтому всегда печатает на том принтере, который к нему подклю чен. Если б он знал, что можно найти и другой принтер в каталоге и без проблем к нему подключиться, то он бы выбрал в меню Start ко манду Search и далее Search for printers. Но даже здесь знание структу ры ОП ему ни к чему. Пользователь знает такие атрибуты принтера, как его месторасположение, цветной он или нет, может быть, даже имя модели. А вот в каком ОП он находится, ему безразлично.

Работа с почтой интересует нас потому, что здесь пользователь актив но занимается поиском адресатов. Какое отношение имеет почтовая адресная книга к Active Directory? Если ваша система построена не на Microsoft Exchange 2000, то никакого. Но даже если у вас Exchange 2000. то и в этом случае структура ОП мало кого интересует. Глав ное Ч это почтовый адрес и другие атрибуты пользователя. Все ос тальные операции с почтовой программой не требуют доступа к ка талогу (с точки зрения пользователя, конечно).

drertety to s Х = ^ C*iktOp * I-J "У Document:

- My Cwnputer 3! MyNetwakFlaces l-j * Entire Network S ^ №ro5oft Windows Network S"<^ Directay B-^l Fyodor,*'Х ^J BuJtn Ф ЧJ Computers L*:--^ DomainContrtillers +...-..) ForsignSecurityPrincip it!

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

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

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

Подразделения нужны администраторам!

Остались администраторы... А нужны ли им ОП? Еще как! Вы же заме тили, что мы постоянно упоминали те операции администрирования, что без ОП невыполнимы.

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

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

В-третьих, это средство группирования ресурсов. Администраторам удобнее видеть рабочие стан! 1ии отдельно от принтеров и пользовате лей. Это позволит эффективнее применять к ним групповые правила.

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

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

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

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

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

Компьютеры, Группы. Можно добавить и другие ОП и поместить в них.

например, пользователей, имеющих отличные от остальных права. Для каждого вложенного, а также для самого учетного ОП создается ло Проектируем AD, или Мелочей не бывает кальная группа домена. Эти группы содержат пользователей, которым делегируется право управления соответствующими пложёнными СП.

Имена этих групп удобно составлять из <имени ОП>_<выполняемой функцииХ Тогда делегирование в учетном ОП сведется к назначению таких полномочий:

Тип доступа Имя группы ОП Тип объекта Full Control Родительское <имя On>_ou_admins Все объекты учетное ОП Дочерние ОП:

<имя ОП> ou user admins Full Control User Users Service Accounts <имя ОП> ou user admins Full Control User <имя on>_ou_computer_ Full Control Computers Computer admins <имя on>_ou_group_admins Full Control Groups Group <имя On>_ou_local_admins Full Control Limited Admins User Для ресурсных ОП в общем случае достаточно одной группы, кото рая владеет ОП и имеет полный доступ к объектам, Разбиваем на сайты Сайты Active Directory Ч это сегменты сети с высокой пропускной способностью. По крайней мере так гласят все определения сайтов.

А для чего они? Вот основные причины, по которым Active Directory нужно разбивать на сайты.

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

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

ф Управление трафиком репликации FRS Так как FRS использует для репликации ту же топологию, что и репликация Active Directory, то сайты положительно илияют на трафик.

+ Управление топологией DFS Если ресурс DFS имеет несколько реплик, то обращающийся к нему клиент будет направлен к бли жайшей к нему реплике.

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

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

3- Active Directory: подход профессионала На репликацию огромное влияние оказывают:

Х пропускная способность каналов;

Х трафик репликации;

Х расположение контроллеров доменов.

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

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

Возможность использовать Может потребоваться дополни нснадсжные каналы тельное оборудование, что удорожает решение Снижение трафика регистрации 11оддержка, специализированных приложений Так какой же все-таки критерий?

Итак, первый критерий разбиения на сайты Ч пропускная способ ность каналов связи. А что считать высокой пропускной способнос тью и что низкой? Часто как водораздел используют значение 10 Мб/с.

Всегда ли это так?

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

Теперь возьмем сегмент сети в соседней организации, Он подключен к основной территории каналом 1,5 Мб/с. На этой территории работников активно используют телефон, весь трафик которого на правляется по единственному каналу и занимает 50% от его пропуск ной способности. Кроме того, пользователи работают с электронной почтой, построенной на Microsoft Exchange 5-5. Этот трафик съедает еще 25% пропускной способности канала. Планируется и миграция на Exchange 2000. Общий размер организации невелик: 800 пользовате Проектируем АР, или Мелочей не бывает лей. но в компании текучка кадров. В такой ситуации однозначно надо говорить о создании отдельного сайта, так как трафик репликации в домене будет большим.

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

Если же он сравним или выше, то сайт необходим.

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

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

Еще один критерий Ч возможность управления межсайтовым трафи ком. Во-первых, можно составить расписание репликации. Если с 9. до 18.00 канал загружен на 90%, а в остальное время он практически свободен, можно сконфигурировать расписание так, что информация будет тиражироваться только в нерабочие часы. Во-вторых, можно задействовать компрессию трафика, которая включается автоматичес ки при превышении объема тиражирования равного 50 кб. В-треть их, для ненадежных каналов можно организовывать асинхронную репликацию по протоколу SMTP.

Алгоритм разбиения на сайты выглядит так (см. след. стр.).

Сколько может быть сайтов?

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