Книги, научные публикации
Pages: | 1 | 2 | 3 | 4 | 5 | ... | 7 | -- [ Страница 1 ] --
Федор Зубанов Active Directory подход профессионала Издание исправленное Москва 2003 УДК 004 ББК 32.973.81-018.2 391 Ф. В.
Active Directory: подход профессионала. Ч 2-е изд., испр. Ч М.: дом Русская 2003. 544 ил.
ISBN В обобщен опыт Microsoft Consulting в обла сти проектирования, развертывания и эксплуатации службы катало гов Active в самых разных организациях. Основной упор сделан на методике выявления проблем в работе Active и способах их устранения. На конкретных примерах разбираются настройки сетевых репликации и групповых правил.
Особое внимание специфике проектирования Active в крупных и очень крупных организациях.
Книга состоит из вступления, 6 глав и словаря терминов.
Это издание адресовано системным и специалис там в области проектирования корпоративных систем на базе 2000.
УДК 004 ББК Использованные а примерах и названия компаний и и события Любые совпадения с реальны ми компаниями, людьми и событиями являются Directory. ActiveX, Microsoft, Press, MS-DOS, PowerPoint, Visual Basic, C++, Visual Visual Visual Studio, Windows и NT являются товарными знаками, либо охра няемыми товарными Microsoft в США и/или других стра MySQL компании MySQL другие токарные знаки фирм.
й Зубанов Ф. В., 2002- й дом ISBN 5-7502-0118-Х Русская Оглавление Об этой книге XIII Структура книги XIV Чего здесь нет XVII Принятые соглашения XVII Проектируем AD, или Мелочей не бывает Что в имени тебе моем? Бизнес определяет имена Имена DNS и имена Active Покажем корень миру Алгоритм именования DNS объектов Active Directory Именование пользователей Именование компьютеров Имена подразделений Один за всех Критерии создания домена Когда одного домена достаточно Преимущества модели... все за одного Преимущества многодоменной модели (дерева) Посадим деревья и вырастет лес Преимущества модели с несколькими деревьями Преимущества модели с одним лесом Модель с несколькими лесами Мигрируем с доменной структуры Windows NT Миграция единственного домена Миграция доменной структуры с одним мастер-доменом Миграция доменной структуры с несколькими мастерами Миграция нескольких доменов с попарным доверием Группы и стратегия их использования Рекомендации по универсальных групп Рекомендации по использованию глобальных групп Рекомендации по использованию локальных групп домена Использование особых объединений Административные группы Если создают, значит, это кому-нибудь нужно Модели подразделений Географическая иерархия Организационная иерархия IV Active Directory: подход профессионала Объектная иерархия Проектная иерархия Административная иерархия Так кому организационные Нужны ли подразделения пользователям? Подразделения нужны администраторам! Делегирование административных полномочий Разбиваем на сайты Так какой же все-таки критерии? может быть сайтов? Сколько нужно контроллеров и где их размещать Менее пользователей От до 50 пользователей От 50 Надежная связь между сайтами Топология сетей Межсайтовые связи Объекты Серверы-форпосты Отказоустойчивые схемы Мастера операций и Глобальный каталог. Оптимальное размещение Мастер схемы Мастер доменных имен Имитатор Мастер RID Мастер инфраструктуры Глобальные каталоги Примеры размещения ' Конфигурация контроллеров доменов для удаленных филиалов Политика изменения схемы Когда и как модифицируют схему Применение политики схемы Active Directory, межсетевые экраны и Интернет Подключение доменов через VPN Подключение доменов с Авторизация ресурсов в DMZ Пример планирования Постановка задачи Предложенная архитектура Леса Домены Сайты Контроллеры доменов Организационные подразделения Группы Сервер Web и доступ к нему Заключение Установка Active Directory Что делать с 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 Файлы базы Active Directory SYSVOL : Журналы регистрации Служба синхронизации времени Автоматическая установка контроллера Новое дерево в новом лесу Дополнительный контроллер в домене -. Новый дочерний домен Новое дерево в лесу Понижение контроллера домена до уровня сервера Описание параметров и значений умолчания VI Directory: подход профессионала Анализируем журналы Как подобрать компьютер? Требования к процессору Требования к оперативной Конфигурация жестких Как проверить работоспособность контроллера домена А если он все-таки не работает?
Попробуем выяснить причину Некорректные параметры TCP/IP или ошибки в сети Некорректная работа службы DNS Проблемы с оборудованием, в первую очередь с дисковой подсистемой. Проблемы с репликацией Aclive Проблемы с репликацией FRS Некорректная групповая политика А все Все работает. Что делать?
Обновление контроллера домена Windows NT 4.0 до Windows 2000 Кое-что о Windows NT 4. Обеспечение безопасной миграции Две стратегии миграции Мигрируем домен Windows NT Обновление первичного контроллера домена Откат назад в случае сбоя работа контроллеров разных версий Алгоритмы установки контроллера домена Алгоритм установки контроллера Алгоритм обновления контроллера Windows NT 4.0 Заключение Репликация Active Directory Немного о том, как работает репликация Обновления в Active Directory USN Штамп Удаление объекта Процесс от А до Я Создание Модификация объекта распространения изменений конфликтов Топология репликации Какой транспорт Синхронная и асинхронная передача транспорт Особенности транспорта SMTP Управление пакетом репликации Автоматическая топологии Простая одного контекста имен Сложная топология для одного контекста имен Топология для нескольких контекстов имен КСС и его возможности Генератор топологии глобальных каталогов критических событий Тиражирование паролей Диагностика репликации Выяснение списка партнеров по репликации Active Directory Sites and Services Repadmin Replication Monitor Контроль состояния партнеров по репликации Repadmin Общая информация о параметрах репликации Поиск и устранение проблем репликации Запрет доступа (Access Denied) Вероятная причина Решение Неизвестная служба аутентификации (Authentication service is Unknown) Контроллер домена не может установить связь репликации Связь репликации существует Неверное имя учетной записи цели (Target account name is incorrect) Отсутствие объекта trusted Domain He совпадает набор SPN Недоступен сервер Server Not Available) Ошибка поиска в DNS (DNS Lookup failure) Служба каталогов перегружена (Directory service too Причина Разрешение во времени LDAP 82) Причина Устранение Внутренняя ошибка системы репликации Причины Устранение Отсутствие конечной точки (No more end-point) Ошибка LDAP 49 Сообщения, не ошибками Active Directory replication has been pre-empted Replication posted, waiting Last attempt... was not successful Заключение Active подход профессионала Групповая политика Общие сведения Клиент, сервер или кто важнее Типы групповых Структура и обработка групповой политики Устройство объекта групповой Хранение групповой политики Версии и ревизии Клиентские Обработка по медленным каналам связи Периодическое фоновое Применение неизмененной политики Параметры клиентских расширений Применение правил Изменение последовательности Блокировка наследования Принудительное наследование Перемычки правил Х " История правил Где и редактировать правила? Делегирование полномочий Делегирование прав на создание и модификацию ОГП Делегирование полномочий на привязку ОГП к объектам Active Directory Типы правил Правила установки ПО для компьютеров Установки Windows для компьютеров - сценарии Параметры Windows для компьютеров: безопасности Правила учетных записей Локальные правила Правила журнала регистрации Параметры Windows для компьютеров: правила групп с ограниченным членством Параметры Windows для компьютеров: системных служб Параметры Windows для правила реестра Параметры Windows для компьютеров: правила файловой системы Параметры Windows для компьютеров: правила открытых ключей Параметры Windows для Административные шаблоны для компьютеров Правила установки ПО для Параметры 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 профессионала Журналы Журнал регистрации File Replication System Журналы NTFRS между и в журнале Восстановление Неавторитетное восстановление Авторитетное восстановление Восстановление конфигурации FRS, процессов восстановления Сокращение числа серверов, создающих подготовительные файлы Сокращение числа реплицируемых файлов на выполнения процесса Разрешение выполнения только одного подключения вектора версий на входном партнере Распределенная файловая система Немного о DFS Таблица Взаимодействие клиента с сервером DFS Репликация Сайты и DFS Предельные возможности и ограничения Ограничения доступа Полезные советы Работа DFS без NetBIOS Резервное копирование пространства имен DFS Использование Использование DfsUtil Делегирование полномочий по управлению DFS модификации конфигурации DFS Делегирование полномочий настройки репликации томов DFS Делегирование управлению томами DFS и разграничению доступа Поиск и устранение проблем DFS DfsUtil /view Аргументы управления конфигурацией Аргументы отладочного режима Наиболее общие проблемы и их разрешение сервера до новой аерсии Изменение имени хоста DFS Удаление последнего корня DFS Перемещение хоста DFS в другой сайт Проблемы доступа к пространству имен DFS Невозможность DFS Оглавление XI Удаление конфигурационной информации Удаление доменных корней Удаление корней отдельно стоящих DFS Заключение Поиск и устранение проблем Алгоритм поиска и проблем Active Directory Резервное копирование Active Directory Чем нужно копировать Что нужно копировать Кто может копировать Файлы, игнорируемые при копировании резервной копии Никогда не ставьте время на больше Восстановление Active Directory Восстановление через переустановку Принудительное назначение мастеров операций с помощью Восстановление резервной копии Неавторитетное восстановление Проверка с помощью Ntdsutil Восстановление на другую технику Если система загрузилась Если система загружается только в безопасном режиме Если система не загружается восстановление Авторитетное восстановление с помощью Ntdsutil Обеспечение правильности Влияние авторитетного Влияние на доверительные отношения и учетные записи компьютеров Влияние на членство в группах Восстановление каталога Восстановление мастеров операций Кто может быть мастером операций? Восстановление мастера схемы Восстановление мастера доменных имен мастера Восстановление имитатора Восстановление мастера инфраструктуры Проверка целостности и восстановление базы восстановление журналов базы Проверка целостности базы Семантический анализ базы Ремонт базы Перенос базы Active Directory Выяснение местоположения файлов Перенос файлов базы Перенос файлов журналов Если надо переустановить домен в лесу Active подход профессионала Постановка задачи Общая последовательность действий Определение правил переноса Последовательность действий с первого взгляда Перенос и групп в Проверка результата План аварийного Если в лесу все перестало работать Общая последовательность действий шаги Документирование текущей структуры леса Разработка процедуры отката назад Выявление лучшего кандидата на восстановление Выключение всех контроллеров доменов Восстановление Восстановление корневого домена Восстановление остальных доменов Добавление дополнительных контроллеров Заключительные шаги Заключение - Словарь терминов Предметный указатель Список литературы Об авторе Об этой книге Скоро будет уже четыре года, как вышла система Windows а с ней Ч служба Active Уже стихли ные баталии о том, чем она лучше или хуже уже не ются осторожные реплики, дескать, подождать надо, пока другие не попробуют да сервисный пакет не выйдет, а то и два. Уже прочитана уйма литературы на эту тему, благо ее на русском языке издано пре достаточно. И вот результат: крупные и средние компа нии массово стали переходить на Windows 2000 и Active Directory.
После выхода Windows Server 2003 все было обращено на этот продукт. Уже сейчас компании все чаще планируют внедрение именно этой ОС, а не ее предшественницы. Возможно, открывая специалисты хотели бы видеть самую последнюю информацию об Active Directory 2003. Но для данной книги это невозможное требова ние, так как здесь я пишу о том. с чем работал длительное время. Но это не означает, что книга бесполезна для таких читателей.
Все концепции построения службы каталогов и ее обслуживания ос тались прежними. Поэтому все, что здесь описано, в полной мере относится и к Windows 2003.
С момента выхода Windows 2000 я помогал компаниям внедрять Directory. Шишек за это время было набито немало: в каждой органи зации своя специфика и свои все обладают разным нем готовности к этому шагу. Это требовало искать обходные пуги и нетривиальные решения. Но подобные процессы имели место и в дру гих странах. В итоге в Microsoft накопился значительный опыт внедре знания и достижения сотен консультантов Microsoft Consulting Services. Часть информации опубликована на Web-сай те Microsoft, в базе знаний Microsoft, также доступной в Интернете XIV Directory: профессионала и на дисках по подписке, часть Ч на курсах по отладке Active Directory.
Ни одна самая хорошая не даст вам столько, сколько эти три источника. Но я и не ставил такой задачи.
Цель книги Ч научить пользоваться в нужное время и в нуж ном месте нужными источниками информации для решения сложных задач настройки и Active Directory.
Обидно, что сотни ознакомившись с обзорными мате риалами по Windows 2000, пытаются строить лес в организации и совершают при этом нелепейшие ошибки, приводящие если не к полной неработоспособности, то к системы. Систе ма вопит о своем а не понимая ее моль бы о помощи, продолжают душить.
Эта книга содержит тот минимум информации, который должен знать любой администратор системы или ее чтобы само стоятельно поддерживать систему в добром здравии и обеспечивать не только ее работу, но и восстановление в случае краха.
Работая над книгой, я исходил того, что читатель имеет общее пред ставление о Windows 2000, Active Directory и о том, как это все тает, Поэтому здесь вы не найдете разжевывания базовых понятий службы каталогов;
это все я уже объяснял в книге Windows 2000. Планирование, развертывание, (2-е изд. М.: Русская Редакция. Ч 2000 г.). которую можно с полным основанием считать первой частью настоящей. Но если там акцент делался на описании новых возможностей Windows 2000 и на том, как их то здесь на том, как функции Active использовать с максималь ной эффективностью и бороться с возникающими проблемами. В первой книге вы знакомились со стандартными инструментами, вхо дящими в комплект ОС, здесь же описывается практическая работа с дополнительными программами и либо в составе Windows 2000 Server Resource Kit, либо в составе Widows Support Tools.
Я постарался избегать по возможности сухой теории и специальной терминологии. Я хотел вам просто рассказать самое главное, что знаю на эту тему. Но не расслабляйтесь: за шутками порой скрывается очень важная которую надо как таблицу умножения. Хотя я беру за основу английскую версию ОС, употребляю я при этом рус ские термины. Меня коробит, когда русский человек начинает выдавать перлы вроде или сайт У всех терминов есть русские эквиваленты, которыми пользоваться.
За год, прошедший с момента выхода первого издания, книга широ ко разошлась по стране. Для многих она стала настольной книгой и первым источником при поиске решения каких-либо проблем. Во второе издание были небольшие, но очень существенные изменения и дополнения в первую главу, посвященную планированию Active Directory. Эти изменения касаются вопросов построения безо пасной доменной архитектуры и базируются на опыте реальных про последних двух лет. Помимо местами введены замечания об особенностях AD для Windows 2003. были устранены замеченные мною и читателями досадные опечатки, Структура книги Шесть из которых состоит книга, я намеренно не стал нумеро вать: определенно сказать, какую читать первой, а какую Ч последней, нельзя, Главы перекликаются: из одной ссылки идут ко всем осталь ным. Там, где этого мало, я делаю ссылки на другие книги и в первую очередь на уже упоминавшуюся Windows 2000. Планиро вание, развертывание, управление.
Если Active Directory уже в вашей организации, то это со всем не означает, что глава Проектируем Active Directory, или Ме лочей не не для вас. Во-первых, никогда не поздно прове все ли правильно у вас сделано. Возможно, есть какие-то мелочи, которым вы пока не придавали значения, но способные отравить вам жизнь в будущем. Во-вторых, компании постоянно развиваются: при обретаются и открываются новые подразделения, продаются ющие, происходит слияние с расширяются территории и т. п. Вот тут-то эта глава и поможет вам. Наконец, никогда не считай те полученные ранее абсолютными и неизменными. За прошед шие годы многое изменилось в принципах построения Active Directory.
То, что пару лет назад казалось единственно верным, сегодня уже не представляется столь бесспорным и претерпевает изменения. То, о чем раньше даже и не всплыло во время крупных проектов и теперь считается обязательным условием проектирования.
Название Active Directory может сбить с С одной стороны, те, кто ее уже установил, решат, что читать об этом незачем.
Новички же, только осваивающие этот путь, могут подумать, что это для них. Не Эта информация станет полностью доступной только того, как вы хотя бы в рамках стандартной ции познакомитесь с Windows 2000 DNS, DHCP, Active про граммой Эта глава не о том, как из сервера сделать контрол лер домена, а о том, как не допустить ошибок на предварительной ста дии и как избавиться от ошибок, если они все-таки возникли при уста новке.
От правильной настройки служб DNS, WINS и DHCP зависит, как будет работать система. Способов конфигурирования так много, что выбрать XVI Active профессионала самый верный Ч не очень простая задача. Но вот контроллер домена установлен. Как понять, что псе сделано правильно и выявить потен циальные проблемы? Ответ на этот вопрос дан в этой главе. Плюс к этому Ч полезные сведения о конфигурировании системы в нестан дартных Так же. как Active Directory немыслима без репликации, так и книга немыслима без главы Active Directory. Масса про блем с Active возникает некорректно работающей реп ликации. Чтобы их надо, с одной стороны, разобраться в ме ханизмах репликации, а с другой Ч знать и уметь использовать инст рументы диагностики. поэтому теорию данного процесса я раскрыл гораздо полнее, чем в других книгах, А теорию, вы без труда справитесь с той которую предоставляют средства диагностики. А с чем не справитесь, найдете объясне ние в этой главе.
Но репликация службы каталогов не единственный вид репликации в Windows 2000. Active Directory тесно с файловой системой:
это файлы базы данных и журнала транзакций, составляющие группо вых правил, хранящиеся на диске, профили пользователей и сценарии.
От того, насколько эти компоненты согласованы с данными в Active Directory, зависит и защищенность системы. А согласо ванием занимается служба репликации файловой системы. Вот о ней и идет речь в главе *Active Directory и файловая система. Как не но этим вопросом многие просто пренебрегают, полагая, что тут все ясно, оно всегда работает. Увы, это не Эта тема менее всего отражена в литературе, а зря! Проблемы с репликацией файлов могла причинить столько проблем, что с лихвой хватит, чтобы омрачить радость от нормальной работы остальных служб. основной лейтмотив этой главы Ч диагностика проблем.
С репликацией файловой системы связана работа распре деленной файловой системы DFS. Неискушенный администратор лег ко отыскивая причину недоступности тома на одном ком пьютере и совершенно нормальной работе на другом. Только грамот ное средств диагностики DFS и репликации файловой системы может помочь своевременно восстановить работоспособ ность распределенной файловой системы, А диагностика без пони мания основ Ч пустое занятие Поэтому в этой главе я привел необ ходимый минимум теоретических сведений.
Одним из звеньев, связывающих объекты Directory и пользова групповая полигика. К сожалению, еще далеко не все представляют, как можно и нужно применять групповые правила, как применять принципы наследования и блокировки, что такое фильтры Об книге и т. п. Этому посвящена глава Групповая политика. Хорошо, когда политика применяется. Хуже, когда возникают проблемы. Их поиск Ч одна из самых неприятных и запутанных операций в Windows 2000.
И даже применение инструментов диагностики требует определенной подготовки и навыка. В этом, надеюсь, вам поможет данная глава.
Глава Поиск и устранение проблем Ч не фармакологический Здесь нет симптомов болезни и перечня лекарств от нее. О том, как искать причины конкретной ошибки и устранять ее, рассказано в остальных главах. А что же тогда Ч спросите вы.
А здесь Ч описание алгоритмов поиска источника проблем, что гораз по-моему, важнее. Алгоритмы ссылаются на ту или иную главу. А все вместе Ч дает решение.
Любая проблема подобна простуде: стоит запустить Ч и она перерас тет в хроническую болезнь. Хорошо, если вовремя принять лекарство, а то и до скальпеля недалеко, Хирургическое вмешательство в Active Directory Ч дело рискованное и чревато летальным исходом. Счастье, если у вас есть резервная копия. Хорошая резервная копия, из которой можно восстановить каталог и потерянные объекты. Что такое хоро шая резервная копия Active Directory, как ее сделать и как из нее вос становить информацию Ч вот то, что вы найдете в этой главе.
Если говорить языком здесь вы найдете и описание транс плантации органов целых доменов в и вос крешение из (восстановление погибшего каталога).
Чего здесь нет В этой книге вы НЕ найдете:
Х описания модели безопасности Active Х описания инфраструктуры открытых ключей и ее диагностики;
возможно, когда потребности в этом увеличатся, соответствующая глава будет добавлена;
описания процесса установки Windows 2000 и конфигурирования служб, не имеющих прямого отношения к Active Directory: не сто ит утяжелять книгу сопутствующим Х рекомендаций по управлению проектом внедрения Active Directory:
эта тема слишком объемна и требует отдельного освещения;
Х советов по организации сопровождения и поддержки корпоратив ной вычислительной системы на базе Active Directory: это предмет такой дисциплины, как Microsoft Operations Framework и требует систематизированного подхода.
Короче, здесь нет ни слова о том, что не относится к Windows 2000 и Active Directory.
Active Принятые Для удобства чтения в книге приняты следующие обозначения:
Любой термин, первый раз, выделен курсивам.
Выделение служит также подсказкой о том, что объяснение термина приведено в Словаре в конце книги.
Ссылки дополнительную литературу приведены в скобках].
Тексты сценариев и листинги файлов выделены шрифтом, Описания синтаксиса команд ОС или дополнительных утилит выде лены моноширинным шрифтом полужирного начертания.
Замечание Если на что-то требуется обратить особое внимание, то соответствующий абзац выделен точно так же, как и этот.
Проектируем AD, или Мелочей не бывает Прежде чем установить Active ее нужно спроектировать.
В прошлом, когда служба каталогов Windows про ектирование было столь же необходимо, как и сейчас. Вот цена ошибки была гораздо ниже. Существовало четыре типовых схемы связей между доменами, которые использовались полностью либо в некоторой комбинации [9]. Если какой-то из доменов был спроекти рован неверно, его можно было совершенно безболезненно для ос тальных лубить и сделать по-новому. В Active Directory все домены объединены в лес. Ошиблись при корневого домена Ч придется переделывать весь лес, а это может Не меньше может стоить и ошибка в одном из промежуточных доменов, Я уж не говорю о том, что неверная топология репликации и плани ровка сайтов могут вам сплошные хлопоты и неоправдан ные затраты на приобретение дополнительного оборудования. Разби ение на подразделения, выполненное не в соответствии с админист ративными а по может превра тить процесс администрирования в ад для технических специалистов и повлечет неоправданный рост численности технического персонала.
Суммируя можно констатировать, что неправильное пла нирование компонентов Active Directory чревато:
Х неоправданными расходами на Х неоправданными расходами на технических специалистов;
Х повышенной трудоемкостью работ;
Х нестабильной работой системы:
Active подход профессионала потерей данных;
утечкой конфиденциальной информации;
вашим увольнением.
Как список и на вероятность любого из перечис ленных в нем событий оказывает влияние масса Порой это в гигантскую проблему. Вот почему в этой гла ве мы обсудим вопросы планирования Active Directory и, в частности:
+ стратегию именования;
и на домены:
Х принципы построения структуры подразделений;
правила разбиения на сайты;
принципы размещения сетевых сервисов, Глобальных каталогов (ГК) и других служб Active Directory;
модификации схемы.
Что в имени тебе моем?..
Казалось бы, какое может иметь название домена к ста работы или администрирования? Отве чая на этот вопрос, надо вспомнить, что живем мы в мире, наполнен ном глобальными сетями, Интернетом и всякими хакерами, способ ными просто из спортивного интереса лисследовать что-то, что мо жет представлять для них лакомый Не забывайте, что построена на системе именований DNS и очень тесно с ней что в свою очередь предполагает понимание различий меж ду имен DNS и пространством имен Active Directory.
Кроме того, имя. которое вы даете своей в первую очередь определяется потребностями бизнеса организации и условиями его развития.
определяет имена Не важно, сколько доменов в вашей Active Directory. Главное, обяза будет корневой домен Ч носитель имени леса доменов Active Directory, Назвав его, впоследствии ничего уже нельзя будет изменить, иначе как только переустановив домены в Active Directory, начи ная с Замечание Для доменов Windows 2003 это не В состав этой опе рационной системы входит утилита, позволяющая переименовывать домены. Правда для этого лес должен работать в режиме естественно го Windows 2003, то есть в нем не может быть доменов Windows 2000.
AD, или Мелочей Критерии выбора имени леса таковы:
отражение компании в доменном имени;
в Интернете;
планы по приобретению других компаний;
сложность имени.
критерий очевиден. Странно было бы назвать coffec sale.ru чайную компанию. Однако, лес Active Directory, поста райтесь учесть возможные в ближайшем будущем смены направлений деятельности или имени компании, например, при ее по купке более крупной компанией.
Если компания уже в Интернете и имеет там зарегист рированное имя, то вполне очевидно желание то же имя и внутри Но даже если сейчас вы еще не вышли в тернет, не что это будет сделано в ближайшем будущем.
А раз так, выбранное имя должно зарегистрировано в иначе оно может оказаться занятым, и вам придется вы бирать новое название па заданную тему.
Называя корень Active подумайте, какую долю бизнеса ком пании будет доменная структура. Допустим, компания за производством молока и соков, причем это произошло в ре зультате слияния двух независимых компаний, и каждая имеет в зна чительной степени независимое управление и политику ИТ. Если в корневого домена будет слово это скры тое раздражение производителей сока, и, домен соч именем, вы рискуете вызвать гнев молочников. Имя должно быть нейтральным или совмещать в себе признаки обеих организа ций. Например, это может быть название совместной зарегистриро ванной торговой марки или объединенное имя компаний, что-то вроде milkandjuce.ru. Правда, в последнем случае есть угроза нажить себе врагов после приобретения компанией фирмы по производству газированных напитков.
Замечание Всегда можно добавить в лес новое дерево с нужным именем. Правда, у корня по-прежнему будет оригинальное имя.
Наконец, последний критерий Ч сложность имени. Назвав корневой домен братья и вы кроме раздражения администраторов, не наживете. Ведь им придется для выполнения разного рода операций отладки и мониторинга писать длиннющее имя домена или контекста в Active Directory в LDAP-нотации.
Active Directory: профессионала Имена DNS и имена Active Directory Давайте вспомним о разнице между именами DNS и Active Directory.
Вы, конечно, знаете, что как систему именований Active Directory ис пользует DNS. Сервер DNS хранит информацию об именах и соответ ствующих им адресах IP, обеспечивает разрешение этих имен по зап росам от клиентов и тиражирует эту информацию между отдельны ми серверами согласно установленным правилам.
Active Directory хранит сведения о своих объектах подразделениях и т. п.), тиражирует их между контрол лерами доменов и предоставляет своим клиентам в ответ на запросы.
Для каждого домена Active Directory есть данные (записи типа имена доменов и хостов, партнеров по репликации), которые хранятся в зонах DNS. Каждому имени домена Active Direc соответствует такое же зоны DNS. А вот обратное Ч для каж дой зоны DNS обязательно имеется соответствующий домен Active Directory Ч неверно.
Mycorp.ru Контроллер mycorp.ru Сервер DNS MSK.Mycorp.ru Для каждого домена существует зона в DNS, но не наоборот Покажем корень миру Как упомянуто выше, к названию леса (то есть корневого домена в ле су) надо подходить чрезвычайно внимательно. Особо на ситуации с именем корня. Практика показывает, что боль шинство организаций выбирает для корня имена вида xxx.yyy.zzz, то есть имя, соответствующее системе именований в котором есть по крайней мере одна точка. Это такие имена, как mybank.ru, corp.net и пр. Однако в ряде организаций сильны традиции имен NetBIOS. Они стремятся дать корневому домену имя, то есть или Мелочей не состоящее из одной части, например mycorp или ad. Свое решение специалисты этих компаний аргументируют так: Так короче. А где сказано, что это запрещено? И ведь в самом деле это не запрещено.
Более того, в большинстве случаев это не вызывает никаких проблем, Проблема возникает, как только контроллеры дочерних доменов или серверы-члены корневого домена в другой подсе ти, такой, что NetBIOS-имена между этими подсетями не разрешают ся. проблема приводит к невозможности нормального функцио нирования Active Directory. Именно поэтому я настоятельно рекомен дую избегать таких имен. Но уж если вы упрямы, что желаете использовать их во что бы то ни стало, то обратитесь к главе Уста новка Active где описано, как правильно сконфигурировать контроллеры доменов и серверы для работы с плоскими именами доменов.
Между именем корня леса доменов Active Directory и внешнем име нем DNS компании могут быть разные взаимосвязи. Все возможные варианты сводятся к трем:
Х доменное имя и имя в Интернете совпадают;
доменное имя является дочерним для имени в Х доменное имя не имеет ничего общего с представленным в Ин тернете.
О настройке DNS см. главу Установка Active здесь же я приведу только общие рекомендации. Главное, что в любом случае внутренний и внешний серверы DNS разделены межсетевым экраном.
Если имя леса Active Directory совпадает с зарегистрированным вне шним именем DNS:
пользователи осуществляют доступ как ко внешним, так и внутрен ним ресурсам по доменному имени;
нельзя открывать внутренние ресурсы для внешнего мира;
вне шний сервер DNS не должен хранить имен, используемых Active Directory;
для разрешения внешних имен внутренней сети используйте передачу неразрешенных вызовов на внешний сервер DNS;
Х ресурсы, доступные извне, должны храниться в демилитаризован ной зоне (DMZ), доступа к ним Ч выполняться через а не контроллер домена;
на прокси-сервере надо сконфигурировать список исключений;
при использовании протокола трансляции адресов (NAT) внутренний сервер должен содержать свои записи о ресур сах, доступных как извне, так и изнутри;
этими адре сами Ч забота администратора.
Active Directory: подход профессионала Если имя леса Active Directory является дочерним по отношению к имени Х только содержит информацию об Active на внешнем сервере создается делегирование зоны, соответ зоне домена Active Directory;
Х пользователи применяют разные имена для доступа к внешним внутренним ресурсам;
для обеспечения доступа пользователей ко внешним не требуется предпринимать дополнительных усилий;
полные имена ресурсов чем в предыдущем случае.
При различных именах леса Active Directory и внешнего имени DNS:
управление безопасностью внутренней сети проще за счет полно стью различных имен;
Х внутренние имена не видны снаружи;
тиражировать информацию с внешнего DNS на внутрен ний не обязательно;
инфраструктура DNS может оставаться без изменений;
внутреннее имя не регистрировать в ICAAN.
Дополнительную информацию по именованию см. в [8].
Алгоритм именования DNS Если суммировать сказанное в этом с материалами посвященного Установка Active можно составить такой алгоритм стратегии именования, как показано на рисунке Именование объектов Active Directory Об именовании объектов (т. е. компьютеров, пользователей и подраз делений) не часто пишут в книгах no Active Directory. Возможно, их авторы считают, что на таком тривиальном вопросе останавливаться не стоит. Мой опыт показывает, что изобретательности службы ИТ нет границ. Ниже приводятся примеры наиболее удачных типов имен.
Именование пользователей Когда речь идет об объектах типа User, следует отдельно говорить о таких атрибутах, как:
Сп Ч общее имя;
Х Ч имя отображаемое в каталоге;
Ч имя, используемое при регистрации в домене Windows NT;
или Мелочей не Создать четыре ресурсных на сервере I их DNS в и создать на и серверах зоны с одним именем Серверы разделить другое имя межсетевым зону на в для сервер на существующем сервере DNS V DNS ее зону с этим именем и в I имя и на и две различные зоны DNS 2000. Серверы на двух межсетевым межсетевым Внутренний р будет Стратегия использования доменных имен Ч используемое при регистрации в домене Windows 2000.
Общее имя совпадает с именем, в каталоге, и представ ляется почти так. как мы привыкли обращаться друг к другу: имя, фамилия и кусочек отчества. Формат общего имени такой:
пробел<часть Максимальная дли на имени совместно с фамилией составляет 57 символов при отсут отчества и 55 Ч при максимальной длине отчества, равной символам. Предельная длина общего имени Ч 64 символа. В качестве символов имени допустимы символы UNICODE, т, е. пользователей вполне можно называть Active профессионала Имя, применяемое при регистрации в домене Windows NT, обычно служит и для регистрации домене Windows 2000. В диалоговом окне регистрации пользователь вводит именно это имя, пароль и имя до мена. Если же он введет данные в формате то он введет имя UPN. Первая часть и имя регистрации в домене Win dows NT по умолчанию совпадают, но могут быть и разными. Для простоты далее мы будем полагать, что они совпадают, и назовем их просто именем регистрации.
В качестве имени используется несколько схем. Наибо лее употребительная основывается на имени и фамилии пользователя записанных латинскими В этой схеме несколько вариаций:
<первая буква имени><фамилия><номер*>;
<имя><первая буква номер*>;
<часть Звездочка означает, что номер используется в случае наличия полных тезок на предприятии. Иногда вместо номера применяется иная ла тинская транслитерация, например, Petrov, Petroff, Petrow.
Вторая схема встречается довольно Она основывается на не котором персональном идентификаторе пользователя. Это можег быть его табельный номер. К идентификатору можно добавлять до полнительную обозначающую статус сотрудника (времен сотрудник Ч t, сотрудник компании поставщика Ч v и т. п.), ме стонахождение или к тому или иному подразделе нию. Последнее нельзя признать удачным, так как при переходе другое подразделение имя регистрации пользователя придется менять.
Именование компьютеров В именовании компьютеров наблюдается полный разнобой. прав да, объединяет все схемы наименований: администраторы стараются давать принципиально разные имена серверам и рабочим станциям.
В качестве примера удачного именования серверов можно привести;
где:
+ XXX соответствует территориальному расположению сервера;
это может быть код записанный в Конституции РФ, аббреви атура, соответствующая определенному городу NSK, SPB) или любой иной код, понятный администраторам;
YYY Ч тип сервера, например, SRV Ч сервер общего DC Ч контроллер Ч почтовый сервер, PXY Ч кси-сервер, WWW Ч Web-сервер и т. п.;
NN Ч порядковый номер сервера данного типа в данном регионе.
Проектируем или не бывает Если структура Active Directory такова, что каждому региону (или каж дой площадке) соответствует свой домен, то из имени можно исклю чить первый префикс, так как из полного имени сервера и так будет понятно, где расположен сервер.
Еще одна распространенная схема именования: присвоение серве рам условных имен, например, MARS. SATURN, JUPITER и т. п. Если рассматривать неочевидность наименования как достоинство, не позволяющее разобраться с первого взгляда, что есть что, то это же и недостаток, так как администратор вынужден держать в голове таблицу соответствия серверов выполняемым ими функциям.
Имена рабочих станций лучше всего связывать с именами пользова телей, которые на них работают (если, конечно, на одной станции не работает несколько пользователей по очереди). Это удобно при по иске источника проблем или при оказании помощи пользователям.
схема именования имеет следующий формат:
XXXYYYYYYYNN где:
XXX - тип операционной системы YYYYYYYY Ч имя регистрации пользователя;
Х NN Ч порядковый номер, если у пользователя несколько компью теров.
Вместо номера можно применять суффиксы, указывающие на тип компьютера, например. MOB Ч для мобильных компьютеров.
Иногда схема именования учитывает номер комнаты и номер сете вой розетки в ней. Недостаток схемы: при перемещении сотрудника в новый офис полностью меняется имя компьютера. Достоинство:
можно моментально не только вычислить злоумышленника в сети, но и оперативно отключить его от нее.
Имена подразделений Специальных требований к именам подразделений нет. Они могут жать символы UNICODE и довольно длинными Ч до 64 символов.
К сожалению, длина отличительного имени объекта (distinguished включающего имена всех родительских подразделений и имя домена, не воспринимается корректно некоторыми приложениями.
Эта явная ошибка в приложении может доставить массу неприятнос тей, так как диагностика ее может быть весьма непростой.
Специалисты по Windows NT считали, что создать доменную струк туру очень просто: существовало четыре модели;
с одним доменом, с одним с мастер-доменами и модель 10 Active Directory:
полностью доверительных отношений. Выбор модели определялся р.
основном размерами организации и ее финансовыми возможностями, Active Directory внесла определенную смуту. Во-первых, оказалось, что прежние модели объединения более не имеют смысла. Во-вторых, наличие организационных подразделений решает многие зада чи, ранее решаемые посредством разбиения на домены. Наконец, свойства коренным образом пересмот реть способы построения организационной структуры предприятий.
Прежде чем перейти к обсуждению возможностей, вспомним некоторые основные Итак для Windows ливы следующие определения.
Домен Ч это элемент имеющий свое собственное про странство имен. Внутри домена действуют правила безопасности, не распространяемые за пределы.
Х Доменные функции контроллерами доменов. Все контроллеры домена и хранят реплики каталога, доступные для внесения изменений. Изменения между контролле рами тиражируются при репликации. Тип репликации Ч со мно гими мастерами.
Х Между доменами устанавливаться отношения доверия. Тип доверительных ий транзитивный, т. е. если домен А ряет домену Б. а домен доверяет домену В. то домен А домену В. Транзитивные доверительные отношения Х Домены объединяются в деревья. Самый первый домен в дереве корневым. Дочерние домены наследуют имен от родительского домена. Между доменами в тически устанавливаются транзитивные доверительные отношения Деревья доменов могут объединяться в леса. Самый первый в первом: дереве леса называется корнем леса. Каждое дерево име ет свое имя, определяемое именем корневого домена в дереве. Имя леса определяется именем корня леса. Между доменами в лесу су ществуют транзитивные доверительные отношения. Все домены леса используют общую схему и конфигурацию.
Два леса характеризуются разными пространствами имен, разной конфигурацией и разной схемой. Между двумя лесами можно ус тановить одно- или нетранзитивные довери тельные Замечание Между лесами Windows 2003 можно устанавливать тран зитивные доверительные отношения.
Проектируем или Мелочей не бывает Один за всех...
Как вы помните, один домен способен поддерживать до 10 миллионов каталога. По крайней мере так пособия по Active Directory. He могу не что на момент написания книги мне было известно о домене, в котором было 34 миллиона объектов. Даже если предположить, что из всех этих объектов только 1 миллион прихо дится на пользователей, а все остальные на компьютеры, подразделения и т. п., то, повторяя небезызвестного так и хо чется сказать: А ведь и в самом деле, почему бы не оста новиться на одном домене для любого предприятия? Вы можете на звать в России хоть одну организацию с миллионом сотрудников?
жизнь не столь проста, и одним доменом не всегда можно отде латься. Для начала рассмотрим критерии, по следует опре делять использования доменов.
Критерии создания домена Первый критерий Ч соображения политики.
Прошу не путать администрирование с управлением. Управленцы (включая президента компании, его замов, директоров и менеджеров) вообще должны влиять на доменную структуру. Администраторы системы определять, построить чтобы ею было проще управлять. что не президент компании и даже не вице по информационным технологиям будут управлять полити ками безопасности, распространением программ по рабочим местам и поддержкой пользователей. Они будут требовать с вас, чтобы все работало без сбоев, и именно ваша задача сделать так, чтобы доменная структура работала на вас и обеспечивала требуемую руководством с минимумом затрат и усилий.
Второй критерий Ч Вспомните определение домена: имен но в нем звучит этот термин! Домен можно рассматривать как некое го правительство которого проводит определенную политику по его защите. Это, например, правила работы с паролями, аутентификации (читай "паспортный и т. п. Все граждане государства (пользова тели) обязаны строго соблюдать правила и подвергаться наказаниям при их нарушении (например, блокировка учетной записи).
Третий критерий Ч размер. Организацию с миллионом лей представить трудно. Но если, например, налоговики захотят со здать для каждого работоспособного гражданина учетную запись в то это уже десятки миллионов пользователей!
Когда одного домена достаточно Опираясь на эти критерии, легко сообразить, когда можно обойтись одним доменом.
12 подход в компании существует некоторая организационная структура:
департаменты, лаборатории и т. д. Нужно ли для каж дого из этих образований создавать отдельный домен? Чтобы ответить на этот вопрос, чем отличаются в своих сотрудники каждого из подразделений? Можете ли вы сказать, что в разных департаментах должны применять разные политики безопас ности и почему? Чем пароли департаменте А отличаются от паролей в департаменте В?
Надо задуматься и над тем, как часто сотрудники переходят из под разделения как часто организационная предприятия. Помните: не переименуешь, не пере несешь в новое место. переместить домен из одного участка леса в другой. А перенос пользователей между доменами ра далеко не элементарная.
Не забудьте о том, как предприятие разбросано географически. Хоро шо, если оно столь богато, что все площадки связаны хотя бы линиями надежными и незагруженными. Если же это ком мутируемые каналы или линии, забитые на 70%, вы рис куете прервать репликацию между контроллерами домена на самом интересном месте. Существуют оценки максимального числа пользо вателей в одном глобальном домене в от пропускной способности самого медленного канала связи между сайтами. Эти оцен ки приведены в таблице и на следующих предположениях:
по крайней мере 10% способности канала доступно для репликации;
все контроллеры являются Х течение добавляется и увольняется пользователей;
Х каждому пользователю предоставлен отдельный компьютер;
+ используются зоны DNS интегрированные с Active Directory.
размера домена от пропускной способности каналов Пропускная способность Максимальное медленного канала (Кб/с) в домене 0,6 20 30 14. 19,2 40 28,8 50 38,4 75 56,0 сколько администраторов и где они находятся? Если у вас жесткая модель управления то наличие одного Проектируем Мелочей бывает домена Ч это идеальное решение. Если же сеть не только распределе на географически, но и администрирование децентрализовано, то сто ит задуматься о потенциальных конфликтах администраторов в доме не. Помните, люди весьма когда пытаются отстоять то, что у них пытаются отобрать.
только один домен создается, если:
размер организации что может управляться одним доменом (рекомендуется менее 1-2 миллионов используется централизованная структура управления сетью с хорошо детализированной политикой;
Х допустимо применение единой политики безопасности блокировка учетных записей, файловая система с шиф рованием, IPSecurity, инфраструктура открытых ключей);
4 географическая распределенность такова, что некаче ственные или каналы между отдельными участками;
Х предприятие стабильно и не планируется его деление на несколь ко новых либо слияние с другим предприятием;
нет нужды в более одного доменного имени.
Если компания соответствует этим критериям, можно говорить об модели. Таким образом, лес предприятия будет состо ять из одного дерева, в котором есть только один домен. Он же явля ется корнем всего леса и носителем имени.
Преимущества однодоменной модели однодоменной модели Active Directory таковы.
Простота управления Все администраторы сосредоточены в одном месге, имеют четкую специализацию. Не нужно делегиро вать (даже временно) избыточные административные полномочия дополнительным администраторам.
Х дешевое решение Для поддержания работоспособности одного домена требуется контроллеров домена. Учитывая требования к контроллерам (см. Active это немалые средства.
Простота Полномочия администра торов распределяются по внутри одного домена, а не между несколькими.
число Для управления несколькими доменами, особенно разбросанными географически, требуется больше а значит, дополнительные расходы на их обучение и удержание.
Предельная же, как у целого леса доменов ГК мо жет хранить не более 4 миллиардов объектов. С другой стороны, Directory: подход он содержит краткие сведения обо всех объектах в лесу независи мо от количества доменов в лесу. Значит, и для одного и для нескольких этот предел неизменен.
... все за одного Выяснив критерии создания одного домена, можно предположить, что прямо противоположные критерии должны определять необходи мость создания нескольких доменов. Однако это не совсем так.
Начнем с размера организации. Конечно, если превышены мак симальные значения, допустимые для одного домена, надо создавать несколько. Но, как я уже говорил, организаций такого размера не так много. Значит ли это, что в остальных случаях нужно использовать один домен?
Отнюдь нет. Вспомните критерии создания домена. Первым была названа безопасность, Если в организации существуют требо вания к безопасности которых существенно отличаются от остальных, то такие подразделения лучше выделить в отдельные домены. К при меру, в банке это может быть отдел пластиковых карточек, на круп ном предприятии Ч отдел безопасности и т. п. Понятно, что у пользо вателей этих подразделений должны быть более стойкие пароли, их регистрация в системе и доступ к ресурсам, должны по смарт-картам или электронным ключам, персональ ные данные должны быть зашифрованы без возможности их прочте ния обычными администраторами сети.
Проблема безопасности тесно связана и с полномочиями админи страторов. Если взять единственного домена (а зна чит, и корневого домена в лесу), то по умолчанию они включены в такие группы, как Domain Schema Admins, Enterprise Admins.
Последние две наделены полномочиями в рамках леса.
Нужны ли такие всем администраторам? Ясно, нет. ад в системе быть не должно. Чтобы не было у администратора даже возможности самостоятельно включить себя в группу с абсолют властью, целесообразно создавать минимум два домена: корне вой, в котором нет но есть учетная запись админист ратора предприятия, и другой Ч где хранятся как учетные записи пользователей, так и все администраторы домена.
Замечание Создание пустого корневого домена для в нем учетных записей администратора предприятия обязательно при на личии более чем одного дочернего домена или нескольких в лесу.
Пустой корневой домен играет и еще одну важную роль. Это своего рода хранитель организации. Так как корневой домен дает или Мелочей не бывает имя всему лесу, то никакие изменения доменной структуре не отражаются в имени леса. Можно добавлять новые до мены в лес при приобретении или слиянии с другими предприятия ми, удалять домены при части бизнеса Ч имя организации останется прежним.
Еще один положительный фактор наличия пустого корневого доме на в том, что по самой природе в нем нет значительных нагрузок на контроллеры, и надежность их возрастает. Поэтому в этом домене можно разместить и мастеров схемы и которые можно будет задействовать для системы в чрезвычай ной ситуации.
К недостаткам такого домена можно отнести необходимость исполь зовать два дополнительных сервера в качестве его контроллеров. Но, по-моему, плюсы перевешивают этот минус, тем более что аппарат ные требования к этим контроллерам не так уж высоки.
Второй критерий создания домена Ч модель администрирования.
Если все администраторы сосредоточены в штаб-квартире или в еди ном центре управления сетью, неразумно добавлять к домену допол нительные домены. Дело в том. что обычно одни и те же люди адми нистрируют все домены. если нет иных стоит оста вить один домен. Если же у вас модель децентрализованного управле ния, то стоит подумать о разбиении на домены Ч по одному на каж дую группу администраторов. Однако здесь надо быть очень осто рожным! Вы должны абсолютно доверять региональным администра торам. Несмотря на то, что они обладают всей полнотой власти толь ко в своем их ошибки или преднамеренные действия могут отрицательно сказаться па работе всего леса.
Очень тесно связана с этим критерием ситуация, когда региональные представительства компании относительно независимы. У них свой отдел который проводит прием персонала, в том числе и в отдел ИТ. О том, кто именно занят управлением пользователями в регионе, в центре зачастую не имеют ни малейшего представления.
Где гарантия того, что регионального ИТ нет внутренних кон фликтов персонала с руководством, что все сотрудники имеют высо кую квалификацию и опыт работы с Active Directory, что среди них нет шпионов, засланных конкурентами? А ведь у региональных адми нистраторов есть физический доступ к контроллерам домена, что в совокупности с высокими административными полномочиями откры вает большой простор для деструктивной деятельности.
рассматривая данный критерий создания домена, стоит ли это делать? Может лучше все учетные записи пользователей и компьютеров в регионе разместить в организационном а локальным делегировать определенные права по 2- Active Directory: подход профессионала управлению подразделением? Этот же подход следует применить и в том когда домен в регионе должен быть создан в соответствии с другими критериями. Все равно не отдавайте ключи от всех дверей в доме, Управляйте таким доменом из центра, а региональным админи страторам позвольте заниматься поддержкой пользователей.
Вы можете что региональные службы ИТ будут сопротив ляться их полномочий. Будут. Еще как будут! Но безопасность организации в целом должна ставиться в основу вашего решения. И тут все средства хороши: от распоряжения генерального директора до просветительской работы с массами. Например, стоит объяснить региональным администраторам, что у них отбирают не так уж много власти. Наглядно демонстрирует следующая таблица.
различных категорий Администраторы ОП (Take Ownership) любого объекта в Active / Создание пользовательских учетных записей / / Удаление пользовательских учетных записей / / / Сброс паролей / / / Создание групп / / групп / / Изменение членства в группах / Создание объектов Типа и управление ими / / общего доступа и управление ими (па контроллерах домена) / / Установка программного обеспечения на контроллеры домена / / Создание учетных компьютеров и ими / / Создание нового домена в лесу / Установка контроллеров домена / копирование и контроллеров / / / Управление Групповыми / / Установка Server / / Настройка доверительных отношений между Управление Сайтами и / Создание политик Admission Service (ACS) Ч см. след. стр.
или не бывает Администраторы домена ОП Авторизация сервера DHCP / Авторизация сервера / printer / Инсталляция Routing Server Конфигурирование / / MSMQ links / предприятия / Установка Удостоверяющего центра Установка Simple Certificate Protocol (SCEP) Add-on для службы Certificate Services / сервиса MSMQ Replication работе MSMQ в смешанном режиме (на некоторых MSMQ 1.0 на / MSMQ Upgrade wizard / Для администраторов предприятия и домена полномочия по умолчанию, для ад министраторов ОП Ч рекомендуемые.
- Область полномочий Ч лес Область полномочий Ч домен.
Область полномочий Ч ОП.
Создание домена может быть делегировано администратору ОП. Однако точно сложная процедура, требующая большого и предварительной В си лу своей сложности она не в данной книге.
Хорошо видно, что те полномочия, которые делегируются на уровень подразделения, охватывают именно те работы, которые ежедневно выполняют сотрудники региональной службы ИТ. А вот слежением за здоровьем Active Directory и управлением ее базовыми функция ми занимается центральная команда администраторов.
Еще один критерий многодоменности Ч разбросанность по обшир ной территории и наличие ненадежных каналов связи. Разбие ние на сайты, конечно, играет важную роль, но в случае одного доме на между сайтами тиражируются доменный контекст имен, контекст имен контекст имен схемы и данные для ПС Реплика ция доменного контекста имен значительно превосходит по объему остальные данные. Разместив в каждом сайте отдельный домен, вы тем самым исключаете доменный контекст имен из процесса репликации.
Существуют оценки максимального числа пользователей одном региональном домене в зависимости от пропускной способности самого медленного канала связи между сайтами в лесу. Эти оценки приведены в таблице и основаны на следующих Active подход минимум 10% способности канала доступно для реп ликации;
все контроллеры доменов являются серверами Х в течение года добавляется 20% и увольняется пользователей;
у каждого отдельный компьютер;
используются зоны интегрированные с Active Directory.
Аналогично тому, как мы это сделали для одного домена, подведем итог. Итак, несколько доменов могут созданы когда:
размер организации таков, что не может управляться одним до меном (более 1-2 миллионов пользователей);
используется децентрализованная управления сетью с несколькими действующими достаточно независи мо друг от друга;
Х необходимо исключить даже случайную региональ ных администраторов вмешиваться в управление всей сетью;
существуют категории пользователей для которых должна быть применена отдельная политика безопасности;
' географическая такова, что имеются некачествен ные или перегруженные каналы между отдельными участками;
само предприятие нестабильно;
возможна продажа отдельных направлений бизнеса либо слияние с другим предприятием.
Зависимость размера глобального домена от пропускной способности каналов Пропускная способность число самого медленного Максимальное число канала в лесу в региональном домене 9,6 25 000 50 14,4 19,2 50 000 25 28,8 75 100 000 45 38, 56,0 100 100 Проектируем AD, или не Медленный Наличие в регионе вы администраторов из ответственности Критерии разбиения па доменов Преимущества модели (дерева) Преимущества многодоменной модели Active таковы.
4 Различные доменные политики Так как политики учетных сей и паролей определяются на уровне домена, можно разделить пользователей по требованиям, диктуемым соображениями безо пасности.
Х Простота включения приобретенных предприятий Если компа ния фирму, имеющую свой обученный технический персонал, свои правила безопасности и пр.. многодоменная струк тура позволяет значительно легче подключать новую структуру в существующую.
Х Пониженный трафик репликации Междоменная репликация за трагивает только тиражирование объектов схемы и Объем этих данных несоизмеримо мал в сравнении с до менной репликацией.
20 Active подход профессионала Посадим и вырастет лес Обсуждая причины создания нескольких доменов, мы полагали, что речь идет о дереве, в котором все дочерние домены наследуют имя корневого. Однако не всегда такое приемлемо. Часто состоит из ряда ассоциированных с ним предприятий. Каждое такое предприятие занимается независимым имеет свое руковод ство и политику. Возможно также, что имя этого предприятия извес тно широкому кругу лиц и безотносительно к связи с головной орга низацией. Так, с крупной телекоммуникационной корпорацией могут быть ассоциированы компании по доставке писем и грузов, обще ственного питания, строительно-монтажная и т. п. Их тесная с телекоммуникационной корпорацией определяется тем, что большую часть своего бизнеса они выполняют по ее заказам. Раз так, то для удобства обработки заказов и организации совместного планирова ния и подготовки отчетности нужно обеспечивать интеграцию ин формационных этих предприятий с Под этим подразумевается и доступ к единой системе пла нирования единая почтовая система и система документо оборота, доступа к определенным ресурсам и т. п. Понятно, что речь не может идти о полном слиянии, так как эти компании довольно много и на сторонние фирмы и сохраняют свою независимость как юридические лица.
А раз так. то эти компании могут не согласиться на применение в своей сети чужого доменного имени. С другой стороны, требование единой адресной книги, на Active Directory, подразумева ет, что это должен быть единый лес. Именно в этом случае резонно создать отдельное дерево для каждой из таких компаний. У этого дерева будет свое уникальное в рамках леса имя, но конфигурация и схема будут общими. Кроме того, они смогут обращаться к единому и осуществ лять доступ ко всем предоставленным им Напомню здесь о пути доверия. Дело в том, что если пользователям из одного дерева в лесу надо обратиться ресурсам, расположенным в домене другого то аутентификация такого доступа будет вы полняться не напрямую, а по цепочке, путем перебора доменов от исходного к корневому, а затем от корневого Ч к домену назначе ния. Если необходимость в таком доступе существует регулярно, то следует организовать сокращения Ч доверительные отношения, свя зывающие эти два домена напрямую.
Проектируем AD, или не бывает Obedy.ru Crm.msk.mycorp.ru Для пути доверия между деревьями сокращения Преимущества модели с несколькими деревьями Преимущества модели Active Directory с несколькими деревьями та ковы.
Х Возможность имен Имя каждого дерева уникально леса.
Х Ассоциированные предприятия ряда компаний обладают независимостью как юридические лица и имеют собственные Х Простота ассоциированных предприятий Ес ли компания приобретает фирму с техническим своими правилами и пр., то структура с несколь кими деревьями создать для нее дерево согласно ее требованиям.
Использование единой и Несмотря на органи зации, входящие в разные единые приложе ния, интегрированные с Active Directory, и единую адресную кни гу (например, в Microsoft Exchange 2000).
22 Active Directory:
модели с одним лесом Рассмотренные выше модели построения доменной структуры отно сятся к так называемой модели Directory с одним лесом доме нов, В 99 % случаев следует именно этой Объяснение данного факта простое;
вы получаете максимум выгоды от Active Directory. Ниже перечислены основные пре имущества этой модели.
Как следует из лес характеризуется наличием едино го глобального каталога. Это означает, что для создания единой ад ресной книги не надо применять никаких дополнительных усилий.
В случае Microsoft 2000/2003 этот каталог будет взят за основу. Для других систем он может быть указан в каче стве Любой почтовый клиент, понимающий прото кол LDAP, использует существующий ГК в качестве адресной книги.
Х Наличие единого глобального каталога также может быть исполь зовано и различными приложений например, как IBM Web Sphere. Они могут обратиться к глобальному катало гу для авторизации Это может стать первым шагом на пути к созданию единой точки входа в гетерогенную систему (single Одним из важнейших достоинств единого леса является простота и отслеживания единой политики безопасности.
Связано это как с организационными, так и с техническими при чинами. Так как управление всем лесом выполняется единой ко мандой ИТ, то не существует причин, по которым одна и та же политика была бы по-разному одними и теми же людь ми. С другой высокий уровень квалификации сотрудни ков обеспечивает ее правильное внедрение и поддержание. Техни чески единство обеспечивается тем. что, невзирая на ные домены, к ним применяется один и тот же объект групповой политики, хранимый в Directory. Кроме того, неизменность данного объекта гарантируется возможностью защиты его от не санкционированного доступа средствами AD.
В рамках единой политики безопасности легко реализуется кон цепция делегирования полномочий. Делегирование позволяет, с одной резко число сотрудников, обладающих административными полномочиями, а с другой Ч централизован но контролировать зону ответственности каждого из сервисных В такой ситуации лица, не обладающие доста точной квалификацией, не смогут доступ к функциям, влияющим на стабильность и безопасность всей системы.
или Мелочей не бывает Х Наличие единого леса позволяет централизованно внедрить сис тему мониторинга, которая будет в реальном масштабе времени следить за контроллерами доменов и иным оборудованием. При чем такая как Microsoft Operations Manager (MOM 2000), позволит не только контролировать состояние обслуживаемых систем и своевременно сообщать оператору обо всех но и автоматически отрабатывать процедуры по устранению неисправ ностей. Одной из особенностей MOM является возможность ния базы знаний о возникавших проблемах. Такая база позволяет легко организовать преемственность административного персона ла, когда увольнение одного не станет узким местом при разре шении проблем. Стоит что MOM имеет специальные наборы настроек, интеллектуально управлять состо янием Active Directory. DNS, Windows 2000/2003 и остальных служб.
При необходимости MOM может быть использован для управле ния и серверами приложений (SQL, Exchange и пр.), причем не только на платформе Microsoft.
Наличие единого леса Active Directory значительно упрощает про цесс внедрения корпоративных стандартов на рабочие места пользователей. Использование политик в рамках леса позволяет управлять приложениями, установленными на настоль ных и мобильных компьютерах, выполнять своевременное их об новление, применять определенные настройки отдельных прило жений, регулирующие доступ к ресурсам, централизованно управ лять сценариями регистрации и пр. Так, по литика может для пользователей определить расположение сервера Software Update Service в корпоративной сети пред приятия, который используется для распространения ных исправлений для операционной системы и связанных с ней приложений.
Х Одной из задач, стоящих перед работа которых не должна прерываться при любых обстоятельствах (катастрофы, дей ствия террористов и т. п.), является организация резервного цент ра управления. Резерв может быть как так и холодным.
В том случае, когда имеется единый лес Active Directory, инфраструк тура каталога может быть таким образом, что даже в случае полного уничтожения центральной части организации вся оставшаяся часть будет продолжать функционирование без переры вов и потери функциональности. Более того, сотрудники централь ной части, переехавшие в любое место в структуре предприятия, смогут незамедлительно приступить к работе, сохранив при этом ко всем необходимым 24 Directory:
Х Постоянно повышающиеся требования к защите информации предполагают использование более эффективных средств обеспе чения зашиты. Одним таких средств является внедрение инф раструктуры открытых ключей на базе сертификатов Х. v.3. Внедрение этой позволит использовать стан дартизованные средства шифрования и защиты информации, сер тифицированные соответствующими органами Российской Феде рации. Так, в частности, и дополнение к встроенным средствам защиты можно будет использовать цифровые смарт-карты для идентификации личности на компьютерах руководителей, а так же для выполнения критичных административных операций. Кро ме того, станет возможно использование электронной цифровой подписи (ЭЦП) системах документооборота и почты. Несмотря на то, что внедрение возможно и для несколь ких лесов, в одном лесу использование системы будет наиболее прозрачным для пользователей.
Х Мобильные пользователи смогут абсолютно безопасно подклю чаться к сети из любой точки для доступа к своей почте или иным Единый лес обеспечивает для них про зрачность а использование смарт-карт Ч безопасность.
Модель с несколькими лесами Напоследок рассмотрим модель с несколькими лесами. Какая ж это модель? Ч спросите вы. Ч Это просто два разных каталога Directory. Так-то оно так. Только ведь никому в голову не приходило в Windows NT говорить о доменах как о несвязанных структу рах. Так и тут. Раз могут отдельные леса, значит, они могут и использоваться для каких-либо целей.
Начнем с того, что модель с разными лесами использовать не реко мендуется. Она практически требует больших затрат и имеет ограниченное при менение. Ну, например, что две крупные компании, каж дая из которых уже имеет свою структуру Active Directory, свое имя на рынке, свои приложения, интегрированные с решили объеди ниться. Слить два леса Даже если б было можно, то как посту пить со схемами? Они же разные! Единственный способ Ч установить прямые нетранзитивные доверительные отношения между теми до менами в каждом из предприятий, для которых нужен доступ к ресур сам друг друга.
Установить доверительные отношения можно только между лесами, в естественном режиме Windows Проектируем или Мелочей не бывает Отсутствие у лесов общего ГК также не им использовать единую адресную книгу в почтовой системе (если, конечно, в этой системе нет собственного каталога почтовых пользователей).
ственный выход Ч задействовать службы синхронизации каталогов, например Microsoft Identity Integration Server 2003.
Кроме того, иногда без нескольких лесов не обойтись. Простейший пример Ч наличие в компании отдела создающего ПО, работающее с Active Directory и модифицирующее схему. Понятно, что тестовая сеть должна иметь свою службу иначе проблемы в основной сети гарантированы. Иногда такую модель Active Directory моделью с лесом подписки forest).
Явное доверие Основной лес Предприятие А Предприятие Б Примеры нескольких лесов:
Тестовый и предприятия (с лесом подписки) Два разных предприятия доступа к ресурсам используется явное нетранзитивное для синхронизации каталогов Ч Поэтому, обозначим причины возможного использования нескольких лесов.
Х Не требуется общая схема Это связано либо с тестовыми раз работками, либо с использованием различного ПО, интегрирован ного с Active Directory.
Не нужен единый ГК Допустимо, когда почтовое или иное при ложение использует свой каталог либо есть приложение синхро низации каталогов.
26 Active Directory: подход профессионала Отношения с или Они не настолько чтобы объединять сети, либо инфраструктуры Active Direc tory для предприятий уже существуют.
Х Центральному отделу удалось договориться с службой При взаимодоверия и невозможности вне дрения единой политики следует пойти на разделение лесов.
Мигрируем с доменной структуры Windows NT Уяснив, как разбивать сеть на домены, обсудим доменную тактику и стратегию при миграции домена Windows NT. Для этого переберем все четыре модели объединения доменов Windows NT.
Прежде всего подчеркну, что совместимости существующих приложений с Windows 2000 мы затрагивать не будем. Дело в том, что даже после миграции домена в нем можно оставить как так и контроллеры, работающие иод Windows NT.
О технических аспектах миграции см. главу Миграция домена Если в организации был лишь один домен 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.
Затем (это может быть сделано много позже) ресурсы из ресурсных доменов переносятся, а сами домены уничтожаются. дан ного способа миграции таковы:
Х прозрачность для домена может не изменяться, все ресурсы остаются постоянно доступными;
Х сокращение количества используемой техники: на каждый ресурсный домен тратится минимум 2 контроллера домена, кото рые в результате миграции высвобождаются;
Х постепенность миграции: перенос можно выполнять длительное время.
способ в случае однозначного соответствия категорий пользователей и к которым они обращаются.
Например, это может быть или административное разделение. Миграция выполняется в три этапа. На первом мастер домен обновляется до корневого домена Windows 2000. Этот этап прозрачен для пользователей, так как с точки зрения аутентификации в домене, на первый взгляд, все остается по-прежнему.
На втором ресурсные домены обновляются до доменов 2000:
они подключаются как домены к ранее мигрировавшему мастер-домену. Если эти домены разнесены территориально, то кон фигурируются соответствующие сайты. Этот этап также для пользователей, так как с точки зрения доступа к ресурсам они не видят никакой разницы.
На третьем этапе пользователи и их компьютеры группами выводят ся из корневого и переносятся в дочерние. Перенос выполня ется с специальных утилит позволяющих сохранить исто рию SID пользователей (SID history) и тем самым обеспечить посто янство доступа к ресурсам. Одновременно в дочерних доменах созда ются группы, куда включаются перенесенные пользова тели. Эти группы включаются в соответствующие локальные группы, предоставляющие различные виды доступа к ресурсам. Это ет более не хранить историю SID и удалить глобальные груп пы из домена. Данный этап непрозрачен для пользовате лей, так как им придется переключить свой компьютер в новый до мен и применять новый пароль.
Миграция когда все пользователи переносятся из корневого домена, в нем удаляются все глобальные группы, оставшиеся от старых времен, и остаются лишь административные группы предприятия (Sche ma Admins, Enterprise Admins) и административные группы домена.
Преимущества данного способа миграции таковы:
постепенность миграции: перенос ресурсов можно выполнять в течение длительного периода времени;
Х сокращение трафика репликации;
разделение на сайты спо собствует этому;
создание границ безопасности между категория ми пользователей: пользователи теперь находятся в разных доменах;
возможность перехода на распределенную модель управ ления: каждым доменом может своя команда админи страторов.
или Мелочей не бывает модели с Третий как это легко Ч комбинация первых двух. Его выбирают, когда нельзя всех пользователей от нести к разным категориям. При этом точно определить количество этапов миграции нельзя, хотя можно выделить следующие.
На первом этапе создается пустой корневой домен. Далее к нему в качестве дочернего присоединяется мигрировавший мастер-домен.
Этот этап прозрачен для пользователей.
На втором могут одновременно выполняться разные действия.
из некоторых доменов переносятся в мигрировавший мастер-домен. Если это целесообразно, ресурсные домены обновляются до Windows 2000. К ним, например, можно применить специальную по литику безопасности. работающих преимущественно с этими можно также в эти Поскольку действия на этом этапе в значительной степени его могут выполнять разные группы специалистов в разные периоды времени.
Миграция считается завершенной, когда не остается ресурсных доме нов Windows NT, а в мигрировавшем мастер-домене не остается не нужных унаследованных глобальных групп.
Active Directory;
подход профессионала доменной структуры с несколькими мастерами Схема с несколькими мастерами характерна для крупных географи чески распределенных Она создание попарных между ресурсными доменами и всеми мастер-доменами. Пути миграции во многом определяются теми которые решить.
Если причиной разбиения на несколько мастер-доменов была пре дельная емкость домена Windows NT, то очевидно, что при миграции эти домены можно слить в один. Ресурсные домены можно уничто жить. Это самый выгодный тип миграции, при котором высвобожда ется большое число серверов. Для пользователей такая миграция не прозрачна. Они вынуждены переместить свои рабочие станции в новый домен и применять новые пароли. Если миграцию совместить с обновлением ОС на клиентских то эту смену домена выполнят технические Если задачей является сокращение числа поддерживаемых доверительных отношений и тем самым упрощения администриро вания, то, выполнив миграцию ресурсных доменов и переместив в них учетные записи пользователей и клиентских компьютеров, можно подключить их в качестве дочерних к объединенному мастер-домену.
варианты миграции модели с мастер-доменами или Мелочей не бывает Если мастер-домены были разнесены то это разделе ние можно оставить, сделав мигрировавшие домены дочерними к пустому домену. Это позволяет единое имя предприятия, снизить трафик репликации и применить различные политики в разных географических Как при этом вы посту пите с ресурсными доменами, зависит от ваших потребностей.
Миграция нескольких доменов с доверием Перечислить все возможные модели миграции схемы с полным дове рием (или. более точно, с попарным доверием) просто невозможно:
чем больше доменов, тем больше вариантов доверительных отноше ний между ними. Одно можно сказать вполне определенно: управля емость новой системы возрастет многократно.
Несмотря на такое многообразие, попробуем выделить правила рационального создания новой структуры.
1. Если все домены связаны попарно двусторонними отношениями и были созданы исключительно из-за политических соображений, важность которых сейчас не имеет то все домены мож но объединить в один домен Windows 2000. Выполнить это мож но, либо создав новый домен и перенеся в него учетные записи пользователей, компьютеров и ресурсы, либо самый крупный домен, а потом перенеся в него объекты из остальных.
Замечание В это может вмешаться фактор географической разоб щенности. Тогда домены при миграции можно сгруппировать и пре образовать каждую группу в отдельный домен, расположенный на одной территории. Эти домены можно объединить под крышей пустого корневого домена либо в виде отдельных деревьев.
2. Если же политические соображения сохранили актуальность, иде альным станет решение создать пустой корневой домен и подклю чить к нему в качестве дочерних мигрировавшие. С точки зрения положения в дереве Active Directory, они равны, с точки зрения безопасности и политики Ч различны.
Если ключевым фактором разбиения на домены было имя, то при миграции можно сохранить этот фактор уникальнос ти, преобразовав каждый из доменов в корень нового дерева в лесу.
4. Если доверительные отношения не двусторонние, надо проанали зировать пути доверия и выделить учетные домены и ресурсные домены, а потом выбрать один из описанных выше путей мигра ции. Если при этом учесть географическое расположение доменов, наличие локального технического а также устойчивые долговременные связи, можно разработать весьма и управляемую что позволит сократить количество спе циалистов ИТ.
32 Active Группы и стратегия их использования Прежде чем говорить о планировании групп, кратко напомню о ви дах групп в Windows 2000.
Универсальные группы объединяют пользователей в рамках леса и могут включать как отдельных пользователей, так и другие универсаль ные или глобальные группы из любого домена в лесу. Сведения о член стве в универсальных группах тиражируются на все серверы ГК.
Глобальные группы объединяют пользователей в рамках домена и могут включать как отдельных пользователей, так и другие глобаль ные этого же домена. Сведения о членстве в глобальных группах не тиражируются на серверы ГК. Тиражируется только имя глобальной группы.
Локальные группы домена служат для предоставления доступа к ре и могут включать как отдельных так и другие универсальные или глобальные группы из любого домена в лесу. Они применяются только в списках контроля доступа локального домена.
Информация о членстве в универсальных группах не тиражируется на серверы ГК.
Внимание группы существуют только в доменах, работающих в режиме. Только при этом условии воз можно вложение универсальных и глобальных групп друг в друга.
Рекомендации по использованию универсальных групп Членство в универсальных группах публикуется в ГК. Это значит, что если внести в группу или исключить пользователя, то вся информа ция о группе начнет по серверам ГК. В распределен ных сетях, состоящих из большого числа подключенных по медленным это вызовет нежелательную канала.
Поэтому первая рекомендация: содержимое универсальных групп должно постоянным длительное время и меняться только в случае крайней нужды.
Возможно вы что в не может быть более 5 000 членов.
С одной стороны, это достаточно много для. скажем, типичного до мена. Однако пользователей в рамках леса может быть и гораздо боль ше. Тиражирование большого количества группы может соста вить значительный трафик Отсюда не включайте в универсальные груп пы много членов.
А что же, спросите вы, надо включить почти всех пользо вателей в универсальную Мало что их много, так ведь они постоянно меняются: приходят, или Мелочей не бывает В таком случае в сальную группу несколько дополнительных универсальных. В них в свою очередь включите глобальные группы разных доменов. А уже в глобальные группы включите пользователей этих доменов.
Рассмотрим пример. Пусть в лесу Active Directory пять доменов и в каждом 800-1 500 пользователей. Вы планируете все учетные записи рассортировать по их статусу на предприятии: постоянные работни ки, контракторы или временные сотрудники, сотрудники предприя тий-партнеров. Чтобы выполнить сортировку, поступим так.
В каждом домене создаем по три глобальные группы: FTDomainName для постоянных сотрудников, для контракторов, для партнеров. создаем три универсальные груп пы: Ч и в них соот глобальные группы. можно создать универсаль ную группу и включить в нее три ранее созданных универ сальных группы.
Несмотря на то, что в итоге в группу AllUsers попадет более 5 пользователей, она в себе содержит только 3 членов. другие уни версальные группы содержат по 5 членов. А максимальное число чле нов описанных глобальных групп не превышает 1 500 человек, и то при условии, что в каком-то домене все сотрудники принадлежат только к одной категории. Очевидно, что с точки групп, членство в них неизменно, поэтому репликация выполняется только при их создании и первичном наполнении другими группами.
Пример групп Для чего понадобиться эти универсальные группы? Ну, напри мер, для фильтрации групповой политики или разграничения досту па к корпоративным файловым ресурсам в масштабах всего предпри ятия. Правда, в последнем случае не обойтись без локальных групп домена. Но об этом чуть Рекомендации по использованию глобальных групп Теперь поговорим о глобальных группах. Выше мы создали довольно крупные глобальные группы. Поддерживать членство в крупных груп пах достаточно сложно. создать несколько глобальных групп меньшего размера, а их включить в глобальную группу в своем же домене.
создавая глобальные группы, делайте их По какому принципу глобальные группы? Наверное, здесь уместно что группы будут использовать ся для включения в группы домена для последующего пре доставления доступа к ресурсам. Все ресурсы обычно можно разде лить по функциональности. Это могут быть, например, принтеры и подразделений, каталоги рабочих и проектных групп, фай лы руководства и т. п.
Отсюда вторая глобальные группы нужно создавать по признаку.
Рассмотрим в которой есть секретариат, отдел продаж, отдел маркетинга, склад продукции, и бух галтерия. Часть из отдела продаж, склада продукции и заняты в проекте, направленном на улучшение работы склада. Исходя из этих условий, целесообразно создать 9 гло бальных групп:
для руководства;
Х SECRETARY для секретариата;
Х SALES для отдела продаж;
Х MKTG для отдела маркетинга;
Х STORE для склада;
Х IT для службы ИТ;
Х для бухгалтерии;
PROJECT для тех, кто включен в проект;
и ALL Ч группу, включающую в себя все перечисленные группы, кроме PROJECT.
или Мелочей не бывает Кстати, это необходимый минимум групп. Если при этом на каждом этаже есть свой можно создать и поэтажные группы. Если также обнаружится, что сотрудники даже одного отдела должны иметь доступ к разным ресурсам, то это тоже повод для раз биения их на глобальные группы. Об этом ниже.
Рекомендации по использованию локальных групп домена Локальные группы служат для предоставления досту па к ресурсам домена. Назначение прав доступа к принтерам, файлам, каталогам и сетевым предоставленным в общее пользова ние, должно выполняться только применительно к группам. Причина этого тривиальна. Если вы предоставили доступ отдельному пользо вателю, а потом он то в списке контроля доступа останется запись о несуществующем же ему был пре доставлен через членство в то при удалении из Active Directory пользователь будет удален из всех групп автоматически.
Рассматривая всевозможные виды доступа к файловым ресурсам, мож но выделить три наиболее распространенных: полный доступ чтение+исполнение (R). В соответ ствии с этой классификацией можно рекомендовать создание трех локальных групп для каждого файлового ресурса. Название группы может состоять из имени ресурса и обозначения вида доступа. Напри мер, для каталога Public можно создать локальные группы:
Х Public_F;
Х Х Pubiic_R.
Теперь для доступа к такому ресурсу вклю чить соответствующие глобальные группы в локальные с необходи мым типом доступа. Допустим, в рассматриваемом выше примере все работники предприятия должны иметь доступ только на чтение, а со трудники отделов продаж и маркетинга Ч еще и на запись. Полный доступ должен иметь Тогда в группу включаем группу ALL, в Ч группы MKTG и SALES, а в Ч груп пу IT. Это но с одним отличием Ч бухгалтерия выне сена в отдельный в котором и существует группа АССТ, Ч показано на рисунке ниже.
Рассмотренный пример довольно прост, и в реальной жизни встре чаются куда более запутанные ситуации, когда нельзя всех сотрудни ков одного отдела однозначно включить в группу до ступа. Для них надо создавать специальные глобальные группы и вклю чать их в группы доступа к ресурсам.
36 Directory: профессионала Список контроля доступа:
Modify Public Control Локальная группа Public R, Локальная группа члены:
члены:
Домен IT, SALES, STORE, PROJECT ALL Домен account.mycorp.ru Глобальная предоставления доступа к через членство в группах Внимание Всякий раз, предоставляя локальной группе доступ к какому-либо ресурсу, документируйте это событие и фиксируйте имя название ресурса и доступа. Это облегчит вам Кто должен заниматься включением пользователей в группы досту па? Ответ неоднозначен. Если это маленькая организация, то с такой работой могут справиться сотрудники службы Если же это ком пания, в которой много отделов, обладающих своими ресурсами, то лучше назначить ресурсов. У каждого ресурса, доставленного в совместное пользование, должно быть не менее двух основной и запасной. Им должно быть делегировано право включать пользователей в свои группы. Причем это можно сделать через Web-интерфейс и сценарии ADSI. Если какому-то пользовате лю требуется доступ к ресурсу, он открывает страницу Web и запра шивает нужный доступ. Сценарий ADSI определяет и посылает ему например по почте. Ответственный, по лучив письмо, заходит на по такому случаю страницу Web и предоставляет/запрещает доступ.
Проектируем или Использование особых Говоря о предоставлении доступа к ресурсам через членство в груп пах, нельзя не упомянуть особые объединения (special identities). Их можно для удобства считать группами, хотя это и не так: в них нельзя включить учетные записи пользователей, однако они включаются туда автоматически в зависимости от обстоятельств. Эти объединения не представлены в списке групп в Active но служат для разгра ничения доступа к ресурсам.
Х В категорию Everyone попадают все зарегистриро вавшиеся в сети. Это могут быть даже пользователи и гости из других доменов. Главное условие включения в эту категорию быть зарегистрированным в сети.
Users Ч почти то же, что и Everyone, но не содер жит анонимных пользователей (гостей), Х В категорию Network Users входят осуществляю щие в данный момент доступ к определенному ресурсу по сети.
Х В категорию Interactive Users входят осуществля ющие в данный момент доступ к ресурсу на том компьютере, за которым они непосредственно работают;
Для нас представляют интерес Everyone и Authenticated Users.
категорию надо по возможности исключать из контро ля доступа. А вот весьма полезна, так как избавиться от глобальной или универсальной группы, в которую вклю чены все пользователи. при репликации тра фик будет меньше.
Административные группы Теперь о том, как лучше административные группы.
Начнем со встроенной локальной группы Administrators. По умолча нию нее включены глобальные группы Domain (в естественном режиме работы домена это универсальная группа) и учетная запись Administrator. Так как это локальная группа, она служит для предоставления прав доступа к ресурсам домена. Если рассматриваемый домен не является корневым и вы не хотите, чтобы администраторы предприятия имели к вам отношение, исключите группу Enterprise Admins из локальной группы Внимание Не стройте иллюзий относительно своей независимос ти после исключения группы Enterprise Admins из группы Adminis trators. Если администраторам предприятия понадобится какие-то действия в вашем домене, они всегда это смогут сделать. Для этого им достаточно стать владельцами "ваших При пра вильно настроенном аудите эта операция будет отслежена в журнале.
38 Active Directory:
Группа Enterprise практически власть.
Поэтому администраторов в ней должно быть минимум. Это же тре относится и к группе Schema Admins. Пусть ее члены и не все властны, но последствия их действий стать ката строфы в Active Directory. Я говорил, что эти две группы существу ют только в корневом домене. Если нем есть и другие учетные запи си с административными полномочиями, то они могут включить себя в эти группы для выполнения несанкционированных действий в лю бой момент. Вот почему рекомендуется создавать пустой корневой домен, в котором нет учетных записей, кроме администратора Ч толь ко он вправе включать в группы Enterprise Admins и Schema Admins пользователей из других доменов.
Замечание Пустой корневой должен работать в естествен ном режиме чтобы группы предприятия были универсальными.
Членство в группах должно жестко регламенти роваться. Одним из средств регламентирования является групповое правило Restricted Groups, ограничивающее членство в указываемых группах. В политике жестко кто может быть членом груп пы. Если кто-то добавит себя в одну из групп с ограниченным член ством, то по истечении срока обновления правил (5 минут для кон троллеров домена) он будет исключен из этой группы.
Включать ли всех в группу администраторов, пусть даже не всего предприятия, а одного домена? Ни в коем случае. В ад министративных группах должно быть минимум пользовате лей. Отдельные административные полномочия должны быть делеги рованы так, чтобы:
Х обеспечивалась непрерывность администрирования;
Х отсутствовали полномочия.
Таким от групп мы переходим к рассмотрению организаци онных подразделений (ОП).
Если ОП значит, это кому-нибудь нужно Организационные подразделения Ч это контейнеры в Active Directory, в которых находиться такие объекты, как пользователи, компь ютеры, группы, принтеры, совместно используемые ресурсы, прило жения и другие ОП. Отличительной особенностью ОП является воз можность к ним политики политики безопасности, применяемой ко всему домену). С другой стороны, ОП Ч это объект Active Directory, и, как к любому объекту, к нему и ко все или Мелочей не бывает что в нем лежит, можно задать права доступа. Так что ОП Ч вещь довольно ценная.
Когда же использовать ОП? Ответов множество. Вот главные.
Х Для делегирования административных полномочий Раз можно регламентировать права доступа к контейнеру, значит, можно назначать тех, кто имеет полный доступ, т. е. является ад министратором по отношению к объектам внутри контейнера.
Для разграничения групповой политики Разделив пользо вателей и компьютеры по разным контейнерам, вы можете при менять различную групповую политику.
Для рассортировки объектов Можно отдельно разместить принтеры, компьютеры и т. д.
Для ограничения числа объектов в контейнерах Хотя объ ем контейнера не ограничен, просматривать содержимое больших ОП неудобно Ч проще в один ОП поместить несколько меньших по объему.
Х Для помощи в миграции При переносе ресурсов из доменов Windows NT желательно сохранить управляемость этими ресурса ми. Поэтому удобно их перемещать в отдельные ОП, для управле ния которыми делегирование.
Вы. конечно, что структура ОП планируется по определенным правилам. Вот они.
Первый уровень ОП внутри предприятия должен следовать неко торому т. е. в каждом домене применяется общий прин цип построения ОП. Это значительно облегчит использование ОП.
Не увлекайтесь глубиной вложения ОП. Дело тут не только в том, что навигация по глубоко вложенным подразделениям Ч дело достаточно занудное, а в том, что выполнение по иска по структурам с глубокой вложенностью заметно замедляет ся. С другой стороны, вложенность не сказывается на репликации.
Иерархия ОП должна иметь смысл и быть понятной. Создавать ОП только ради него самого бессмысленно. Смысл же определяется ответом на вопросы: кто будет управлять кто будет видеть ОП?
Любой объект может находиться одновременно только в одном ОП (в отличие от групп). если вы хотите применять разные групповые политики к нескольким пересекающимся рам объектов, нужно продумать иерархию ОП. При этом полити ки с верхних уровней будут наследоваться на нижних.
40 Active подход профессионала Модели организационных подразделений Эти правила привели к разработке нескольких моделей ОП.
Географическая иерархия Подразумевает строительство дерева ОП в соответствии с географи ческим положением. мы рассматривали удаленность как один из критериев разделения на домены. В чем же Пусть в крупной организации имеется три домена: производства, маркетинга и продаж. Это с тем, что к сотрудникам этих под разделений предъявляются разные безопасности. Вместе с тем предприятие разбросано по нескольким регионам: Москва.
Нижний Новгород и В каждом из го родов должна своя групповая политика установки при ложений. Поэтому в каждом из трех доменов создаются ОП для каж дой территории.
Преимущества такой модели:
Х ОП первого уровня стабильны, так как существуют все время, пока предприятие ведет на указанной территории;
Х администраторам легко где именно находятся ресурсы.
Недосгаток модели в том. что она не отражает бизнес-потребностей предприятия.
Организационная иерархия Пользуется симпатией начальства, потому что отражает организаци онную структуру компании. На вершине иерархии Ч руководство, па втором уровне Ч на третьем Ч отделы внутри дирек ций и т. д. Всякий раз, когда руководителю требуется указать сотруд на его он может открыть, скажем, Microsoft кото рый автоматически выведет на экран графическое представление структуры Active а значит, и фактическую оргструктуру.
Опять когда возникает ситуация из разряда А подать сюда Ляп задается поиск этого субъекта в каталоге, А из имени субъекта следует, в каком отделе он работает. Вот и причина любви!
И невдомек начальству, что всякий раз, когда переименовываются отделы, создаются или подразделения, администратор вы нужден эти изменения отражать и в структуре ОП. Но и это не самое плохое. Хуже, когда требуется какие-то отделы или дирек ции выносить в отдельный домен по соображением безопасности, например. И все, рушится стройная Объектная иерархия Эту модель я бы назвал по-военному прямолинейной. Есть классы объектов, вот их и дифференцируем. Компьютеры в одну кучу, или Мелочей не бывает пользователей Ч в другую, принтеры Ч в третью и т. д. Резон для такого деления есть, и не один:
Х ресурсами легче поскольку они все легче создавать общие списки контроля доступа к различным клас сам объектов;
легче делегировать полномочия для различных классов объектов.
Представим структуру ОП, на объектной модели: на первом уровне ОП Принтеры, Пользователи, Рабочие станции и Сер веры, на втором идет по какому-либо признаку, напри мер, Принтеры 1 этажа, Принтеры 2 этажа, Пользователи 1 этажа, Пользователи 2 этажа и т. д.
Но логичнее использовать эту модель в совокупности с другими. На пример, если верхние уровни определены по организационной мо дели, то, дойдя до нижнего уровня (например, до отделов), можно переключиться на объектную модель и для каждого отдела пользователей, компьютеры и пр.
Вы можете усомниться в простоте использования такой модели и будете правы. Но только до тех пор, пока не выяснится, что учет сотрудников и техники ведется с помощью специального при ложения, интегрированного с Active Directory. Если оно позволяет в графическом виде просматривать планы этажей, с легкостью переме щать сотрудников и технику между подразделениями и отслеживать инвентаризацию этой то вам уже не придется вручную ша рить по каталогу в поисках нужного объекта.
Проектная иерархия Подразумевает, что ОП строятся с учетом проектов, исполняемых в организации. При этом легко отслеживать ресурсы и затраты для каж дого из проектов. Однако проект длится определенное А зна чит. по его завершении структуру ОП переработать.
А если кто-то из сотрудников вовлечен сразу проекта? Поделить его пополам и назначить две разные учетные записи? Представляете, как сложно будет следовать модели!
Поэтому она может иметь очень ограниченное применение.
Административная иерархия Предмет любви так как именно им она обеспечива ет максимум комфорта;
ОП создаются на основании того, как легче управлять компьютерами и пр. Например, если из вестно. что все различия пользователей в домене в том. с какими приложениями они работают, то списки пользователей каждого приложения. Из общего списка выбирается подмножество Active Directory: подход профессионала приложений, нужных числу пользователей. Для это го приложения создается групповая политика, назначаемая корнево му ОП. Затем выбираются приложения, нужные меньшему числу поль зователей, и соответствующие групповые правила применяются к ОП второго Наконец, создается ОП нижнего уровня и заполняет ся которым нужны специфические Рас смотрим пример.
Согласно корпоративному стандарту организации используется почто вый клиент Microsoft Outlook, а в офисных приложений Word и Excel. Кроме того, сотрудники бухгалтерии должны работать с и клиентской частью SAP. Последняя так же требуется сотрудникам отдела кадров и аналитического отдела.
Дополнительно к этому аналитического отдела нужны Microsoft Visio и Microsoft Project.
Вот как такую ОП по административной модели:
верхний ОП, названное SAP, в которое включены ники отдела кадров;
второй уровень: ОП 1C (сотрудники бухгалтерии) и Анализ (со трудники аналитического отдела);
+ остальные пользователи не входят ни в какие ОП.
К домену в целом применяется офисная политика. Ко всем ОП при менены соответствующие групповые по установке прило жений. Сколь дикой ни казалась бы такая структура на первый взгляд, она обеспечивает нужную функциональность с минимумом затрачи ваемых усилий.
ОГП1 - офисных приложений - установка клиента SAP - установка Visio и Project 1 (Ж Сотрудники 1C Сотрудники бухгалтерии аналитического отдела Все остальные Иллюстрация модели ОП Проектируем AD, или Мелочей не бывает Тот же но модель ее с другими моделями. Если следовать географической то в данном случае все пользователи располагаются в одном Это что для применения различных групповых правил понадобится фильтрация. Для этого будет нужно предварительно со здать группы, включить в них пользователей из каждого подразделе ния, а затем для каждой из групповой политик (разве кроме офисной) определить фильтры.
Согласно административной модели последовательность действий такова. Вы распределяете всех пользователей по ОП. Далее создаете объекты групповой политики для установки каждого из приложений и применяете их к нужным ОП. Пока мало, сложность реализа ции групповых правил близка к сложности административной моде ли. С ростом числа ОП распределять объекты групповой политики по все большему числу что затруднит их учет и анализ взаимовлияния.
Так кому нужны организационные подразделения?
У каждой из пяти моделей построения ОП свои плюсы и минусы. Так что ни одна не является догмой. Можете смело их и создавать гибрид, который вас устроит. Но в любом случае что-то одно надо выбрать за основу. Что?
Все зависит от вашего ответа для кого создается структура ОП? Если отбросить ответ для остаются такие варианты:
для себя (т. е. для администратора);
Х для начальства;
Х для пользователей.
Active подход профессионала начальству структура ОП ни к чему. Увы, убедить его в этом долж ны вы. Сделать это но надо.
Предупреждение Выбивая деньги на развертывание Active Direc tory, ни коем случае не ссылайтесь на возможность для руководства кто и где находится. Иначе вам придется следовать организа ционной модели, даже если вы поймете, что она вам не нужна.
Нужны ли подразделения пользователям?
Пользователь повседневно работает:
с (поиск, сохранение, печать);
с почтой в адресной редактирование/чтение писем);
Х со специализированными приложениями;
с и предоставляет локальные ресурсы в совместное использование (если разрешено).
Начнем по порядку. Прежде чем документ открыть, его надо найти.
Он может храниться как на компьютере, так и в сети. Что бы его найти, пользователь команду Search в меню Start Ч она выводит диалоговое которое по умолчанию предлагает файлы па локальном компьютере. Поверьте мне, для большин это возможностей.
Замечание Даже этот для многих пользователей Ч непре одолимое препятствие. Обычно документы хранятся в папке My Docu ments или в некотором подключаемом при регистрации пользователя в сети.
И все же допустим, что познания нашего столь глубоки, что в списке Look in он выбирает команду Browse. Но даже тогда, чтобы добраться до ему надо раскрыть My Places, Entire Network, Directory и найти имя своего домена! Вот только тут он впервые увидит ОП. Я уж не говорю о том, что далее ему придется отыскать в каталоге ресурс и только после этого начать поиск. Итак, считаем данное событие маловероятным.
Процесс редактирования документов не связан с доступом к каталогу и ОП в нем.
Операция сохранения документа практически идентична его откры Но если в первом поиск в каталоге еще имеет какой-то то теперь смысла нет, так как найти нужный ресурс просто невозможно! Таким образом, вероятность события равна 0.
Проектируем или Мелочей не бывает Вывод документа на печать доступа к каталогу. Но это знаете вы, технические специалисты, А пользователь об этом не ет, поэтому всегда печатает на том принтере, который к нему подклю чен. Если б он знал, что можно найти и другой принтер в каталоге и без проблем к нему то он бы выбрал в меню ко манду Search и далее Search for printers. Но даже здесь знание структу ры ОП ему ни к чему. Пользователь знает такие атрибуты принтера, как его месторасположение, цветной он или нет, может быть, даже имя модели. А вот в каком ОП он находится, ему безразлично.
Работа с почтой интересует нас потому, что здесь пользователь актив но занимается поиском адресатов. Какое отношение имеет почтовая адресная книга к Active Directory? Если ваша система построена не на Microsoft Exchange 2000, то никакого. Но даже если у вас Exchange 2000. то и в этом случае структура ОП мало кого интересует. Глав ное Ч это почтовый адрес и другие атрибуты Все тальные операции с почтовой программой не требуют доступа к ка талогу (с точки зрения пользователя, конечно).
to s * Document:
My Entire...-..) it!
окно поиска ресурсов в Работу со специализированными приложениями мы даже рассматри вать не будем: ведь они, как правило, не требуют обращения пользо вателя к каталогу.
Поиск сетевых ресурсов мы уже рассмотрели выше, поэтому остается последнее: предоставление своих ресурсов в совместное ние. Эта операция относится к разряду тех, что обычно запрещены 46 Active Directory: подход групповой политикой. Но так как в ряде организаций она разрешена, обсудим ее подробнее.
Предоставляя свой ресурс в совместный доступ, обыч но не ограничивает права доступа к нему. Если же он попытается это то при определении списка контроля доступа он не увидит структуры Ч только структуру доменов, Вывод: рядовым пользователям структура ОП не нужна, а значит, вы черкнем их из списка тех, чьи интересы нужно учесть, планируя ОП.
Подразделения нужны администраторам!
Остались администраторы... А нужны ли им ОП? Еще как! Вы же заме тили, что мы постоянно упоминали те операции администрирования, что без ОП невыполнимы.
Во-первых, это делегирование административных полномочий. Про ще делегировать полномочия по управлению одним контейнером, чем списком различных объектов.
Во-вторых, это групповые правила, благодаря наследованию которых, в иерархии ОП можно строить гибкие управляемые системы.
В-третьих, это средство группирования ресурсов. Администраторам удобнее видеть рабочие отдельно от принтеров и пользовате лей. Это эффективнее применять к ним групповые правила.
Так что, проектируя иерархию ОП, думайте только об администриро вании системы. Старайтесь сделать ее такой, чтобы управление не требовало привлечения дополнительного для ния рутинных работ.
Делегирование административных полномочий Стратегия делегирования полномочий может быть произвольной.
И все же существует набор правил, позволяющих реализовать ную стратегию делегирования. Они основаны на предположении, что ОП делятся на две категории: учетные и ресурсные. Это предположе ние не с рассмотренными моделями ОП, так в лю бой из них могут иметься и те и другие.
В учетных ОП хранятся учетные записи пользователей, служб, ком пьютеров и групп, в ресурсных Ч принтеры, совместно используемые ресурсы и приложения. В этом плане они чем-то напоминают учет ные и ресурсные домены Windows NT. Но только в отличие от доме нов вы можете жестко разграничить полномочия администраторов.
С целью делегирования полномочий записи в учетных ОП размеща ются по разным вложенным ОП: Пользователи, Учетные записи Компьютеры, Группы. Можно добавить и ОП и поместить в них.
пользователей, имеющих отличные от остальных права. Для каждого вложенного, а также для самого учетного ОП создается ло Проектируем AD, или Мелочей не бывает кальная группа домена. Эти содержат которым делегируется право управления соответствующими Имена этих групп удобно составлять из Тогда делегирование в учетном сведется к назначению таких полномочий:
ОП группы Тип доступа Тип объекта Родительское Control Все объекты ОП Дочерние ОП:
Users <имя ОП> user admins Control User Service Accounts ОП> ou user admins Full Control User Computers <имя Full Control Computer admins Groups Full Control Group Limited Full Для ресурсных ОП в общем случае достаточно одной группы, кото рая владеет ОП и имеет полный доступ к объектам, Разбиваем на сайты Сайты Active Directory Ч это сегменты сети с высокой пропускной способностью. По крайней мере так гласят все определения сайтов.
А для чего они? Вот основные причины, по которым Active Directory нужно разбивать на сайты.
Х Управление трафиком репликации При тиражировании измене ний в Active Directory сайты позволяют указывать, как и когда пой дет поток репликации.
+ Минимизация трафика регистрации клиентских станций При регистрации клиентский компьютер обращается к контроллеру домена, расположенному в том же сайте (или если локального контроллера домена нет).
Управление трафиком репликации Так как FRS использует для репликации ту же топологию, что и репликация Active Directory, то сайты положительно на Управление DFS Если ресурс DFS имеет несколько то обращающийся к нему клиент будет направлен к жайшей к нему реплике.
Поддержка специализированных приложений Эти приложения, связанные с Active Directory, адресуют клиентов к ресурсам, расположенным в ближайшем сайте.
Главное значение разбиение на сайты имеет для репликации, поэто му в основном об этом мы и будем думать, рассуждая о топологии сайтов. О репликации Active Directory см. одноименную главу.
3- Active подход профессионала На репликацию огромное влияние оказывают:
Х пропускная способность каналов;
трафик репликации;
Х расположение контроллеров доменов.
Поэтому дизайн сайтов надо начинать с тщательного документиро вания и анализа топологии сети. Помимо фиксирования пропускной способности каналов и их надо записать количество пользо вателей на каждой площадке и бизнес-проблемы, решаемые ими. При этом следует помнить о плюсах и минусах разбиения на сайты:
Преимущества и недостатки на сайты Преимущества Недостатки Управление Синхронизация изменений объем и расписание контроллерами в сайтах выполняется спустя длительное время.
Возможность дополни каналы тельное что удорожает решение трафика регистрации приложений Так какой же все-таки критерий?
Итак, первый критерий на сайты Ч пропускная способ ность каналов связи. А что считать высокой пропускной способнос тью и что низкой? Часто как используют значение 10 Мб/с.
Всегда ли это так?
сегмент с основной ее частью каналом с пропускной способностью 128 Кб/с. В сегменте 10 пользователей, частью работающих с локальными ресурсами. Канал прак тически свободен. Добавим к этому стабильность коллектива, т. е. ско рость изменений в Active Directory низка. Понятно, что пропускная способность канала более чем достаточна, чтобы не выделять этот сегмент в отдельный сайт.
Теперь возьмем сегмент сети в соседней организации, Он подключен к основной территории каналом 1,5 Мб/с. На этой территории работников активно используют телефон, весь трафик которого на правляется по единственному каналу и занимает 50% от его пропуск ной способности. Кроме пользователи работают с электронной почтой, построенной на Microsoft Exchange Этот трафик съедает еще 25% пропускной способности канала. Планируется и миграция на Exchange 2000. Общий размер организации невелик: 800 пользовате Проектируем или не бывает лей. но в компании текучка кадров. В такой ситуации однозначно надо говорить о создании отдельного сайта, так как трафик репликации в домене будет большим.
Итак, анализируя пропускную способность каналов, в первую очередь выделяют каналы с пропускной способностью менее 10 Мб/с. Далее рассматривают площадки, подключенные по этим каналам и анали зируют потенциальный рост трафика в канале после Active Directory. Следующий шаг Ч анализ текущей загрузки канала и вычис ление его эффективной пропускной способности. Если прогнозиру емый трафик в пиковые моменты существенно ниже пропускной способности, то нет нужды создавать отдельный сайт.
Если же он сравним или то сайт необходим.
Замечание Анализируя эффективную пропускную способность канала, нельзя полностью полагаться на цифры, содержащиеся в до говоре с провайдером линии. Провайдеры обычно делят один канал между несколькими клиентами, что может приводить к снижению эффективной пропускной способности. Поэтому лучше измерить реальную пропускную в разное время суток.
Второй критерий разбиения на сайты Ч надежность канала, под ко торой в первую очередь понимают его постоянную доступность. Если есть вероятность разрыва канала (даже следу ет говорить об отдельном сайте.
Еще один критерий Ч управления трафи ком. Во-первых, можно составить расписание репликации. Если с 9. до 18.00 канал загружен на 90%, а в остальное время он практически свободен, можно сконфигурировать расписание так, что информация будет тиражироваться только в нерабочие часы. Во-вторых, можно задействовать компрессию трафика, которая включается автоматичес ки при превышении объема тиражирования равного 50 кб. В-треть их, для ненадежных каналов можно организовывать асинхронную репликацию по протоколу SMTP.
Алгоритм разбиения на сайты выглядит так (см. след. стр.).
Сколько может быть сайтов?
Сколько может быть сайтов? Чтобы на этот вопрос, подума ем, на что влияет их число. Начнем с репликации. Да, само по себе наличие сайтов влияет на трафик репликации, которая выполняется в соответствии с топологией. Топология базируется на соединениях. А соединения... создаются автоматически службой КСС (Knowledge Consistency Checker), точнее, той ее что называется Генератором межсайтовой топологии (ISTG). Для меж 50 подход профессионала сайтовой репликации служба КСС периодически ность контроллеров домена, выполняющих роль и. если они недоступны, назначает новые серверы, т. е. перестраивает топологию репликации. Эта работа в совокупности с аналогичной деятельностью внутри сайта весьма ресурсоемка и при большом чис ле сайтов и доменов полностью поглощает все процессорное время компьютера, выполняющего роль КСС и ISTG.
Совет Чтобы понять, насколько КСС можно изменить в ре естре значение параметра ветви Если установить его большим или равным 3, в журнал регистрации попадут события и 1013, сигнализирующие о начале и конце проверки топологии.
Есть описывающая максимальное число сайтов и доменов при использовании автоматической генерации топологии:
<= где D Ч число доменов, a S Ч число сайтов.
Так, если у вас всего один домен, максимальное число сайтов 223, если же два домена, число сайтов не может быть больше 182. И это все? А как быть с организацией, в которой 50 доменов в 50 сайтах? Это ведь далеко не запредельные значения!
Замечание В Windows 2003 алгоритм работы КСС изменен таким образом, что удалось существенно улучшить способность этого элемента. В приведенной выше формуле зависимость от числа сайтов стала линейной. На момент подготовки этого издания автору было известно о нормальном функционировании с 1700 сайтами.
Вот результаты измерения времени работы КСС в разных системах с одним центральным сайтом и несколькими периферийными, выпол ненные на компьютере с Intel Pentium III и 1 Гб ОЗУ.
Используемая Расположение Число сайтов Число доменов Время память Филиал 125 1 Центр 125 1 12 Филиал 250 1 45 0:00: Центр 250 1 0:01:05 500 1 0:02:56 173 Центр 0:04:34 174 Филиал 1 685 см, стр.
или Мелочей не бывает Используемая Расположение Число сайтов Число доменов Время память (Кб) Центр 1 1 688 Филиал 000 0:15:54 685 Центр 1 000 1 0:17:51 Филиал 125 10 58 Центр 58 250 10 228 Центр 250 10 0:04:47 227 0:21:32 Филиал 500 Филиал 500 10 823 Центр 500 10 0:21: 828 Филиал 50 266 Центр 125 50 0:05:54 264 Филиал 250 50 0:20:19 Центр 250 50 0:22:49 841 Как видите, нагрузка велика. Есть несколько вариантов решения про блемы. Не предлагаю изменить число Очевидно, если вы приняли решение создать столько то так тому и Ниже я дам ряд рекомендаций, но одна из них такова: отключите ISTG и сгенерируйте топологию репликации вручную. При этом надо иметь в виду, что за топологией придется постоянно следить и порой перестраивать. это та цена, которую приходится платить в крупной сети. О том, как упростить себе жизнь, я расскажу в разде ле Надежная связь между сайтами*.
Сколько нужно и где их размещать Очень часто спрашивают, нужно контроллеров домена и где их размещать. То, что в домене должно быть не менее двух контрол леров, уже знаете. А если домен разделен на несколько Вообще вариантов ответа Ч три:
Х для сайтов с количеством пользователей до 10;
Х для сайтов с численностью от 10 до 50 пользователей;
Х для сайтов с числом пользователей от 50.
Менее 10 пользователей Если в сайте менее 10 пользователей и они не работают с Microsoft Exchange 2000, контроллеры домена в сайте можно не устанавливать:
52 Active Directory: профессионала и отсутствия контроллеров в сайте Недостатки трафик трафик регистрации репликации в связи Не требуется дополни- Весь трафик к ГК оборудование ся по каналу связи При канала связи нельзя полу чить доступ к ресурсам, в том числе к локаль ным. Нужны альтернативные решения При канала связи и работе домена естественном режиме невозможна регистрация в сети. Нужны альтернативные решения Как видите, минусов больше, чем плюсов, но это не значит, что это решение неприемлемо. Если канал связи достаточно надежен и не сильно загружен, то нет большой беды, что трафик запросов к ГК и трафик регистрации по нему. А если канал недоступен?
Как видно из таблицы, это чревато в первую очередь невозможнос тью обращаться к локальным ресурсам, например, файловым или принтерным, Но этот недостаток можно преодолеть.
На файловом сервере создадим локальные группы, включив их в спис ки контроля доступа к ресурсам наравне с локальными группами до мена. На же создадим локальные учетные записи для всех пользователей в сайте. Этих пользователей также включим в локаль ные группы сервера. Пока канал открыт, пользователи осуществляют доступ по своим доменным записям. Если канал недоступен, применяются локальные учетные записи сервера. Очевидный недоста ток этого решения Ч сложность администрирования: ведь приходит ся поддерживать второй комплект учетных записей пользователей.
Еще один способ Ч задействовать терминальный сервер. Пользова тели осуществляют доступ к ресурсам не напрямую, а открывая тер минальный сеанс. Для этого им нужно на терми нальном сервере. Пока канал они регистрируются соглас но своим полномочиям в домене. Если канал недоступен, они все равно могут зарегистрироваться на терминальном сервере, применяя полномочия. Такое решение предпочтительно при работе с локальными и требует гораздо меньших уси лий по администрированию.
Замечание Если канал недоступен, пользователь может не зареги стрироваться, не имея доступа к контроллеру домена. Если он регис трировался ранее, то с помощью на рабочей станции Проектируем или информации войдет в сеть. Если же он регистрируется на конкрет ном компьютере впервые, то его постигнет неудача.
От 10 до 50 пользователей Число контроллеров домена на сайтах в этом случае зависит от опе раций, выполняемых в сайте. Для каждого домена нужен минимум один контроллер! Если сайт принадлежит нескольким доменам, в нем должны быть контроллеры для каждого, и вот почему.
Вспомните (см. главу Репликация Active какие контексты имен тиражируются при репликации:
контекст конфигурации, включающий информацию о структуре и конфигурации леса;
Х контекст схемы, содержащий базовую информацию об Active Directory и их атрибутах;
Х доменный имен, содержащий информацию как об объек тах домена (пользователи, компьютеры и пр.), так и объекты груп повой политики, Контроллер в домене знает о доменном контексте имен только свое го домена, но не чужих. Если сайт принадлежит нескольким доменам, то при регистрации пользователь должен обратиться к контроллеру того домена, в котором регистрируется. Если нужного контроллера в сайте нет. трафик регистрации будет направлен по каналу связи.
Приложения типа Microsoft Exchange 2000 потребуют установки на одном из контроллеров, так как понадобится обслуживать большое число LDAP-запросов поиска объектов из всего леса. В противном случае эти запросы пойдут по каналу связи к серверу ГК в другом сайте.
Сервер ГК нужен в сайте, когда домен работает в естественном режи ме. Дело в том, что при регистрации пользователя к ГК отправляется запрос о его членстве в универсальных группах. Если ГК недоступен, становится неясно, какие права доступа имеет пользователь, а раз так, то ему отказывают в регистрации.
Замечание Эту функциональность можно отключить на рабочей в реестре измените значение параметра Failures. Это позволит пользова телю зарегистрироваться в сети, но права доступа к некоторым ре сурсам будут так как членство в универсальной группе проверено не будет. В Windows 2003 от ГК в небольших сайтах мож но избавиться без этого недостатка. Для этого достаточно на контрол лере домена в сайте включить функцию кэширования глобальных и универсальных групп.
54 Active подход Наличие ГК в сайте сразу увеличивает трафик репликации по каналу.
Чем больше доменов в лесу, тем выше трафик репликации ГК.
Преимущества и недостатки размещения контроллеров домена в сайте таковы.
Преимущества и размещения контроллеров в небольшом сайте Преимущества Недостатки В случае недоступности канала связи Канал трафиком могут регистрироваться Если канал загружен в сети и осуществлять доступ часы, нужно планировать к время репликации Одни и те же серверы могут Требуется размещать сервер ГК для нять несколько функций: DNS, некоторых приложений, что ГК, сервер и т. чивает трафик репликации Можно разворачивать приложения. Требуется дополнительное работающие с ГК дование (от 1 контроллера на домен) От 50 пользователей В крупных сайтах одного контроллера на может оказаться недостаточно. Допустим, сайт обслуживает 200 пользователей, и вы поставили один контроллер домена.
Риск такого решения очевиден: в случае недоступности этого контрол лера локально весь трафик регистрации в сети будет направлен по каналу. В пиковые моменты времени это может оказаться весьма кри и регистрация растянется на продолжительное время.
Далее. Не очень мощный компьютер в пиковые моменты просто не справится с потоком запросов на что опять же се рьезно затормозит аутентификацию.
Следующая проблема не столь очевидна. Связана она с тем, что един ственный контроллер домена тянет на себе слишком много: занима ясь аутентификацией, он еще играет роль через который направляется трафик репликации. При высокой скорости изменений в Active велик будет и объем тиражируемой ин формации. Если же топология репликации такова, что наш сайт явля ется сайтом верхнего уровня для нескольких мелких сайтов, то загру жен он будет постоянно. Добавьте к этому возможность исполнения им таких функций, как сервер ГК, сервер DNS, WINS, DHCP, и вы пой мете, что это далеко не лучшее решение. Мало того, что такой компь ютер будет весьма дорогим, он при этом останется единичной точ кой сбоев, не имеющей Наличие нескольких контроллеров домена в крупном сайте предос поле для маневров. Два из них можно назначить выделенны ми серверами форпостов: один Ч сервером WINS, DHCP и DNS, Проектируем Мелочей не бывает Ч сервером Как поступить, вы в каждом конкретном случае, исходя из нагрузки в сайте.
Надежная связь между сайтами Теперь обсудим создание межсайтовых связей и мостов, а также рас положение серверов-форпостов (подробнее о них см. главу кация Active Поскольку топологию репликации можно создавать автоматически и вручную, мы уделим особое внимание ручному проектированию то пологии, которое обеспечивает надежность такую если не выше, чем при автоматической генерации. А начнем мы с топологии сети.
Топология сетей Топология межсайтовых связей зависит от топологии сети. В общем случае можно выделить три разновидности топологии сети:
Х КОЛЬЦО;
Х звезда (иногда называют со сложная.
Кольцевая топология что все сайты связаны между собой по очереди: первый со вторым, второй с третьим... последний с первым.
Достоинство Ч равномерная загрузка всех сайтов, недоста ток Ч длинный путь передачи информации между ними.
В один центральный сайт связан со всеми остальными. При большом числе сайтов звезда очень напоминает ось колеса с отхо дящими от нее спицами. Ее достоинство Ч фиксированная скорость передачи информации недостаток Ч перегруженность центрального сайта. В дальнейшем центральный сайт будем называть центром, а подключенные к нему Ч филиалами.
Active подход профессионала Сложная (комбинированная) топология встречается чаще описанных выше и представляет собой их комбинацию, не достатки и связи Для выполнения репликации между сайтами служат специальные объекты Active Directory Ч связи. Каждый такой объект характеризуется:
Х стоимостью;
расписанием;
интервалом;
Х репликации.
Одна связь может использоваться между двумя и более сайтами. Поясню последнее. на предыдущем рисунке меж ду тремя существуют каналы связи. Можно создать межсай связь, каждому из а можно Ч одну которая будет обслуживать все три этих сайта.
Если мы считаем, что все три центральных сайта расположены на магистральной сети, то нет смысла создавать несколько межсаитовых так как у них будут идентичные характеристики.
не Стоимость связи Ч это числовое значение, показываю щее, насколько данная связь дороже альтернативной. Стоимость в основном от пропускной способности канала. Следующая формула позволяет автоматически назначать стоимость и не допус кать ошибок при проектировании:
Стоимость способность Вот значения стоимостей для типовых величин эффективной пропус кной способности:
Зависимость стоимости от пропускной способности канала пропускная способность Стоимость 9,6 1 38,8 56 64 128 256 512 1024 2048 4096 Замечание Ни ни таблица не являются догмой. Вы може те использовать произвольные значения.
Данная методика расчета стоимости межсайтовой связи не учитыва ет надежности канала. Проектируя связи, можно наме ренно завысить стоимость для ненадежного канала.
Межсайтовые связи по умолчанию считаются транзитивными. Это значит, что если межсайтовые связи установлены между сайтами А и В и сайтами В и С, то существует межсайтовая связь между А и С. Тран зитивность работает только в полностью маршрутизируемых сетях.
Если же отдельные сегменты сети не являются полностью маршру тизируемыми, в них нужно создавать межсайтовые мосты Ч специ альные объекты Active Directory. Необходимость в мос те возникает, когда в сегменте находится контроллер того домена, контроллеров которого нет в сегментах, непосредственно связанных с рассматриваемым. Вот пример немаршрутизируемой сети:
подход профессионала мост Контроллер домена А Контроллер домена А Пример немаршрутизируемой сети и моста В этой сети Сайт 2 не маршрутизирует трафик IP. Для Сайта 3 нужно мост к сайту так как только в нем находится контроллер того же домена, что и в сайте 3- А вот для сайта 4 такой мост не нужен, так как контроллер домена в пределах прямой досягаемости.
Pages: | 1 | 2 | 3 | 4 | 5 | ... | 7 | Книги, научные публикации