Официальное
пособием для
самоподготоики
Проектирование инфраструктуры Active Directory' и сети на основе Microsoft®
Windows erver 2003 Экзамен 7 0 - 2 9 7
Москва * Санкт-Петербург * Нижний Новгород * Воронеж Новосибирск * Ростов-на-Дону * Екатеринбург * Самара Киев * Харьков * Минск 2006
М . РУССКАЯ Р Е И К Ш
[^ППТЕР
Оф и ц и *шь н о с п о с о б и с дл я само п од го то i J I % .> i
» »,«,.
m i l l ,
j Li iP'
Проектирование инфраструктуры Active Direct и сети на основе Microsoft8
indows erver 2003 Экзамен 7
. Помимо этих ограничений, налагаемых на символы, имена участников системы бе зопасности должны соответствовать следующим правилам: • имена учетных записей пользователей могут содержать максимум 20 символов; • имена учетных записей компьютеров могут содержать максимум 15 символов; • имена учетных записей групп могут содержать максимум 63 символа. Кроме того, имена участников системы безопасности не могут состоять только из точек, пробелов и знаков @. Любые точки или пробелы в начале имени пользователя отбрасываются. Допускается применение одного и того же имени участника системы безопасности в разных доменах. Так, можно создать пользователя wjglenn в доменах hr.contoso.com и sales.contoso.com. Это не приведет к проблемам, поскольку составное, относительное составное и каноническое имена каждого объекта автоматически генерируются Active Directory и все равно позволяют глобально идентифицировать этот объект.
Закрепление материала Ответив на вопросы, приведенные ниже, вы сможете лучше усвоить основные темы за нятия. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытай тесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы. 1. Перечислите компоненты составных, относительных составных и канонических имен, а также расскажите, как формируются эти имена. 2. Чем отличаются имена доменов в DNS и NetBIOS? 3. Вы решаете, как создать пространство имен для компании, у которой имеется заре гистрированное DNS-имя proseware.com. Компания подключена к Интернету и под держивает несколько сервисов, доступных через Интернет. Каковы два варианта по строения пространства имен с учетом зарегистрированного DNS-имени? 4. Вы планируете сеть, где есть два домена, содержащих учетные записи пользователей. Вы обнаружили, что в каждом домене имеется пользователь Keith Harris. Вы не хоти те нарушать установленное вами же соглашение об именовании, в соответствии с которым обоим пользователям нужно присвоить имя участника системы безопасно сти kharris. Какие утверждения, перечисленные ниже, являются правильными в дан ном случае? a. Это можно сделать без ручного вмешательства. b. Это можно сделать, но придется вручную изменить относительное составное имя объекта пользователя. c. Это можно сделать, но придется вручную изменить составное и каноническое имя объекта пользователя. d. Active Directory не позволит создать в одном лесу два объекта пользователя с оди наковыми именами.
Пример ИЗ орактикй
Резюме •
Active Directory поддерживает несколько типов имен: составные (distinguished names), относительные составные (relative distinguished names), канонические имена и имена участников системы безопасности (user principal names). • При реализации схемы именования необходимо планировать две роли хозяина опе раций: именования доменов (управляет добавлением и удалением доменов) и RID (выделяет последовательности RID каждому контроллеру домена в своем домене). в Пространство имен DNS имеет иерархическую структуру, а пространство имен Net BIOS — плоскую. Для каждого объекта Active Directory создаются имена обоих ти пов. NetBIOS-имена (компьютеров и доменов) могут иметь длину до 15 символов, а DNS-имена — до 64. Чтобы соблюсти требования обоих пространств, используйте короткие имена (не более 15 символов). я При управлении зарегистрированными DNS-именами есть три варианта. Первый — использовать в качестве имени корневого домена Active Directory зарегистрирован ное DNS-имя компании. Второй — задействовать в качестве корневого домена Active Directory поддомен зарегистрированного DNS-имени. Третий — определить разные внутреннее и внешнее имена, но применять данный вариант не рекомендуется.
Ц Пример из практики Изучите следующий сценарий и ответьте на вопросы.
Сценарий Вам поручили планирование новой структуры Active Directory для компании Fourth Coffee — поставщика кофе для ресторанов юго-востока США. В настоящее время все серверы ее сети работают под управлением Windows NT Server 4.0. На клиентских ком пьютерах используются Windows 98 и Windows NT Professional 4.0. Fourth Coffee наняла вас, чтобы привести сетевую инфраструктуру компании в соответствие с требованиями времени. Руководство компании хочет, чтобы все серверы работали под управлением Windows Server 2003 и чтобы вы реализовали Active Directory. Все клиентские компьюте ры должны работать под управлением Windows XP Professional. Кроме того, желательно по возможности упростить сетевую инфраструктур}'.
Краткие сведения о компании Компания Fourth Coffee значительно выросла за последние несколько лет и стала одним из ведущих поставщиков высших сортов кофе для крупных сетей ресторанов и гости ниц. В прошлом году Fourth Coffee приобрела компанию по выращиванию кофе, распо ложенную на Ямайке, и собирается подключить ее сеть к своей.
География Главный офис Fourth Coffee находится в Нашвилле (штат Теннеси). Кроме того, у Fourth Coffee есть филиалы в Хьюстоне (штат Техас) и Роме (штат Джорджия). 5 каждом фили н е имеются отделы продаж и маркетинга, в которых работает множество сотрудников, .-:: нет своего ИТ-отдела. Их обслуживает ИТ-отдел, расположенный в глазном офисе в Нашвилле.
Планирование структуры Active Directory
Глава 3
Недавно приобретенный производитель и экспортер кофе — компания Northwind Traders — находится в Кингстоне на Ямайке. Офис на Ямайке обладает полноценной корпоративной инфраструктурой, в частности в нем имеется собственный ИТ-отдел. Хотя местный ИТ-отдел продолжает обслуживать свой офис, управление сетевой инфраструктурой передается ИТ-отделу главного офиса в Нашвилле. У офиса в Кинг стоне есть собственное пространство имен, northwindtraders.com, которое нужно со хранить в новой корпоративной инфраструктуре.
Сетевая инфраструктура Штаб-квартира в Нашвилле связана с филиалом в Хьюстоне 512-килобитным каналом Frame Relay. Главный офис в Нашвилле соединен с офисом в Роме точно таким же ка налом, а с офисом в Кингстоне — коммутируемой линией с соединением по требова нию, пропускная способность которой составляет 64 Кбит/с. Во всех офисах клиенты и серверы связаны сетевыми соединениями с пропускной способностью 10/100 Мбит/с. В настоящее время каждый офис использует свой домен Windows NT, имя которого совпадает с названием места, в котором находится офис. Это решение приняли главным образом для того, чтобы управлять трафиком репликации, передаваемым по WAN-кана лам между главным офисом и филиалами. Все домены настроены на двусторонние дове рительные отношения друг с другом. Вы не обязаны сохранять какие-либо существую щие домены.
Планы на будущее Сейчас не планируется расширять штат или приобретать новые компании. Однако ру ководство компании хотело бы в конечном итоге прекратить использование названия Northwind Traders и доменного имени northwindtraders.com и выпускать всю продук цию под товарным знаком Fourth Coffee. Но на данный момент пространство имен northwindtraders.com следует включить в ваш проект.
ИТ-менеджмент ИТ-отдел в Нашвилле определяет структуру и требования к политике безопасности для сети в целом. Кроме того, он напрямую управляет работой офисов в Хьюстоне и Роме. Местный ИТ-отдел в Кингстоне управляет локальной сетью. Но за работу сети в целом в конечном итоге отвечает ИТ-отдел в Нашвилле.
Вопросы Исходя из данного сценария ответьте на следующие вопросы. 1. Нарисуйте географическую схему структуры компании и выберите модель лесов и доменов, учитывая, что руководство компании хочет по возможности упростить ин фраструктуру компании. 2. Перечислите преимущества использования одного домена для офисов в Нашвилле, Роме и Хьюстоне по сравнению с применением нескольких доменов. И какие пре имущества вы получили бы, все же создав несколько доменов? 3. Вы решили не использовать один домен для офисов в Нашвилле, Роме и Хьюстоне, а оставить свои домены для каждого офиса. Вы не хотите, чтобы офисы в Роме и Хьюстоне казались подразделениями офиса в Нашвилле, но должны использовать зарегистрированное DNS-имя fourthcoffee.com. Создайте иерархию доменов для этих офисов. Какой домен вы выбрали бы в качестве корневого для леса?
Рекомендаций по подготовке к экзамену 4. Соответствуют ли имена, которые вы выбрали для доменов в структуре Active Direc tory, требованиям к DNS-именам? А к NetBIOS-именам? Если они не соответствуют какому-либо требованию, какие проблемы при этом возникнут?
Ц Резюме главы • •
• •
•
•
•
•
По возможности всегда используйте один домен, поскольку такая структура наибо лее проста в планировании, развертывании и сопровождении. Применяйте несколько доменов, когда требуется реализовать разные политики безо пасности, обеспечить децентрализованное администрирование, оптимизировать тра фик репликации или сохранить существующую структуру доменов. Используйте несколько деревьев доменов, если вам нужно поддерживать несколько пространств имен DNS. Используйте несколько лесов, если требуется поддерживать несколько компаний или обеспечить автономную/изолированную работу какого-либо подразделения компа нии. Active Directory поддерживает несколько типов имен: составные (distinguished names), относительные составные (relative distinguished names), канонические имена и имена участников системы безопасности (user principal names). При реализации схемы именования необходимо планировать две роли хозяина опе раций: именования доменов (управляет добавлением и удалением доменов) и RID (выделяет последовательности RID каждому контроллеру домена в своем домене). Пространство имен DNS имеет иерархическую структуру, а пространство имен NetBIOS — плоскую. Для каждого объекта Active Directory создаются имена обоих типов. NetBIOS-имена (компьютеров и доменов) могут иметь длину до 15 симво лов, а DNS-имена — до 64. Чтобы соблюсти требования обоих пространств, исполь зуйте короткие имена (не более 15 символов). При управлении зарегистрированными DNS-именами есть три варианта. Первый — использовать в качестве имени корневого домена Active Directory зарегистрирован ное DNS-имя компании. Второй — задействовать в качестве корневого домена Active Directory поддомен зарегистрированного DNS-имени. Третий — определить разные внутреннее и внешнее имена, но применять данный вариант не рекомендуется.
Ц Рекомендации по подготовке к экзамену Прежде чем сдавать экзамен, повторите основные положения и термины, приведенные ниже, чтобы выяснить, какие темы нужно проработать дополнительно.
Основные положения • • •
Когда нужно создать дополнительные домены или OU, лучше использовать допол нительные OU (если, конечно, можно обойтись без дополнительных доменов). Используйте несколько деревьев доменов, только если необходимо поддерживать более одного пространства имен DNS в лесу. Применение нескольких лесов настоятельно не рекомендуется за исключением осо бых случаев. Почти всегда лучше создать несколько деревьев в одном лесу.
Планирование структуры Active Directory •
Глава 3
Использование зарегистрированного DNS-имени в качестве имени корневого доме на Active Directory — подход, рекомендуемый Microsoft. Когда вы будете отвечать на экзаменационные вопросы, он скорее всего окажется лучшим выбором, если только требования к проекту не вынудят выбрать другой вариант.
Основные термины NetBIOS — плоское пространство имен, которое было основным механизмом разреше ния имен в предыдущих версиях Windows. Поскольку Active Directory основана на DNS, пространство имен NetBIOS отошло на второй план, но по-прежнему поддер живается и используется. Автономный/изолированный ~ autonomous/isolated. Автономный домен — это домен, который все равно управляется центральным ИТ-отделом и входит в существую щую структуру доменов, но требует определенной степени свободы в изменении структуры и схемы Active Directory. Изолированный домен — то же, что и автоном ный, но в нем не используется структура остальной сети, и он недоступен из других доменов. Корневой домен леса ~ forest root domain — первый домен, который вы создаете в лесу Active Directory; служит основой для структуры леса. Любой другой домен, который вы создаете в лесу (даже в других деревьях доменов), наследует свое составное имя и используемое по умолчанию DNS-имя от имени корневого домена леса.
Щ
Вопросы и ответы
Занятие 1. Лабораторная работа 1. Какую модель лесов вы предложили бы? Сколько лесов следует использовать? Почему? Правильный ответ: одно из решений — создать для Northwind Traders два леса. Есть и другие решения. В данном решении используется отдельный лес R&D, поскольку их дан ные и службы нуждаются в изоляции. Остальной организации не требуется изоляция служб. Следовательно, остальной организации достаточно одного леса. 2. Нарисуйте схему предлагаемой вами для Northwind Traders структуры доменов. Правильный ответ: одно из возможных решений — применить региональную модель до менов и выделенный корневой домен леса. Для леса корпорации Northwind Traders (NWtraders) требуется пять доменов — пустой корневой домен и четыре региональных домена. В лесу R&D достаточно одного домена.
д Лес R&D
Лес NWtraders
Занятие 1. Закрепление материала 1. Вы разрабатываете модель лесов для компании и размышляет:-, сколько доменов ис пользовать — один или несколько. По каким причинам может г.стребсьаться несколь ких доменов? т, Правильный ответ: несколько доменов может потребс« ».. ч1> г> реализо вать разные политики безопасности на уровне доменер i к > (равления паролями или учетными записями); б) обеспечить децрр! i > "-» , растрирова ние с более широкими возможностями управления на ме>.тх ч " иэвтгь трафик репликации по WAN-каналам в большей мере, чем э^о г < " ,ла г) разделить пространство имен по территориальному признаку илч >с i ^ i я \ т, сохранить существующую структуру доменов Windows NT 4.0; е) в » ' ^ i" ^ » > ч LTBC корне вого домена компании? Правильный ответ: чтобы администраторам домена было проще управлять членством в универсальных группах Администраторы предприятия (Enterprise Admins) и Админи страторы схемы (Schema Admins), сведения о котором хранятся а корне леса; чтобы усилить изоляцию от изменений в структуре компании; наконец, чтобы корневой домен леса был меньшего размера (поскольку он не содержит другие ресурсы) и его было легче реплицировать на другие серверы предприятия для обеспечения отказоустойчивости. 3. Какова основная причина использования в сети нескольких деревьев доменов? В чем заключаются недостатки такого подхода? Правильный ответ: единственная причина использования в лесу нэскольких деревьев доменов — необходимость поддержки нескольких пространств имен DNS. У такого под хода два основных недостатка — требуется поддерживать дополнительные ресурсы DNS и обслуживать больше доменов. 4. По каким причинам может потребоваться реализация нескольким лесов? Правильный ответ: лес представляет крайние границы зоны безопасности. Между леса ми невозможно административное управление или пользовательский доступ, если на это нет явного разрешения. Поэтому применение нескольких лесов позволяет поддерживать несколько отдельных компаний, предоставить административную автономию, создать изолированное подразделение.
Занятие 2. Закрепление материала 1. Перечислите компоненты составных, относительных составных и канонических имен, а также расскажите, как формируются эти имена. Правильный ответ: составные имена глобально идентифицируют объект; они включают простые имена объекта, его родительских контейнеров и информглдею о домене. Относи тельные составные имена идентифицируют объект в родительском контейнере; они со держат только простое имя самого объекта. Канонические имена аналогичны составным (в том смысле, что глобально идентифицируют объект), но имеют другой синтаксис. Все три вида имен автоматически генерируются Active Directory по простым именам объекта и его родительских контейнеров.
Планирование структуры ftctiye Directory
Глава 3
2. Чем отличаются имена доменов в DNS и NetBIOS? Правильный ответ: пространство имен DNS имеет иерархическую структуру, тогда как пространство имен NetBIOS — плоскую. NetBIOS-имена служат для поддержки уна следованной системы разрешения имен в Windows. DNS-имена могут быть длиной до 64 символов, а NetBIOS-имена — только до 15. 3. Вы решаете, как создать пространство имен для компании, у которой имеется заре гистрированное DNS-имя proseware.com. Компания подключена к Интернету и под держивает несколько сервисов, доступных через Интернет. Каковы два варианта по строения пространства имен с учетом зарегистрированного DNS-имени? Правильный ответ: первый вариант — использовать зарегистрированное DNS-имя proseware.com в качестве имени корневого домена в структуре Active Directory. Второй вариант — задействовать в качестве корневого домена поддомен proseware.com (напри мер sales.proseware.com). 4. Вы планируете сеть, где есть два домена, содержащих учетные записи пользователей. Вы обнаружили, что в каждом домене имеется пользователь Keith Harris. Вы не хоти те нарушать установленное вами же соглашение об именовании, в соответствии с которым обоим пользователям нужно присвоить имя участника системы безопасно сти kharris. Какие утверждения, перечисленные ниже, являются правильными в дан ном случае? a. Это можно сделать без ручного вмешательства. b. Это можно сделать, но придется вручную изменить относительное составное имя объекта пользователя. c. Это можно сделать, но придется вручную изменить составное и каноническое имя объекта пользователя. d. Active Directory не позволит создать в одном лесу два объекта пользователя с оди наковыми именами. Правильный ответ: а.
Пример из практики 1. Нарисуйте географическую схему структуры компании и выберите модель лесов и доменов, учитывая, что руководство компании хочет по возможности упростить ин фраструктуру компании. Правильный ответ: географическая схема должна отражать штаб-квартира в Нашвилле, два филиала и офис в Кингстоне. Кроме того, вы должны отметить типы соединений, связывающих офисы. Простейшая структура состояла бы из двух деревьев доменов, каж дое из которых содержит по одному домену. В первое дерево входил бы единственный домен, fourthcoffee.com, содержащий ресурсы штаб-квартиры в Нашвилле и филиалов в Роме и Хьюстоне. Для управления трафиком репликации между филиалами можно было бы использовать сайты. Для приобретенной компании в Кингстоне нужно создать от дельное дерево доменов — в первую очередь потому, что следует сохранить пространство имен northwindtraders. 2. Перечислите преимущества использования одного домена для офисов в Нашвилле, Роме и Хьюстоне по сравнению с применением нескольких доменов. И какие пре имущества вы получили бы, все же создав несколько доменов?
Вопросы и ответы
Правильный ответ: один домен проще в создании и управлении; кроме того, в этом слу чае администрирование было бы более централизованным. При необходимости можно было бы создать сайты для управления трафиком репликации по WAN-каналам и со здать OU, чтобы разделить административные функции. В применении нескольких до менов в этом случае были бы следующие преимущества: еще больший контроль над трафиком репликации и возможность реализации разных политик безопасности для каждого домена. 3. Вы решили не использовать один домен для офисов в Нашвилле, Роме и Хьюстоне, а оставить свои домены для каждого офиса. Вы не хотите, чтобы офисы в Роме и Хьюстоне казались подразделениями офиса в Нашвилле, но должны использовать зарегистрированное DNS-имя fourthcoffee.com. Создайте иерархию доменов для этих офисов. Какой домен вы выбрали бы в качестве корневого для леса? Правильный ответ: в данном случае лучше всего присвоить корневому домену леса заре гистрированное DNS-имя fourthcoffee.com. Затем для каждого из трех участков создайте свой дочерний домен этого корневого домена (рис. 3-7).
LA fourthcoffee.com
L\ LA LA nashville. fourthcoffee.com
Рис. 3-7.
rome. fourthcoffee.com
houston. fourthcoffee.com
Иерархия доменов fourthcoffee.com
4. Соответствуют ли имена, которые вы выбрали для доменов в структуре Active Directory, требованиям к DNS-именам? А к NetBIOS-именам? Если они не соответ ствуют какому-либо требованию, какие проблемы при этом возникнут? Правильный ответ: имя fourthcoffee отвечает соглашениям об именовании в DNS и NetBIOS, где допускаются имена дайной не более 64 и 15 символов соответственно. Имя northwindtraders (длиной 16 символов) не соответствует соглашению об именовании в NetBIOS. Вы можете использовать разные DNS- и NetBIOS-имена, и в данном случае это не приведет к слишком тяжелым последствиям. Обычно самая крупная проблема изза использования разных имен состоит в том, что это может запутать администраторов и пользователей. Однако в данном случае можно в определенной мере снять остроту этой проблемы, просто отбросив последний символ и используя NetBIOS-имя northwindtrader.
ГЛА iOi
Занятие 1. Проектирование структуры OU
101
Занятие 2. Планирование стратегии управления учетными записями
117
Занятие 3, Планирование реализации групповой политики
126
Темы экзамена я
Проектирование инфраструктуры Active Directory, соответствующей бизнес-требова ниям и техническим условиям: а создание принципиальной схемы структуры организационных единиц (OU).
и
Проектирование структуры OU: • определение требований групповой политики для структуры OU; • разработка структуры OU, предназначенной для делегирования полномочий.
и
Разработка стратегии управления учетными записями компьютеров и пользователей: а описание требований к политике управления учетными записями; а описание требований к учетным записям пользователей, компьютеров, админи страторов и служб.
•
Разработка стратегии управления группами безопасности: а определение областей действия групп безопасности; а определение требований к управлению доступом к ресурсам; а определение требований к управлению административным доступом; а определение ролей пользователей.
•
Разработка стратегии аутентификации пользователей и компьютеров: а определение общих требований к аутентификации; а выбор механизмов аутентификации; •'ггг'мизация аутентификации с помощью доверия к сокращениям.
Занятие 1
Проектирование структуры организационных единиц
м Разработка стратегии реализации групповой политики: • проектирование стратегии администрирования GPO; а разработка стратегии развертывания GPO; а создание стратегии настройки среды для пользователя через групповую политику; • создание стратегии настройки среды для компьютера через групповую политику. В этой главе В предыдущей главе вы узнали, как проектировать структуру Active Directory для орга низации. Для этого требуется определить, сколько доменов нужно и как организовать эти домены — в одно дерево доменов или в лес. По завершении этого этапа проектиро вания наступает время переключить внимание на планирование структуры администра тивной защиты каждого домена. По собранной вами информации о компании и ИТперсонале вы должны определить, как лучше всего делегировать административные пол номочия в доменах. Первый этап проектирования административной структуры защиты — планирование использования организационных единиц (OU) в каждом домене. Следующий этап про ектирования этой структуры — выработка стратегии управления учетными записями пользователей, компьютеров и групп. Затем вы должны разработать эффективную реа лизацию групповой политики. Прежде всего Для усвоения материалов этой главы нужно иметь представление об основных концеп циях Active Directory —- см. главу 1. Кроме того, следует собрать и проанализировать все возможную информацию о существующей в вашей компании инфраструктуре Active Directory — см. главу 2. Хотя перед созданием административной структуры защиты сле дует спроектировать структуру Active Directory (см. главу 3), для изучения концеп ций, о которых рассказывается здесь, читать главу 3 не обязательно.
Занятие 1. Проектирование структуры 0U Первый этап разработки структуры административной защиты — создание плана ис пользования организационных единиц (OU) в каждом домене среды. Для этого опре делите, как лучше всего делегировать административное управление ресурсами каж дого домена. Кроме того, при проектировании архитектуры учитывайте требования групповой политики. Изучив материал этого занятия, вы сможете: •S рассказать, зачем нужны OU; •S выбрать способы использования OU для делегирования административного управления; S описать влияние наследования при проектировании структуры OU; •/ проектировать архитектуру с учетом требований групповой политики. Продолжительность занятия - около 40 минут.
Проектирование административной структуры защиты
Глава 4
Введение в 0U Как вы уже знаете из главы 1, OU служит контейнером, в который можно поместить ресурсы и учетные записи домена. Затем можно назначить OU административные раз решения и позволить содержащимся в нем объектам наследовать эти разрешения. OU могут содержать любые объекты следующих типов: • пользователи; • компьютеры; • группы; • принтеры; • приложения; • политики безопасности; • общие папки; • другие OU. OU — это прежде всего административный инструмент. Они не появляются в струк туре именования DNS, применяемой организацией, поэтому конечным пользователям незачем изучать структуру OU. То есть вы проектируете структуру OU главным образом для того, чтобы облегчить жизнь администраторам сети. В частности, OU позволяют упорядочить учетные записи и ресурсы домена, что упрощает управление этими объек тами и их поиск. Часто проектировщики создают структуру OU на основе структуры отделов или по территориальному признаку, поскольку такое решение представляется очевидным, но иногда это не является необходимым и даже может привести к отрицательным результа там. Не следует создавать структуру OU исключительно ради того, чтобы иметь какуюто структуру, — OU используются в определенных целях. К этим целям относятся: • делегирование административного управления объектами; • ограничение видимости объектов; • управление применением групповой политики. Определяющее влияние на структуру OU должна оказывать первая из этих трех целей — делегирование административного управления. Всегда следует начинать с со здания структуры OU, эффективно делегирующей управление, а затем совершенство вать эту структуру, создавая OU, управляющие групповой политикой и скрывающие объекты. В последующих разделах эти причины создания OU рассматриваются более подробно. Примечание Хотя создавать отдельные OU по территориальному признаку лишь из-за очевидности такого деления не следует, иногда такое решение приемлемо. Когда сеть охватывает обширную территорию, а ее части соединены более медленными WAN-кана лами, можно упростить проектирование структуры сайтов (см. главу 5), создав отдель ную OU для каждого участка, а затем создав вложенные OU для делегирования админи стративного управления.
Применение 0U для делегирования административного управления У вас может появиться соблазн создать структуру OU по территориальному признаку или организационной схеме, составленной ИТ-отделом. Но на самом деле структура OU,
Занятие 1
Проектирование структуры организационных единиц
основанная на таком делении, не обязательно сделает администрирование объектов Active Directory более удобным, а ведь структуру OU создают, чтобы уменьшить нагруз ку на администраторов. Запомните: структура OU нужна не для того, чтобы облегчить жизнь пользователям или просто лучше упорядочить объекты, а для того, чтобы упростить администраторам управление объектами, помещенными в эти OU и чтобы было проще предоставлять соответствующие разрешения этим администраторам. Таким образом, следует создать иерархию OU, решающую задачи администрирования и обеспечения безопасности, сто ящие перед предприятием. Стремитесь к максимально возможному упрощению архи тектуры и выбирайте имена OU, имеющие смысл для людей, которые будут их исполь зовать (т. е. для администраторов). Есть две основные архитектуры OU, применяемые для делегирования администра тивных полномочий: на основе объектов и на основе задач. Эти две архитектуры рас сматриваются в следующих разделах. Архитектура, основанная на объектах В структуре OU, основанной на объектах (рис. 4-1), делегирование полномочий выпол няется в зависимости от типа объектов, которые хранятся в OU. Вы можете выбрать структуру OU, в которой объекты группируются по принадлежности к одному из следу ющих типов: • пользователям; • компьютерам; • сайтам; • доменам; А • OU. /
/.
ДОМЕН
(Domain!
Л Встроенный (Builtin) • Компьютеры (Computers)
•, "£->
Контроллеры домена (Domain Controllers) Пользователи (Users)
•
Учетные записи (Accounts) - Ч, ^
Учетные записи пользователей (User Accounts)
"" * V *
Учетные записи администраторов (Admin Accounts)
- **>
Группы (Groups)
Рис. 4-1. Пример структуры OU, основанной на объектах
t£14
Проектирование административной структуры защиты
Глава 4
Чтобы делегировать полномочия по администрированию объектов, входящих в OU, определенному пользователю или группе, придерживайтесь следующей схемы. 1. Поместите пользователя или группу, которой требуются административные права, в группу безопасности (подробнее о группах безопасности см. занятие 2). 2. Поместите в OU набор объектов, которыми нужно управлять. 3. Делегируйте административные задачи для этой OU группе безопасности, в которую вы добавляли пользователя или группу на этапе 1.
Apxiiienypas основанная на задачах В архитектуре, основанной на задачах, делегирование управления осуществляется в за висимости от административных задач, которые требуется решать, а не от типа объек тов, подлежащих администрированию. К этим задачам относятся: а создание, удаление и изменение учетных записей пользователей; я сброс сроков действия паролей; н определение группо'вой политики; в управление членством в группах и разрешениями.
Планирование структуры 0U Служба каталогов Active Directory позволяет весьма точно управлять делегированием административных полномочий. Например, можно предоставить одной группе полный доступ ко всем объектам OU, второй — права на создание, удаление и изменение объек тов OU определенного типа, а третьей — право управлять определенным атрибутом объектов конкретного типа (скажем, возможностью сбрасывать срок действия паролей учетных записей пользователей). Кроме того, можно сделать эти разрешения наследуе мыми, чтобы они применялись не только к данному OU, но и ко всем создаваемым OU более низкого уровня. Такое тонкое управление обеспечивает огромную гибкость. Если вы выберете структуру OU на основе объектов, то сможете поместить все объекты некоего типа в один контейнер, а затем назначить довольно сложный набор административных разрешений для этих OU, определяющих, что вправе делать каж дый администратор. Далее можно создать OU более низкого уровня, управляющие применением групповой политики или решением какие-либо других задач, причем эти ОU унаследуют ту же структуру разрешений. Пример структуры такого рода при веден на рис. 4-2. Правильно разработанная структура OU позволяет администраторам эффективно делегировать полномочия. Следует уделять особое внимание верхнему уровню структу ры OU, который всегда должен отражать относительно неизменную часть структуры предприятия, чтобы его не приходилось изменять в случае реорганизации. Так, следую щие типы структуры верхнего уровня основаны на постоянных характеристиках пред приятия, изменение которых маловероятно. в
Физические участки. В филиалах, физически расположенных в разных местах (осо бенно, когда компания действует на обширной территории, например в нескольких странах), часто имеются свои ИТ-отделы, поэтому у филиалов разные требования к администрированию. Создание отдельного OU верхнего уровня для каждого фи лиала — один из вариантов архитектуры, основанной на задачах; в зависимости от местонахождения определяются разные административные задачи (рис. 4-3).
Занетие 1
Проектирование структуры организационных единиц
Встроенный (Builtin)
Компьютеры (Computers)
Контроллеры домена (Domain Controllers)
Пользователи (Users) Группа
Доступ
Объекты
Domain Admins
Полный
Все
Учетные записи администраторов (Admin Accounts)
User Admins
Полный
Пользователи
Группы (Groups)
Group Admins
Полный
Группы
Учетные записи (Accounts)
•**>*
Рис. 4-2. •
•
Учетные записи пользователей (User Accounts) "*~™
СЛОЖНЫЙ набор разрешений для сравнительно простой структуры OU
Типы административных задач. Структура верхнего уровня, основанная на адми нистративных задачах, относительно постоянна. Какие бы реорганизации не про исходили в компании, основные типы административных задач вряд ли сильно изменятся. Типы объектов. Как и структура, основанная на задачах, структура, в которой OU верхнего уровня соответствуют типам объектов, обеспечивает устойчивость архи тектуры к изменениям.
Каждый из приведенных выше вариантов структуры OU верхнего уровня лучше, чем, например, OU, основанные на структуре отделов компании, вероятность измене ния которой гораздо выше. При планировании структуры OU верхнего уровня для среды с несколькими доме нами, есть смысл подумать о создании структуры верхнего уровня, которая будет одной и той же для каждого домена сети. В этом случае особенно эффективна архитектура, основанная на объектах или на задачах (об этих архитектурах рассказывается далее). Создание структуры OU, одинаковой для различных доменов, позволяет реализовать единый подход к администрированию и поддержке сети. OU нижних уровней (создаваемые в OU верхнего уровня) должны использоваться для более тонкого управления административными полномочиями или в других целях, например для применения групповой политики. Запомните: по умолчанию OU нижних уровней наследуют разрешения от родительских OU. При планировании архитектуры вы должны определить и то, когда наследуются разрешения и когда они не наследуются.
Проектирование административной структуры защить
Глава 4
/ / /
L
\ Домен
Встроенный (Builtin) Компьютеры (Computers) Контроллеры домена (Domain Controllers) Пользователи (Users)
~ ^$>, Даллас • ^f>
Мемфис
* ,.
Портленд
Рис. 4-3. Структура OU верхнего уровня, в которой административные задачи основаны на физических участках При проектировании OU нижних уровней легко переусердствовать. Помните: ваша основная задача — получить структуру, максимально облегчающую администрирова ние учетных записей и ресурсов. Поэтому ваша архитектура должна быть как можно проще. Если вы создадите слишком глубоко вложенную структуру OU, то не только будете иметь дело с более запутанной структурой, но и можете столкнуться со сниже нием производительности. Групповая политика может применяться к OU на разных уровнях — на уровне домена, сайта и каждого из родительских OU. Чем больше поли тик нужно применить, тем больше время ответа и тем ниже производительность. Подготовка к экзамену И в случае архитектуры, основанной на объектах, и в случае архитектуры, основанной на задачах, следует сначала создать структуру OU, позволя ющую делегировать административные полномочия. Закончив начальную стадию про ектирования OU, создайте дополнительные структуры OU, управляющие применени ем групповой политики к пользователям и компьютерам и ограничивающие видимость объектов.
Применение 0U для ограничения видимости объектов В некоторых организациях определенные объекты должны быть скрыты от определен ных администраторов или пользователей. Даже если вы запретите изменение атрибутов объекта, пользователи, имеющие доступ к контейнеру с таким объектом, все равно смо гут видеть, существует ли этот объект. Однако вы можете скрыть объекты, поместив их в OU и ограничив круг пользователей, которые имеют разрешение Список содержи мого (List Contents) для этой OU. Тогда объекты, помещенные в контейнер, будут неви-
Проектирование структуры организационных еданиц
Занятие 1
-j gy
:нмы пользователям, не имеющим этого разрешения. Пример такой архитектуры при веден на рис. 4-4.
Л Домен ; Domain)
Встроенный (Builtin) Компьютеры (Computers) Контроллеры домена (Domain Controllers) Пользователи (Users) Даллас --i„ j
Мемфис Портленд Пользователи (Users)
< ^Sjj Скрытые (Hidden) Рис. 4-4. OU позволяют скрывать объекты Хотя необходимость ограничить видимость объектов — менее важная проблема, чем создание качественной административной структуры, может оказаться, что из-за поли тических или юридических требований или по соображениям безопасности нужно скры вать объекты. Лучший способ это сделать — сначала сосредоточиться на создании каче ственной структуры OU, основанной на предоставлении административных полномо чий. Поместите объекты в OU, в которых они должны находиться в соответствии с этой структурой. После этого создайте новые OU, которые будут служить для скрытия объек тов, входящих в новую структуру.
Применение OU для управления групповой политикой О планировании групповой политики подробнее будет рассказано на занятии 3. Тем не менее, в этом разделе вы познакомитесь с третьей веской причиной использова ния OU — управлением групповой политикой. Групповая политика позволяет применять одни и те же параметры конфигурации сразу к нескольким объектам. С ее помощью можно определять параметры пользовате лей (например ограничения, налагаемые на пароли) или компьютеров. При использова нии групповой политики вы создаете объект групповой политики (Group Policy Object,
108
Проектирование административной структуры защиты
Глава 4
GPO) — объект, содержащий параметры конфигурации, которые вам нужно приме нить. Создав GPO, вы связываете его с доменом, сайтом или OU. Если вы применяете GPO на уровне сайта или домена, он влияет на большее коли чество объектов, чем на уровне OU. Однако при этом у вас меньше возможностей по управлению каждым объектом индивидуально. Объекты, к которым применяются па раметры, заданные в GPO, можно фильтровать, но фильтрация может привести к из лишнему усложнению, поэтому ее следует использовать только в определенных случа ях, но не в качестве общепринятого подхода. Гораздо лучше с самого начала продумать, как эффективнее применять GPO. Свя зывание GPO с OU как раз и дает такую схему применения. Создавая GPO для OU, вы управляете применением групповой политики гораздо эффективнее, поскольку отпа дает необходимость в фильтрации параметров групповой политики. Однако необходимо тщательное планирование. Создание GPO для OU означает, что придется управлять большим числом GPO. Возможны конфликты между GPO, посколь ку OU бывают вложенными, а групповая политика наследуется от родительских OU; таким образом, к объекту в зависимости от места, которое он занимает в иерархии OU, могут применяться несколько GPO. После того как вы создали структуру OU, управляющую делегированием админи стративных полномочий в домене, в этой структуре можно создать дополнительные OU, управляющие применением групповой политики. Например, если верхний уро вень вашей структуры OU основан на объектах и вы создали OU, содержащую учетные записи пользователей, можно разделить этот OU на несколько OU более низкого уров ня для пользователей, к которым применяются другие параметры групповой политики. Проектируя структуру OU, управляющую применением групповой политики, старай тесь соблюдать следующие принципы. • Планируйте структуру OU так, чтобы использовать как можно меньше GPO. Чем больше GPO связано с каким-либо объектом, тем больше времени потребуется пользователям, чтобы войти в сеть. • Создавайте OU верхнего уровня, основанные на объектах или задачах, а затем со здавайте OU более низких уровней, управляющие групповой политикой. • Создавайте дополнительные OU, чтобы обойтись без фильтрации для изъятия груп пы пользователей из OU, связанной с GPO.
Контейнеры и OU по умолчанию При установке Active Directory создается несколько контейнеров и OU, используемых по умолчанию. • Контейнер Домен (Domain). Корневой контейнер в иерархии Active Directory. Ад министративные разрешения, применяемые к этому контейнеру, могут влиять на дочерние контейнеры и объекты всего домена. Не делегируйте полномочия на уп равление этим контейнером — им должны управлять администраторы служб. • Контейнер Встроенный (Built-in). Содержит учетные записи администраторов служб, используемые по умолчанию. • Контейнер Пользователи (Users). Применяемое по умолчанию хранилище учетных записей новых пользователей и групп, создаваемых в домене. Также не следует изменять разрешения на доступ к этому контейнеру, действующие по умолчанию. Если требуется делегировать управление определенными пользователями, создайте новые OU и перенесите в них объекты пользователей. Кроме того, с контейнером
Занятие 1
Проектирование структуры организационных единиц
Пользователи (Users) нельзя связать GPO. Чтобы применить групповую политику к пользователям, вы также должны создать OU и перенести в них пользователей. • Контейнер Компьютеры (Computers). Применяемое по умолчанию хранилище но вых учетных записей компьютеров, создаваемых в домене. Как и в случае контей нера Пользователи (Users), чтобы назначить разрешения или GPO компьютерам, следует создать OU. • OU Контроллеры домена (Domain Controllers). Здесь по умолчанию хранятся учет ные записи компьютеров — контроллеров домена. К этому OU по умолчанию при меняется ряд политик. Чтобы обеспечить единообразие применения этих политик ко всем контроллерам домена, рекомендуется не переносить объекты-компьютеры, являющиеся контроллерами домена, из этого OU. По умолчанию этим OU управля ют администраторы служб. Не делегируйте управление этим OU пользователям, которые не являются администраторами служб. Используемые по умолчанию контейнеры управляются администраторами служб, и рекомендуется оставить управление ими в руках этих администраторов. Если вам нужно делегировать управление объектами, содержащимися в каталоге, создайте новые OU и перенесите объекты в эти OU. Делегируйте управление этими OU соответствующим ад министраторам. Это позволит делегировать управление объектами в каталоге, не изме няя настройки по умолчанию, задающие, что управление осуществляют администрато ры служб.
Планирование наследования Каждый OU по умолчанию наследует разрешения, заданные для родительского OU. Ана логично объекты, содержащиеся в OU, наследуют разрешения, заданные для этого OU (и для каждого из его родителей). Наследование — эффективный способ предоставить или делегировать разрешения на доступ к объектам. Преимущество наследования в том, что администратор может управлять разрешениями на доступ ко всем объектам в OU, задавая разрешения для самого OU, а не конфигурируя все дочерние объекты по отдель ности. По сути, администратор может задавать разрешения на доступ к самому объекту, к объекту и его потомкам, только к потомкам или только к потомкам определенных ти пов (например к компьютерам и пользователям). При создании структуры OU следует в полной мере применять наследование. Логи чески упорядочивайте OU так, чтобы получить простую структуру, в которой механизм наследования выполняет за вас большую часть работы. Но бывают ситуации, где наследование препятствует решению нужных задач. Вам может потребоваться, чтобы некоторые разрешения на доступ к объекту переопределяли разрешения, наследуемые объектом от родителей. В таком случае заблокируйте наследо вание разрешений, применяемых к родительской OU, чтобы они не распространялись на дочернюю OU.
Стандартные модели структуры 0U Создание структуры OU может оказаться сложной задачей. К счастью, есть несколько стандартных моделей, которые можно взять за основу для своего проекта. Каждая мо дель описывает категории OU и отношения, связывающие OU друг с другом. Существует пять базовых моделей структуры OU: • на основе местонахождения; • на основе структуры организации;
11Q
Проектирование административной структуры защиты
Глава 4
на основе функций; смешанная — сначала по местонахождению, а затем по структуре организации; смешанная — сначала по структуре организации, а затем по местонахождению. Примечание Модели OU, описанные в этом разделе, подходят для большинства слу чаев и, вероятно, вы столкнетесь с ними на экзамене. Однако вы, конечно, не обяза ны использовать при проектировании структуры OU только эти модели. См. Microsoft Windows Server 2003 Deployment Kit, входящий в набор Microsoft Resource Kit (Micro soft Press, 2003), и статьи по развертыванию Active Directory no ссылке http://www.micwsoft. com/technet.
Модель на основе местонахождения В модели OU на основе местонахождения (рис. 4-5) административные полномочия рас пределены между несколькими филиалами, расположенными в разных местах. Эта мо дель полезна, когда у каждого филиала свои требования к администрированию, отлич ные от требований других филиалов.
Встроенный (Builtin) Компьютеры (Computers) Контроллеры домена (Domain Controllers) Пользователи (Users) Даллас Мемфис JS2L KLf
Учетные записи пользователей Учетные записи компьютеров
Рис. 4-5. В модели OU на основе местонахождения административные полномочия поделены по территориальному признаку
•
Модель на основе местонахождения дает ряд преимуществ, в том числе: OU устойчивы к изменениям. Структура ресурсов или отделов компании может измениться, а географическая структура, как правило, более постоянна;
Занятие 1
Проектирование структуры организационных единиц
-J -J ^
• для центрального ИТ-отдела не составляет труда реализовать общедоменные поли тики; • легче определить, где находятся ресурсы; • проще создать новые OU при расширении компании или ее слиянии с другой компа нией. Но у этой модели есть и недостатки, в частности: • структура основана на географическом местонахождении, следовательно, предпола гается, что в каждом филиале имеются администраторы сетей; • архитектура не соответствует бизнес-структуре или административной структуре. Примечание Назначение объектов групповой политики сайтам (обычно выполняемое по территориальному признаку) обеспечивает во многом такие же преимущества, что и модель OU на основе местонахождения, но лишено ее недостатков. Подробнее о проек тировании сайтов — в главе 5.
Модель на основе структуры организации В модели OU на основе структуры организации (рис. 4-6) административные полномо чия распределены между отделами или бизнес-подразделениями, в каждом из которых имеется собственный администратор. Эта модель полезна, когда у компании есть четкая структура отделов.
А А
/ / /
\ Домен (Domain;
\ \ Встроенный (Builtin) Компьютеры (Computers) Контроллеры домена (Domain Controllers) Пользователи (Users) Отдел исследований и разработок Отдел маркетинга
Отдел продаж Рис. 4-6. В модели OU на основе структуры организации административные полномочия поделены между отделами или бизнес-подразделениями
112
Проектирование административной структуры защиты
Глава 4
Модель на основе структуры организации дает ряд преимуществ, в том числе: обеспечивает определенный уровень автономии для каждого отдела или бизнес-под разделения; • поддерживает слияния и расширения; а удобна администраторам, поскольку понятна любому сотруднику компании. Однако у модели на основе структуры организации есть серьезный недостаток. Эта структура уязвима при реорганизациях. Из-за изменений в структуре отделов может потребоваться изменение верхнего уровня структуры OU. •
Модель на основе функций В модели OU на основе функций (рис. 4-7) административный персонал децентрализо ван и использует модель управления, основанную на бизнес-функциях, существую щих в организации. Это идеальный выбор для малых компаний, в которых ряд бизнесфункций выполняется несколькими отделами одновременно.
Встроенный (Builtin) Компьютеры (Computers) Контроллеры домена (Domain Controllers) Пользователи (Users) Проектирование __ Снабжение *y>j ^JSILI
Исследования
Транспортировка
Рис. 4-7. В модели OU на основе функций административные полномочия поделены в соответствии с бизнес-функциями Значительное преимущество модели на основе функций — ее относительная устой чивость к реорганизациям. Но у этой модели тоже есть существенный изъян. Скорее всего она потребует создать дополнительные уровни OU, чтобы делегировать административное управление пользо вателями, компьютерами, принтерами и сетевыми каталогами.
Проектирование структуры организационных единиц
Занятие 1
"ИЗ
Смешанная модель — сначала по местонахождению, затем по структуре организации В этой модели (рис. 4-8) сначала создаются OU верхнего уровня, представляющие гео графические участки, на которых находятся филиалы компании, а потом — OU более низкого уровня, представляющие структуру организации.
I . _ ,'- Встроенный (Builtin) 1 .._„_. —LllSL'
Компьютеры (Computers) Контроллеры домена (Domain Controllers) Пользователи (Users)
Go,I Даллас >J
Мемфис Отдел продаж j
Отдел маркетинга
Рис. 4-8. Смешанная модель OU — сначала по местонахождению, затем по структуре организации Эта модель обладает двумя преимуществами: поддерживает дальнейший рост числа подразделений и отделов; позволяет создавать различные зоны безопасности. Но у данной смешанной модели есть и некоторые недостатки: • при реорганизации административного персонала скорее всего придется пересмо треть структуру; • необходимо взаимодействие между администраторами, работающими в разных отде лах одного филиала.
• •
114
Проектирование административной структуры защиты
Глава 4
Смешанная модель — сначала по структуре организации, затем по местонахождению В этой модели (рис. 4-9) сначала создаются OU верхнего уровня, представляющие орга низационную структуру компании, а потом — OU более низкого уровня, представляю щие территориальные участки.
/ / Домен .'Domain)
Встроенный (Builtin) Компьютеры (Computers) Контроллеры домена (Domain Controllers) Пользователи (Users) Отдел исследований и разработок Отдел маркетинга Сан-Франциско 5У
Форт-Уорт
Рис. 4-9. Смешанная модель OU — сначала по структуре организации, затем по местонахождению У этой модели одно существенное преимущество: она позволяет обеспечить надеж ную защиту на уровне отделов и подразделений и в то же время делегировать админи стративные полномочия в зависимости от местонахождения. Но у нее, как и у модели на основе структуры организации, есть недостаток — уязви мость к реорганизациям.
Лабораторная работа. Проектирование структуры OU На этой лабораторной работе вы создадите структуру OU для компании Northwind Traders. Если вы не сумеете ответить на вопрос, повторите материал занятия и попы тайтесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы.
Занятое 1
Проектирование структуры организационных единиц
115
Сценарий Компания Northwind Traders производит линейку сетевых устройств, расширяющих воз можности в передаче данных. Сейчас Northwind Traders использует основную модель юменов Microsoft Windows NT 4.0 (master domain model). В последние годы компания значительно расширилась и ожидает дальнейшего существенного роста в следующие три года, в том числе увеличения своей доли рынка, доходов и численности сотрудников. Помимо открытия двух новых офисов, администрация решила реализовать новый про ект Windows Server 2003 Active Directory, отвечающий текущим и будущим потребно стям компании. В следующей таблице перечислены территории, отделы на каждой территории и ко личество пользователей. Территория
Отделы
Число пользователей
Париж
Администрация в штаб-квартире Финансы Продажи Маркетинг Производство Исследования Разработка ИТ
2000
Лос-Анджелес
Продажи Маркетинг Финансы ИТ
1000
Атланта
Обслуживание клиентов Техническая поддержка клиентов Обучение
750
Етазго, Шотландия
Исследования Разработка Долгосрочные проекты ИТ
750
Сидней, Австралия
Консалтинг Производство Продажи Финансы
500
Для совместимости с предыдущей структурой доменов у сотрудников некоторых от делов имеются учетные записи в удаленных доменах. В следующей таблице приведена информация о том, в каких доменах содержатся учетные записи таких сотрудников. Пользователи
Учетные записи пользователей в домене
Все сотрудники отделов продаж и маркетинга
NAwest
Все сотрудники производственных отделов
AsiaPacific
Все сотрудники исследовательских отделов и отделов разработки (R&D)
Glasgow
Все сотрудники финансовых отделов
Corp
•j -j g
Проектирование административной струетуры защиты
Глава 4
Компания Northwind Traders уже выбрала структуру лесов и доменов, показанную на следующей схеме. RDNwtraders.local
NWtraders.local
Л Glasgow Asia Pacific
NAeast
Лес R&D
NAwest
Corp
Лес NWTraders
Вопросы к лабораторной работе Исходя из приведенной выше структуры лесов и доменов создайте структуру OU для компании Northwind Traders. Для описания структуры воспользуйтесь следующей таб лицей. Домен
Организационные единицы
nwtraders. local Corp.nwtraders.local NAwest.nwtraders.local NAeast.nwtraders.local Glasgow. RDNwtraders .local AsiaPacific. nwtrade rs. local
Закрепление материала Ответив на вопросы, приведенные ниже, вы сможете лучше усвоить основные темы за нятия. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытайтесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы. 1. По каким трем причинам следует создавать OU? Какая из этих трех причин влияет на проект OU в целом? 2. Чем отличается структура OU на основе объектов от структуры OU на основе задач? 3. Вы планируете структуру каталога. Одно из требований — возможность делегировать управление пользователями, назначая групповую политику. Что вы должны сделать? 4. Каковы преимущества модели OU на основе местонахождения? В чем ее недостатки?
Резюме •
•
Создавайте структуру OU, облегчающую делегирование управления администрато рам, а также поиск ресурсов и учетных записей. Можно создать административную структуру, основанную на объектах или на задачах. OU создаются для того, чтобы делегировать административное управление, ограни чить видимость объектов и управлять применением групповой политики. Сначала
Занятие 2
Планирование стратегии управления учетными записями
сосредоточьте усилия на делегировании административных полномочий, затем до бейтесь, чтобы структура соответствовала другим требованиям. • Создавайте OU верхнего уровня так, чтобы они отражали сравнительно неизменную сторону деятельности предприятия, например территориальную структуру, админи стративные задачи или объекты, а затем используйте OU более низкого уровня для более тонкого разграничения административных полномочий. • Наследование позволяет передавать разрешения между уровнями структуры. Бло кируйте наследование, если вам нужно переопределить разрешения, наследуемые от родителя.
Занятие 2. Планирование стратегии управления учетными записями После проектирования структуры OU следующий шаг в создании административного плана — выработка стратегии управления учетными записями. На этом занятии вы узна ете, как планировать учетные записи пользователей, компьютеров и групп. Изучив материал этого занятия, вы сможете:
•S рассказать о типах учетных записей, доступных в Active Directory; •S определить стратегию управления учетными записями пользователей; •/ выработать стратегию реализации групп. Продолжительность занятия - около 25 минут.
Типы учетных записей Учетная запись в Active Directory — это список атрибутов, определяющих участника системы безопасности (security principal), например пользователя или группу пользова телей. В Active Directory можно создать пять типов учетных записей, перечисленных ниже. В этой главе в основном рассматриваются учетные записи компьютеров, пользо вателей и групп. в Компьютер. Всякий раз, когда в домен добавляется компьютер под управлением Microsoft Windows NT, Windows 2000, Windows XP или Windows Server 2003, для него создается учетная запись компьютера. Учетные записи компьютеров служат для аутен тификации компьютеров, которые обращаются к сети и ресурсам домена. • Пользователь. Учетная запись пользователя — это набор атрибутов для пользовате ля. Объект-пользователь хранится в Active Directory и позволяет пользователю вхо дить в сеть. Пользователь должен указать удостоверения (имя и пароль) только один раз, затем ему предоставляются соответствующие разрешения на доступ к сетевым ресурсам. • Группа. Это набор пользователей, компьютеров или других групп, для которого мож но задать разрешения. Задавая разрешения группам и добавляя члены в эти группы, можно сэкономить время, поскольку не приходится назначать разрешения каждому отдельно взятому члену группы.
•j •$ g
Проектирование адаинистративной структуры защиты
Глава 4
•
InetOrgPerson. Учетная запись InetOrgPerson работает во многом аналогично учет ной записи пользователя за исключением того, что учетные записи InetOrgPerson совместимы с другими службами каталогов, основанными на LDAP (Lightweight Directory Access Protocol). Это обеспечивает совместимость между Active Directory и другими системами. • Контакт. Объект, который хранится в Active Directory, но для которого не задаются разрешения. То есть контакт нельзя использовать для входа в сеть или доступа к ре сурсам. Часто контакты связывают с пользователями, работающими вне сети, кото рым отправляет сообщения почтовая система.
Планирование учетных записей компьютеров Учетные записи компьютеров позволяют применять к компьютерам, входящим в до мен, во многом такие же средства защиты, как и для пользователей. Эти учетные запи си дают возможность выполнять аутентификацию компьютеров — членов домена про зрачным для пользователей образом, добавлять серверы приложений как рядовые сер веры (member servers) в доверяемые домены и запрашивать аутентификацию пользова телей или служб, которые обращаются к этим серверам ресурсов. Так как разрешается помещать учетные записи компьютеров в OU и назначать им групповую политику, вы можете управлять тем, как выполняется аутентификация и обеспечивается защита компьютеров различных типов. Например, для компьютеров, установленных в общедоступном информационном киоске, действуют другие требова ния безопасности, чем для рабочих станций, установленных в управляемой среде с огра ниченным доступом. Всякий раз, когда в домен добавляется новый компьютер, создается новая учетная запись компьютера. Таким образом, еще одна составляющая стратегии управления учет ными записями — определение пользователей, которые вправе добавлять компьютеры в домен, создавая их учетные записи. Кроме того, необходимо продумать соглашение об именовании компьютеров. Хо рошее соглашение должно позволять без труда идентифицировать компьютер по вла дельцу, местонахождению, типу или любой комбинации этих данных. Например, имя DAL-SVR1, присвоенное серверу, расположенному в Далласе, идентифицирует место нахождение и тип компьютера. Имя BPOTTER1, которое присвоено серверу, принад лежащему Барри Поттеру (Barry Potter), идентифицирует основного пользователя это го компьютера.
Планирование учетных записей пользователей Учетные записи пользователей позволяют идентифицировать пользователей, входящих в сеть, задавать, к каким ресурсам они вправе обращаться, и указывать всевозможную информацию о пользователях. Администраторы — тоже пользователи, но с более широ кими правами доступа к ресурсам, связанным с управлением сетью. Группы служат для того, чтобы формировать наборы пользователей, для которых нужно задать одни и те же требования к безопасности или права доступа. Учетные записи пользователей предоставляют пользователям возможность входить в домен или на локальный компьютер и обращаться к ресурсам. Объекты учетных записей пользователей содержат информацию о пользователях и связывают с ними определенные привилегии или ограничения. Каждый объект Active Directory связан со
Занятие 2
Планирование стратегии управлений учетными записями
списком управления доступом (Access Control List, ACL), который представляет собой список разрешений на доступ к объекту, заданных для пользователей и групп.
Типы учетных записей пользователей В Windows Server 2003 существует два основных типа учетных записей пользователей. • Локальные учетные записи пользователей. Создаются в базе данных защиты локаль ного компьютера и управляют доступом к ресурсам этого компьютера. Локальные учетные записи пользователей предназначены для управления доступом к изолиро ванным компьютерам или к компьютерам, входящим в рабочую группу. Когда вы только что установили операционную систему на сервер, используются локальные учетные записи, управление которыми осуществляется через консоль Управление компьютером (Computer Management) в узле Локальные пользователи и группы (Local Users and Groups). Если вы сделаете сервер контроллером домена, инструмент Управ ление компьютером запретит доступ к этому узлу, и вместо него будет использовать ся инструмент Active Directory — пользователи и компьютеры (Active Directory Users and Computers) (учетные записи пользователей на контроллерах домена хранятся в Active Directory). • Доменные учетные записи пользователей. Создаются в Active Directory и дают воз можность пользователям входить в домен и обращаться к любым ресурсам сети. Вы можете создать доменную учетную запись пользователя с помощью Active Directory — пользователи и компьютеры (Active Directory Users and Computers). Такие учетные записи пользователей реплицируются на все контроллеры в домене, поэтому после репликации любой контроллер домена сможет аутентифицировать пользователя.
Встроенные учетные записи пользователей Windows автоматически создает несколько учетных записей пользователей, называе мых встроенными. И на локальных компьютерах, и в доменах создается две ключевых учетных записи: Администратор (Administrator) и Гость (Guest). Учетная запись Администратор обладает наибольшими возможностями, поскольку она автоматически включается в группу Администраторы (Administrators). Члены этой группы имеют высший уровень прав по управлению компьютером, им предоставляются почти все пользовательские права. Учетная запись Администратор уровня домена дает максимум возможностей по управлению доменом в целом; по умолчанию она включа ется в группу Администраторы домена (Domain Admins) [а администратор корневого домена леса, кроме того, входит в группы Администраторы предприятия (Enterprise Admins) и Администраторы схемы (Schema Admins)]. Учетную запись Администратор нельзя удалить, но ее можно переименовать (и это следует сделать для большей безо пасности). Также следует задать для этой учетной записи непустой пароль и не переда вать его другим пользователям. Учетная запись Гость (Guest) — еще одна базовая встроенная учетная запись пользо вателя. Она предназначена для того, чтобы администратор мог задать единый набор раз решений для любых пользователей, которые иногда входят в сеть, но не имеют обычной учетной записи. Учетная запись Гость позволяет это сделать, так как автоматически включается в локальную группу Гости (Guests). В среде, где есть домен, эта учетная запись также включается в группу Гости домена (Domain Guests). По умолчанию учет ная запись Гость отключена. И действительно, ее следует использовать только в сетях,
120
Проектирование административной структуры защиты
Глава 4
не требующих особой защиты. Эту учетную запись нельзя удалить, но можно отключить и/или переименовать.
Именование учетных записей пользователей Тщательное планирование схемы именовании учетных записей пользователей позволяет стандартизировать идентификацию пользователей домена. Единое соглашение также облегчает распознавание и запоминание имен пользователей. Есть несколько правил, которые нужно соблюдать при планировании стратегии име нования пользователей. • У каждого пользователя должно быть имя для входа (логин), уникальное в домене. Полное имя пользователя также должно быть уникальным в OU, в которой хранится его учетная запись. • Имена пользователей для входа могут содержать более 20 символов, но для совмести мости с ОС, предшествовавшими Windows 2000, следует ограничить длину 20 симво лами. Имена пользователей для входа нечувствительны к регистру букв. В ОС, пред шествовавших Windows 2000, имена пользователей не должны были содержать сле дующие символы: " / \ [ ] : ; | = , + * ? < >. • Какое соглашение вы бы ни выбрали, оно должно быть достаточно гибким, чтобы учитывать ситуацию, когда у двух пользователей получаются одинаковые имена для входа. Например, если в вашем соглашении имя для входа формируется по фами лии и первой букве имени пользователя и есть два пользователя, у которых в этом случае оказываются одинаковые имена для входа, может потребоваться добавить в имя для входа первую букву отчества или даже вторую букву имени. • Принимайте во внимание совместимость с другими приложениями. В некоторых приложениях вроде систем электронной почты в именах пользователей недопусти мы некоторые другие символы или установлены иные ограничения на длину. Существует много разных соглашений, применимых при создании имен, и у каждого администратора или проектировщика сети есть свои предпочтения. Однако хорошее со глашение об именовании должно быть таким, чтобы имена для входа легко запомина лись и чтобы можно было различать сотрудников с похожими именами.
Планирование политики управления паролями Пароли — один из наиболее важных аспектов сетевой безопасности, поэтому полити ку определения паролей пользователей необходимо тщательно продумать. В Windows Server 2003 по умолчанию действуют более строгие ограничения на пароли, чем в предыдущих версиях. Например, в Windows Server 2003 имеется новое средство, про веряющее сложность пароля учетной записи Администратор (Administrator). Если па роль пустой или недостаточно сложный, Windows предупреждает, что использовать нестойкий пароль опасно. Оставив пароль пустым, вы не сможете обращаться к учет ной записи через сеть. Надежная политика управления паролями гарантирует, что пользователи в полной мере соблюдают принципы задания паролей, установленные компанией. При планиро вании политики управления паролями следует соблюдать ряд правил. • Задайте значение параметра политики, указывающее, что запоминаются как мини мум 24 последних пароля. Благодаря этому пользователи не смогут применять лишь несколько паролей, указывая один из них по истечении срока действия очередного пароля.
Занята© 2
Планирований стратегии управления учетными записями
•
Требуйте, чтобы пользователи меняли свои пароли через определенные периоды времени. Microsoft рекомендует ограничить срок использования одного пароля 42 днями, и в Windows Server 2003 это ограничение действует по умолчанию. Благодаря этому человек, который узнал пароль, не сможет получить доступ в сеть, после того как срок действия пароля истечет. Администраторы должны менять свои пароли чаще, чем обычные пользователи. • Заданный пароль должен сохраняться определенное число дней, чтобы пользовате ли не могли быстро менять пароли до тех пор, пока не подберут пароль, который им по вкусу. Microsoft рекомендует хранить пароль минимум один день. • Пароли должны быть длиной не менее семи символов. Длинные пароли сложнее взломать, чем короткие. • Пароли должны быть сложными. Они должны состоять из строчных и прописных букв, цифр и других символов.
Выработка стратегии аутентификации Важно, чтобы контроллеры домена могли проверять идентификацию пользователя или компьютера, прежде чем предоставить соответствующий доступ к системным и сетевым ресурсам. Эта проверка называется аутентификацией и выполняется всякий раз, когда пользователь входит в сеть. При выработке стратегии аутентификации примите следующие меры. • Создайте политику блокировки учетных записей. Политика блокировки учетных за писей отключает учетную запись пользователя, если число неудачных попыток входа достигло определенного значения. Это не позволяет проводить так называемые сло варные атаки, при которых программа автоматически проверяет один пароль за дру гим. Однако политика блокировки учетных записей должна допускать хотя бы не сколько попыток входа, чтобы не блокировать легальных пользователей, у которых возникли проблемы с запоминанием или вводом сложных паролей. Пользователям следует предоставить минимум пять попыток ввода пароля. Кроме того, нужно за дать период, в течение которого блокируется учетная запись, и время, по истечении которого после неудачной попытки входа счетчик попыток сбрасывается. • Ограничьте время, в которое разрешен вход, чтобы сотрудники могли использовать компьютеры только в рабочее время. Эту политику следует применять как при инте рактивном входе (когда пользователь работает за компьютером), так и при входе че рез сеть. Задание времени, когда разрешен вход, особенно полезно, когда компью теры доступны большому количеству сотрудников, и при работе в несколько смен. Ограничение времени, в которое разрешен вход, может быть необходимо для полу чения некоторых правительственных сертификатов безопасности. • Создайте политику истечения срока действия билетов (tickets). Когда пользователь входит в сеть, клиентскому компьютеру назначается билет, используемый им для аутентификации при доступе к сетевым ресурсам. Срок действия билета должен быть достаточно длительным, чтобы пользователи не испытывали неудобств, но достаточ но коротким, чтобы злоумышленники не успели получить доступ к билету и извлечь хранящиеся в нем удостоверения. В параметре GPO домена по умолчанию (Default Domain GPO) задан срок действия билета 10 часов, отлично подходящий для боль шинства сетей. Уменьшение срока действия повышает безопасность, но увеличива ет сетевой трафик из-за выдачи дополнительных билетов.
122
Проектирование административной отрусгуры защиты
Глава 4
•
Требуйте, чтобы администраторы входили в свои системы как обычные пользовате ли. Администраторы должны входить под учетными записями обычных пользовате лей и выполнять административные операции с помощью команды Запуск от имени (Run As). На контроллеры домена или другие серверы администраторы должны вхо дить по учетным записям администраторов. Также ограничьте число пользователей, входящих в группу Администраторы (Administrators). Вместо этого делегируйте ад министративные полномочия учетным записям администраторов с помощью OU. * Переименуйте и отключите встроенные учетные записи Администратор (Admi nistrator) и Гость (Guest). Поскольку это общеизвестные учетные записи, их часто атакуют злоумышленники.
Планирование групп Группы упрощают предоставление разрешений пользователям. Например, назначить разрешения группе и добавить пользователей в эту группу гораздо проще, чем по отдель ности назначать разрешения многочисленным пользователям и управлять этими разре шениями. Когда пользователи входят в группу, для изменения того или иного разреше ния всех этих пользователей достаточно одной операции. Как и в случае учетных записей пользователей, группы бывают локальные и уровня домена. Локальные группы хранятся в базе данных защиты локального компьютера и предназначены для управления доступом к ресурсам этого компьютера. Группы уровня домена хранятся в Active Directory и позволяют помещать в них пользователей и управ лять доступом к ресурсам домена и его контроллеров. В этой главе рассматриваются до менные группы.
Типы групп При создании группы в Windows Server 2003 необходимо указать ее тип и предполагае мую область действия. В Windows два типа групп. • Группы безопасности (security groups). Служат для объединения пользователей до мена в одну административную единицу. Группам безопасности можно назначать разрешения; кроме того, их можно использовать как списки распространения элект ронной почты. Пользователи, помещаемые в эту группу, наследуют разрешения груп пы в течение всего времени, пока они остаются ее членами. Сама Windows исполь зует только группы безопасности. • Группы распространения (distribution groups). Используются программным обеспе чением, отличным от Windows, в целях, не связанных с защитой. Одно из их основ ных применений — использование сервером электронной почты в качестве списков рассылки. Группам распространения нельзя назначать разрешения.
Области действия групп Области действия групп задают, в какой части леса Active Directory доступна данная группа и какие объекты в нее можно поместить. В Windows Server 2003 группы в зави симости от области действия делятся на три типа: глобальные, локальные в домене и универсальные. • Глобальные группы объединяют пользователей, которым требуется предоставить оди наковые разрешения. Глобальные группы имеют следующие характеристики: а могут содержать учетные записи пользователей и компьютеров только того до мена, в котором создана эта группа;
Занятие 2 •
а
Планирование стратегии управления учетными записями
когда функциональный уровень домена установлен как основной режим Windows 2000 или Windows Server 2003 (т. е. домен содержит только серверы Windows 2000 или 2003), глобальные группы могут, кроме того, включать другие глобальные группы локального домена; глобальным группам можно назначать разрешения или добавлять в локальные группы любого домена в данном лесу.
•
Локальные группы домена существуют на контроллерах домена и используются для управления доступом к ресурсам, содержащимся на контроллерах локального доме на (для рядовых серверов и рабочих станций вместо локальных групп домена ис пользуются локальные группы на этих компьютерах). Локальные группы домена имеют следующие характеристики: а в любом режиме работы домена локальные группы домена могут включать пользо вателей и глобальные группы из любого домена леса; • когда домен работает в основном режиме Windows 2000 или Windows Server 2003, локальные группы домена могут также включать другие локальные группы до мена и универсальные группы.
•
Универсальные группы обычно служат для назначения разрешений на доступ к соот ветствующим ресурсам нескольких доменов. Универсальные группы имеют следую щие характеристики: а доступны, только когда режимом работы леса является основной режим Windows 2000 или Windows Server 2003; • существуют вне границ доменов и управляются серверами глобального каталога; • служат для назначения разрешений на доступ к соответствующим ресурсам не скольких доменов; • могут включать пользователей, глобальные группы и другие универсальные группы любого домена леса; • универсальной группе можно предоставить разрешение на доступ к любому ре сурсу любого домена.
В табл. 4-1 перечислено, какие элементы могут содержать группы с разными обла стями действия в доменах, работающих в смешанном или основном режиме. Табл. 4-1.
Области действия групп и их функциональность
Область
Элементы, которые группа может содержать, когда домен работает в основном режиме Windows 2000 или Windows Server 2003
Элементы, которые группа может содержать, когда домен работает в режиме более низкого уровня
Глобальная (G)
Учетные записи пользователей и гло бальные группы локального домена
Пользователи и компьютеры того же домена
Локальная в домене (DL)
Учетные записи пользователей, универсальные группы и глобальные группы любого домена; локальные группы того же домена
Пользователи и компьютеры любого домена
Универсальная (U) Учетные записи пользователей, универсальные и глобальные группы любого домена
В доменах, работающих на более низких функциональных уровнях, нельзя создавать универсальные группы
124
Проектирование административной структуры защиты
Глава 4
Вложение групп Active Directory позволяет вкладывать группы (т. е. помещать одни группы в другие). Вложение групп — эффективный способ упорядочения пользователей. Например, в че тырех филиалах у вас есть администраторы низшего звена (рис. 4-10). Тогда можно со здать отдельную группу для каждого филиала (с именем типа Dallas Junior Admins). За тем создать общую группу Junior Admins и сделать группы «младших администраторов» каждого филиала членами обшей группы. Такой подход позволяет задать разрешения для одной группы и передать их членам этой группы, в то же время разделив админист раторов на группы в соответствии с филиалами. При вложении групп стремитесь к тому, чтобы уровень вложения был минималь ным. В сущности, лучше ограничиться одним уровнем вложения. Чем глубже вложе ние, тем сложнее поддерживать структуру разрешений.
Рис. 4-10. Пример вложения групп
Именование групп Как и в случае учетных записей пользователей, при именовании групп нужно следовать определенному соглашению. Продуманное соглашение об именовании дает возможность пользователям и администраторам тратить меньше сил на идентификацию и запомина ние групп, а также облегчает управление членством в группах. При разработке соглашения об именовании групп учтите, что: • имя каждой группы домена должно быть уникальным в этом домене; • имена групп могут содержать до 64 символов; • некоторые символы нельзя использовать в именах групп в операционных системах, предшествовавших Windows 2000. К недопустимым символам относятся: " / \ [ ] :; ] = , + *?; • имена групп нечувствительны к регистру букв, но Windows сохраняет их регистр.
Взаимодействие пользователей и групп Итак, вы ознакомились с доступными типами и областями действия групп и планирова нием учетных записей пользователей. Теперь пора посмотреть, какое место занимают пользователи и группы в стратегии управления учетными записями.
Занятие 2
.
Планирование стратегии управления учетными записями
-f 2 5
При использовании групп рекомендуется соблюдать следующие принципы. Избегайте выдачи разрешений учетным записям пользователей. Назначение разре шений группам позволяет получить более гибкую и простую в управлении структуру разрешений. Для этого нужно тщательно продумать структуру групп. • Создайте локальные группы домена, представляющие ресурсы контроллера домена, для которых вы хотите задать права доступа и то, как будут использоваться эти ресур сы. Назначьте соответствующие разрешения для ресурсов группы. Если ресурсы хра нятся на рядовом сервере или рабочей станции домена, используйте локальные груп пы вместо локальных групп домена. • Чтобы упорядочить пользователей, создавайте глобальные группы. Например, мож но создать группу Executives («высшее руководство»). • Помещайте глобальные группы в локальные группы домена. • Не включайте пользователей в универсальные группы. Помещайте их только в гло бальные группы. Это позволит избежать репликации объектов в глобальный каталог. Универсальные группы служат только для хранения глобальных групп с одинаковы ми требованиями. Конечно, никто не может заставить вас следовать этим рекомендациям, но на прак тике вы сами будете заинтересованы в их соблюдении. Понимание этих принципов про веряется на экзамене. Следующая последовательность операций вкратце описывает рекомендуемую стратегию управления группами безопасности. 1. Поместите учетные записи пользователей в глобальные группы. 2. Поместите глобальные группы в универсальные. 3. Поместите универсальные группы в локальные группы домена. 4. Назначьте разрешения локальным группам домена. •
Подготовка к экзамену Принципы использования групп, рекомендуемые Microsoft, мож но запомнить с помощью простого сокращения: AGUDLP. Учетные записи (accounts, A) помещают в глобальные группы (global groups, G), глобальные группы — в универсаль ные (universal groups, U), а те — в локальные группы домена (domain local groups, DL), которым назначают разрешения (permissions, P). Это сокращение можно запомнить с помощью фразы «All Good Users Do Love Permissions» («все хорошие пользователи обо жают разрешения»).
Лабораторная работа. Планирование стратегии управления учетными записями На этой лабораторной работе вы изучите требования, которые необходимо выполнить при планировании стратегии управления учетными записями. Вспомните компанию, в которой вы работаете (или работали раньше) и опишите, каковы в ней требования к стра тегии управления учетными записями. Чтобы мыслить в верном направлении, ответьте на следующие вопросы; ответы зависят от вашего опыта. 1. Какие соглашения об именовании применяются в вашей организации? 2. Какие требования к паролям действуют в вашей организации? 3. Какие стратегии управления группами используются в вашей сети?
Проектирование административной структуры защиты
Глава 4
Закрепление материала Ответив на вопросы, приведенные ниже, вы сможете лучше усвоить основные темы за нятия. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытайтесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы. 1. Какие пять типов учетных записей можно создать в Active Directory для Windows Server 2003? 2. Вы создаете политику управления паролями. Какие требования к паролям рекомен дуется ввести? 3. По какой стратегии рекомендуется помещать пользователей в группы безопасности?
Резюме • •
•
•
н
В Windows Server 2003 в Active Directory существует пять типов учетных записей: пользователь, компьютер, группа, контакт и InetOrgPerson. Учетные записи компьютеров позволяют компьютерам, входящим в домен, прохо дить аутентификацию прозрачным для пользователей образом. Следует выработать стратегию именования учетных записей компьютеров и определить, кто имеет пра во добавлять учетные записи компьютеров в Active Directory. Учетные записи пользователей идентифицируют пользователей и позволяют выпол нять их аутентификацию при доступе к сетевым ресурсам. Стратегия управления учетными записями пользователей должна включать в себя продуманное соглаше ние об именовании, политику управления паролями и политику аутентификации. Группы упрощают назначение разрешений, позволяя упорядочить пользователей. Область действия группы задает, в каких частях Active Directory доступна эта груп па и какие объекты могут стать ее членами. По области действия группы делятся на глобальные, универсальные и локальные группы домена. Включая пользователей в группы, помните, что учетные записи пользователей по мещают в глобальные группы, глобальные группы — в универсальные, а те — в локальные группы домена, которым и назначают разрешения.
Занятие 3. Планирование реализации групповой политики Групповая политика — мощное и эффективное средство, позволяющее задать парамет ры сразу для нескольких пользователей и компьютеров. Кроме того, групповая полити ка применяется для распространения и обновления ПО в организации. На этом занятии вы ознакомитесь с применением групповой политики в Windows Server 2003 и изучите стратегии создания эффективной структуры групповой политики. Изучив материал этого занятия, вы сможете:
•S описать, как работает групповая политика и дня чего она предназначена; •S рассказать о том, как комбинируются объекты групповой политики (GPO); •S выбрать стратегию реализации групповой политики в организации. Продолжительность занятия — около 40 минут.
Занятие 3
Планирование реализации групповой ПОЛИТИКИ
-{27
Введение в групповую политику Групповая политика — набор параметров конфигурации пользователей и компьютеров, который можно связать с компьютерами, сайтами, доменами и OU в Active Directory. Такой набор параметров групповой политики называется объектом групповой политики (Group Policy Object, GPO). Любой компьютер под управлением Windows 2000, Windows ХР или Windows Server 2003 (независимо от того, входит он в Active Directory или нет) содержит один локаль ный GPO, в котором заданы политики, применяемые к этому компьютеру. Если ком пьютер входит в Active Directory, к нему можно применить несколько дополнительных GPO, не являющихся локальными. Существует два основных типа параметров групповой политики. •
Конфигурация компьютера (Computer Configuration) используется для задания груп повых политик, применяемых к определенным компьютерам независимо от того, кто входит на них.
•
Конфигурация пользователя (User Configuration) предназначена для задания группо вых политик, применяемых к определенным пользователям независимо от того, на какой компьютер они входят. Какие бы параметры вы ни настраивали (компьютера или пользователя), есть три их категории: Параметры программ (Software Settings), Параметры Windows (Windows Settings) и Административные шаблоны (Administrative Templates).
Параметры программ Узел Параметры программ (Software Settings) содержит параметры, которые можно ис пользовать для развертывания ПО на клиентских компьютерах, к которым применяется групповая политика. Для этого клиентские компьютеры должны работать под управле нием Windows 2000 Professional, Windows 2000 Server, Windows ХР Professional, Windows XP 64-Bit Edition или Windows Server 2003 и быть членами домена. Вы можете задать, для каких пользователей или на какие компьютеры будет установлено ПО, при необходимо сти указать обновления и даже удалить ПО. Для поддержки этой функции нужны два взаимодействующих компонента. •
•
Служба установки Windows (Windows Installer service) — служба, которая разверты вает и обновляет ПО в соответствии с инструкциями в установочных пакетах Win dows (Windows Installer packages) (см. ниже).
Установочные пакеты Windows (Windows Installer Packages) — исполняемые файлы сценариев со всеми инструкциями, нужными Windows Installer для установки, об новления или восстановления ПО. Файлы Windows Installer Package имеют расши рение msi. Служба Windows Installer отслеживает состояние устанавливаемого приложения. Эта информация может использоваться для переустановки приложения, восстановления от сутствующих или поврежденных файлов и удаления больше не нужного приложения. Существует два способа развертывания ПО с помощью групповой политики: пу бликация (publishing) и назначение (assigning). Когда приложение назначается пользова телю, создается ярлык, доступный пользователю и показываемый в меню Пуск (Start) или на рабочем столе этого пользователя. Это называется предложением (advertising) приложения пользователю. Когда пользователь щелкает ярлык (или открывает файл, связанный с программой), запускается программа установки. Когда приложение на-
128
Проектирование административной структуры защиты
Глава 4
значается компьютеру, приложение устанавливается при первом запуске компьютера после назначения. Если вы публикуете приложение, оно становится доступным пользователям, кото рые могут установить его, когда пожелают. Приложения можно публиковать только для пользователей — сделать это для компьютера нельзя. Приложение становится доступ ным в апплете Установка и удаление программ (Add/Remove Programs) панели управле ния (Control Panel) и устанавливается по запросу пользователя, если тот откроет файл, связанный с программой.
Параметры Windows Категория Параметры Windows (Windows Settings) предназначена для изменения ряда параметров конфигурации, связанных со средой Windows. • Сценарии (Scripts). При настройке конфигурации компьютера можно задать сце нарии, которые выполняются при его включении или выключении. При настройке конфигурации для пользователя можно задать сценарии, выполняемые при входе или выходе пользователя. Сценарии можно писать на любое языке сценариев с поддержкой ActiveX, в том числе на VBScript, JScript, Perl, языке командных фай лов MS-DOS и др. • Параметры безопасности (Security Settings). Это параметры безопасности, задава емые для компьютеров и пользователей. • Настройка Internet Explorer (Internet Explorer Maintenance). Этот узел доступен толь ко для пользователей. Он служит для управления работой Internet Explorer на клиен тских компьютерах. • Службы удаленной установки (Remote Installation Services, RIS). RIS позволяет ав томатически выполнять удаленную установку операционной системы на новые кли ентские компьютеры. Эти параметры тоже доступны только для конфигураций пользователей. Они управляют удаленной установкой операционных систем. и Перенаправление папок (Folder Redirection). И эти параметры доступны только для конфигураций пользователей. Они позволяют переопределить специальные папки Windows [такие как Мои документы (My Documents), Главное меню (Start Menu) и Application Data], изменив их местонахождение по умолчанию на сетевой каталог. Благодаря этому можно централизованно управлять папками пользователей. Административные шаблоны Категория Административные шаблоны (Administrative Templates), доступная для конфи гураций компьютеров и пользователей, содержит все параметры групповой политики, хранящиеся в реестре. Параметры этой категории перечислены в табл. 4-2. Табл. 4-2. Параметры категории Административные шаблоны Узел
Конфигурация компьютера
Конфигурация Описание пользователя
Панель управления (Control Panel) Рабочий стол (Desktop)
Неприменимы
X
Определяет средства панели управ ления, доступные пользователю
Неприменимы
X
Задает внешний вид рабочего стола пользователя
Занятие 3 Табл. 4-2.
Планирование реализации групповой политики
-|29
(окончание)
Узел
Конфигурация компьютера
Конфигурация пользователя
Описание
Сеть (Network)
X
X
Управляет параметрами для средств Автономные файлы (Offline Files) и Сеть и удаленный доступ к сети (Network and Dial-Up Connections)
Принтеры (Printers)
X
Неприменимы
Задает параметры принтеров
Панель задач и меню «Пуск» (Start Menu and Taskbar)
Неприменимы
X
Задает параметры конфигурации для меню Пуск и панели задач пользователя
Система (System)
X
X
Управляет входом/выходом (для пользователей), запуском/выключе нием (для компьютеров) и самими групповыми политиками
Компоненты Windows X (Windows Components)
X
Управляет встроенными компонентами Windows вроде Проводника (Windows Explorer), Internet Explorer и Windows Installer
Разрешение GPO из нескольких источников Поскольку GPO, применяемые к пользователю или компьютеру, могут поступать из не скольких источников, нужен способ определения того, как эти GPO сочетаются друг с другом. GPO обрабатываются в следующем порядке. • Локальный GPO — обрабатывается локальный GPO компьютера и применяются все параметры защиты, заданные в этом GPO. • GPO сайта — обрабатываются GPO, связанные с сайтом, к которому относится ком пьютер. Параметры, заданные на этом уровне, переопределяют любые параметры, заданные на предыдущем уровне, с которыми они конфликтуют. Если с сайтом связано несколько GPO, администратор сайта может задать, в каком порядке обра батываются эти GPO. • GPO домена — обрабатываются GPO, связанные с доменом, к которому относится компьютер, и применяются содержащиеся в них параметры. Параметры, заданные на уровне домена, переопределяют параметры, примененные на локальном уровне или на уровне сайта, с которыми они конфликтуют. Если с доменом связано не сколько GPO, администратор, как и в предыдущем случае, может задать порядок их обработки. • GPO OU — обрабатываются GPO, связанные с любыми OU, содержащими пользо вателя или компьютер. Параметры, заданные на уровне OU, переопределяют пара метры, примененные на локальном уровне или уровне домена/сайта, с которыми они конфликтуют. Один и тот же объект может входить в несколько OU. В этом случае сначала обрабатываются GPO, связанные с OU, находящимся на самом высоком уровне иерархии Active Directory, затем — с OU, находящимся на следу ющем уровне и т.д. Если с одной OU связано несколько GPO, администратор, как и в предыдущих случаях, может задать порядок их обработки.
130
Проектированиеадминистративнойструктуры защиты
Глава 4
Подготовка к экзамену Простой способ запомнить порядок, в котором обрабатываются GPO, — усвоить, что сначала обрабатывается локальный GPO, затем — GPO, опреде ленные в Active Directory. Обработка GPO из Active Directory начинается с самой дале кой от пользователя структуры (сайта), затем идет более близкая к пользователю струк тура (домен) и, наконец, самая близкая структура (OU).
Наследование групповой политики По умолчанию дочерние контейнеры наследуют групповую политику от родительских контейнеров. Однако можно переопределить унаследованные параметры, задав для до чернего объекта другие значения параметров. Кроме того, в GPO можно задать, что тот или иной параметр активен, неактивен или не определен. Параметры, которые не опре делены для родительского контейнера, вообще не наследуются дочерними контейнера ми, а параметры, которые активны или неактивны, наследуются. Если GPO определены и для родителя, и для потомка и если заданные в них пара метры совместимы, эти параметры комбинируются. Например, если в родительской OU задана определенная длина пароля, а в дочерней OU — некая политика блокировки учетных записей, будут использоваться оба этих параметра. Если параметры несовме стимы, то по умолчанию с дочерним контейнером связывается значение параметра, переопределяющее значение параметра, который связан с родительским контейнером. Совет На вкладке Общие (General) окна свойств GPO можно отключить неиспользуе мые параметры конфигурации компьютера или пользователя, содержащиеся в GPO. В большинстве политик задействована лишь часть доступных параметров. Если неис пользуемые параметры включены, они все равно обрабатываются, что приводит к лиш нему расходу системных ресурсов. Отключив неиспользуемые параметры, вы снизите нагрузку на клиентские компьютеры, обрабатывающие политику.
Конечно, описанное выше наследование применяется только по умолчанию. Име ется еще два механизма, применяемых при управлении наследованием групповых по литик. • Не перекрывать (No Override). Когда вы связываете GPO с контейнером, можно выбрать Не перекрывать, чтобы параметры, заданные в этом GPO, не переопределя лись параметрами в GPO, связанных с дочерними контейнерами. Это гарантирует, что для дочерних контейнеров будет применяться заданная вами политика. • Блокировать наследование политики (Block Policy Inheritance). При выборе этого п раметра контейнер не наследует параметры GPO, заданные для родительского кон тейнера. Однако, если для родительского контейнера указан параметр Не перекры вать, дочерний контейнер не может заблокировать наследование от своего родителя. Эти два механизма — весьма существенные исключения из правил наследования, но к ним следует прибегать только в редких случаях. Гораздо лучше создать продуман ный проект групповых политик, используя OU, с которыми групповые политики свя зываются при необходимости, а не создавать систему исключений, где так легко запу таться.
Занятие 3
Планирование реализации групповой ПОЛИТИКИ
-jg-j
Подготовка к экзамену Отвечая на вопросы по групповой политике, помните о прави~ах наследования. Также помните, как объединяются параметры групповой политики: сначала применяется локальный GPO, затем — GPO домена, сайта и OU. Наконец, не сбудьте, что GPO нельзя напрямую связывать с пользователями, группами или встро енными контейнерами. GPO можно связать только с сайтом, доменом или OU. Фильтрация GPO с помощью разрешений Одна из потенциальных проблем использования групповых политик может возникнуть, если вам нужно, например, связать GPO с OU, содержащей 500 пользователей и 20 групп, но вы не хотите, чтобы параметры применялись ко всем этим объектам. Чтобы не применять политику к пользователю или группе, можно изменить на стройку разрешений для этих пользователей. Для применения политики необходимы "вз разрешения: Чтение (Read) (вполне логично: если политику нельзя прочитать, ее нельзя и применить) и Применение групповой политики (Apply Group Policy), название поторого говорит само за себя. Чтобы политика не применялась к пользователю или группе, можно изменить разрешения, запретив чтение или применение этой политики.
Планирование структуры GPO При реализации групповой политики сначала создают GPO, затем связывают их с сай тами, доменами и OU. Может потребоваться применение некоторых GPO на уровне томенов или сайтов, но в большинстве случаев следует применять GPO на уровне OU. Связывание GPO с доменом GPO, связанный с доменом, применяется ко всем пользователям и компьютерам доме на. Поскольку это мощная политика, следует свести к минимуму количество GPO этого уровня. Типичное применение GPO уровня домена — реализация корпоративных стан дартов. Например, в компании может действовать стандартное требование, состоящее в том, что ко всем компьютерам и пользователям должна применяться одна и та же поли тика управления паролями и аутентификацией. В этом случае применение GPO уровня томена было бы отличным решением. Связывание GFO с сайтом GPO связывают с сайтами очень редко, поскольку гораздо эффективнее связывать GPO с OU, структура которых основана на территориальном делении. Но при опреде ленных обстоятельствах связывание GPO с сайтом — приемлемое решение. Если пара метры должны быть общими для всех компьютеров, физически находящихся в опреде ленном месте, и для этого места создан сайт, есть смысл связать GPO с сайтом. Напри мер, для компьютеров, расположенных в некоем филиале, нужно задать определенную сетевую конфигурацию с поддержкой подключения к Интернету. В этом случае иде ально подходит GPO, связанный с сайтом.
132
Проектирование административной структуры защиты
Глаеа 4
Связывание GPO с 0U В большинстве случаев лучше связывать GPO с хорошо продуманной структурой OU, чем с сайтами или доменами. OU обеспечивают наибольшую гибкость, поскольку по зволяют спроектировать структуру, хотя бы отчасти упрощающую применение группо вой политики. Кроме того, OU гибче в администрировании. Вы можете без проблем перемещать пользователей и компьютеры между OU, изменять структуру OU и даже переименовывать сами OU. На заметку По умолчанию новые учетные записи пользователей и компьютеров со здаются в контейнерах Пользователи (Users) и Компьютеры (Computers) соответственно. Вы не можете связать GPO с одним из этих встроенных контейнеров. Несмотря на то, что встроенные контейнеры наследуют GPO, связанные с доменом, вы можете столк нуться с ситуацией, когда учетные записи пользователей и компьютеров требуется хра нить в OU, с которыми можно связать GPO. В Windows Server 2003 есть два новых инструмента, позволяющих изменять целевое местонахождение, где по умолчанию сохраняются новые учетные записи пользовате лей и компьютеров. Утилита redirusr.exe перенаправляет учетные записи пользователей, а redircomp.exe — учетные записи компьютеров. После выбора OU, в которую пере направляются записи, новые учетные записи создаются прямо в новой целевой OU, с которой можно связать соответствующие GPO. Например, можно создать OU с име нем New Users, связать с этой OU соответствующий GPO и задать, что новые учетные записи пользователей будут помещаться в OU «New Users». Тогда к любым новым пользо вателям сразу же после создания будут применяться параметры, заданные в GPO. В дальнейшем администраторы могут переместить новые учетные записи пользовате лей в более подходящее место. Вы найдете эти два инструмента в папке %windir%\system32 любого компьютера, рабо тающего под управлением Windows Server 2003. Подробнее об этих средствах — в статье 324949 «Redirecting the Users and Computers Containers in Windows Server 2003 Domains» на сайте Microsoft Knowledge Base по ссылке http:/support.microsoft.com.
Планирование развертывания GPO Важным аспектом планирования групповой политики для компании является создание плана управления групповой политикой после первоначального развертывания. При со здании этого плана нужно определить пользователей, управляющих групповой полити кой организации. Кроме того, требуется обеспечить, чтобы клиентские компьютеры, работающие в сети, принимали параметры, задаваемые GPO.
Администрирование групповой политики Скорее всего задачи, связанные с созданием и управлением GPO, следует делегировать различным администраторам организации. Вы должны, основываясь на административ ной модели вашей организации, определить, какие параметры управления конфигура цией лучше задавать на уровне домена, сайта или OU. Также определите, как на каждом из уровней сайта, домена и OU осуществить дальнейшее деление полномочий между администраторами или их группами этого уровня.
Занятие 3
Планирование реализации групповой ПОЛИТИКИ
-jgg
Решая, как делегировать полномочия на уровне сайта, домена или OU, примите во внимание следующие соображения. • Полномочия, делегируемые на уровне домена, влияют на все объекты домена, если задано наследование разрешений всеми дочерними контейнерами. • Полномочия, делегируемые на уровне OU, могут влиять только на эту OU или на OU и ее дочерние OU. • Управление разрешениями будет более простым и эффективным, если назначать полномочия на как можно более высоких уровнях OU. • Полномочия, делегируемые на уровне сайта, вероятно, охватывают несколько до менов и могут влиять на объекты в доменах, отличных от того, который содержит GPO. Чтобы управлять GPO, администраторам нужны следующие разрешения: • для редактирования GPO, связанных с сайтами, — разрешения на администрирова ние предприятия; • для редактирования GPO, связанных с доменами, — разрешения на администриро вание домена; • для редактирования GPO, связанных с OU, — разрешения на администрирова ние OU.
Требования к клиентам, поддерживающим групповую политику Для принятия параметров групповой политики клиентские компьютеры должны быть членами Active Directory. Основные операционные системы обладают следующими воз можностями по поддержке групповой политики. • Windows 95/98/Ме не поддерживают групповую политику. • Windows NT 4.0 и более ранних версий не поддерживает групповую политику. • Windows 2000 Professional и Server поддерживают многие параметры групповой поли тики, доступные в Windows Server 2003, но не все. Неподдерживаемые параметры иг норируются. • Windows XP Professional, Windows XP 64-bit Edition и Windows Server 2003 полностью поддерживают групповую политику. Примечание Более подробную информацию о том, как Windows 2000 Professional под держивает параметры групповой политики, заданные в Windows Server 2003, — в Micro soft Windows Server 2003 Deployment Kit (Microsoft Press, 2003).
Лабораторная работа. Проектирование реализации групповой политики На этой лабораторной работе вы приведете структуру организационных единиц (OU) в соответствие с требованиями к групповой политике компании Northwind Traders. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытайтесь отве тить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы.
134
Проектирование административной структуры защиты
Глава 4
Сценарий Northwind Traders проектирует инфраструктуру Active Directory. Компания уже опреде лила структуру OU. Эта структура показана в следующей таблице. Домены
OU
Nwtraders.local
Нет HQ Management Finance IT
Corp.nwtraders.local
NAwest.nwtraders. local
Sales Marketing IT
NAeast. nwtraders. local
Customer Service Customer Support Training Glasgow.RDNwtraders.local Development Sustained Engineering IT
AsiaPacific.nwtraders.local
Research
Consulting Production
В следующей таблице перечислены филиалы, отделы в них и требования групповой политики, специфичные для каждого филиала. Филиал
Отделы
Требования групповой политики
Париж
Основной офис Финансы Продажи Маркетинг Производство Исследования Разработки ИТ
Высшее руководство работает с конфиденциальной информацией, поэтому для портативных компью теров всех менеджеров высшего звена требуется задать особые параметры защиты. Однако они не хотят, чтобы эти параметры применялись к их настольным компьютерам. Все серверы финансового отдела должны исполь зовать IPSec при любой коммуникационной связи
Лос-Анд желес
Продажи Маркетинг Финансы ИТ
На компьютеры всех сотрудников отдела продаж необходимо установить приложение, работающее с данными о клиентах. На всех портативных компьютерах этого филиала необходимо установить экранную заставку с защитой по паролю
Атланта
Обслуживание клиентов Техническая поддержка клиентов Обучение
Все сотрудники отдела поддержки клиентов, работающие в центре обработки телефонных звонков, используют специальные приложения, которые необходимо установить на их компьютеры
Занятие 8
Планирование реализации групповой политики
(окончание) Филиал
Отделы
Требования групповой политики
Глазго, Исследования Шотландия Разработки Долгосрочные проекты ИТ
Ко всем компьютерам, даже к только что добавленным в домен, должна применяться политика IPSec. Для всех компьютеров исследовательского отдела необходимо задать специфичные параметры защиты
Сидней, Австралия
Все компьютеры производственного отдела используются разными сотрудниками, работаю щими в несколько смен. У каждого из пользова телей, входящих в эти системы, должны быть свои параметры рабочего стола и пользовательского интерфейса
Консалтинг Производство Продажи Финансы
Вопросы Исходя из этого сценария, измените структуру OU так, чтобы она отвечала требовани ям к групповой политике компании. Ответьте на следующие вопросы. 1. Какие дополнительные OU нужно создать для поддержки групповой политики? 2. Кто будет управлять групповой политикой в каждом из доменов?
Закрепление материала Ответив на вопросы, приведенные ниже, вы сможете лучше усвоить основные темы за нятия. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытайтесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы. 1. К каким объектам можно применять параметры групповой политики? Какие типы параметров можно применять при использовании групповой политики? 2. В каком порядке разрешаются GPO из нескольких источников? Что будет, если свя зать несколько GPO с одним контейнером Active Directory? 3. Вы планируете GPO, который будет связан с OU, содержащей учетные записи пользо вателей и групп. Вы хотите, чтобы параметры, заданные в GPO, применялись ко всем учетным записям, входящим в OU, за исключением учетных записей двух групп. Как это сделать?
Резюме •
•
Групповая политика позволяет применять параметры сразу ко многим пользовате лям и компьютерам. Групповую политику можно использовать, чтобы развертывать и обновлять ПО на клиентских компьютерах, настраивать и применять параметры Windows и распространять параметры, помещаемые в реестр, с помощью Админи стративных шаблонов (Administrative Templates). При планировании групповой политики нужно определить, какие настройки требу ется выполнить на клиентах и как лучше всего это сделать. Можно связывать GPO с доменами, сайтами и OU. Следует свести к минимуму количество GPO, связан-
138
•
:
Проектирование административной структуры защиты
Глааа 4
ных с доменами и сайтами. Большинство GPO следует связывать с хорошо проду манной структурой OU. При планировании структуры OU в полной мере используйте наследование GPO. Запомните: лучше не планировать слишком глубокую структуру, поскольку каждый GPO, применяемый к клиенту, тратит дополнительные системные ресурсы. Также помните, что можно блокировать наследование GPO, связанных с родителем, или задать параметр Не перекрывать (No Override), запрещающий дочерним объектам блокировать или переопределять GPO, унаследованные от родителя. С помощью фильтрации разрешений можно запретить применение GPO к определенным объектам.
Пример из практики
Вам поручили планирование административной структуры для компании Humongous Insurance, предоставляющей услуги по медицинскому страхованию на территории США. На всех серверах корпоративной сети операционную систему недавно обновили до Windows Server 2003 Enterprise Edition. На клиентских компьютерах работают операци онные системы Windows NT Professional 4.0, Windows 2000 Professional и Windows XP Professional. Компания Humongous Insurance наняла вас для того, чтобы вы спроектиро вали структуру OU, учетных записей и групповой политики.
Краткие сведения о компании Humongous Insurance выросла за последние несколько лет и стала одной из ведущих компаний по медицинскому страхованию, обслуживающей многие частные и государ ственные организации США.
География Главный офис корпорации Humongous Insurance расположен в Лос-Анджелесе (штат Калифорния). Помимо главного офиса, у Humongous Insurance имеются основные кор поративные офисы в Буффало (штат Нью-Йорк) и Далласе (штат Техас). Существуют также сотни филиалов, разбросанных по всем пятидесяти штатам. Во всех трех основ ных офисах имеются полностью укомплектованные сотрудниками ИТ-отделы, поддер живающие структуру сетей этих офисов. ИТ-отдел в главном офисе корпорации в ЛосАнджелесе выполняет управленческие функции и в конечном счете несет ответствен ность за все решения и директивы, связанные с работой сети. Кроме того, ИТ-отдел в Лос-Анджелесе поддерживает сети филиалов.
Сетевая инфраструктура Офисы в Буффало, Далласе и Лос-Анджелесе связаны между собой 1-мегабитными ли ниями Frame Relay. Филиалы соединены каналами разных типов и пропускной способ ности. Сеть настроена на использование одного домена humongousinsurance.com. Для офи сов в Буффало, Далласе и Лос-Анджелесе созданы собственные сайты — так же, как и для каждого из филиалов. Это решение приняли в основном для управления трафиком репликации по WAN-каналам.
Резюме главы
-j^j
ИТ-менеджмент ИТ-отдел в Лос-Анджелесе определяет структуру и политику для сети в целом. Кроме того, он напрямую управляет филиалами. ИТ-отделы в Буффало и Далласе управляют сетями своих офисов. Однако за работу сети в целом отвечает главный ИТ-отдел в ЛосАнджелесе.
Требования ИТ-отдел в Лос-Анджелесе установил ряд стандартов, которым должны следовать все филиалы. Учетные записи компьютеров, являющихся серверами, должны описывать местонахождение компьютера и его функцию. Учетные записи компьютеров, являющих ся рабочими станциями, должны описывать пользователя и местонахождение компью тера. Применяется строгая политика управления паролями. Пароли необходимо менять раз в месяц, в течение 12 месяцев пароль нельзя использовать повторно. Если удостове рения пользователя неправильно вводятся более 5 раз подряд, учетная запись пользова теля отключается до тех пор, пока он не свяжется с администратором. Кроме того, ИТ-персонал хотел бы использовать групповую политику, чтобы стан дартизировать развертывание ПО, устанавливаемого через сеть на определенные ком пьютеры. При этом желательно, чтобы пользователям при установке не приходилось принимать слишком много решений. В идеале хотелось бы, чтобы установка выполня лась автоматически без ввода данных пользователем.
Вопросы Исходя из этого сценария, ответьте на следующие вопросы. 1. Обрисуйте структуру OU компании, используя модель на основе местонахождения. Какие преимущества и недостатки у такой модели? 2. Какие параметры политики управления паролями вы задали бы, чтобы выполнить корпоративные требования компании? Какую политику аутентификации вы бы ис пользовали? 3. Какую стратегию именования учетных записей компьютеров вы применили бы для серверов сети? А для рабочих станций пользователей? 4. Какой метод развертывания ПО с помощью групповой политики вы выбрали бы в данном случае?
Ц Резюме главы •
Создавайте структуру OU, облегчающую делегирование управления администрато рам, а также поиск ресурсов и учетных записей. Можно создать административную структуру, основанную на объектах или на задачах. • OU создаются для того, чтобы делегировать административное управление, ограни чить видимость объектов и управлять применением групповой политики. Сначала сосредоточьте усилия на делегировании административных полномочий, затем до бейтесь, чтобы структура соответствовала другим требованиям. • Создавайте OU верхнего уровня так, чтобы они отражали сравнительно неизменную сторону деятельности предприятия, например территориальную структуру, админи-
138
•
• •
•
•
•
•
•
•
Проектирование административной структуры защиты
Гяаеа 4
стративные задачи или объекты, а затем используйте OU более низкого уровня для более тонкого разграничения административных полномочий. Наследование позволяет передавать разрешения между уровнями структуры. Бло кируйте наследование, если вам нужно переопределить разрешения, наследуемые от родителя. В Windows Server 2003 в Active Directory существует пять типов учетных записей: пользователь, компьютер, группа, контакт и InetOrgPerson. Учетные записи компьютеров позволяют компьютерам, входящим в домен, прохо дить аутентификацию прозрачным для пользователей образом. Следует выработать стратегию именования учетных записей компьютеров и определить, кто имеет право добавлять учетные записи компьютеров в Active Directory. Учетные записи пользователей идентифицируют пользователей и позволяют выпол нять их аутентификацию при доступе к сетевым ресурсам. Стратегия управления учет ными записями пользователей должна включать в себя продуманное соглашение об именовании, политику управления паролями и политику аутентификации. Группы упрощают назначение разрешений, позволяя упорядочить пользователей. Область действия группы задает, в каких частях Active Directory доступна эта группа и какие объекты могут стать ее членами. По области действия группы делятся на глобальные, универсальные и локальные группы домена. Включая пользователей в группы, помните, что учетные записи пользователей помещают в глобальные группы, глобальные группы — в универсальные, а те — в локальные группы домена, которым и назначают разрешения. Групповая политика позволяет применять параметры сразу ко многим пользовате лям и компьютерам. Групповую политику можно использовать, чтобы развертывать и обновлять ПО на клиентских компьютерах, настраивать и применять параметры Windows и распространять параметры, помещаемые в реестр, с помощью Админи стративных шаблонов (Administrative Templates). При планировании групповой политики нужно определить, какие настройки тре буется выполнить на клиентах и как лучше всего это сделать. Можно связывать GPO с доменами, сайтами и OU. Следует свести к минимуму количество GPO, связанных с доменами и сайтами. Большинство GPO следует связывать с хорошо продуманной структурой OU. При планировании структуры OU в полной мере используйте наследование GPO. Запомните: лучше не планировать слишком глубокую структуру, поскольку каждый GPO, применяемый к клиенту, тратит дополнительные системные ресурсы. Также помните, что можно блокировать наследование GPO, связанных с родителем, или задать параметр Не перекрывать (No Override), запрещающий дочерним объектам бло кировать или переопределять GPO, унаследованные от родителя. С помощью филь трации разрешений можно запретить применение GPO к определенным объектам.
Рекомендации по подготовке к экзамену
Ц Рекомендации по подготовке к экзамену Прежде чем сдавать экзамен, повторите основные положения и термины, приведенные ниже, чтобы выяснить, какие темы нужно проработать дополнительно.
Основные положения •
Следует начинать с создания структуры OU, эффективно делегирующей админи стративное управление. После создания этой структуры можно создать OU более низкого уровня, используемые для управления групповой политикой и скрытия объектов. • Помещая пользователей в группы, руководствуйтесь правилом AGUDLP. Учетные записи (accounts, А) помещаются в глобальные группы (global groups, G), глобаль ные группы — в универсальные (universal groups, U), а те — в локальные группы домена (domain local groups, DL), которым назначаются разрешения (permissions, P). • Сначала обрабатывается локальный GPO, затем, начиная с самой далекой от пользо вателя структуры, обрабатываются GPO в Active Directory. GPO обрабатываются в следующем порядке: локальный, GPO сайта, GPO домена, GPO OU. • Наконец, запомните, что GPO нельзя напрямую связывать с пользователями, груп пами или встроенными контейнерами. GPO можно связать только с сайтом, доме ном или OU.
Основные термины Модель OU ~ OU model — существует пять стандартных моделей организационных еди ниц (OU): 1) на основе местонахождения, 2) на основе структуры организации, 3) на основе функций, 4) сначала по местонахождению, затем по структуре организации и 5) сначала по структуре организации, затем по местонахождению. Учетная запись - account — в Windows Server 2003 можно создавать учетные записи пяти типов: учетные записи пользователей (позволяющие входить в сеть), учетные записи компьютеров (позволяющие проходить аутентификацию в Active Directory), учетные записи групп (позволяющие упорядочивать пользователей и другие группы, чтобы назначать им разрешения), контакты (описывают пользователей, находящих ся за пределами сети) и InetOrgPerson (работают аналогично учетным записям пользователей; совместимы с другими службами каталогов, основанными на LDAP). Групповая политика ~ Group Policy — упрощает развертывание ПО и настройку Windows на клиентских компьютерах. Создайте набор параметров, определяемый объектом групповой политики (GPO), а затем свяжите GPO с доменом, сайтом или OU.
140
Проектирование административной структуры защиты
Щ
Вопросы и ответы
Глаза 4
Занятие 1. Лабораторная работа Исходя из утвержденной структуры лесов и доменов создайте структуру QU для компа нии Northwind Traders. Для описания структуры воспользуйтесь следующей таблицей. Домен
Организационные единицы
nwtraders.local
Нет
Corp.nwtraders.local
HQ Management (администрация в штаб-квартире) Finance (отдел финансов) IT (ИТ-отдел)
NAwest.nwtraders.local
Sales (отдел продаж) Marketing (отдел маркетинга) IT (ИТ-отдел)
NAeast.nwtraders.local
Customer Service (отдел обслуживания клиентов) Customer Support (отдел технической поддержки клиентов) Training (отдел обучения)
Glasgow.RDNwtraders.local
Research (отдел исследований) Development (отдел разработок) Sustained Engineering (отдел долгосрочных проектов) IT (ИТ-отдел)
AsiaPacific.nwtraders.local
Consulting (отдел консалтинга) Production (производственный отдел)
Занятие 1. Закрепление материала 1. По каким трем причинам следует создавать OU? Какая из этих трех причин влияет на проект OU в целом? Правильный ответ: OU создаются для делегирования административного управления объектами, для ограничения видимости объектов и для управления применением группо вой политики. Определяющее влияние на архитектуру OU оказывает делегирование ад министративных полномочий. 2. Чем отличается структура OU на основе объектов от структуры OU на основе задач? Правильный ответ: в структуре OU, основанной на объектах, административные полно мочия делегируются в зависимости от типа объектов, которые будут храниться в OU. В структуре OU, основанной на задачах, управление делегируется в зависимости от административных задач, которые требуется выполнять, а не от типа объектов, которые нужно администрировать. 3. Вы планируете структуру каталога. Одно из требований — возможность делегировать управление пользователями, назначая групповую политику. Что вы должны сделать? Правильный ответ: поскольку встроенный контейнер Users не является OU, связать GPO с этим объектом нельзя. Вы должны создать новую OU, поместить в нее пользова телей, а затем связать GPO с этой OU.
Вопросы и ответы
4. Каковы преимущества модели OU на основе местонахождения? В чем ее недостат ки? Правильный ответ: к преимуществам относятся большая устойчивость к реорганизаци ям компании, упрощение реализации общедоменных политик центральным ИТ-отделом, более простой поиск ресурсов, легкость создания новых OU для новых филиалов. К не достаткам относятся потенциальная сложность ограничения административных прав, вероятная потребность в наличии собственных администраторов в каждом филиале, воз можное отклонение проекта инфраструктуры от бизнес-структуры или административ ной структуры.
Занятие 2. Закрепление материала 1. Какие пять типов учетных записей можно создать в Active Directory для Windows Server 2003? Правильный ответ: можно создавать учетные записи компьютера, пользователя, группы, а также контакт и InetOrgPerson. 2. Вы создаете политику управления паролями. Какие требования к паролям рекомен дуется ввести? Правильный ответ: следует запоминать минимум 24 последних использовавшихся паро ля. Кроме того, требуйте, чтобы пользователи периодически меняли свои пароли. По умолчанию (и согласно рекомендациям Microsoft) это нужно делать каждые 42 дня. Па роль пользователя должен сохраняться хотя бы в течение одного дня — это не позволит пользователям быстро менять пароли, чтобы подобрать те пароли, которые им нравятся. Пароли должны быть длиной минимум семь символов и содержать буквы в верхнем и нижнем регистре, цифры и прочие символы. 3. По какой стратегии рекомендуется помещать пользователей в группы безопасности? Правильный ответ: поместите учетные записи пользователей в глобальные группы, гло бальные группы — в универсальные, а универсальные — в локальные группы домена. Назначьте разрешения локальным группам домена.
Занятие 3. Лабораторная работа 1. Какие дополнительные OU нужно создать для поддержки групповой политики? Правильные ответы: одним из возможных способов фильтрации объектов, к которым применяется групповая политика, является создание OTJ. Для достижения этой цели мож но выбрать и другой подход, например использовать группы безопасности. Создайте в OU «HQ Management» новую OU «Laptops» (портативные компьютеры). Эта OU будет содержать все учетные записи портативных компьютеров, принадлежащих высшему руководству. Создайте в домене NAwest новую OU «LaptopComputers», чтобы упростить применение параметров групповой политики ко всем портативным компьютерам этого филиала. Создайте в OU «Customer Support» новую OTJ «CallCenter» (центр обработки телефон ных звонков). Эта OTJ будет содержать все учетные записи компьютеров центра обра ботки. С его помощью вы без проблем примените к этим компьютерам специфичные параметры групповой политики. Создайте в домене Glasgow новую OU «ComputerAccounts» (учетные записи компьюте ров) и командой redircmp.exe задайте, что все новые учетные записи компьютеров будут создаваться в этой OU.
142
Проектированиеадминистративнойструктуры защиты
Глаза 4
2. Кто будет управлять групповой политикой в каждом из доменов? Правильный ответ: ИТ-отдел в Париже будет определять параметры групповой полити ки для филиалов в Атланте, Париже и Сиднее. В остальных филиалах параметрами груп повой политики будут управлять местные ИТ-отделы.
Занятие 3. Закрепление материала 1. К каким объектам можно применять параметры групповой политики? Какие типы параметров можно применять при использовании групповой политики? Правильный ответ: параметры групповой политики можно применять к пользователям и компьютерам, входящим в Active Directory. Групповую политику можно использовать для настройки развертывания и обновления ПО, настройки параметров Windows и распро странения настроек реестра с помощью Административных шаблонов (Administrative Templates). 2. В каком порядке разрешаются GPO из нескольких источников? Что будет, если свя зать несколько GPO с одним контейнером Active Directory? Правильный ответ: в первую очередь всегда разрешаются GPO локального компьютера, затем GPO в Active Directory. Сначала разрешаются GPO, связанные с сайтом, потом — GPO, связанные с доменом, и, наконец, GPO, связанные с OU. Если параметры совме стимы, они объединяются. Иначе каждый последующий GPO переопределяет параме тры, заданные GPO, который применялся до него. Если для одного контейнера задано несколько GPO, администратор может определить порядок, в котором они будут приме няться. 3. Вы планируете GPO, который будет связан с OU, содержащей учетные записи пользо вателей и групп. Вы хотите, чтобы параметры, заданные в GPO, применялись ко всем учетным записям, входящим в OU, за исключением учетных записей двух групп. Как это сделать? Правильный ответ: есть два варианта. Можно создать дочернюю OU в существующем OU и переместить в новую OTJ учетные записи этих двух групп. Затем можно переопре делить параметры, заданные GPO, или блокировать наследование этого GPO от роди тельского контейнера. Другой вариант — оставить эти две группы в той же OU и отфиль тровать GPO, удалив разрешение на чтение или применение GPO этими двумя группами.
Пример из практики 1. Обрисуйте структуру OU компании, используя модель на основе местонахождения. Какие преимущества и недостатки у такой модели? Правильный ответ: в модели на основе местонахождения можно было бы создать по од ной OU для каждого основного филиала и, возможно, еще одну OU, объединяющую все остальные филиалы. Группирование по филиалам дает несколько преимуществ: устойчи вость к реструктуризации компании, возможность централизованной реализации поли тик масштаба домена, более простой поиск ресурсов по их местонахождению. К недо статкам относится вероятная необходимость в наличии администраторов сети в каждом филиале и тот факт, что ваш проект не будет отражать административную структуру ком пании. 2. Какие параметры политики управления паролями вы задали бы, чтобы выполнить корпоративные требования компании? Какую политику аутентификации вы бы ис пользовали?
Вопросы и ответы
143
Правильный ответ: чтобы соблюсти требования к паролям, задайте параметры полити ки паролей — параметру Максимальный срок действия пароля (Maximum Password Age) присвойте значение 30 дней, а параметр Требовать неповторяемости паролей (Enforce Password History) установите в 12 паролей. Параметры по умолчанию обеспечивают до полнительную безопасность — они требуют, чтобы пароль был сложным и использовался минимум один день. Чтобы выполнить требования к аутентификации, можно создать по литику блокировки учетных записей, отключающую учетные записи после пяти неудач ных попыток ввода паролей. Можно ужесточить требования к аутентификации, задав время, в которое разрешен вход, и создав политику истечения срока действия билета (ticket expiration policy). 3. Какую стратегию именования учетных записей компьютеров вы применили бы для серверов сети? А для рабочих станций пользователей? Правильный ответ: серверы следует идентифицировать по местонахождению и функции. В идеале имя сервера должно указывать, что это сервер. Популярный способ — исполь зование в имени сокращения SRV. Местонахождение можно задать первыми тремя бук вами названия города (еще одно решение — указывать трехбуквенные коды аэропортов). Функции вы можете идентифицировать так, как считаете нужным, но ваша методика должна быть единой для всей сети. Например, имя компьютера SRV-DAL-EXCH означа ло бы, что это сервер, который установлен в Далласе и на котором выполняется Exchange Server. 4. Какой метод развертывания ПО с помощью групповой политики вы выбрали бы в данном случае? Правильный ответ: вы должны задать групповую политику, которая назначает приложе ния компьютерам. Когда приложение назначается компьютеру, оно устанавливается при первом запуске компьютера после назначения.
ГЛАВА
5
Планирование сайтов
Занятие 1 . Проектирование топологии сайтов
145
Занятие 2. Планирование контроллеров доменов
151
Занятие 3. Планирование стратегии репликации
161
Занятие 4. Разработка стратегии перехода
170
Темы экзамена • Проектирование инфраструктуры Active Directory в соответствии с бизнес-требова ниями и техническими условиями: а выработка стратегии репликации Active Directory. • Проектирование топологии сайтов Active Directory: а проектирование сайтов; а определение связей сайтов. • Планирование внедрения Active Directory: а планирование размещения контроллеров домена и серверов глобального ката лога; а назначение ролей хозяев операций; а создание контроллеров домена. • Выработка стратегии перехода на Active Directory: а определение вариантов перехода — обновление существующих доменов, изме нение структуры доменов или переход на новую среду Active Directory. В этой главе В главах 3 и 4 вы научились проектировать логическую часть инфраструктуры Active Directory. К ней относятся структура лесов и доменов, а также административная струк тура организационных единиц (OU), пользователей и групп. Прочитав эту главу, вы узнаете, как определять физическую структуру сети с помощью сайтов. Одна из основ ных задач при проектировании любых сетей — управление трафиком между удаленны ми филиалами по WAN-каналам, и сайты являются основным средством такого управ ления. В этой главе объясняется, как определить расположение сайтов и указать связи между ними. Кроме того, вы научитесь создавать проекты, в которых оптимизирована
Занетие 1
Проектирование ТОПОЛОГИЙ сайтов
внутрисайтовая и межсайтовая репликация. Вы узнаете, как размещать контроллеры доменов и планировать роли, назначаемые серверам. Наконец, вы изучите, как плани ровать стратегию перехода с предыдущих версий Windows. Прежде всего
Для усвоения материалов этой главы вы должны быть знакомы с концепциями Active Directory, изложенными в главе 1. Кроме того, вы уже собрали и проанализировали всевозможную информацию о существующей в вашей компании инфраструктуре Active Directory (об этом см. главу 2). Для проектирования топологии сайтов вам потребуются собранные ранее сведения о географической структуре и топологии сети компании.
Занятие 1. Проектирование топологии сайтов Первый этап разработки структуры сайтов — выбор их топологии, т. е. расположения сайтов и связей между ними. На этом занятии сначала рассматривается использование сайтов, затем описываются факторы, которые необходимо учитывать при проектирова нии топологии сайтов. Изучив материал этого занятия, вы сможете:
•S рассказать о том, как с помощью сайтов управляют сетевым трафиком, передаваемым по WAN-каналам; S задать границы сайтов на основе физической структуры сети; •S определить, как связаны сайты. Продолжительность занятия - около 20 минут.
Для чего нужны сайты Как вы помните из главы 1, сайт — это группа контроллеров домена, существующих в одной или нескольких IP-подсетях, связанных быстрым и надежным сетевым соеди нением. Поскольку сайты основаны на IP-подсетях, они обычно соответствуют тополо гии сети, а значит, соответствуют и географической структуре компании (рис. 5-1). Сайты соединяются с другими сайтами WAN-каналами. Сайты Active Directory позволяют отделить логическую организацию структуры ка талогов (структуры лесов, доменов и OU) от физической структуры сети. Сайты пред ставляют физическую структуру сети на основе Active Directory. Поскольку сайты не зависят от структуры доменов, в один домен может входить несколько сайтов или, наоборот, один сайт может содержать несколько доменов (рис. 5-2). Сайты не входят в пространство имен Active Directory. Пользователь, просматрива ющий логическое пространство имен, видит компьютеры и пользователей, сгруппиро ванных в домены и OU, но сайты при этом не показываются. Однако имена сайтов используются в записях DNS (Domain Name System), поэтому у сайтов должны быть допустимые DNS-имена. Если вы не конфигурируете в Active Directory собственные сайты, все контролле ры доменов автоматически входят в один сайт по умолчанию с именем Default-FirstSite-Name, который создается при создании первого домена. Сайты содержат объекты
146
Планирование сайтов
Глаза 5
Рис. 5-1. Простая топология сайтов на основе географической структуры
По одному сайту для каждого домена
Один сайт, охватывающий два домена
Один домен, содержащий два сайта
Рис. 5-2. Сайты и домены не зависят друг от друга только двух типов: контролеры доменов, входящие в сайт, и связи сайтов (site links), настраиваемые для соединения с другими сайтами. В целом, сайты служат для управления трафиком по WAN-каналам. А конкретнее, сайты используются для управления: • трафиком входа на рабочие станции; • трафиком репликации; • распределенной файловой системой (Distributed File System, DFS); • службой репликации файлов (File Replication Service, FRS).
Управление трафиком входа на рабочие станции Когда пользователь входит в сеть, компьютеры с Microsoft Windows 2000 или Microsoft Windows XP ищут контроллеры домена, принадлежащие тому же сайту, что и рабочая станция. В процессе входа контроллеры домена по IP-адресу клиента определяют, к какому сайту он относится, и возвращают ему информацию о сайте. Кроме того, кон троллер домена передает клиенту сведения о ближайшем контроллере домена. Эта ин формация кэшируется для дальнейшего использования, чтобы ускорить вход.
Занятие 1
Проектирование топологии сайтов
Использование контроллера домена, принадлежащего тому же сайту, позволяет из бежать ненужной передачи трафика аутентификации по WAN-каналам. Если там, где находится клиент, нет контроллера домена, клиент проходит аутентификацию на кон троллере домена, принадлежащем сайту, цена соединения с которым минимальна по сравнению с другими сайтами. В DNS создаются записи ресурса службы (SRV) с ин формацией о том, какой контроллер домена предпочтительнее при аутентификации компьютеров из каждого сайта.
Управление трафиком репликации В Active Directory применяется модель репликации с несколькими хозяевами (multimaster replication). В этой модели все копии БД Active Directory являются равноправными. Изменения, внесенные в БД Active Directory на любом контроллере домена, автома тически реплицируются на остальные контроллеры, входящие в этот домен. Внутри сайта контроллеры домена реплицируют изменения сразу после их внесения. Когда данные, хранящиеся на контроллере домена, изменяются, он уведомляет своих партнеров по репликации (остальные контроллеры в пределах сайта); тогда партнеры запрашивают эти изменения, и репликация выполняется почти сразу же. При реплика ции между контроллерами, принадлежащими одному и тому же сайту, данные переда ются в несжатом формате. Поскольку предполагается, что у соединения высокая про пускная способность, использование несжатого формата гарантирует максимально быстрое выполнение репликации (даже несмотря на генерацию дополнительного сете вого трафика). Репликация между сайтами выполняется немного иначе. При репликации между сайтами выделенный в каждом сайте контроллер домена собирает и сохраняет измене ния, внесенные в каталог, сжимает эту информацию и передает ее в соответствии с расписанием контроллеру домена, принадлежащему другому сайту. Репликация между сайтами оптимизируется так, чтобы повысить эффективность, а не скорость. На заня тии 3 вы подробнее ознакомитесь с тем, как выполняется репликация.
Управление топологией DFS DFS (Distributed File System) — серверный компонент, который поддерживает унифи цированную схему именования файлов и папок, хранящихся на различных серверах в сети. DFS позволяет создать логическую иерархию файлов и папок, единую для всей сети, независимо от того, где они находятся на самом деле. Файлы, представленные в DFS, могут храниться в разных местах сети, поэтому есть смысл в том, чтобы Active Directory могла направлять пользователей в ближайшее место, где находятся нужные им данные. В связи с этим DFS использует информацию о сайтах, чтобы направить клиент на сервер, который принадлежит тому же сайту и содержит запрашиваемые данные. Если DFS не удалось найти копию данные в сайте, к которому относится клиент, DFS использует информацию о сайтах, хранящуюся в Active Directory, чтобы определить, какой файловый сервер с общими данными, до ступными через DFS, находится ближе всего к клиенту. Примечание Подробнее о применении DFS в Windows Server 2003 — в документе «Simplifying Infrastructure Complexity with Windows Distributed File System» по ссылке http:/www. microsoft.com/windowsserver2003/techinfo/overview/dfs.mspx.
Плакирование сайтов
Глава 5
Управление FRS На каждом контроллере домена имеется встроенный набор папок с именем SYSVOL (сокращение от System Volume). В Active Directory в папках SYSVOL по умолчанию хранятся файлы, которые требуется реплицировать на другие серверы домена. SYSVOL можно использовать для репликации GPO, а также сценариев, выполняемых при за пуске, выключении, входе или выходе. FRS (File Replication Service) — это служба Windows Server 2003, которая выполняет репликацию файлов, содержащихся в папках SYSVOL, между контроллерами домена. При управлении репликацией данных, содер жащихся в папках SYSVOL, FRS использует структуру сайтов. Примечание Подробнее о службе FRS, входящей в Windows Server 2003, — в статье «Technical Overview of Windows Server 2003 File Services» по ссылке http://www.mkrosoft.com/windowsserver2003/techinfo/overview/file.mspx.
Выбор структуры сайтов Чтобы разработать эффективную топологию сайтов, вы должны прежде всего собрать информацию о физической структуре сети (см. главу 2). В частности, нужна следующая информация: • территориальное местонахождение филиалов компании; • структура и скорость локальной сети (LAN) каждого филиала; • сведения о TCP/IP-подсетях в каждом филиале; • общая и доступная пропускные способности WAN-соединений, связывающих фи лиалы друг с другом. Помимо информации о физической структуре сети, необходимы сведения о логи ческой архитектуре Active Directory — о плане лесов и доменов, административной иерархии. Следует также получить информацию о структуре DNS для Active Directory. Располагая всей этой информацией, вы сможете определить границы сайтов. Чаще всего сайты соответствуют территориальным подразделениям компании, поскольку в каждом из мест, где есть офисы компании, имеется своя высокоскоростная LAN. Од нако это не всегда так. Если все участки сети связаны быстрыми и надежными кана лами, можно использовать один сайт для целой сети. Вообще говоря, при создании структуры сайтов следует руководствоваться следую щими принципами. • Создавайте сайт для каждой LAN или группы LAN, связанных высокоскоростной сетевой магистралью (опорной сетью). Обычно, но не всегда, эти LAN соответству ют территориальным подразделениям компании. Однако учтите, что даже при со единении двух удаленных друг от друга офисов высокоскоростным каналом задер жка, возникающая при передаче данных между ними, часто является веской при чиной для того, чтобы все равно создать отдельный сайт для каждого офиса. • Создавайте сайт для каждого территориального участка, где вы планируете уста новить контроллер домена. Подробнее о размещении контроллеров домена — в за нятии 2. • Создавайте сайт для каждого участка, где есть сервер, на котором выполняется приложение, работающее с данными о сайтах. Например, если в данном месте име-
Занятие 1
Проектирование ТОПОЛОГИИ сайтов
|4§
ются серверы, на которых хранятся общедоступные ресурсы иерархии DFS, можно создать сайт, чтобы управлять доступом клиентов к этим DFS-ресурсам. Подготовка к экзамену На практике вопрос, какое соединение считать быстрым, тре бует обсуждения. Вы увидите, что в документации рекомендуемая скорость соединения знутри сайта может варьироваться от 512 Кбит/с до 3 Мбит/с. Однако при проектирова нии сайтов на экзамене быстрым считается соединение со скоростью минимум 10 Мбит/с. Другими словами, границы сайтов обычно соответствуют границам LAN. Если в сети несколько LAN, связанных WAN-каналами, то скорее всего нужно создать по одному сайту для каждой LAN. Иногда нет смысла создавать сайт для территориального участка, даже если этот участок связан с остальной сетью каналом с относительно низкой пропускной способ ностью. Это особенно верно в случае небольших офисов, где работает мало пользовате лей, нет котроллеров домена и нет серверов, на которых выполняются службы, работа ющие с сайтами. В таких случаях часто бывает лучше добавить IP-подсеть этого участ ка в другой сайт сети, даже если пропускная способность ограничена. Трафик, генери руемый запросами аутентификации от такого небольшого сайта, сравнительно неве лик. Создание сайта связано с издержками, в частности с увеличением сетевого трафи ка (поскольку контроллеры доменов должны отслеживать информацию о сайтах и об ращаться к пользователям) и усложнением управления. Вы должны подумать, переве сят ли преимущества, которые обеспечивает сайт в управлении трафиком, издержки создания сайта. При разработке структуры сайтов начинайте с построения простой схемы, пред ставляющей все сайты сети (рис. 5-3). Пометьте общую и доступную пропускную спо собность соединений между сайтами. Для каждого сайта укажите следующую инфор мацию. f
145 X пользо вателей \
256 Кбит/с Доступно 60%
1 I
192.168.1.0 \Нью-Йорк/
\
1,5 Мбит/с Доступно 45%
г 245 ^ Ч у / пользо=а;елей у ^
t
Атла ига
J У
/
Мемфис У
yS у / уг
192.16 8.3.0
7 5 X N / пользователей 1 I 192.168.2.0
256 КбитА Доступно 30%
256 Кбит/с Доступно 40% f 65 >i / пользователей 1
192.168,40 \ V
Лондон
л
Рис. 5-3. Типичная схема сайтов, на которой показана доступная пропускная способность каналов между территориальными участками
150
Планирование сайтсш
Глава 5
Имя сайта. Это имя объекта-сайта, который вы создадите в Active Directory. Если имя сайта отличается от названия территориального участка, отметьте на схеме и название этого участка. Подсети, входящие в сайт. Перечислите диапазон IP-адресов подсети, имя, при своенное объекту-подсети в Active Directory, и маску подсети.
Ответственный за топологию сайтов При планировании сайта следует подумать и о том, кто будет управлять структу рой сайта после его развертывания. Ответственным за топологию сайтов назна чают администратора (или администраторов). Он должен по мере роста и измене ния физической сети вносить необходимые изменения в структуру сайтов. От ветственный за топологию сайтов выполняет следующие обязанности. • Изменяет топологию сайтов в соответствии с изменениями в физической то пологии сети. • Отслеживает сведения о подсетях в сети: IP-адреса, маски подсетей и место нахождения подсетей. • Наблюдает за сетевыми соединениями и задает цены связей между сайтами.
Закрепление материала Ответив на вопросы, приведенные ниже, вы сможете лучше усвоить основные темы за нятия. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытай тесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы. 1. Вы разрабатываете структуру сайтов для компании, у которой имеются филиалы в Атланте, Чикаго и Лос-Анджелесе. Каждый филиал связан с двумя другими линия ми с пропускной способностью 512 Кбит/с. Сколько сайтов вы бы создали? 2. Какие задачи управления сетевым трафиком решают с помощью сайтов? 3. По каким критериям следует определять, нужно ли создавать сайт?
Резюме •
•
•
Сайты используются для управления сетевым трафиком, генерируемым при входе на рабочие станции, при репликации данных Active Directory, работе DFS (Distributed File System) и FRS (File Replication Service). Чтобы подготовиться к разработке структуры сайтов, нужны сведения о территори альной структуре компании, структуре и скорости локальной сети каждого из офи сов, TCP/IP-подсетях каждого из офисов и пропускной способности каналов между офисами. Вы должны создать по сайту для каждой LAN (или группы LAN, соединенных вы сокоскоростной сетевой магистралью), каждого участка, где есть контроллер доме на, и каждого участка, где имеется служба, работающая с сайтами.
Занетие 2
Планирование контроллеров доменов
Занятие 2. Планирование контроллеров доменов После того как вы определили структуру сайтов сети, наступает следующий этап пла нирования сайтов — определение количества и размещения контроллеров доменов в этих сайтах. Вы также должны определить, соответствует ли каждый контроллер доме на требованиям к оборудованию, чтобы работать под управлением Windows Server 2003 и справляться со своей нагрузкой. На этом занятии рассматривается, как определить, нужны ли контроллеры доменов для данного сайта, следует ли назначать им какиелибо дополнительные роли и какая пропускная способность должна быть у каждого контроллера домена. Изучив материал этого занятия, вы сможете:
•S •S •S •S •S
определить, как разместить контроллеры доменов, входящих в сайты; проектировать размещение контроллеров корневого домена леса; планировать структуру серверов глобального каталога; задавать роли хозяев операций для серверов; определять требования к пропускной способности контроллеров доменов. Продолжительность занятия — около 30 минут.
Планирование размещения контроллеров доменов Контроллеры доменов аутентифицируют пользователей, хранят политики безопасности для домена, содержат и реплицируют на другие контроллеры домена БД Active Directory. Важная часть планирования сайтов — проектирование размещения контроллеров доме нов. При этом следует определить: • нужен ли контроллер домена для данного участка; и количество контроллеров доменов, необходимых для сайта; • размещение контроллеров корневого домена леса. Как определить, нужен ли контроллер домена для данного участка
Первый этап планирования контроллеров доменов в сети — определить, где должны находиться контроллеры. Часто администраторы используют слишком мало контролле ров домена, предполагая, что чем меньше контроллеров у домена, тем проще им управ лять. Но бывает, что контроллеров домена, наоборот, слишком много, поскольку адми нистраторы полагают, будто в каждом из участков сети должен быть минимум один контроллер домена. Предположения, выдвигаемые в обоих случаях, вполне могут ока заться правильными, но это не всегда так. Чтобы определить, нужно ли создать контроллер домена для данного сайта, руко водствуйтесь следующими принципами. • Если сайт охватывает много пользователей, помещение контроллера домена в сайт обеспечивает, что при аутентификации пользователей, входящих в сеть, не генери руется сетевой трафик, который нужно передавать на удаленный контроллер доме на по WAN-каналу.
152
Планирование сайтов
Глаеа 5
•
Если пользователям нужна возможность входить в домен, даже когда WAN-канал не работает, следует установить контроллер домена в локальном сайте. Если WAN-ка нал недоступен и нет локальных контроллеров домена, способных обработать запро сы на вход в систему, пользователи регистрируются с кэшированными удостовере ниями и не могут обращаться к ресурсам других компьютеров. • Если на серверах сайта выполняются приложения, работающие с сайтами, и нужно обеспечить доступ пользователей домена к этим приложениям, установите в этом сайте контроллер домена. Тогда серверы, на которых выполняются такие приложе ния, смогут выполнять аутентификацию пользователей, обращаясь к локальному контроллеру домена, и не будут генерировать трафик аутентификации, передавае мый по WAN-каналу. • Если сайт является узловым (hub site), т. е. связывает друг с другом остальные сайты меньшего размера, и если у этих сайтов меньшего размера нет своих контроллеров доменов, имеет смысл поместить контроллер домена в узловой сайт, чтобы умень шить время отклика при входе. Как видите, при принятии большинства решений, связанных с добавлением кон троллеров в сайты, вам нужно найти баланс между издержками из-за установки допол нительных контроллеров доменов и выгодой от того, что трафик аутентификации не передается по WAN-каналам. Когда вы добавляете контроллер домена по любой из вышеперечисленных причин, нужно учитывать следующие моменты. • Контроллерами доменов нужно управлять. Устанавливайте контроллеры только там, где есть администраторы, достаточно квалифицированные для того, чтобы управ лять контроллерами домена. Если таких администраторов нет, вы должны обеспе чить сотрудникам ИТ-отдела уровень доступа, позволяющий удаленно управлять контроллером домена. • Контроллеры домена должны быть защищены. Устанавливайте контроллеры домена только в тех сайтах, в которых можно гарантировать физическую безопасность кон троллера.
Как определить количество необходимых контроллеров доменов Следующий этап — определить, сколько контроллеров доменов требуется на сайте для обслуживания каждого из его доменов. Количество пользователей домена, входящих на сайт, — основной фактор, влияю щий на число контроллеров, необходимых данному домену. Чтобы определить, сколько контроллеров требуется каждому из доменов сайта, руководствуйтесь следующими пра вилами. • Если данный домен сайта охватывает менее 1000 пользователей, в нем достаточно установить всего один контроллер. • Если данный домен сайта охватывает от 1000 до 10 000 пользователей, в нем требу ется установить не менее двух контроллеров. • Для каждых дополнительных 5000 пользователей следует добавлять по одному кон троллеру. Например, если на сайт входят 20 000 пользователей домена, в этом доме не следует установить четыре контроллера. Кроме того, при определении количества контроллеров домена, необходимых сайту, следует учитывать издержки, которые возникают при репликации между сайтами. Ба зовое правило состоит в том, что для каждых 15 соединений репликации, устанавлива-
Занятае 2
Плакирование контроллеров доменов
| gg
емых с сайтом, следует добавлять один контроллер домена, который будет нести эту нагрузку. На заметку Даже если можно выполнить требования сайта, установив лишь один кон троллер, в сайт надо поместить минимум два контроллера домена, чтобы обеспечить отказоустойчивость в случае, если один из контроллеров даст сбой. Кроме того, второй контроллер домена обеспечивает балансировку нагрузки, даже если в этом нет техни ческой необходимости. Вообще говоря, можно добиться некоторого уровня отказоус тойчивости, установив на один контроллер больше, чем определенное вами минималь ное количество. Если будет доступен еще один контроллер домена, то в случае сбоя одного из контроллеров остальные не будут перегружены.
Как разместить контроллеры корневого домена леса Первый домен, создаваемый в новом лесу, называется корневым доменом леса и зани мает особое место среди доменов леса. Корневой домен леса закладывает основу струк туры леса и пространства имен. Кроме того, данные о группах Администраторы пред приятия (Enterprise Admins) и Администраторы схемы (Schema Admins) уровня леса так же хранятся в корневом домене леса. Доверительные отношения между доменами являются транзитивными, и вся аутен тификация между разными доменами леса выполняется или через корневой домен леса (т. е. контроллер корневого домена леса), или через специально сконфигурированное доверие к сокращению (shortcut trusts) между региональными доменами. Если один сайт содержит несколько доменов, но корневой домен леса находится в другом сайте, можно определеить доверие к сокращению или добавить контроллер корневого домена леса в локальный сайт. Это позволит аутентифицировать пользователей между доменами локального сайта, даже если WAN-канал неработоспособен.
Планирование серверов — хозяев операций Существуют задачи, которые в отличие от модели репликации с несколькими хозяева ми решаются только определенными контроллерами домена. Эти контроллеры выпол няют так называемые роли хозяев операций. Хозяева операций (operations masters) — контроллеры домена, которым назначены определенные роли, связанные с обслужива нием домена или леса, и они всегда выполняют функции, специфичные для домена или леса, — никакой другой компьютер не вправе брать на себя эти функции. Такие функции разделены на категории для лучшей управляемости.
Роли хозяев операций уровня леса В Windows Server 2003 две роли хозяев операций уровня леса. • Хозяин схемы (Schema Master). Первый контроллер домена в лесу принимает роль хозяина схемы и отвечает за поддержку и распространение схемы на остальную часть леса. Он поддерживает список всех возможных классов объектов и атрибутов, определяющих объекты, которые находятся в Active Directory. Если схему нужно обновлять или изменять, — как, например, в случае установки приложения, кото рое должно модифицировать классы или атрибуты схемы, — то делать это следует на хозяине схемы [т. е. должен быть доступен контроллер домена (DC), имеющий роль хозяина схемы] одному из членов группы Администраторы схемы (Schema
154
Планирование сайтов
Глава 5
Admins). Если DC, являющийся хозяином схемы, недоступен, а вы должны внести изменения в схему, можно передать эту роль другому DC. ш Хозяин именования доменов (Domain Naming Master). Протоколирует добавление и удаление доменов в лесу и жизненно необходим для поддержания целостности до менов. Хозяин именования доменов запрашивается при добавлении к лесу новых доменов. Если хозяин именования доменов недоступен, добавление новых доменов невозможно; однако при необходимости эта роль может быть передана другому кон троллеру. Здесь есть одна тонкость, о которой важно помнить в среде с несколькими доменами: хозяин именования доменов должен быть еще и сервером глобального каталога. Дело вот в чем. Чтобы проверить, является ли уникальным домен, созда ваемый в лесу, хозяин именования доменов запрашивает глобальный каталог. Эти две роли автоматически назначаются первому контроллеру домена в лесу. В однодоменной среде (или в лесу с нескольким доменами, в котором все контролле ры корневого домена леса хранят глобальный каталог) вы должны оставить обе роли хозяев операций уровня леса первому контроллеру, созданному в корневом домене леса. В лесу с несколькими доменами, в котором глобальный каталог хранится не на всех контроллерах, передайте обе роли хозяев операций уровня леса контроллеру корневого домена леса, не являющемуся сервером глобального каталога.
Роли хозяев операций уровня домена
В Windows Server 2003 три роли хозяев операций уровня домена. • Эмулятор основного контроллера домена [Primary Domain Controller (PDC) Emulator] отвечает за эмуляцию Windows NT 4.0 PDC для клиентских машин, которые еще не переведены на Windows Server 2003. Одна из основных задач эмулятора PDC — регистрировать устаревшие клиенты. Кроме того, к эмулятору PDC происходит об ращение, если аутентификация клиента оказалась неудачной. • Хозяин RID [Relative Identifier (RID) Master] отвечает за выделение диапазонов от носительных идентификаторов (RID) всем контроллерам в домене. Идентификатор защиты (security identifier, SID) — уникальный идентификатор каждого объекта в домене. SID в Windows Server 2003 состоит из двух частей. Первая часть общая для всех объектов в домене; для создания уникального SID к этой части добавляется уникальный RID. Вместе они уникально идентифицируют объект в домене и ука зывают, где он был создан. • Хозяин инфраструктуры (Infrastructure Master) регистрирует изменения, вносимые в контролируемые объекты в домене. Обо всех изменениях сначала сообщается хо зяину инфраструктуры, и лишь потом они реплицируются на другие контроллеры домена. Хозяин инфраструктуры обрабатывает информацию о группах и членстве в них для всех объектов в домене. Еще одна задача хозяина инфраструктуры — пере давать информацию об изменениях, внесенных в объекты, в другие домены. Не назначайте роль хозяина инфраструктуры контроллеру домена, содержащему гло бальный каталог, если только этот каталог не хранится на всех контроллерах доме на. Это объясняется тем, что хозяин инфраструктуры не будет нормально работать, если он содержит ссылки на объекты, не входящие в домен. Если хозяин инфра структуры является еще и сервером глобального каталога, то глобальный каталог будет содержать объекты, которые не хранятся на хозяине инфраструктуры, что опять же помешает его работе.
Занятое 2
Планирование контроллеров доменов
15з
Все три роли уровня домена автоматически назначаются первому контроллеру доме на, созданному в домене. Следует по возможности всегда назначать три роли уровня ~омена одному серверу, входящему в домен. Поскольку по умолчанию эти роли получа ет первый установленный контроллер домена, самое лучшее — все так и оставить. Это весьма упрощает администрирование. Не забывайте: этот сервер либо не должен содер жать глобальный каталог, либо, если тот все же хранится на этом сервере, глобальный каталог должен содержаться и на остальных контролерах этого домена. Помните, что всем пользователям домена требуется регулярный доступ к серверу 'или серверам), выполняющему эти роли. Если в домен входит несколько сайтов, поме стите хозяев операций в сайт с наибольшим числом пользователей. Если таких сайтов несколько, поместите хозяев операций в тот из них, который доступен всем пользова телям.
Планирование серверов глобального каталога Сервер глобального каталога — это контроллер домена, поддерживающий подмноже ство атрибутов объектов Active Directory, к которым чаще всего обращаются пользова тели или клиентские компьютеры, например регистрационное имя пользователя. Сер веры глобального каталога выполняют две важные функции. Они дают возможность пользователям входить в сеть и находить объекты в любой части леса, не обращаясь к конкретным контроллерам доменов, на которых хранятся эти объекты. Active Directory состоит из трех разделов. •
•
•
Раздел схемы. Хранит определения всех объектов, которые можно создать в лесу, а также их атрибутов. В лесу существует только один раздел схемы. Его копия репли цируется на все контроллеры доменов, входящие в лес. Раздел конфигурации. Определяет структура доменов, сайтов и объектов-серверов Active Directory. В лесу существует только один раздел конфигурации. Его копия реплицируется на все контроллеры доменов, входящие в лес. Раздел домена. Служит для идентификации и определения объектов, специфич ных для домена. В каждом домене существует свой раздел домена, копия которого реплицируется на все контроллеры этого домена.
Как и все контроллеры доменов, сервер глобального каталога содержит полные ко пии разделов схемы и конфигурации, а также полную копию раздела домена для того домена, в который он входит. В эти копии можно записывать данные. Кроме того, он содержит глобальный каталог, где хранится подмножество информации раздела домена и который реплицируется на другие контроллеры этого домена. Когда пользователь пытается войти в сеть или обратиться к какому-то сетевому ресурсу из любой точки леса, соответствующий запрос разрешается с участием глобаль ного каталога. Без глобального каталога этот запрос мог бы долго передаваться от одно го контроллера домена к другому. Если в вашей сети один домен, необходимости в этой функции глобального каталога нет, так как информация обо всех пользователях и объектах сети находится на любом контроллере домена. Но при наличии нескольких доменов эта функция глобального каталога становится важной. Другая функция глобального каталога, полезная независимо от того, сколько доме нов в вашей сети, — участие в процессе аутентификации при входе пользователя в сеть. Когда пользователь входит в сеть, указывая имя участника системы безопасности (user prinipal name, UPN) вида
[email protected], оно сначала сверяется с содержимым гло бального каталога. Это позволяет входить в сеть с компьютеров в доменах, отличных
•jgg
Планирование сайтов
Глава 5
от того, где хранится нужная пользовательская учетная запись. Кроме того, это позво ляет входить в сеть, когда контроллер домена недоступен, например из-за того, что не работает WAN-канал. Примечание В Windows Server 2003 введена новая функция — кэширование информа ции о членстве в универсальных группах. Если эта функция активизирована для сайта, контроллеры домена этого сайта кэшируют информацию о членстве пользователей в универсальных группах, когда пользователи входят в сеть. Контроллеры домена также обновляют этот кэш, связываясь через заданные интервалы с серверами глобального каталога. Если кэширование информации о членстве в универсальных группах вклю чено, контроллеры доменов могут аутентифицировать пользователей, не обращаясь к глобальному каталогу. Эта функция полезна в случае небольших сайтов, когда добав ление сервера глобального каталога привело бы к созданию лишнего трафика репли кации. По умолчанию сервером глобального каталога становится первый контроллер доме на, установленный в лесу. Однако в отличие от ролей хозяина операций роль сервера глобального каталога может быть назначена нескольким контроллерам. Установка до статочного количества серверов глобального каталога на каждом участке обеспечит при емлемое время отклика для пользователей, входящих в сеть из удаленных доменов. Подготовка к экзамену В лесу с одним доменом сделайте все контроллеры домена сер верами глобального каталога, поскольку для этого не потребуется дополнительного про странства и это не приведет к генерации дополнительного трафика репликации. В лесу с несколькими доменами можно создать столько серверов глобального каталога, сколь ко нужно, чтобы обеспечить балансировку нагрузки и избыточность. Microsoft реко мендует устанавливать минимум один сервер глобального каталога в каждом сайте. Хотя любой контроллер домена можно сделать сервером глобального каталога, будь те осторожны, решая, каким серверам назначить те или иные роли. Прежде всего не следует превращать один и тот же контроллер домена в хозяина инфраструктуры и в сервер глобального каталога, если у вас не один контроллер домена. Кроме того, сервер глобального каталога требует большого объема ресурсов от контроллера домена. По этой причине не стоит создавать сервер глобального каталога из контроллера домена, вы полняющего другие ресурсоемкие роли. При добавлении серверов глобального каталога в сайты руководствуйтесь следую щими правилами. • Если сайт включает более 100 пользователей, поместите в него сервер глобального каталога, чтобы сократить трафик аутентификации, передаваемый по WAN-кана лам. В случае небольших сайтов используйте вместо сервера глобального каталога кэширование информации о членстве в универсальных группах. • Если в сайте несколько контроллеров домена, установите несколько серверов гло бального каталога. Общее базовое правило — количество серверов глобального ка талога должно быть равно половине количества контроллеров домена в сайте. • Помещайте серверы глобального каталога в сайты, в которых установлены прило жения, постоянно выполняющие поиск в Active Directory. Возможность обращаться к локальному серверу глобального каталога повысит производительность и сократит трафик по WAN-каналам.
Занятие 2
Планирование контроллеров доменов
-| g j
Планирование пропускной способности контроллеров доменов Под пропускной способностью контроллера домена имеется в виду число пользовате лей сайта, которое может поддерживать этот контроллер. Администраторы должны по нимать требования, предъявляемые к каждому контроллеру домена, и подбирать аппа ратное обеспечение в соответствии с этими требованиями, чтобы в дальнейшем не было трудноразрешимых проблем, связанных с тем, что контроллеры доменов не отвечают на запросы пользователей, поскольку не справляются с нагрузкой. Основной фактор, влияющий на требования к пропускной способности, — количе ство пользователей домена, которые должны проходить аутентификацию. После того как вы оценили требования к оборудованию с учетом количества пользователей, следу ет уточнить эти требования — принять во внимание дополнительные роли и службы, которые будут работать на этом контроллере домена.
Определение требований к процессорам Количество процессоров, необходимых контроллеру домена, в основном зависит от того, сколько пользователей будут входить в домен. Чтобы по числу пользователей, входящих в домен, определить, какие процессоры использовать, руководствуйтесь следующими правилами. • Если пользователей меньше 500, контроллеру домена под управлением Windows Server 2003 достаточно одного процессора с тактовой частотой 850 МГц или выше. • Если количество пользователей находится в пределах от 500 до 1500, контроллеру домена под управлением Windows Server 2003 требуется два процессора с тактовой частотой 850 МГц или выше. • Если пользователей больше 1500, контроллеру домена под управлением Windows Server 2003 нужно четыре процессора с тактовой частотой 850 МГц или выше. На заметку Хотя для сдачи экзамена вы должны запомнить требования, перечислен ные в разделе «Определение требований к процессорам», есть и другие подходы к обес печению необходимой процессорной мощности. С ростом числа пользователей кон троллерам доменов требуются дополнительные вычислительные ресурсы. Вместо уста новки дополнительных процессоров можно увеличивать тактовую частоту процессора. Так, один процессор с тактовой частотой 1,6 ГГц способен заменить два процессора на 850 МГц, а процессор с тактовой частотой 3 ГГц — четыре процессора на 850 МГц. Преимущество многопроцессорных систем — возможность одновременной обработки большего количества запросов, но это преимущество во многих случаях не компенси рует издержки от установки нескольких процессоров. Системы с несколькими процес сорами, как правило, дороже, чем системы с одним, но более мощным процессором. Кроме того, условия лицензирования ПО зависят от количества процессоров в системе.
Определение требований к дисковому пространству Как и требования к процессорам, требования к дисковому пространству в первую оче редь зависят от числа пользователей в домене. Чтобы определить требования к дисково му пространству, руководствуйтесь следующими правилами.
Занятие 2
Планирований контроллеров доменов
-j g j
Планирование пропускной способности контроллеров доменов Под пропускной способностью контроллера домена имеется в виду число пользовате лей сайта, которое может поддерживать этот контроллер. Администраторы должны по нимать требования, предъявляемые к каждому контроллеру домена, и подбирать аппа ратное обеспечение в соответствии с этими требованиями, чтобы в дальнейшем не было трудноразрешимых проблем, связанных с тем, что контроллеры доменов не отвечают на опросы пользователей, поскольку не справляются с нагрузкой. Основной фактор, влияющий на требования к пропускной способности, — количе ство пользователей домена, которые должны проходить аутентификацию. После того как вы оценили требования к оборудованию с учетом количества пользователей, следу ет уточнить эти требования — принять во внимание дополнительные роли и службы, которые будут работать на этом контроллере домена.
Определение требований к процессорам Количество процессоров, необходимых контроллеру домена, в основном зависит от того, сколько пользователей будут входить в домен. Чтобы по числу пользователей, входящих з домен, определить, какие процессоры использовать, руководствуйтесь следующими .травилами. • Если пользователей меньше 500, контроллеру домена под управлением Windows Server 2003 достаточно одного процессора с тактовой частотой 850 МГц или выше. • Если количество пользователей находится в пределах от 500 до 1500, контроллеру домена под управлением Windows Server 2003 требуется два процессора с тактовой частотой 850 МГц или выше. • Если пользователей больше 1500, контроллеру домена под управлением Windows Server 2003 нужно четыре процессора с тактовой частотой 850 МГц или выше. На заметку Хотя для сдачи экзамена вы должны запомнить требования, перечислен ные в разделе «Определение требований к процессорам», есть и другие подходы к обес печению необходимой процессорной мощности. С ростом числа пользователей кон троллерам доменов требуются дополнительные вычислительные ресурсы. Вместо уста новки дополнительных процессоров можно увеличивать тактовую частоту процессора. Так, один процессор с тактовой частотой 1,6 ГГц способен заменить два процессора на 350 МГц, а процессор с тактовой частотой 3 ГГц — четыре процессора на 850 МГц. Преимущество многопроцессорных систем — возможность одновременной обработки большего количества запросов, но это преимущество во многих случаях не компенси рует издержки от установки нескольких процессоров. Системы с несколькими процес сорами, как правило, дороже, чем системы с одним, но более мощным процессором. Кроме того, условия лицензирования ПО зависят от количества процессоров в системе.
Определение требований к дисковому пространству Как и требования к процессорам, требования к дисковому пространству в первую оче редь зависят от числа пользователей в домене. Чтобы определить требования к дисково му пространству, руководствуйтесь следующими правилами.
158
Планирование сайтаз
Глава 5
•
На диске, содержащем БД Active Directory (NTDS.dit), для хранения данных о каж дой 1000 пользователей необходимо выделить минимум 400 Мб. Сюда входит и про странство, занимаемое разделом DNS. • На диске, содержащем файлы журналов транзакций Active Directory, должно быть минимум 500 Мб свободного места. • На диске, содержащем общие папки SYSVOL, должно быть минимум 500 Мб. • На диске, на который устанавливается ОС Windows Server 2003, должно быть при мерно 2 Гб свободного дискового пространства. Определив минимальный объем дискового пространства, необходимый контролле рам доменов, вы должны выделить дополнительное дисковое пространство на тех кон троллерах домена, на которых будет храниться глобальный каталог. Если в лесу только один домен, назначение контроллеру домена роли сервера глобального каталога не при ведет к увеличению размера БД. Однако, если в лесу более одного домена, для каждого дополнительного домена размер глобального каталога увеличивается приблизительно на 50% от размера базы данных этого домена.
Определение требований к памяти И вновь основным фактором, влияющим на требования к объему памяти контроллера домена, является количество пользователей. Чтобы определить требования к памяти контроллера домена, руководствуйтесь следующими правилами. • Если пользователей меньше 500, контроллеру домена требуется 512 Мб памяти. • Если количество пользователей находится в пределах от 500 до 1000, контроллеру домена требуется 1 Гб памяти. • Если пользователей больше 1000, контроллеру домена требуется 2 Гб памяти.
Совет Microsoft предлагает утилиту Active Directory Sizer Tool, которая по числу пользо вателей, информации о домене и топологии сайтов сети позволяет оценить требования к оборудованию для развертывания Active Directory. Эта утилита доступна по ссылке http://www.microsoft.com/windows2000/downloads/tools/sizer/default.asp. Она разработана д Windows 2000, но остается полезной и при оценке требований к оборудованию компью тера под управлением Windows Server 2003.
Лабораторная работа. Планирование контроллеров доменов На этой лабораторной работе вы спроектируете размещение контроллеров доменов и серверов глобального каталога для компании Northwind Traders. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытайтесь ответить снова. Отве ты для самопроверки — в разделе «Вопросы и ответы» в конце главы.
Сценарий Компания Northwind Traders производит линейку сетевых устройств, расширяющих возможности в передаче данных. Сейчас Northwind Traders использует основную мо дель доменов Microsoft Windows NT 4.0 (master domain model). Все домены настроены на двусторонние доверительные отношения между собой. В последние годы компания зна чительно расширилась и ожидает дальнейшего существенного роста в следующие три года, в том числе увеличения своей доли рынка, доходов и численности сотрудников.
Занятие 2
Планирование контроллеров доменов
Помимо открытия двух новых офисов, администрация решила реализовать новый про ект Windows Server 2003 Active Directory, отвечающий текущим и будущим потребнос тям компании. Территориальная структура сети компании Northwind показана ниже. Сотрудники ИТ-отдела, расположенного в главном офисе корпорации в Париже, очень хотели бы оез проблем выполнять поиск информации, которая будет содержаться в БД Active Directory. Это требование объясняется тем, что в текущей модели поиск различных ресурсов и информации об учетных записях занимает много времени. Кроме того, не которые сотрудники региональных офисов посещают главный офис в Париже. Им нуж но без проблем входить на компьютеры парижского офиса и других офисов, в которых они бывают.
В офисе в Сиднее планируется установить несколько серверных DCOM-приложений (Distributed Component Object Model), работающих с сайтами. Эти приложения потребуют быстрого ответа от серверов.
Вопросы к лабораторной работе Исходя из этого сценария ответьте на следующие вопросы. 1. Сколько контроллеров домена вы установили бы в каждом сайте? Почему? Укажите их количество в следующей таблице. Домен
Число контроллеров домена в каждом сайте Париж
Nwtraders .local AsiaPacific. nwtraders .local NAeast.nwtraders.local NAwest.nwtraders.local Corp.nwtraders.local RDNwtraders.local Glasgow.RDNwtraders.local
Глазго
Сидней
Атланта
Лос-Анджелес
160
Планирование сайтов
Глава 5
2. В каких сайтах вы разместили бы серверы глобального каталога? В каких сайтах вы включили бы кэширование членства в универсальных группах? Заполните следую щую таблицу. Сайт
Число серверов глобального каталога для леса Nwtraders.local
Число серверов глобального каталога для леса RDNwtraders.local
Включить кэширование членства в группах для сайта (да/нет)
Париж Глазго Сидней Атланта Лос-Анджелес
Закрепление материала Ответив на вопросы, приведенные ниже, вы сможете лучше усвоить основные темы за нятия. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытайтесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы. 1. По каким причинам в сайты помещают контроллеры домена? Какие причины могут быть для того, чтобы не помещать в сайт контроллер домена? 2. Вы определяете, сколько контроллеров доменов нужно установить в сайте. Сайт охватывает 15 000 пользователей. Поддерживается восемь соединений репликации с сайтом. Сколько контроллеров доменов следует установить? 3. Какие рекомендации следует выполнять при установке серверов глобального ката лога?
Резюме •
Основная причина помещения контроллеров доменов в сайт — необходимость изба виться от передачи WAN-трафика между сайтами. Этот трафик может генериро ваться, когда пользователи связываются с контроллерами доменов при аутентифи кации, когда приложения, работающие с сайтами, обращаются к контроллерам доменов, чтобы выполнить поиск, а также при репликации. • Если пользователей сайта менее 1000, достаточно одного контроллера домена. Если пользователей от 1000 до 10 000, рекомендуется установить два контроллера домена. Для каждых дополнительных 5000 пользователей сверх 10 000 добавляйте один кон тролер домена. Однако даже в сайтах менее чем с 1000 пользователей следует уста навливать второй контроллер домена, чтобы обеспечить отказоустойчивость. • По возможности назначайте все роли хозяина операций для леса или домена одному и тому же контроллеру домена. Запомните следующее правило: хозяин инфраструк туры не должен хранить глобальный каталог за исключением случая, когда все дру гие контроллеры этого домена тоже содержат глобальный каталог. • На серверах глобального каталога хранится подмножество атрибутов объектов Active Directory, к которым чаще всего обращаются пользователи или клиентские компью теры. Они позволяют пользователям входить в сеть и искать объекты Active Director, по всему лесу, не обращаясь к тем контроллерам домена, где хранятся эти объекты.
Занятие 3 •
Планирование стратегам репликации
jg-j
Требования к оборудованию контроллера домена в основном зависят от числа пользо вателей, которые должны проходить аутентификацию в домене. Определив требова ния в соответствии с этим критерием, примите во внимание, является ли контрол лер домена сервером глобального каталога и выполняет ли он другие роли.
Занятие 3. Планирование стратегии репликации Репликация Active Directory — жизненно важная операция, которую необходимо тща тельно планировать. Правильно спланированная репликация ускоряет ответ каталога, уменьшает сетевой трафик по WAN-каналам и сокращает административные издерж ки. На этом занятии рассказывается, как выполняется репликация и как выработать четкую стратегию репликации. Изучив материал этого занятия, вы сможете: •S объяснить, как выполняется репликация Active Directory внутри сайта и между сайтами; •S рассказать об использовании связей сайтов, мостов связей сайтов и серверов-плацдармов (серверов репликации между сайтами); •S выработать стратегию репликации для компании. Продолжительность занятия — около 25 минут.
Процесс репликации Как вы уже знаете, в Windows Server 2003 используется модель репликации с несколь кими хозяевами, при которой на всех контроллерах домена хранятся равноправные копии БД Active Directory. Когда вы создаете, удаляете или переносите объект либо изменяете его атрибуты на любом контроллере домена, эти изменения реплицируются на остальные контроллеры домена.
Внутрисайтовая и межсайтовая репликация Поскольку в Active Directory могут храниться тысячи и даже миллионы объектов, реп ликация изменений этих объектов запросто может отобрать значительную часть про пускной способности сети и системных ресурсов контроллеров доменов. Внутрисайто вая (между контроллерами домена одного сайта) и межсайтовая репликация (между контроллерами домена, относящимися к разным сайтам) выполняется по-разному. При внутрисайтовой репликации трафик репликации передается в несжатом фор мате. Это объясняется тем, что контроллеры домена, принадлежащие одному сайту, как предполагается, связаны каналами с высокой пропускной способностью. Помимо того, что данные не сжимаются, используется механизм репликации, основанный на уве домлении об изменениях. Значит, если в данные домена вносятся изменения, эти изме- . нения быстро реплицируются на все контроллеры домена. При межсайтовой репликации все данные передаются в сжатом виде. Это отражает тот факт, что трафик, вероятно, передается по более медленным WAN-каналам (в срав-
162
Планирование сайтов
Глава 5
нении с соединениями локальной сети, используемыми при внутрисайтовой реплика ции). Однако при этом увеличивается нагрузка на серверы, поскольку, помимо прочих операций по обработке, им приходится упаковывать/распаковывать данные. Кроме того, репликация выполняется по расписанию во время, лучше подходящее данной органи зации. Например, вы можете разрешить репликацию только в те часы, когда каналы менее загружены. Конечно, из-за того, что репликация выполняется с задержкой, воз никает задержка и в передаче изменений на серверы других сайтов. Примечание Подробнее о том, как работает система уведомлений об изменениях, и об основных механизмах репликации — в руководстве «Directory Services Guide», кото рое является частью Microsoft Windows Server 2003 Resource Kit (Microsoft Press, 2003). Дополнительные сайты создаются для управления передачей трафика репликации по медленным WAN-каналам. Например, у вас имеется несколько контроллеров доме на в основной LAN и несколько контроллеров домена в LAN филиала. Эти две LAN связаны друг с другом относительно медленным WAN-каналом. Вы хотели бы, чтобы репликация между контроллерами домена каждой локальной сети выполнялась сразу после внесения изменений, а репликация по WAN-каналу — с некоторой задержкой. Чтобы соблюсти это требование, создайте два сайта: один будет охватывать все кон троллеры домена основной LAN, а другой — все контроллеры домена удаленной LAN.
Транспорты, используемые при репликации При любом коммуникационном взаимодействии в сети нужен некий транспорт ный протокол, по которому передается информация. Это относится и к трафику репликации Active Directory. При репликации данных применяются два транс порта: RPC (Remote Procedure Call) и SMTP (Simple Mail Transfer Protocol). Удаленные вызовы процедур выполняются при отправке сообщений репли кации внутри сайта и между сайтами. Протокол RPC используется по умолча нию при всех операциях репликации Active Directory, поскольку является отра слевым стандартом и совместим с большинством типов сетей. SMTP применяется при репликации между сайтами, не связанными посто янными соединениями (необходимыми для работы RPC). Одно из ограничений при использовании SMTP — он не позволяет реплицировать информацию раздела домена (domain partition information) на DC, входящие в домен. Поскольку SMTP применяется только при репликации между сайтами, проблем с репликацией информации раздела домена внутри домена не возникает (в этом случае автома тически используется RPC). То есть SMTP полезен лишь при репликации схе мы и глобального каталога.
Как выполняется репликация Каждый контроллер домена в сайте представляется объектом-сервером. У каждого объекта-сервера есть дочерний объект NTDS Settings, управляющий репликацией дан ных контроллера домена внутри сайта, а у каждого объекта NTDS Settings — объектсоединение, в котором хранятся атрибуты соединения и который представляет комму никационный канал, применяемый при репликации данных с одного контроллера до-
Занятие 8
Планирование стратегам репликации
мена на другой. Для репликации нужно, чтобы на обеих сторонах было по объектусоединению. Сервис Knowledge Consistency Checker (KCC) автоматически создает набор объек тов-соединений для репликации с одного контроллера домена на другой. Однако при необходимости можно создать объекты-соединения вручную. КСС создает различные топологии (т. е. задает местонахождение объектов-соедине ний и их конфигурацию) для внутрисайтовой и межсайтовой репликации. Кроме того, КСС изменяет созданные им топологии всякий раз, когда вы добавляете и удаляете контроллеры домена или перемещаете их из одного сайта в другой. Примечание О топологиях, создаваемых сервисом КСС, — в руководстве «Directory Services Guide», входящем в Windows Server 2003 Resource Kit (Microsoft Press, 2003).
Связи сайта Связь сайта (site link) — это объект Active Directory, представляющий физическое со единение между двумя или более сайтами. Для репликации данных между сайтами необходимо создать связь между ними. Эта связь состоит из двух компонентов: соб ственно физического соединения между сайтами (обычно WAN-канала) и объекта свя зи сайта. Последний определяет протокол, используемый при передаче трафика репли кации (IP или SMTP), и расписание репликации. Вся сайты, входящие в объект связи, должны быть соединены сетью одного типа. Чтобы контроллеры домена, относящиеся к одному сайту, могли реплицировать дан ные об изменениях каталога на контроллеры домена, относящиеся к другому сайту, с помощью связей сайтов вы должны вручную связать сайт с другими сайтами. Один и тот же объект связи сайта можно использовать для управления более чем одной парой сайтов. Например, если ваша сеть состоит из четырех сайтов, которые используют один и тот же протокол, соединены WAN-каналами одного типа и пропускной способности и должны выполнять репликацию по одному и тому же расписанию, вы можете создать один объект связи для всех этих сайтов. Кроме того, если два сайта связаны более чем одним WAN-соединением, вам нужно создать лишь одну связь сайта, так как назна чить эту связь заданному соединению нельзя. Если используется более сложная сеть, в которой имеются соединения разных ти пов и пропускных способностей, потребуется создать отдельные связи сайтов, опреде ляющие разные типы соединений. Однако по возможности старайтесь группировать однотипные WAN-каналы, создавая для них одну и ту же связь сайта.
Транзитивность связей сайтов и мосты таких связей По умолчанию связи сайта являются транзитивными (рис. 5-4). То есть, если связаны сайты А и В, В и С, то сайты А и С также связаны транзитивным соединением. Вы можете отключить транзитивность связей сайтов для заданного транспорта, но это не рекомендуется, кроме особых случаев, когда: • нужен полный контроль над репликацией; • требуется исключить определенный путь репликации; • сеть не обеспечивает полной маршрутизации или же брандмауэр не позволяет на прямую выполнять репликацию между двумя сайтами.
184
Планирование сайтов
Глава 5
Рис. 5-4. По умолчанию связи сайтов транзитивны Отключение транзитивности связей сайтов для транспорта влияет на все связи, ис пользующие этот транспорт, — они станут нетранзитивными. Тогда, чтобы поддержи вать транзитивные соединения, вам придется создать мосты связей сайтов. Мосты связей сайтов (site-link bridges) — логические соединения, использующие связи сайтов в качестве транспорта. Когда транзитивность связей включена, между всеми сайтами автоматически создаются логические мосты связей сайтов. А когда тран зитивность связей отключена, вы должны создавать такие мосты вручную. На рис. 5-5 показана простая группа из четырех сайтов, соединенных связями по принципу кару сели. Если транзитивность связей для этих сайтов отключена, вам придется вручную создать мосты связей сайтов, чтобы сделать возможной репликацию между всеми сай тами. В основном такие мосты служат для того, чтобы при отключенной транзитивности связей у каждого сайта был путь репликации к другим сайтам. Рассуждайте следую щим образом. Когда транзитивность связей включена, между всеми связями сайтов имеются мосты, поэтому все сайты могут обмениваться данными репликации друг с другом. А когда транзитивность отключена, вы должны самостоятельно создать мосты, поскольку связаны только те сайты, между которыми вручную сконфигурированы свя зи. Мосты связей сайтов передают трафик репликации между соответствующими сай тами по цепочке из нескольких связей.
I сайт А I V J %. ^S
(
СайтС 1 ^"*—^
f \ \
^Ч Сайт В I §
м00т связи
сайта
связь сайта
\тш,_ ~~~-—J СайтО I
Рис. 5-5. Мосты связей сайтов используются, когда транзитивность связей отключена Подготовка к экзамену По возможности всегда применяйте конфигурацию по умолча нию (в которой транзитивность связей сайтов включена). На экзамене вы можете стол кнуться с двумя случаями, где требуется отключить связи сайтов и использовать мосты связей: при необходимости полного контроля над путями репликации (из-за ограниче ний WAN-каналов или конфигурации брандмауэров) и при отсутствии в сети полной маршрутизации.
Занятие 3
Планирование стратегии репликации
Назначение цен связям сайтов Всем связям сайтов назначается цена, которая определяет, насколько данный путь лучше или хуже других связей. По умолчанию все связи имеют цену 100. Если одну связь сделать дороже другой, то при репликации (и при работе других приложений и служб, например Domain Controller Locator) предпочтение будет отдаваться связи с меньшей ценой. Цены цепочки связей суммируются. Например, рассмотрим схему на рис. 5-6. Если контроллеру домена в сайте А потребуется реплицировать информацию на контроллер домена в сайте D, будет использоваться путь через сайт В, поскольку его суммарная цена (600) меньше, чем суммарная цена другого доступного пути (1000).
Рис. 5-6. Цены цепочки связей суммируются Желательно выработать единую схему назначения цен связям сайтов на основе до ступной пропускной способности соединений. В табл. 5-1 показано, какие цены реко мендуется назначать в зависимости от доступной пропускной способности. Табл. 5-1. Рекомендуемая шкала зависимости цен связей сайтов от доступной пропускной способности Доступная пропускная способность (Кбит/с)
Цена связи сайта
9,6
1042
19,2
798
38,4
644
56
586
64
567
128
486
256
425
512
378
1024
340
2048
309
4096
283
166
Планирование сайтов
Глава 5
Расписание доступности связей сайтов По умолчанию связи сайтов доступны постоянно, т. е. репликация может выполняться, как только в ней возникнет необходимость. Однако, если вы хотите более тонко управ лять репликацией, то можете изменить время доступности связей, например задать расписание, указывающее, что связь доступна только в нерабочее время, чтобы репли кация не мешала использованию WAN-каналов в других целях. Но имейте в виду: такая блокировка репликации в определенное время не только отдает приоритет друго му WAN-трафику, но и увеличивает задержку при репликации — время, которое требу ется, чтобы все контроллеры данного домена пришли в одно и то же состояние. Когда при репликации между двумя сайтами используется несколько связей, реп ликация домена не завершится, пока каждая связь в этой цепочке не получит возмож ность передать данные репликации. Помимо репликации по расписанию, есть еще один подход — задание интервала репликации. Это значение указывает, насколько часто должна выполняться реплика ция с использованием данной связи. По умолчанию интервал репликации равен 180 минутам, т. е. репликация между сайтами происходит примерно раз в три часа (если это позволяет расписание, заданное для связи). Как и создание расписания, определение интервала репликации — своего рода искусство. Задавая более продолжительные ин тервалы, вы сокращаете трафик по WAN-каналу, но увеличиваете задержку при реп ликации.
Создание связей сайтов При установке Active Directory для протокола IP создается объект связи сайта по умол чанию — DEFAULTIPSITELINK. Этот объект сопоставляется с сайтом, используемым по умолчанию. Для протокола SMTP объект связи сайта по умолчанию не создается. При создании дополнительных связей учтите следующее. • Убедитесь, что все сайты соединены друг с другом. • Когда вы добавляете сайт в связь, проверьте, не является ли этот сайт членом другой связи, и, если это нужно, удалите ее. Иначе КСС сгенерирует топологию, в которой данный сайт будет членом двух связей. • Используйте для именования связей сайтов единую схему, позволяющую идентифи цировать их предназначение. • Используйте для всех связей сайтов транспортный протокол RPC поверх IP за ис ключением случаев, когда ваша сеть не обеспечивает полную маршрутизацию и приходится применять SMTP.
Серверы-плацдармы После создания связей сайтов КСС автоматически назначает один или несколько кон троллеров в каждом домене на роль серверов-плацдармов (bridgehead servers), или серве ров репликации между сайтами. Данные репликации передаются между этими серве рами, а не напрямую между всеми контроллерами домена (рис. 5-7). Запомните, что внутри сайта контроллеры домена (в том числе и серверы репликации между сайтами) выполняют репликацию, как только в ней возникает необходимость. Затем, когда со гласно расписанию связи доступны, серверы-плацдармы инициируют репликацию с аналогичными серверами других сайтов через заданный интервал.
Занятие 3
Планирование стратегий репликации
Рис. 5-7. Серверы репликации между сайтами Соединения репликации, создаваемые КСС, случайным образом распределяются между всеми серверами сайта, которые могут быть плацдармами репликации между сайтами, — это делается для распределения нагрузки по поддержке репликации. Обыч но КСС распределяет соединения, только когда создаются новые объекты-соединения. Однако в Windows Server 2003 Resource Kit имеется утилита Active Directory Load Balancing (ADLB), которую можно использовать для перераспределения ролей серве ров-плацдармов в любое другое время (например, при добавлении новых контроллеров домена).
Лабораторная работа. Создание структуры сайтов и стратегии репликации На этой лабораторной работе вы создадите проект сайтов для компании Northwind Trad ers. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытайтесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы.
Сценарий Компания Northwind Traders производит линейку сетевых устройств, расширяющих возможности в передаче данных. Сейчас Northwind Traders использует основную мо дель доменов Microsoft Windows NT 4.0 (master domain model). В последние годы компа ния значительно расширилась и ожидает дальнейшего существенного роста в следую щие три года, в том числе увеличения своей доли рынка, доходов и численности со трудников. Помимо открытия двух новых офисов, администрация решила реализовать новый проект Windows Server 2003 Active Directory, отвечающий текущим и будущим потребностям компании. В следующей таблице перечислены территории, отделы на каждой территории и количество пользователей. Территория Париж
Отделы Администрация в штаб-квартире Финансы Продажи Маркетинг Производство Исследования Разработка ИТ
Число пользователей 2000
(см. след. стр.)
168
Глава 5
Планирование сайтов
(окончание) Территория
Отделы
Число пользователей
Лос-Анджелес
Продажи Маркетинг Финансы ИГ Обслуживание клиентов Техническая поддержка клиентов Обучение Исследования Разработка Долгосрочные проекты ИТ Консалтинг Производство Продажи Финансы
1000
Атланта
Глазго, Шотландия
Сидней, Австралия
750
750
500
Большая часть вычислительных мощностей компании находится в главном офисе в Париже. Корпоративный ИТ-отдел хочет централизовать управление паролями и пара метрами защиты. Локальному ИТ-отделу в Лос-Анджелесе нужно сохранить управле ние свой инфраструктурой без участия корпоративного ИТ-отдела. Локальный ИТ-от дел в Глазго требует эксклюзивного управления своей сетевой средой по соображениям безопасности, так как должен исключить несанкционированный доступ к данным, получаемым в результате научно-исследовательских и опытно-конструкторских работ (research and development, R&D). Ton-менеджеры корпорации разделяют эту озабочен ность и хотят добиться максимальной защиты данных R&D. Следующая схема отражает соединения между разными территориальными участ ками компании. Кроме того, в Лос-Анджелесе и Атланте имеются VPN-соединения с главным офисом в Париже через Интернет.
(Лос-Анджелес)
f
Атланта ^
4 w
V
" - " " iШирокополосное lk соединение
В следующей таблице дана остальная информация о возможностях соединений в рамках компании Northwind Traders.
Занятие 3
Планирование стратегии репликации
Связь
Тип
Скорость
Доступная пропускная способность
Париж — Интернет
Dual ЕЗ (с избыточностью) Fractional El El Широкополосное соединение Т1
34,368 Мбит/с
10 Мбит/с
768 Кбит/с 2,048 Мбит/с 1,5 Мбит/с
128 Кбит/с 32 Кбит/с 384 Кбит/с
1,544 Мбит/с
56 Кбит/с
Париж — Глазго Париж — Сидней Атланта — Интернет Лос-Анджелес — Интернет
Вопросы к лабораторной работе Исходя из этого сценария, ответьте на следующие вопросы. 1. Нарисуйте схему сайтов для компании Northwind Traders, в том числе все связи сайтов, которые вы создадите. Укажите цену, которую вы назначите каждой такой связи. Кроме того, задайте расписание для тех связей, для которых не годится рас писание по умолчанию. 2. Собираетесь ли вы отключить транзитивность связей сайтов? Если да, то будете ли вы создавать какие-либо мосты связей сайтов?
Закрепление материала Ответив на вопросы, приведенные ниже, вы сможете лучше усвоить основные темы за нятия. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытайтесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы. 1. Какие характеристики должны быть у WAN-каналов, чтобы за ними можно было закрепить общую связь сайта? 2. Расскажите, чем отличается внутрисайтовая репликация от межсайтовой. 3. Перечислите причины, по которым может потребоваться отключить транзитивность связей сайтов.
Резюме •
Внутрисайтовая репликация оптимизирована для повышения скорости. Контролле ры домена реплицируют изменения сразу после их внесения и передают данные в несжатом формате. Межсайтовая репликация оптимизирована для минимального использования пропускной способности. При этом происходит обмен информацией между серверами-плацдармами (серверами репликации между сайтами), данные сжимаются, и можно задать расписание доступности связей сайтов и интервалы, через которые выполняется репликация. • Сервис Knowledge Consistency Checker (КСС) автоматически создает и изменяет топологию объектов-соединений, необходимых, чтобы контроллеры домена могли обмениваться данными репликации. • Связь сайта — это объект Active Directory, представляющий соединение между дву мя или более сайтами. Для репликации между сайтами нужно установить связь между ними. Все сайты, входящие в такую связь, должны быть соединены сетью одного типа. Каждой связи сайта назначается цена, определяющая, какие связи
Плакирование сайтов
Глава 5
лучше выбирать при определении пути репликации. По умолчанию всем связям назначается цена 100. и По умолчанию связи сайтов являются транзитивными. Вы можете отключить тран зитивность, но тогда, чтобы выполнять репликацию данных между всеми сайтами домена, потребуется вручную создать мосты связей сайтов.
Занятие 4. Разработка стратегии перехода Если вы проектируете структуру Active Directory для уже работающей сети на основе Microsoft Windows NT 4 или Windows 2000, вам придется подумать над тем, как перейти на Windows Server 2003 и реализовать новую инфраструктуру сети. Если вы следовали рекомендациям из главы 2, то уже хорошо понимаете существующую инфраструктуру сети и располагаете набором схем, описывающих эту инфраструктуру. На этом занятии рассказывается, как перейти от Windows NT 4 и Windows 2000 к Windows Server 2003. Изучив материал этого занятия, вы сможете:
•S рассказать об основных проблемах перехода от доменов Windows NT 4; •/ описать основные проблемы перехода от доменов Windows 2000. Продолжительность занятия — около 10 минут.
Переход от доменов Windows NT 4 Между Windows NT 4 и Windows Server 2003 много отличий. С точки зрения проектиро вания доменов, одно из самых больших отличий в том, что в Windows NT 4 не исполь зуются сайты. В Windows NT 4 для создания структуры управления репликацией и логической структуры безопасности служат домены. Поэтому создание доменов в сети на основе Windows NT 4 подчиняется другой логике. Часто для управления трафиком репликации создается несколько доменов там, где в случае Windows Server 2003 можно было бы создать один домен и несколько сайтов. Кроме того, в Windows NT 4 домены применяются для реализации административной структуры, тогда как в Windows Server 2003 можно было бы обойтись одним доменом и несколькими организационными еди ницами (OU). Учитывая эти различия, переход от структуры доменов Windows NT 4 к структуре доменов Windows Server 2003 можно осуществить двумя способами: изменением струк туры доменов или усовершенствованием существующих доменов. Реструктуризация доменов в долгосрочном плане дает больше преимуществ, чем усовершенствование существующих доменов. В большинстве случаев структуру, со держащую несколько доменов Windows NT 4, можно преобразовать в структуру, со держащую один (или хотя бы меньше, чем раньше) домен Windows Server 2003. Кроме того, сеть с хорошо продуманной структурой сайтов и OU почти всегда работает эф фективнее. Однако усовершенствование существующей структуры доменов дает свои преиму щества. Этот подход также следует принимать во внимание. В частности, он годится при следующих обстоятельствах. • Существующую структуру доменов несложно перенести в среду Windows Server 2005, • Вы должны спроектировать и развернуть сеть за весьма ограниченное время.
Занятие 4
Разработка стратегий перехода
-jy^
•
Вы хотите свести к минимуму изменения в текущей административной структуре и управлении передачей информации по сети. • Вам нужно, чтобы переход как можно меньше повлиял на работу пользователей и администраторов.
Переход от доменов Windows 2000 Если вы обновляете структуру доменов Windows 2000, перед вами стоит более простая задача, чем при переходе от Windows NT 4. Большинство функций Active Directory, реализованных в Windows Server 2003, доступно и в Windows 2000, поэтому в распоряже нии проектировщика сети уже имеется продуманная архитектура: структура лесов и доменов, административная структура, размещение сайтов и контроллеров домена и топология репликации. Решение, которое позволит свести к минимуму издержки и усилия, затрачиваемые на проектирование, — обновить контроллеры доменов и задействовать существующую структуру доменов. Обновление существующих доменов также позволяет свести к ми нимуму неудобства, причиняемые пользователям, и время, когда сеть недоступна. Вы можете обновить с Windows 2000 либо все контроллеры доменов, либо некоторые, но имейте в виду, что кое-какие функции, введенные в Windows Server 2003, будут недо ступны, если не все контроллеры в домене или лесу работают под управлением Windows Server 2003. Это функциональный уровень леса или домена. Что такое функциональ ные уровни, см. в главе 1. Перед подготовкой леса Windows 2000 к обновлению до Windows Server 2003 или добавлением нового контроллера домена под управлением Windows Server 2003 необхо димо запустить программу Adprep.exe (Active Directory Preparation), которая находится в папке \I386 на дистрибутивном компакт-диске Windows Server 2003. Это средство подготавливает леса и домены: добавляет в схему соответствующие изменения, сбрасы вает разрешения на доступ к встроенным контейнерам и объектам Active Directory и обновляет административные средства. Примечание В этом разделе дано лишь поверхностное описание методики перехода. Подробнее об обновлении и изменении структуры — в Microsoft Windows Server 2003 Deployment Kit (Microsoft Press, 2003).
Закрепление материала Ответив на вопросы, приведенные ниже, вы сможете лучше усвоить основные темы за нятия. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытай тесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы. 1. Каковы основные различия Windows NT 4 и Windows Server 2003 с точки зрения проектирования структуры доменов? 2. В каких случаях при переходе с Windows NT 4 на Windows Server 2003 стоит поду мать об усовершенствовании существующей структуры доменов, а не о ее измене нии? 3. Можно ли обновить с Windows 2000 до Windows Server 2003 лишь некоторые кон троллеры доменов? 7 Зак. 312
Планирование сайтов
Глава 5
Резюме •
С точки зрения проектирования, самое главное различие между Windows NT 4 и Windows Server 2003 — введение сайтов, позволяющих отделить физическую струк туру сети от логической структуры доменов, и появление организационных единиц, позволяющих делить домены на дополнительные области административного управ ления. • При переходе с Windows NT 4 на Windows Server 2003 обновлять существующие домены вместо того, чтобы изменять структуру доменов, рекомендуется в следую щих случаях: перенос существующей структуры доменов не составляет труда, нуж но свести к минимуму неудобства для пользователей, нужно свести к минимуму изменения в административной структуре и управлении передачей информации, у вас мало времени или денежных средств. • Если вы обновляете операционную систему с Windows 2000 до Windows Server 2003, самая простая и эффективная стратегия перехода — обновить существующие до мены.
Ц Пример из практики Рассмотрите следующий пример из практики и ответьте на вопросы.
Сценарий Вы должны составить план новой инфраструктуры для Contoso Ltd., производителя модемов с главным офисом в Далласе, штат Техас. В настоящее время все серверы в сети этой компании работают под управлением Windows NT Server 4.0. На клиентских компьютерах установлены разные системы — Windows 98 и Windows 2000 Professional. Contoso наняла вас для модернизации сетевой инфраструктуры компании. Нужно, что бы все серверы работали под управлением Windows Server 2003 и чтобы вы подготовили проект реализации Active Directory. Компания также хочет перевести все клиентские компьютеры на Windows XP Professional.
Краткие сведения о компании За последнее десятилетие Contoso стала одним из основных производителей модемов в стране, продавая их главным образом крупным компаниям и интернет-провайдерам (Internet Service Providers, ISP). Два года назад Contoso приобрела лондонскую фирму Trey Research — производителя модемов, которая ориентирована на аналогичный ры нок в Европейских странах.
География В главном офисе в Далласе работает 1900 пользователей и имеется полностью уком плектованный сотрудниками ИТ-отдел. Кроме основного участка, Contoso располагает двумя филиалами в США — в Мемфисе (Теннеси) и Сан-Диего (Калифорния). В фи лиале в Сан-Диего работает 185 пользователей, и есть собственный ИТ-отдел. В фили-
Пример из практики
173
пе в Мемфисе 35 пользователей, а ИТ-отдела нет. Этот филиал обслуживается ИТ}тделом, расположенным в главном офисе в Далласе. Филиал в Мемфисе расположен в небольшом здании, доступ к рабочим местам не ограничен. Поскольку в этом фили але нет своего ИТ-отдела, сотрудники филиала не могут обеспечить сопровождение и физическую безопасность своих серверов. Дочерняя компания (Trey Research) находится в Лондоне. В лондонском офисе ра ботает 215 пользователей — он располагает полным штатом сотрудников, в том числе собственным ИТ-персоналом, и самостоятельно управляет своей сетевой инфраструк турой. Лондонский офис также поддерживает собственное пространство имен.
Сетевая инфраструктура Главный офис в Далласе соединен с филиалом в Мемфисе и Сан-Диего 512-килобитным каналом, а с офисом в Лондоне — 256-килобитным каналом. В качестве опорной сети (backbone) офисы в Далласе и Лондоне используют 155-мегабитную ATM. Клиен ты подключаются к опорной сети через 10/100-мегабитные соединения. В филиалах все клиенты и серверы связаны 10/100-мегабитными соединениями. Сеть офиса в Далласе состоит из четырнадцати подсетей, сеть офиса в Сан-Диего — из трех, а офиса в Мем фисе — из одной. В настоящее время на каждом территориальном участке сконфигурирован свой до мен, имя которого соответствует названию участка. Уже принято решение о создании домена contoso.com, который будет использоваться офисами в Далласе, Сан-Диего и Мемфисе. Кроме того, для компании в Лондоне будет создан еще один домен — treyresearch.com, содержащийся в отдельном дереве.
Планы на будущее На данный момент у компании нет планов по значительному расширению штатов. Од нако не исключено, что компания приобретет небольшую фирму в Монреале, которая владеет новой многообещающей технологией, относящейся к модемам. Если покупка состоится, компания в Монреале сохранит свой ИТ-персонал и собственное простран ство имен. Ваши планы должны учитывать этот момент.
ИТ-менеджмент ИТ-персонал в Далласе отвечает за обслуживание офисов в Далласе и Мемфисе. Сети в офисах в Лондоне и Сан-Диего обслуживаются местными штатами ИТ-сотрудников. Однако основной ИТ-отдел в Далласе отвечает в конечном счете за всю сеть.
Вопросы Исходя из этого сценария, ответьте на следующие вопросы. 1. Сколько сайтов вы бы использовали? Нарисуйте схему этих сайтов. 2. Какое минимальное количество контроллеров домена следует использовать в каж дом сайте? 3. Сколько связей сайтов нужно создать для этой сети? 4. Где бы вы разместили серверы глобального каталога этой сети?
•|74
Планирование сайтэв
Глава 5
щ] Резюме главы в
в
•
в
в
•
в
в
в
в
в
Сайты используются для управления сетевым трафиком, генерируемым при входе на рабочие станции, при репликации данных Active Directory, работе DFS (Distributed File System) и FRS (File Replication Service). Чтобы подготовиться к разработке структуры сайтов, нужны сведения о территори альной структуре компании, структуре и скорости локальной сети каждого из офи сов, TCP/IP-подсетях каждого из офисов и пропускной способности каналов между офисами. Вы должны создать по сайту для каждой LAN (или группы LAN, соединенных вы сокоскоростной сетевой магистралью), каждого участка, где есть контроллер доме на, и каждого участка, где имеется служба, работающая с сайтами. Основная причина помещения контроллеров доменов в сайт — необходимость изба виться от передачи WAN-трафика между сайтами. Этот трафик может генериро ваться, когда пользователи связываются с контроллерами доменов при аутентифи кации, когда приложения, работающие с сайтами, обращаются к контроллерам доменов, чтобы выполнить поиск, а также при репликации. Если пользователей сайта менее 1000, достаточно одного контроллера домена. Если пользователей от 1000 до 10 000, рекомендуется установить два контроллера домена. Для каждых дополнительных 5000 пользователей сверх 10 000 добавляйте один кон тролер домена. Однако даже в сайтах менее чем с 1000 пользователей следует уста навливать второй контроллер домена, чтобы обеспечить отказоустойчивость. По возможности назначайте все роли хозяина операций для леса или домена одному и тому же контроллеру домена. Запомните следующее правило: хозяин инфраструк туры не должен хранить глобальный каталог за исключением случая, когда все дру гие контроллеры этого домена тоже содержат глобальный каталог. На серверах глобального каталога хранится подмножество атрибутов объектов Active Directory, к которым чаще всего обращаются пользователи или клиентские компью теры. Они позволяют пользователям входить в сеть и искать объекты Active Director, по всему лесу, не обращаясь к тем контроллерам домена, где хранятся эти объекты. Требования к оборудованию контроллера домена в основном зависят от числа пользо вателей, которые должны проходить аутентификацию в домене. Определив требова ния в соответствии с этим критерием, примите во внимание, является ли контрол лер домена сервером глобального каталога и выполняет ли он другие роли. Внутрисайтовая репликация оптимизирована для повышения скорости. Контролле ры домена реплицируют изменения сразу после их внесения и передают данные s несжатом формате. Межсайтовая репликация оптимизирована для минимального использования пропускной способности. При этом происходит обмен информацией между серверами-плацдармами (серверами репликации между сайтами), данные сжимаются, и можно задать расписание доступности связей сайтов и интервалы через которые выполняется репликация. Сервис Knowledge Consistency Checker (KCC) автоматически создает и изменяет топологию объектов-соединений, необходимых, чтобы контроллеры домена мог~> обмениваться данными репликации. Связь сайта — это объект Active Directory, представляющий соединение между дв;. мя или более сайтами. Для репликации между сайтами нужно установить свя:-; между ними. Все сайты, входящие в такую связь, должны быть соединены сеть:-:
Рекомендаций по подготовке к экзамену
•
•
•
•
-j j g
одного типа. Каждой связи сайта назначается цена, определяющая, какие связи лучше выбирать при определении пути репликации. По умолчанию всем связям назначается цена 100. По умолчанию связи сайтов являются транзитивными. Вы можете отключить тран зитивность, но тогда, чтобы выполнять репликацию данных между всеми сайтами домена, потребуется вручную создать мосты связей сайтов. С точки зрения проектирования, самое главное различие между Windows NT 4 и Windows Server 2003 — введение сайтов, позволяющих отделить физическую струк туру сети от логической структуры доменов, и появление организационных единиц, позволяющих делить домены на дополнительные области административного управ ления. При переходе с Windows NT 4 на Windows Server 2003 обновлять существующие домены вместо того, чтобы изменять структуру доменов, рекомендуется в следую щих случаях: перенос существующей структуры доменов не составляет труда, нуж но свести к минимуму неудобства для пользователей, нужно свести к минимуму изменения в административной структуре и управлении передачей информации, у вас мало времени или денежных средств. Если вы обновляете операционную систему с Windows 2000 до Windows Server 2003, самая простая и эффективная стратегия перехода — обновить существующие до мены.
Л Рекомендации по подготовке к экзамену Прежде чем сдавать экзамен, повторите основные положения и термины, приведенные ниже, чтобы выяснить, какие темы нужно проработать дополнительно.
Основные положения •
Сайты применяются для управления WAN-трафиком, генерируемым при входе на рабочие станции, трафиком репликации, трафиком DFS (Distributed File System) и FRS (File Replication Service). Создавайте по сайту для каждой LAN или группы LAN, соединенных высокоскоростной опорной сетью (10 Мбит/с и выше). Созда вайте по сайту для каждого территориального участка, где вы планируете устано вить контролер домена. Создавайте по сайту для каждого участка, содержащего сер вер, на котором выполняется приложение, работающее с сайтами. • Устанавливайте контроллеры доменов на участках, где много пользователей и где пользователи должны иметь возможность входить в сеть, когда WAN-канал не рабо тает, или на участках, где выполняются приложения, работающие с сайтами. • Используйте один контроллер домена в сайтах, где менее 1000 пользователей, два контроллера домена, если число пользователей от 1000 до 10 000, а для каждых 5000 пользователей сверх 10 000 добавляйте по одному контроллеру домена. • В лесу с одним доменом сделайте все контроллеры домена серверами глобального каталога, поскольку при этом экономится место и не генерируется дополнительный трафик репликации. В лесах с несколькими доменами можно создать столько сер веров глобального каталога, сколько вы считаете нужным для того, чтобы обеспе чить балансировку нагрузки и избыточность. Microsoft рекомендует устанавливать в каждый сайт минимум по одному серверу глобального каталога.
Планирование сайтов
•
Глава 5
Внутрисайтовая репликация оптимизирована для достижения максимальной скоро сти. Контроллеры домена реплицируют изменения сразу после того, как они про изошли, данные репликации не сжимаются. Межсайтовая репликация оптимизиро вана для минимального расходования пропускной способности: в репликации уча ствуют серверы-плацдармы, данные сжимаются, можно задать расписание доступ ности связей сайтов и интервал, через который выполняется репликация.
Основные термины Knowledge Consistency Checker — Windows-сервис, создающий и изменяющий тополо гию репликации доменов, основанную на объектах-соединениях. Транзитивность связей сайтов ~ site-link transitivity — по умолчанию связи сайтов транзитивны. Соединения, поддерживаемые с помощью таких связей, доступны, даже если сайты не соединены напрямую. Вы можете отключить транзитивность связей, но тогда придется создавать мосты связей для сайтов, не связанных напрямую. Хозяева операций - operations masters — определенные роли в домене и в лесу могут принадлежать только одному контроллеру домена. Существует три роли хозяина опе раций уровня домена (эмулятор основного контроллера домена, хозяин RID и хозя ин инфраструктуры) и две роли хозяина операций уровня леса (хозяин схемы и хозяин именования доменов).
Щ
Вопросы и ответы
Занятие 1. Закрепление материала 1. Вы разрабатываете структуру сайтов для компании, у которой имеются филиалы в Атланте, Чикаго и Лос-Анджелесе. Каждый филиал связан с двумя другими линия ми с пропускной способностью 512 Кбит/с. Сколько сайтов вы бы создали? Правильный ответ: нужно определить три сайта — по одному для каждого участка. Чтобы подсети входили в один сайт, их должно связывать соединение с пропускной способностью 10 Мбит/с и выше. 2. Какие задачи управления сетевым трафиком решают с помощью сайтов? Правильный ответ: сайты используются для управления сетевым трафиком, генерируе мым при входе на рабочие станции, при репликации Active Directory, работе DFS и FRS. 3. По каким критериям следует определять, нужно ли создавать сайт? Правильный ответ: создавайте по сайту для каждой LAN или группы LAN, соединенных высокоскоростной сетевой магистралью (опорной сетью). Создавайте по сайту для каж дого участка, где вы собираетесь установить контроллер домена. Кроме того, создавай те по сайту для каждого участка, где есть сервер, на котором выполняется приложение, работающее с сайтами, или где возникает задержка, связанная с большим расстояниеч или типом WAN-канала (например при использовании спутниковой связи).
Занятие 2. Лабораторная работа 1. Сколько контроллеров домена вы установили бы в каждом сайте? Почему? Укажет; их количество в следующей таблице.
Вопросы и ответы Число контроллеров домена в каждом сайте
Домен Nwtraders.local AsiaPacific.nwtraders.local
Париж 2
Глазго 0
Сидней 1
Атланта 1
Лос-Анджелес 1
1
0
2
0
0
NAeastnwtraders.local
1
0
0
2
0
NAwest.nwtraders.local
1
0
0
0
2
Coф.nwtraders.local
3
1
1
2
1
RDNwtraders.local Glasgow. RDNwtraders .local
1
2
0
0
0
1
2
0
0
0
На этот вопрос можно дать только один ответ. В Париже установите по одному контроллеру для каждого домена, чтобы облегчить вход пользователей, приезжающих в Париж из других филиалов. Кроме того, в Париже нужно установить три контроллера для домена corp.nwtraders.local: два — для управле ния локальной аутентификацией и один — для управления репликацией в удаленные офисы. Чтобы обеспечить избыточность, добавьте два контроллера для корневого доме на леса (nwtraders.local). В Глазго установите два контроллера для корневого домена леса RDNwtraders.local и два для домена Glasgow.RDNwtraders.local. По два контроллера для каждого домена нужны, чтобы обеспечить отказоустойчивость Active Directory. Кроме того, в Глазго требуется установить один контроллер для домена corp.nwtraders.local, чтобы пользова тели, которые приезжают из главного офиса, могли входить в сеть. В каждом из осталь ных сайтов установите два контроллера для локального домена, чтобы обеспечить отка зоустойчивость, один контроллер для корневого домена леса и один контроллер для домена corp.nwtraders.local, чтобы сотрудники, приезжающие из главного офиса, могли входить в сеть, не используя WAN-канал. В каких сайтах вы разместили бы серверы глобального каталога? В каких сайтах вы включили бы кэширование членства в универсальных группах? Заполните следую щую таблицу. Сайт
Число серверов глобального ката лога для леса Nwtraders.local
Число серверов глобального ката лога для леса RDNwtraders.local
Включить кэширо вание членства в группах для сайта (да/нет)
Париж
2
1
Нет
Глазго
1
1
Нет
Сидней
1
0
Нет
Атланта Лос-Анджелес
1
0
Нет
1
0
Нет
Правильный ответ: для поддержки локального входа в каждом сайте, кроме парижско го, должна быть одна копия глобального каталога для леса nwtraders.local. В Париже нужны две копии глобального каталога, поскольку в этом офисе работает много пользо вателей и поскольку сотрудники местного ИТ-отдела часто выполняют поиск в БД Active Directory.
Jg
Планирование сайтов
Глава 5
Занятие 2. Закрепление материала 1. По каким причинам в сайты помещают контроллеры домена? Какие причины могут быть для того, чтобы не помещать в сайт контроллер домена? Правильный ответ: если сайт содержит много пользователей, установка локального кон троллера домена уменьшает трафик аутентификации, передаваемый на другие сайты. Если WAN-канал между сайтами перестанет работать, наличие локального контроллера домена позволит проводить аутентификацию. Если в сайте выполняются приложения, работающие с сайтами, использование локального контроллера домена сократит WANтрафик. Контроллер домена не следует помещать в сайт, если ни один сотрудник, работающий в данном месте, не умеет управлять контроллером домена (и обеспечить удаленный доступ тоже нельзя) или если нет гарантий физической безопасности контроллера домена. 2. Вы определяете, сколько контроллеров доменов нужно установить в сайте. Сайт охватывает 15 000 пользователей. Поддерживается восемь соединений репликации с сайтом. Сколько контроллеров доменов следует установить? Правильный ответ: в этом сайте следует установить минимум три контроллера домена. Если пользователей от 1000 до 10 000, рекомендуется установить два контроллера. Для каждых 5000 пользователей сверх 10 000 нужно добавлять один контроллер домена. 3. Какие рекомендации следует выполнять при установке серверов глобального ката лога? Правильный ответ: устанавливайте минимум один сервер глобального каталога в каж дом сайте. В лесу с одним доменом сделайте все контроллеры домена серверами глобаль ного каталога, поскольку это не потребует дополнительного места и не приведет к гене рации дополнительного трафика. В лесах с несколькими доменами можно создать столько серверов глобального каталога, сколько нужно, чтобы обеспечить балансировку нагруз ки и избыточность.
Занятие 3. Лабораторная работа 1. Нарисуйте схему сайтов для компании Northwind Traders, в том числе все связи сайтов, которые вы создадите. Укажите цену, которую вы назначите каждой такой связи. Кроме того, задайте расписание для тех связей, для которых не годится рас писание по умолчанию. Правильный ответ: создавайте по одной связи сайта для каждого WAN-канала или VPNсоединения. Если доступная пропускная способность соединения меньше 64 Кбит/с, за давайте расписание репликации для этого соединения, чтобы репликация не выполнялась в период с 8 утра до 5 вечера по местному времени на каждом из участков, где исполь зуется это соединение. Для стандартизации местное время преобразовывают во время по Гринвичу (Greenwich Mean Time, GMT). По формуле, приведенной в этой главе, вычи сляют цены связей сайтов. 2. Собираетесь ли вы отключить транзитивность связей сайтов? Если да, то будете л;: вы создавать какие-либо мосты связей сайтов? Правильный ответ: ответы на этот вопрос могут быть разными. Один из возможных ответов — отключать транзитивность связей, если вы используете региональную модель доменов и пропускная способность WAN-каналов ограничена. Тогда создавать мосты связей сайтов не требуется.
.опросы и ответу
179
Занятие 3. Закрепление материала '-. Какие характеристики должны быть у WAN-каналов, чтобы за ними можно было закрепить общую связь сайта? Правильный ответ: связь сайта должна объединять WAN-каналы одного типа и скоро сти, если только вы не собираетесь использовать разные расписания. 2. Расскажите, чем отличается внутрисайтовая репликация от межсайтовой. Правильный ответ: внутрисайтовая репликация оптимизирована для высокопроизводи тельных сетей. Она основана на уведомлении об изменениях. Данные отправляются в несжатом виде. Межсайтовая репликация оптимизирована для минимизации использо вания полосы пропускания. Ее выполняют серверы-плацдармы (серверы репликации меж ду сайтами). Для репликации между сайтами задают расписание доступности связей сайтов и интервал, через который выполняется репликация. 3. Перечислите причины, по которым может потребоваться отключить транзитивность связей сайтов. Правильный ответ: отключив транзитивность связей сайтов, вам придется вручную кон фигурировать мосты связей сайтов, чтобы определить путь репликации между сайтами. Поэтому рекомендуется оставлять включенной транзитивность связей сайтов. Для от ключения транзитивности могут быть следующие причины: сеть не обеспечивает полную маршрутизацию или вам нужно полностью контролировать пути репликации в сети.
Занятие 4. Закрепление материала 1. Каковы основные различия Windows NT 4 и Windows Server 2003 с точки зрения проектирования структуры доменов? Правильный ответ: основное отличие в том, что в Windows Server 2003 введены сайты, позволяющие отделять физическую структуру сети от логической структуры доменов, и организационные единицы (OU), позволяющие делить домены на меньшие области адми нистрирования. 2. В каких случаях при переходе с Windows NT 4 на Windows Server 2003 стоит поду мать об усовершенствовании существующей структуры доменов, а не о ее измене нии? Правильный ответ: обновлять существующие домены, а не изменять их структуру реко мендуется, когда 1) не составляет труда перенести текущую структуру доменов, 2) нуж но свести к минимуму неудобства для пользователей, 3) следует свести к минимуму изме нения в административной структуре или в управлении потоками информации, 4) на процесс переход выделены ограниченные время и бюджет. 3. Можно ли обновить с Windows 2000 до Windows Server 2003 лишь некоторые кон троллеры доменов? Правильный ответ: да, домен может работать в смешанном режиме. Состояние контрол леров в домене или лесу называют функциональным уровнем. Если все контроллеры доменов в лесу работают под управлением Windows Server 2003, говорят, что лес или домен работает на функциональном уровне Windows Server 2003, и ему доступны все возможности, предоставляемые этой ОС.
Планирование сайтов
Глава 5
Пример из практики 1. Сколько сайтов вы бы использовали? Нарисуйте схему этих сайтов. Правильный ответ: скорее всего в этой сети нужно использовать три сайта: общий сайт для Далласа и Мемфиса, сайт для Сан-Диего и сайт для Лондона. Причины того, что для офиса в Мемфисе не создается отдельный сайт, заключаются в следующем: 1) до вольно мало пользователей, следовательно, WAN-трафик при входе на рабочие станции будет незначительным, 2) в Мемфисе нет ИТ-отдела, который поддерживал бы кон троллер домена, и 3) нет гарантий физической безопасности контроллера домена. 2. Какое минимальное количество контроллеров домена следует использовать в каж дом сайте? Правильный ответ: минимальное число контроллеров домена для сайта равно 1. Однако пользователей сайта в Далласе достаточно много, поэтому следует установить второй контроллер домена, чтобы обрабатывать запросы аутентификации. Кроме того, реко мендуется создавать для каждого сайта по два контроллера домена, чтобы обеспечить отказоустойчивость. 3. Сколько связей сайтов нужно создать для этой сети? Правильный ответ: нужно создать одну связь для соединения сайта Даллас-Мемфис с сайтом Сан-Диего и одну связь для соединения Далласа с Лондоном. 4. Где бы вы разместили серверы глобального каталога этой сети? Правильный ответ: по возможности все контроллеры домена должны быть серверами глобального каталога, поскольку контроллеры будут присутствовать на каждом из ос новных участков. Трафик аутентификации, генерируемый 35 пользователями в Мемфи се, незначителен, поэтому в офисе в Мемфисе не будет установлен контроллер домена. Если вы решите не делать все контроллеры домена серверами глобального каталога, позаботьтесь о том, чтобы в каждом сайте был свой сервер глобального каталога.
ГЛАВА
6
Проектирование структуры DNS
Занятие 1 . Анализ существующей реализации DNS
182
Занятие 2. Проектирование стратегии разрешения DNS-имен
188
Занятие 3. Проектирование реализации DNS
199
Занятие 4. Разработка стратегии размещения служб DNS
202
Темы экзамена •
Проектирование инфраструктуры сетевых служб, отвечающей бизнес-требованиям и техническим условиям: а создание концептуального плана инфраструктуры DNS.
• Анализ возможностей DNS для внедрения службы каталогов Active Directory: • анализ существующей инфраструктуры DNS; а анализ существующего пространства имен. •
Проектирование стратегии разрешения DNS-имен: • создание проекта пространства имен; а определение возможности взаимодействия DNS с Active Directory, WINS и DHCP; • определение требований к зонам; а проектирование защиты DNS.
•
Проектирование стратегии взаимодействия DNS со службой имен Berkeley Internet Name Domain (BIND) UNIX для поддержки службы каталогов Active Directory. • Внедрение служб DNS: а разработка стратегии хранения зон DNS; • использование параметров DNS-сервера; а требования к регистрации некоторых записей DNS. •
Проектирование размещения служб DNS.
Прееотрование структуры DNS
Глава 6
В этой главе
Перед проектированием структуры доменной системы именования (Domain Name System DNS) для организации необходимо составить четкую схему инфраструктуры компании с подробными сведениями о размещении серверов, маршрутизаторов и коммутаторов, контроллеров доменов, серверов приложений, пользователей и их групп, подразделе ний и т. д. (см. главу 2). Без этой информации спроектировать структуру DNS вряд ли возможно, так как она основана на физической топологии сети компании. Эта глава посвящена разработке инфраструктуры сетевых служб с целью обеспе чения взаимодействия DNS с WINS, DHCP и Active Directory. Обычно в организа циях уже имеется инфраструктура DNS, кроме случаев, когда приходится создавать сеть «с нуля». Часто DNS реализуют на основе ОС UNIX, что требует интеграции BIND-версии DNS и Active Directory. В силу этих причин очень важно научиться определять текущий тип реализации DNS. В начале главы рассматривается анализ существующей реализации DNS, затем освещается стратегия проектирование и вне дрение DNS «с нуля».
Прежде всего Для понимания материала этой главы необходимо овладеть понятиями, изложенными в главе 1, и научиться собирать информацию о существующей сети, как описано в главе 2.
Занятие 1. Анализ существующей реализации DNS Большинство администраторов, которым не требуется создавать сеть «с нуля», сталки ваются с необходимостью анализа и использования существующей инфраструктуры DNS. В этом занятии описаны компоненты DNS, рассмотрена терминология, необхо димая для проектирования и реализации стратегии DNS для корпоративной сети. Первый этап анализа инфраструктуры сети организации — анализ устройства са мой организации. Как сказано в главе 2, понимание принципов работы компании и хода информационных потоков внутри нее является основой проекта сети. На этом занятии вы научитесь собирать информацию о существующей инфраструктуре DNS. Изучив материал этого занятия, вы сможете:
•S распознавать различные компоненты инфраструктуры DNS; S описывать различные типы DNS-серверов и их функции в существующей инфраструктуре; •S анализировать существующее пространство имен. Продолжительность занятия — около 20 минут.
Обзор DNS Люди обычно не любят иметь дело с цифрами и заучивать IP-адреса, необходимые для подключения к ресурсам сети. Намного проще запомнить адрес www.microsoft.com, не-
Занятие 1
Анализ существующей реализации DNS
жели 172.16.45.67. Когда пользователь сети вводит полное доменное имя (Fully Qualified Domain Name, FQDN), какой-либо механизм или компонент должен преобразовать (разрешить) это имя в IP-адрес. Именно это и делает DNS. Как сказано в главе 1, процесс разрешения имен может быть довольно сложным. В этом разделе вы ознакоми тесь с различными компонентами, благодаря которым все это работает.
Компоненты DNS К этому моменту вы должны собрать всю информацию о физическом размещении от делов и подразделений вашей компании, составить схему сети. Теперь вы почти готовы к анализу структуры DNS в организации. На составленных ранее схемах отражено размещение серверов, маршрутизаторов, коммутаторов и т. д. Эта информация вкупе со сведениями о размещении и числе хостов, подсетей и маршрутизаторов позволит по нять, как устроена текущая инфраструктура DNS. Чтобы распознавать компоненты инфраструктуры DNS, прежде всего необходимо понять, как работает DNS. В сущности, DNS — это база данных. Подобно любой БД, она хранит и поддерживает перечень записей, точнее записей ресурсов. В табл. 6-1 показаны наиболее распространенные типы записей ресурсов, хранимые DNS-сервером в зоне. Табл. 6-1.
Типы записей ресурсов DNS
Тип записи
Описание
SOA (Start of Authority) начало полномочий
Содержится в начале каждой зоны
NS (Name Server) — сервер имен
Указывает на DNS-сервер, полномочный для данной зоны
A (host) — хост
Указывает FQDN, сопоставленное IP-адресу
PTR (Pointer Record) указатель
Указывает IP адрес, сопоставленный данному FQDN
CNAME (Canonical name) каноническое имя
Создает псевдоним для FQDN
MX (Mail Exchange) — почтовый сервер
Указывает почтовый сервер, обрабатывающий и пересылающий почтовые сообщения для определенного домена DNS
SRV (Service) — служба
Указывает расположение серверов, на которых работают определенные службы, например почтовые серверы, контроллеры доменов, Web-серверы и т. д.
Зоны DNS Зона (zone)— это непрерывная часть пространства имен DNS, управляемая DNS-cepвером как единое целое. В ней может храниться информация об одном или нескольких доменах. В зоне содержатся записи ресурсов одного домена. Например, пространство DNS-имен для домена contoso.com, принадлежащего компании Contoso, исходно мо жет создаваться как одна зона, но по мере роста домена и добавления поддоменов, таких как ftp.contoso.com, www.contoso.com, marketing.contoso.com и т. д. поддомены
184
Проектирование структуры DNS
Глава б
могут выделяться в отдельные зоны. Windows Server 2003 поддерживает различные виды зон (рис. 6-1). • Основная зона (Primary zone) — содержит локальную копию зоны DNS, где создают ся и обновляются записи ресурсов. • Дополнительная зона (Secondary zone) — копия зоны DNS, предназначенная только для чтения. Она обновляется только с помощью репликации основной зоны и слу жит для избыточности и балансировки нагрузки. • Зона, интегрированная в Active Directory (Active Director}' integrated zone) — основная зона, хранящаяся в БД Active Directory. • Зона-заглушка (Stub zone) — копия зоны, содержащая только записи ресурсов, не обходимые для поиска полномочных DNS-серверов. Это упрощает администрирова ние DNS и повышает эффективность разрешения имен.
Зона, интегрированная в Active Directory
Дополнительная зона
Основная зона интегрированная в Active Directory
Зона, интегрированная в Active Directory
Зона-заглушка, интегрированная в Active Directory
Рис. 6-1. Различные типы зон О настройке зон речь пойдет позже, а сейчас необходимо выяснить текущую кон фигурацию инфраструктуры DNS с целью ее документирования.
Зонные передачи Неразумно хранить все записи ресурсов сети на единственном DNS-сервере, необхо димо предусмотреть метод репликации этих важных данных на другие DNS-серверы. В Windows Server 2003 существует зонные передачи трех типов. • Добавочная зонная передача (Incremental Zone Transfer, IXFR) — серверы отслежива ют и передают только измененные записи ресурсов зоны. Преимущество этого спо соба в том, что он генерирует меньше трафика. и Полная зонная передача (Full Zone Transfer, AXFR) — в ответ на запрос DNS зона передается на дополнительный DNS-сервер целиком. Этот способ зонной передачи вызывает проблемы при использовании медленных WAN-каналов, поэтому важно выяснить и задокументировать, какие именно типы зонной передачи используются в данной сети. • Быстрая зонная передача (Fast zone transfer) — позволяет передавать в одном сообще нии несколько записей ресурсов, в Windows Server 2003 используется по умолча нию.
Занятие 1
Диализ существующей реализации BUS
Позже вы спроектируете инфраструктуру DNS в соответствии с топологией вашей сети, а сейчас необходимо научиться анализировать и определять конфигурацию DNS в имеющейся сети. Роли DNS-серверов Каждый DNS-сервер выполняют в сети свою функцию. Роли серверов следует указать на схеме размещения серверов в сети; подробнее об этом — в занятии 4. • Основной сервер имен — это DNS-сервер, на котором хранится файл БД локальной зоны, который можно обновлять. В целях обеспечения отказоустойчивости он ре плицируется посредством зонной передачи на дополнительный DNS-сервер. • Дополнительный сервер имен — его наличие в сети не обязательно, но рекомендуется; он обеспечивает отказоустойчивость и балансировку загрузки, поскольку на нем хранятся копии зон, поддерживаемых основным DNS-сервером. • Кэширующий сервер — как ясно из названия, кэширует отклики и возвращает кэшированные результаты. Это уменьшает время отклика и снижает трафик, посколь ку для разрешения имен не требуется запрашивать несколько DNS-серверов. Подготовка к экзамену Перед экзаменом важно тщательно разобраться во всех компо нентах системы и выучить типы серверов (основной, дополнительный и кэширующий). Анализ существующего пространства имен Определить структуру существующего пространства имен компании довольно просто. К этому моменту вы уже должны собрать сведения об инфраструктуре пространства имен Active Directory, что позволит ответить на вопрос, одинакова ли инфраструктура пространства имен в общей и частной сетях компании. Например, если имя общего домена компании contoso.com, используется ли во внутренней сети пространство имен Active Directory sales.contoso.com? Примеры инфраструктуры пространства имен DNS показаны на рис. 6-2 и 6-3, соображения по ее проектированию приводятся ниже, в занятии 2, а сейчас ваша задача — определение и анализ имеющегося пространства имен DNS.
Г
Интернет
Клиент Active Directory: contoso.com (внутреннее пространство имен) Зона DNS: contoso.com (внешнее пространство имен)
Рис. 6-2. Проектирование единого пространства имен DNS
Клиент
186
Глаеа S
Проектирование структуры DNS
*g 3oHaext-contoso.com
I
S
Контроллер домена
} Интернет
Брандмауэр
Клиент
Клиент
Active Directory: contoso.com (внутреннее пространство имен) Зона DNS: ext-contoso.com (внешнее пространство имен)
Рис. 6-3. Проектирование отдельных пространств имен DNS Подготовка к экзамену Важно понимать связь между пространствами имен Active Directory и DNS: во многих случаях они будут идентичными, но возможны ситуации, когда эти пространства имен совершенно различны — этот случай подробно рассматри вается в занятии 2.
Ход анализа При изучении существующей инфраструктуры DNS задайте себе следующие вопросы. и Внедрена ли служба каталогов Active Directory ? ш Как расположены DNS-серверы? • Какие типы зон реализованы? Есть несколько способов внедрения DNS в сети; сей час главное понять, как существующая организована репликация и избыточность записей ресурсов в инфраструктуре DNS. • Сколько пользователей в каждом участке сети? Как сказано выше, эти сведения определены во время первоначального анализа; отсюда ясно, как важно документи ровать все действия, чтобы не повторять лишний раз сделанное ранее. При первоначальном анализе можно воспользоваться ранее составленными схема ми и картами сети, на которых должны быть изображены имеющиеся DNS-серверы и их иерархия в виде деревьев и лесов. Можно скопировать эти схемы и просто добавить в них необходимые сведения о ролях DNS-серверов и зонах. На этом этапе необходимо ответить на следующие вопросы. • Использует ли компания одно и то же пространство имен в Active Directory и в качестве внешнего пространства имен DNS? • Какие зоны использует компания: интегрированные в Active Directory или обыч ные? • Какие способы зонной передачи или репликации применяются: AXFR, IXFR или быстрая зонная передача?
Занятие 1
Анализ существующей реализации DMS
-| g y
•
Сколько DNS-серверов имеется в компании, и какова роль каждого из них (основ ной, дополнительный или кэширующий)? • Защищены ли DNS-серверы, и, если да, то как? По мере изучения материала занятий этой главы, вы будете дополнять схемы сети новой информацией.
Переход от BIND к Windows-реализации DNS Во многих организациях есть ИТ-специалисты, которые считаются авторитета ми в области DNS и отвечают за управление всей инфраструктурой DNS. Анали зируя существующую инфраструктуру DNS, важно дать понять, что вы хотите не просто изменить существующую структуру. Если ваша цель — замена DNS на основе BIND таковой на основе Microsoft Windows Server 2003, проявляйте осто рожность: администраторы склонны привязываться к одной из реализаций DNS. Уговорить администратора перейти с одной на реализации DNS на другой нелегко, поэтому на данном этапе проектирования попробуйте собрать инфор мацию, необходимую для интеграции Active Directory с имеющейся инфраструк турой BIND DNS (о том, как это сделать, — в занятии 2); не стоит наставить на полном отказе от последней.
Закрепление материала Ответив на вопросы, приведенные ниже, вы сможете лучше усвоить основные темы за нятия. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытайтесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы. 1. Какие три способа зонной передачи применяются для репликации зонных файлов? 2. Каково преимущество использования интегрированных зон Active Directory в круп ной организации? 3. Анализ существующей сетевой инфраструктуры организаций показал наличие не скольких DNS-серверов, у одного из них обновление записей занимает слишком много времени. Какова возможная причина задержки?
Резюме •
Первый этап анализа существующей инфраструктуры DNS — создание ее схемы, в отдельных случаях соответствующая схема создается во время анализа структуры Active Directory. • Чтобы определить компоненты существующей инфраструктуры DNS, прежде всего следует разобраться в ее работе. DNS — это, в сущности, база данных, в которой хранятся записи ресурсов, поддерживаемых DNS-серверами. Эти данные должны реплицироваться на другие DNS-серверы для обеспечения отказоустойчивости и балансировки нагрузки. • Репликация зонных файлов происходит с помощью так называемых зонных пере дач; реализация DNS в Windows Server 2003 поддерживает три типа зонных передач:" добавочную (IXFR), полную (AXFR) и быструю зонную передачу.
188
Првектароеание структуры DNS
Глава 6
Занятие 2. Проектирование стратегии разрешения DNS-имен Итак, вы знаете компоненты, необходимые для инфраструктуры DNS, и изучили топо логию сети вашей компании. Пришло время познакомиться со стратегией проектиро вания DNS, которая позволит интегрировать пространство имен Active Directory, UNIXсерверы, обслуживающие BIND DNS, и другие сетевые службы, такие как DHCP и WINS. Из этого занятия вы узнаете, как объединить эти компоненты, а также познако митесь с защитными функциями, которые помогут обезопасить инфраструктуру DNS от потенциальных угроз. Изучив материал этого занятия, вы сможете:
•/ создать проект пространства имен; •/ определить возможность взаимодействия DNS с Active Directory, WINS и DHCP; S определить требования к зонам; •" описать защиту DNS; V спроектировать стратегию взаимодействия DNS с UNIX BIND с целью обеспечения поддержки службы каталогов Active Directory. Продолжительность занятия - около 40 минут.
Создание проекта пространства имен Из главы 2 вы узнали, как создать концептуальную схему пространства имен Active Directory, а сейчас вы научитесь планировать пространство имен DNS. Здесь можно задействовать большую часть данных, собранных во время анализа Active Directory. Проектировать пространство имен DNS организации следует с учетом структуры про странств имен Active Directory и Интернета. Проектирование пространства имен DNS
При проектировании пространства имен DNS следует сначала спроектировать среду Active Directory, а затем разработать для нее структуру DNS. Рекомендуется начать с поиска ответов на следующие вопросы. • Существуют ли в вашей компании правила назначения доменных имен компьюте рам? • Какой домен зарегистрировала организация для использования в Интернете? (При мер — contoso.com.) • Где будут располагаться DNS-серверы: в частной (внутренней) сети или в Интер нете? • Требуется ли от DNS поддерживать Active Directory в сети организации? Выбор домена
Рекомендуется выбрать и зарегистрировать для организации уникальное доменное имя DNS, скорее всего это будет имя домена второго уровня в одном из доменов верхнего уровня Интернета (табл. 6-2).
Занятие 2 Табл. 6-2.
Проектирование стратегии разрешений DNS-имен
-jgg
Домены верхнего уровня
Имя
Кому делегируется
;от
Коммерческим организациям, таким как Microsoft
edu
Образовательным учреждениям, например Гарвардскому юридическому колледжу
gov
Правительственным организациям, таким как Белый дом
mil
Военным организациям, таким как Глобальная сеть Министерства обороны США (Defense Data Network, DDN)
net
Сетевым организациям, таким как Национальный научный фонд (National Science Foundation, NSF) США Некоммерческим организациям, таким как Center for Networked Information Discovery and Retrieval (CNIDR)
org
Примером домена второго уровня может быть contoso.com. Выбрав имя для роди тельского домена, следует создать поддомены с именами, основанными на расположе нии или специфике подразделений. Например, поддомен североамериканского фили ала можно назвать namerica.contoso.com, а в нем можно создать поддомен для отдела сбыта: sales.namerica.contoso.com.
Проектирование пространства имен DNS для Active Directory Чтобы грамотно спроектировать пространство имен DNS, необходимо заранее спроек тировать инфраструктуру Active Directory, если таковая предусмотрена. Предполагает ся, что проект инфраструктуры Active Directory уже готов, теперь пора дополнить его подходящей инфраструктурой DNS. Доменам Active Directory назначаются DNS-имена. Имена доменов Active Directory должны начинаться с доменного суффикса — имени DNS-домена Интернета, зареги стрированного организацией (скажем, contoso.com), к нему можно добавить часть, отра жающую географическое расположение или название подразделения согласно сформу лированным ранее правилам именования. К настоящему моменту на схеме сети должно быть отражено следующее: • разбиение локальной сети (LAN) на подсети (если используется). Эту информацию можно использовать для определения зон, если они требуются, выбора способа зон ной передачи, а также для принятия решения о создании поддоменов; • расположение маршрутизаторов и всех доступных через них служб, а также брандмау эров и прокси-серверов. Эти сведения помогут защитить ресурсы DNS. Об укрепле нии защиты путем фильтрации трафика через заданные порты средствами маршру тизаторов и брандмауэров рассказывается ниже; • сведения о подсетях: адреса, маски подсети, диапазоны хостов, а также конфигура ции DHCP и DNS; требуются для определения числа пользователей сети или ее участка, а также для распределения в ней DNS-серверов.
Взаимодействие DNS с Active Directory, WINS и DHCP При разработке стратегии разрешения DNS-имен необходимо спланировать интегра цию с другими сетевыми службами с целью улучшения производительности сети. Из этого раздела вы узнаете, как интеграция с Active Directory улучшает работу сети и снижает издержки на администрирование; что DHCP не только автоматически настра ивает параметры IP-конфигурации клиентской рабочей станции, но и взаимодействует
Проектирование структуры DNS
Глава 6
со службой DNS для выполнения динамических обновлений. В завершение будет рас смотрена служба WINS, а также оптимизацию DNS для пересылки запросов разреше ния NetBIOS-имен WINS-серверам. Начнем с анализа интеграции с Active Directory.
Интеграция с Active Directory Как сказано в главе 2. Active Directory — это инструмент для управления, организации и поиска ресурсов сети. Служба каталогов Active Directory спроектирована для работы со службой DNS-сервер (DNS Server), которая встроена в ее реализацию, благодаря ему эти службы идеально подходят друг для друга.
Установка Active Directory Если при добавлении на сервер роли Контроллер домена (Domain Controller) мастер установки не обнаружит DNS-сервера, полномочного для данного домена, он предло жит установить DNS-сервер. Это необходимо, поскольку DNS-сервер требуется для поиска этого и других контроллеров домена Active Directory. Мастер также порекомен дует установить DNS, если существующая инфраструктура этой службы не поддержи вает динамические обновления DNS. Из предыдущего занятия вы узнали, что одно из преимуществ интеграции DNS с Active Directory состоит в возможности репликации зон без их хранения в текстовых файлах на основном DNS-сервере. Рассмотрим преимущества интеграции с Active Di rectory подробнее. • Любой контроллер домена, на котором работает служба DNS-сервера, может быть назначен основным источником данных зоны и способен обновлять их. Это отлича ется от стандартной методики, предусматривающей единственный основной DNSсервер с основной DNS-зоной, который может оказаться слабым местом сети. Так, при выходе из строя основного DNS-сервера клиенты не смогут обновлять БД DNS, поскольку обновление дополнительного DNS-сервера возможно только посредством репликации (зонной передачи). В модели DNS, интегрированной с Active Directory, мастер-копия зоны поддерживается службой Active Directory и реплицируется на все контроллеры доменов. • Использование Active Directory повышает безопасность (подробнее об этом см. ниже), поскольку списки управления доступом (Access Control Lists, ACLs) можно применять для защиты объектов DNS, хранящихся в БД Active Directory. Например, ACL позволяют ограничить динамические обновления, выполняемые клиентскими компьютерами, подобно тому, как они ограничивают доступ к сетевым принтерам и папкам. • Зоны автоматически синхронизируются и реплицируются на новые контроллеры доменов без дополнительных усилий по администрированию. • DNS, интегрированная с Active Directory, эффективнее с точки зрения репликации, так как не требует проектирования топологии репликации, отдельной от топологии репликации между контроллерами доменов. Вместо этого БД зон реплицируются между DNS-серверами вместе с другими данными Active Directory, что позволяет объединить стратегии администрирования этих процессов. • Репликация каталога быстрее стандартной репликации DNS, так как в этом случае реплицируются только модификации зон, хранимых в каталоге; к тому же передача обычных зонных файлов (которые могут быть велики), способна отнимать значи тельную часть и без того ограниченной полосы пропускания каналов связи.
Занятие 2
Проектирование стратегии разрешений DNS-имен
-jg^
Нетрудно убедиться, что преимущества от интеграции DNS с Active Directory стоят минимальных начальных усилий по ее реализации; а теперь рассмотрим интеграцию DNS с DHCP. Интеграция DNS с DHCP В прежние времена администраторам сети приходилось вручную создавать записи типа А и PTR для новых пользователей, подключающихся к домену, никто даже не думал о возможной автоматизации этого процесса, в результате он требовал много времени и был предрасположен к ошибкам. При установке службы DHCP в Windows Server 2003 создается DHCP-сервер, спо собный обновлять от имени DHCP-клиентов DNS-серверы, поддерживающие динами ческие обновления. Другими словами, DHCP может регистрировать записи типа А и PTR для DHCP-клиентов, которые предоставляют DHCP-серверу свои FQDN и ин струкции по выполнению динамических обновлений DNS. В Windows Server 2003 DHCP-сервер может быть сконфигурирован одним из следующих способов: • сервер обновляет А и PTR по запросу клиента; • сервер обновляет DNS-записи типа А и PTR независимо от клиента; • сервер не регистрирует и не обновляет сведения о клиенте в DNS; * сервер всегда регистрирует и обновляет сведения о клиенте в DNS независимо от запросов клиента на выполнение этих обновлений; а сервер не регистрирует и не обновляет сведения о клиенте в DNS. По умолчанию DHCP-серверы на основе Windows Server 2003 и Windows 2000 на строены по первому варианту: они регистрируют и обновляют сведения о клиенте на DNS-сервере, полномочном для зоны, в которой расположен этот DHCP-сервер. Мож но настроить DHCP и так, чтобы он приказывал DNS-серверу удалить клиентские записи А и PTR по завершении срока клиентской аренды. Интеграция DHCP улучшает работу сети и помогает администраторам сэкономить время; ниже будет рассмотрено взаимодействие DNS с WINS. Служба WINS В некоторых случаях DNS-серверы не способны разрешать унаследованные NetBIOSимена, для их разрешения применяют службу WINS. DNS обеспечивает разрешение имен в домене DNS, a WINS — в пространстве имен NetBIOS. Чтобы служба DNS смогла просматривать пространство имен NetBIOS (если имя не удается разрешить в пространстве имен DNS), в Windows Server 2003 предусмотрены два типа записей ре сурсов, определяющие WINS-серверы: a WINS; • запись обратного просмотра WINS (WINS-R). Запись ресурса WINS Запись ресурса WINS позволяет службе DNS использовать WINS для просмотра NetBIOS-имен и пересылки ей запросов хост-имен, не найденных в БД DNS-зоны. Например, если клиент А запрашивает у основного DNS-сервер разрешение имени клиента В.sales.contoso.com (рис. 6-4), происходит следующее.
192
Проектирование структуры DNS
Глава 6
1. Вначале предпочитаемый DNS-сервер проверяет наличие IP-адреса в своем кэше. 2. Не обнаружив адрес в своем кэше, DNS-сервер опрашивает от имени клиента дру гие DNS-серверы, пока не будет найден DNS-сервер, полномочный для зоны sales.contoso.com. 3. Далее DNS-сервер ищет в зонном файле этого сервера соответствующую запись ресурса (рис. 6-4). 4. Если искомая запись отсутствует в зонном файле DNS-сервера, уполномоченного для данной зоны, но для этой зоны поддерживается просмотр БД WINS, сервер выделяет из FQDN хост-имя (имя клиента В, который не показан на рисунке) и отправляет запрос разрешения соответствующего NetBIOS-имени WINS-серверу. 5. Если WINS-сервер разрешает это имя, IP-адрес клиента возвращается DNS-серверу. 6. DNS-сервер на основе полученного от WINS-сервера IP-адреса создает запись типа А и возвращает ее предпочитаемому DNS-серверу, запрошенному клиентом А. 7. Основной DNS-сервер передает соответствующий отклик запрашивающему клиенту. DNS-сервер
DNS-сервер
Предпочитаемый DNS-сервер
DNS-сервер
просмотр БД WINS
WINS-сервер
Рис. 6-4. Интеграция WINS и DNS Запись обратного просмотра WINS Запись WINS-R добавляется к зонам обратного просмотра, если включен обратный просмотр WINS. Как вам уже известно, зона обратного просмотра разрешает хост-име на в IP-адреса. База данных WINS не индексируется по IP-адресам, поэтому невоз можно, отправив IP-адрес WINS-серверу, получить соответствующее хост-имя; вместо этого DNS-сервер отправляет запрос о состоянии адаптера узла на IP-адрес, обозначен ный в запросе обратного просмотра DNS. DNS-сервер получает отклик с состоянием адаптера и NetBIOS-именем этого узла, добавляет доменное имя DNS к NetBIOS-име ни и отправляет результат клиенту.
Требования к зонам На занятии 1 вы кратко ознакомились с различными видами зон в Windows Server 2003, на этом занятии мы рассмотрим их подробнее — это поможет вам выбрать подходящий тип зон для сети организации.
Занятие 2
Проектирование стратегии разрешения DNS-имен
Стандартная основная зона Такие зоны обычно применяют в сети на основе UNIX, а также в прежних реализациях DNS. Обычно такая реализация DNS включает минимум один основной и один допол нительный DNS-серверы. Данные реплицируются с основного DNS-сервера на допол нительный в ходе операции, называемой зонной передачей (zone transfer). Обновлять DNS-данные разрешается только на основном DNS-сервере. Дополнительный DNSсервер доступен только для чтения, поэтому изменять его данные можно только с помо щью репликации. Репликация, или зонная передача между основным и дополнительным DNS-серверами происходит: • по истечении периода обновления для зоны; • когда главный сервер сообщает об изменениях вспомогательному; • при запуске службы DNS-сервера на дополнительном DNS-сервере в данной зоне; • когда вспомогательный сервер инициирует передачу с своего главного сервера.
Зона, интегрированная в Active Directory Зоны такого типа обычно реализуют в сети, где уже есть инфраструктура Active Directory, но пока нет инфраструктуры DNS. При этом зоны DNS могут храниться в разделе каталога Active Directory, обслуживающего домен или приложения. Разделы каталога — это структуры данных, с помощью которых Active Directory разделяет данные, подлежащие репликации на разные компьютеры, подробнее об этом — на занятии 3. Рассмотрим возможные области репликации зон, интегрированных в Active Directory. Такие зоны могут реплицироваться на: • все DNS-серверы, работающие на контроллерах доменов леса Active Directory; • все DNS-серверы домена Active Directory (вариант по умолчанию); и все контроллеры данного домена Active Directory; • серверы, заданные параметрами указанного раздела каталога приложений. Одно из ключевых преимуществ зон этого типа по сравнению со стандартными зонами состоит в том, что мастер-копия зонного файла хранится в БД Active Directory и реплицируется с ней на все контроллеры доменов. Обновить можно любую из этих копий, тогда как стандартную зону можно обновить только на основном DNS-сервере. Если в сети работает Active Directory, рекомендуется использовать зоны, интегриро ванные в Active Directory, поскольку: • такие зоны надежнее защищены благодаря безопасным динамическим обновлени ям и спискам управления избирательным доступом (discretionary access control list, DACL); • они автоматически копируются на все контроллеры домена; • репликация каталога быстрее стандартной репликации DNS.
Защита DNS Стратегию разрешения имен следует разрабатывать, ориентируясь на снижение риска атаки инфраструктуры DNS. DNS-серверы могут быть атакованы через Интернет, поэтому следует максимально обезопасить их. DNS в Windows Server 2003 обладает дополнительными возможностями
Проектирование структуры DNS
Глава 6
защиты, которые помогут в этом. В этом разделе рассматриваются различные типы атак инфраструктуры DNS и способы защиты от них. Читая этот раздел, специалистам по защите и администраторы сетей важно отдавать себе отчет в том, что любая система рискует быть атакованной; если сеть подключена к Интернету, этот риск значительно возрастает. Советы, приведенные в этом разделе, — не панацея от взлома, они призваны затруднить проникновение в вашу сеть и переклю чить внимание взломщиков на другие, менее защищенные или вовсе не защищенные системы. Гарантировать абсолютную защиту сервера от атак через сеть можно, только отключив от него сетевой кабель и заперев в комнате с кодовым замком!
Потенциальные угрозы безопасности Защите сетей посвящено множество книг, этот раздел — всего лишь вершина этого «айсберга»; дополнительные сведения см. в справочной системе Windows Server 2003 и на сайте http://www.microsoft.com/technet/ security/prodtech/windows/win2003. Начнем с рассмотрения следующих угроз безопасности инфраструктуры DNS: • разведка сети (footprinting) — дистанционное получение информации о сети при по мощи таких инструментов, как whois, nslookup и axfr (эта программа бесплатно рас пространяется через Интернет; она получает информацию о зонном файле с любого домена без соответствующей защиты, записывает их в сжатый файл, который взлом щик может почитать в любое ему удобное время, отключившись от сеть); • атаки типа «отказ в обслуживании» (denial-of-service, DoS) — прекращение предо ставления доступа к ресурсам сети ее «законным» пользователям. Наиболее широко известна атака «ping of death», когда командой ping на сервер отправляется слиш ком большой пакет, который сервер не может обработать и прекращает отвечать на запросы пользователей. DoS-атака «захлестывает» DNS-сервер лавиной рекурсив ных запросов, перегружая его процессор и блокируя любые другие операции. • перенаправление (redirection) — злоумышленник направляет запросы, посланные пол номочному DNS-серверу, на сервер, подконтрольный ему. Обычно это делается пу тем взлома кэша DNS-сервера и заполнения его неверными DNS-данными, такими как записи ресурсов, указывающими на сервер злоумышленника. В результате взломщик получает сетевые запросы клиентами, в которых могут содержаться па роли к серверам. Видно, что сама по себе DNS крайне уязвима, что и понятно, поскольку ее проек тировали почти без защиты или вовсе без нее. Защита инфраструктуры DNS Следующие рекомендации помогут защитить инфраструктуру DNS. • Исключите прямое взаимодействие клиентов внутренней сети с DNS-серверами через Интернет. Для этого можно поместить внутренние DNS-серверы в частное пространство имен, а внешние — разместить на внешних DNS-серверах. Если хосту из внутренней сети потребуется разрешить имя из внешней сети, внутренний DNSсервер сможет переслать запрос внешнему DNS-серверу. • Чтобы закрыть доступ внешним компьютерам к внутреннему пространству имен DNS, настройте брандмауэр так, чтобы взаимодействие по протоколам UDP и TCP через порт 53 было разрешено только внутренним и внешним DNS-серверам. в Чтобы злоумышленник не смог начать DoS-атаку DNS-серверов, ограничьте число IP-адресов, обслуживаемых DNS-сервером, адресами DNS-клиентов, а также от-
Занятяе 2
Проектирование стратегам разрешения DNS-имвк
ключите рекурсию у DNS-серверов, не настроенных на выполнение рекурсивных запросов, ш Чтобы защититься от «отравления» DNS-кэша (cache pollution), не снимайте поме ченный по умолчанию флажок Включить безопасный кэш (Secure Cache Against Pollution), чтобы не позволить взломщику добавить в файл зоны ложные записи ресурсов. • На DNS-серверах, работающих на контроллерах домена, используйте DACL с це лью управления разрешениями для службы DNS-сервера. DACL входит в дескрип тор безопасности DNS-объекта, разрешающий или запрещающий пользователям и группам доступ к этому объекту. • Чтобы предотвратить разведку сети через зонные передачи DNS, разрешайте зон ные передачи только между DNS-серверами, указанными в записях ресурсов как серверы имен данной зоны. Это задано по умолчанию, если требуется дополнитель ная защита, можно ограничить число IP адресов, на которые разрешена переда зоны. • Чтобы укрепить защиту DNS-сервера на основе Windows Server 2003, всегда ис пользуйте файловую систему NTFS, а не FAT или FAT32. ш Если в инфраструктуре DNS используется только зоны, интегрированные в Active Directory, разрешайте только безопасные динамические обновления. Итак, вы познакомились с различными способами защиты DNS-серверов, они не позволяют защитить данные зоны от перехвата во время репликации (зонной переда чи), когда они передаются через публичные сети. Всякий раз, когда данные передаются через Интернет, существует опасность, что посторонний, вооруженный анализатором протоколов (программой-перехватчиком па кетов), перехватит пакеты и сможет просмотреть их содержимое. В завершение раз дела, посвященного защите DNS, мы кратко расскажем о защите данных при репли кации.
Защита данных при репликации Вы уже знаете, что значение репликации зон DNS на дополнительные DNS-серверы заключается в обеспечении отказоустойчивости и балансировке загрузки; но что, если данные пересылаются по глобальной сети (WAN), использующей Интернет как среду передачи? Посторонние вполне могут перехватывать ваши данные с помощью анализа тора протокола и просматривать их содержимое. Есть несколько способов избежать или, по крайней мере, снизить вероятность перехвата данных: • защита шифрованием с помощью протокола IP-безопасности (IPSec); • защита шифрованием с помощью виртуальной частной сети (VPN); • защита шифрованием средствами Active Directory Трафик зонной репликации можно зашифровать средствами туннеля IPSec или VPN. Независимо от выбранного способа, используйте самый стойкий шифровальный алго ритм, например 3DES (произносится как «трипл-дэс»). Еще раз подчеркнем: любые зашифрованные данные могут быть расшифрованы, вопрос лишь в том, сколько вре мени это займет. Кроме того, есть простые способы взлома шифра любой сложности, например, похищения единственного шифровального ключа, который по небрежности часто передают через Интернет. Здесь уместно повторить, что шифрование не гаранти рует полной защиты от несанкционированного доступа.
196
Проектирование структуры BUS
Глава б
Выбрав зоны, интегрированные в Active Directory, вы автоматически получите их защиту встроенными средствами. Можно настроить Active Directory так, чтобы разре шить репликацию зон только на зарегистрированные DNS-серверы зон.
Взаимодействие со службой BIND в UNIX Как сказано в занятии 1, не во всех организациях для разрешения имен используется Microsoft-реализация DNS. Из этого раздела вы узнаете, как интегрировать Active Directory в Windows Server 2003 с реализацией DNS в виде BIND. Если планируется сохранить DNS-серверы на основе BIND, новые DNS-серверы, которые, возможно, буду использовать Microsoft-реализацию DNS, должны поддерживать прежние реали зации этой службы: BIND и DNS Windows NT. Windows 2003 рассматривает эти реали зации DNS как традиционные DNS-серверы, поддерживающие: • стандартные основные зоны • стандартные дополнительные зоны • делегирование доменов.
Версии BIND, протестированные Microsoft Разработчики DNS для Windows Server 2003 протестировала взаимодействие серверных клиентских служб DNS из Windows Server 2003 со следующими реализациями DNS на основе BIND: • BIND 4.9.7; • BIND 8.1; • BIND 8.2; • BIND 9.1.0. Когда пользователь пытается войти в сеть Windows Server 2003, для поиска контрол лера домена и других сетевых ресурсов ему требуется DNS. Фактически при установке Windows Server 2003 на первом сервере сети и повышении его до контроллера домена можно поручить мастеру установки установить DNS-сервер и добавить зоны на основе DNS-имени, введенного при установке. Во многих организациях используется BINDверсия DNS, которая, к сожалению, не всегда соответствует требованиям к DNS для развертыванию Active Directory. Эти проблемы можно решить следующими способами: • обновите все DNS-серверы на основе BIND до версии 8.1.2 и выше; • убедитесь, что текущая реализация DNS на основе BIND поддерживает записи ре сурсов типа SRV (указатель службы). Например, запись _http._tcp.contoso.com IK SRV 0 0 80 может указывать всем пользователям Web-сервер webserver.contoso.com; • убедитесь, что текущая реализация DNS на основе BIND поддерживает динамиче ские обновления, описанные в RFC 2136; это не обязательно, но настоятельно ре комендуется. Без поддержки этой функции текущая реализация DNS на основе BIND потребует ручного администрирования записей SRV для нормальной работь: Active Directory.
Зонная передача BIND Зонная передача между DNS-серверами на основе Windows Server 2003 не представляет сложности: по умолчанию используется быстрая зонная передача, для повышения эф фективности применяется сжатие данных. Этот метод позволяет пересылать в одном сообщении несколько записей ресурсов, что повышает скорость зонной передачи.
Занятие 2
Проектирование стратегии разрешения DNS-имен
-цду
DNS-серверы Windows Server 2003 можно настроить на передачу зоны в несжатом виде для обмена зонными данными с серверами, не поддерживающими быструю зон ную передачу, например, с BIND-серверами версий до 4.9.4. Также BIND-серверы не распознают записи WINS и WINS-R, поэтому при репликации на такие серверы необ ходимо пометить флажок Не выполнять репликацию этой записи (Do Not Replicate This Record).
Лабораторная работа. Проектирование пространства имен DNS для лесов и доменов На этой лабораторной работы вы спроектируете пространство имен DNS для компании Northwind Traders. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытайтесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и от веты» в конце главы.
Сценарий Компания Northwind Traders занимается производством сетевого оборудования, пред назначенного для наращивания возможностей корпоративных коммуникаций. В насто ящее время в сети компании используется модель доменов Windows NT 4.0 (модель с главным доменом). За последние годы компания значительно расширилась, в течение следующих трех лет также ожидается значительный рост, включая увеличение доли на рынке, роста доходов и числа служащих. Чтобы привести сеть компании в соответствие с текущими и будущими потребностям, руководство решило открыть два новых офиса и внедрить модель доменов Active Directory на основе Windows Server 2003. В следующей таблице показано географическое расположение представительств компании, существующие в них отделы и число пользователей. Расположение
Имеющиеся отделы
Число пользователей
Париж
Основной офис Финансы Продажи Маркетинг Производство Исследования Разработки ИТ Продажи Маркетинг Финансы ИТ Обслуживание клиентов Техническая поддержка клиентов Обучение Исследования Разработки Долгосрочные проекты ИТ
2000
Лос-Анджелес
Атланта
Глазго, Шотландия
1000
750
750
(см. след. стр.)
198
Проектирование структуры DNS
Глава 6
(окончание) Расположение
Имеющиеся отделы
Число пользователей
Сидней, Австралия
Консалтинг Производство Продажи Финансы
500
Большинство информационных служб компании расположено в штаб-квартире в Париже. ИТ-отделу требуется возможность централизованного управления паролями и параметрами защиты, но ИТ-подразделение филиала в Лос-Анджелесе хочет оставить за собой управление инфраструктурой филиала, а ИТ-отдел филиала в Глазго требует автономии в управлении сетью филиала с целью надлежащей защиты данных НИОКР. Руководство компанией разделяет их позиции и требует организовать надежную защи ту данных отдела НИОКР. На схеме изображены каналы связи между подразделениями компании; кроме того, офисы в Лос-Анджелесе и в Атланте подключены к сети штаб-квартиры в Париже через VPN.
Зона, интегрированная в Active Directory
Дополнительная зона
Основная зона, интегрированная в Active Directory
Зона, интегрированная в Active Directory
Зона-заглушка, интегрированная в Active Directory
Руководство компании Northwind Traders приняло проект лесов и доменов, показан ный на рис. ниже; доменам Active Directory решено назначить частные (не зарегистри рованные в Интернете) имена.
Лес отдела НИОКР
Лес NWTraders
Вопросы к лабораторной работе Исходя из представленного сценария, выполните следующее задание. По схеме лесов и доменов, приведенной в сценарии, разработайте стратегию име нования для компании Northwind Traders. Обоснуйте свое предложение.
Занятие 3
Проектирование реализации DN5
Закрепление материала Ответив на вопросы, приведенные ниже, вы сможете лучше усвоить основные темы за нятия. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытай тесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы. 1. В вашей организации более 350 пользователей, работающих с ОС Windows 98 и Windows NT Workstation. Пользователи постоянно перемещаются по территории ком пании, при этом вам требуется обновлять записи хостов в DNS. Какие функции DNS позволят снизить нагрузку на администратора по созданию и обновлению этих записей? 2. Прочитав в компьютерном журнале статью про перехват зонной передачи при помо щи анализатора протоколов, ваш начальник считает, что репликация DNS-данных по сети слишком уязвима для атак. Как успокоить начальника? 3. Какая версия BIND рекомендуется для использования с Active Directory?
Резюме •
Проектирование пространства имен DNS начинается с изучения существующей среды Active Directory. Сначала спроектируйте инфраструктуру Active Directory, а затем добавьте к ней инфраструктуру DNS. • Для этого процесса критически важно наличие схемы сети и хорошей документа ции. • Один из важнейших аспектов проектирования DNS — защита компонентов DNS. Разведка сети, DoS-атаки и «отравление» кэша DNS — это лишь часть потенциаль ных угроз безопасности инфраструктуры DNS.
Занятие 3. Проектирование реализации DNS Настало время решить, будет ли новый сервер основным DNS-сервером или кэширующим, а также какие записи ресурсов потребуется создать. Проектировать реализацию DNS необходимо с учетом типа зонной передачи и пропускной способности каналов связи между DNS-серверами. На этом занятии вы узнаете, как выбрать стратегию хра нения DNS-зон, как настроить различные параметры DNS-сервера и поближе позна комитесь с записями ресурсов DNS. Изучив материал этого занятия, вы сможете:
•S разработать стратегию хранения зоны DNS; S выбрать подходящие параметры DNS-сервера. Продолжительность занятия — около 15 минут.
При проектировании реализации DNS необходимо четко представлять себе тополо гию сети, размещение пользователей, серверов, маршрутизаторов и других компонен тов. На рис. 6-5 показана общая схема сети. Такую схему можно дополнить конкретной" информацией, например типами зон, сведениями о размещении DNS-серверов и т. п.
200
Проестирование структуры DNS
Глава 6
Рис. 6-5. Пример общей схемы сети
• • • • •
К данному моменту вы должны быть готовы дать ответы на следующие вопросы. Какие типы зон потребуются для проекта: интегрированные с Active Directory, стан дартные основные зоны или иные? Как расположить DNS-серверы в сети? (Подробнее об этом — в занятии 4.) Требуется ли проекту интеграция с DNS-службой UNIX BIND или устаревшими версиями DNS? Требуется ли проекту интеграция с другими сетевыми службами, например с DHCP и WINS? Предполагается ли интеграция проектируемого пространства имен DNS с простран ством имен Active Directory?
Хранение зон На занятии I вы кратко познакомились с различными способами хранения зон в инфра структуре DNS. При наличии Active Directory зонные файы можно хранить двумя спо собами: • как текстовые файлы в папке systemroot\System32\DNS на каждом из DNS-серверов. Например, для зоны для домена marketing.contoso.com зонный файл будет назы ваться marketing.contoso.com.dns. Заметьте, что зонным файлам назначается расшире ние «dns»; • в БД Active Directory (в разделе каталога домена или приложений; см. ниже). о преимуществах зон, интегрированных с Active Directory, см. в занятии 2.
Разделы каталога приложений Из занятия 2 вы узнали, что зоны DNS хранятся в БД Active Directory, например, Б разделе каталога приложений. Этот раздел каталога позволяет, храня данные в Active Directory, разрешить их репликацию только на определенные контроллеры доменов.
Занятие 3
Проектирование реализаций DNS
Зоны-заглушки Зона-заглушка (stub zone) — это копия зоны, содержащая только записи ресурсов, ука зывающие на DNS-сервер, полномочный для определенной зоны DNS. При этом за прашивающему DNS-серверу не требуется вести поиск полномочного DNS-сервера в Интернете: достаточно обратиться к списку серверов имен (записей ресурсов NS) зоны-заглушки. Список полномочных DNS-серверов для определенной зоны может распространять ся с помощью зоны-заглушки. В отличие от дополнительных зон, используемых в пер вую очередь для избыточности и балансировки нагрузки, зоны-заглушки используются для повышения эффективность разрешения имен.
Проектирование зон обратного просмотра По соображениям безопасности серверу иногда необходимо узнать имя узла, но изве стен лишь его IP-адрес. В таких случаях инициируется обратный просмотр. Зоны об ратного просмотра проектируют так же, как зоны прямого просмотра, только с учетом необходимости репликации файлов зон обратного просмотра по домену. Типы зон об ратного просмотра бывают те же, что и зон прямого просмотра: • зоны, интегрированные в Active Directory; • стандартные основные зоны; • стандартные дополнительные зоны. Параметры DNS-сервера Проектируя инфраструктуру DNS, необходимо решить, на каких серверах будут хра ниться основные и дополнительные копии зон. Если планируется использовать Active Directory необходимо также решить, какие серверы станут контроллерами домена, а какие — его рядовыми серверами. Естественно, от этих решений зависит потребность в оборудовании. Так, если сер вер будет совмещать роли основного DNS-сервера и контроллера домена, ему может потребоваться дополнительная память. Подробнее об этом — в занятии 4. Настройка DNS-сервера Определившись с ролью сервера, необходимо настроить его, но сначала следует: • определить, планируется ли развертывание Active Directory. Если да, можно перело жить задачу установки и настройки DNS на мастер установки Active Directory; • убедиться, что ОС и TCP/IP настроены правильно; • убедиться, что на дисках сервера достаточно места и оперативной памяти хватит для работы с размещенной на нем зоной; Размещение серверов подробно рассматривается в следующем занятии; вообще, рекомендуется в каждом удаленном участке сети установить хотя бы один DNS-сервер.
Закрепление материала Ответив на вопросы, приведенные ниже, вы сможете лучше усвоить основные темы за нятия. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытай тесь ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце главы.
202
Проектирование структуры DNS
Глава 6
1. Вы — администратор сети с Windows Server 2003, в которой имеется компьютер под управлением UNIX, где работает унаследованная программа. Эта программа требу ет проверки подлинности подключающихся к ней рабочие станции по хост-именам. Пользователи жалуются, что они не могут работать с этой программой и получают сообщение о отказе в доступе из-за отсутствия разрешений. Что может быть причи ной этой проблемы? 2. Вы готовитесь подключить в сеть сервер с Windows Server 2003. Это первый сервер сети, и после установки ОС вы собираетесь повысить его до контроллера домена. Перечислите этапы установки DNS на этот компьютер. 3. Вы только что установили Active Directory и создали зону для домена sales.contoso.com. Назовите два способа хранения зонного файла для этого домена.
Резюме •
•
•
Зонный файл можно хранить двумя способами: в виде текстового файла в папке systemroot\System32\DNS на каждом DNS-сервере, либо (для зон, интегрированных в Active Directory), в БД Active Directory. Раздел каталога приложений позволяет хранить в Active Directory специфичные для приложений данные, которые следует реплицировать только на определенные кон троллеры доменов. Зоны обратного просмотра проектируют так же, как зоны прямого просмотра. По мните о репликации зон с целью обеспечения отказоустойчивости и балансировки нагрузки.
Занятие 4. Разработка стратегии размещения служб DNS Итак, вы уже собрали в проектной документации информацию о всех серверах сети: а если известны типы зон DNS, топологии LAN и WAN, а также число пользовате лей в сети, вы готовы к проектированию стратегии размещения служб DNS. На этом занятии вы узнаете, как разместить DNS-серверы, чтобы обеспечить оптимальную про изводительно сть. Изучив материал этого занятия, вы сможете:
•S спроектировать размещение DNS-служб. Продолжительность занятия - около 25 минут.
Проектирование размещения служб DNS Развертывание DNS-серверов в сети требует тщательного анализа всех сведений, со бранных к этому моменту, включая схему размещения всех ресурсов сети. Необходим: также четкое представление о пропускной способности каналов связи и производи тельность оборудования серверов. Так, необходимые сведения, например число DNSсерверов в каждом офисе, можно нанести на общую схему сети (рис. 6-6).
Занятое 4
Разработка стратегии размещения служб DNS
203
В этом разделе рассматриваются некоторые вопросы, которые помогут верно вы брать число серверов и грамотно разместить их в сети.
Рис. 6-6.
Пример схема сети с указанием размещение серверов
Размещение серверов Чтобы решить, сколько DNS-серверов потребуется, и где их следует разместить, необ ходимо ответить на следующие вопросы. • Сколько зон будет на DNS-серверах? Чем больше зон, гем больше оперативной памяти потребуется серверу. • Насколько велики зоны? (Ответ зависит от количества записей ресурсов в зоне или размера зонного файла, он также влияет на выбор размера памяти или оборудования сервера для работы с данной зоной.) • Сколько DNS-запросов от клиентов предположительно будет получать служба DNSсервера? Если клиенты постоянно бомбардируют DNS-сервер запросами, его произ водительность значительно снизится. Подумайте об установке нескольких DNSсерверов с целью балансировки нагрузки по обработке запросов. • На каких серверах будут храниться основные и дополнительные копии зон? Ответ на этот вопрос поможет оценить влияние трафика, генерируемого зонной переда чей. Если это трафик слишком велик, подумайте об установки кэширующих DNSсерверов в удаленных участках сети, подключенных через медленные WAN-кана лы. Кэширующие серверы рассматриваются ниже в этом разделе. • Если в сети используется Active Directory, будет ли DNS-сервер работать на кон троллере домена или рядовом сервере? От этого зависят требования к оборудованию сервера. я Будут ли использоваться только DNS-серверы на основе Windows Server 2003 или .. планируется применение DNS-реализаций из других ОС? В последнем случае обя зательно изучите все применяемые реализации DNS.
204
Проектирование структуры DNS
Глава 6
•
Предусмотрен ли альтернативный DNS-сервер на случай внезапного отказа предпо читаемого DNS-сервера? Это очень важно, так как в организациях часто применя ют DNS не только для разрешения внутренних имен, но и для доступа к ресурсам через Интернет. Устройство DNS требует наличие хотя бы двух серверов для каждой зоны, основного и дополнительного: это, как и создание зон, интегрированных в Active Directory, обеспечивает отказоустойчивость. • Предусмотрен ли в удаленной подсети альтернативный DNS-сервер на случай вы хода из строя маршрутизатора? Если в подсети много пользователей, обращающихся к DNS за разрешением имен, стоит подумать об установке в ней DNS-сервера. Например, установка DNS-сервера в сегменте сети, где всего три пользователя, нерентабельна, лучше направить запросы пользователей на ближайший DNS-сер вер. Трафик разрешения имен, как и трафик зонной передачи, делает и без того небыстрые WAN-каналы еще более медленными. Одним из решений этой проблемы является установка кэширующих DNS-серверов, о которых рассказывается ниже.
Мониторинг DNS
Microsoft проведено тестирование производительности своей реализации DNS. В тече ние четырех дней велось наблюдение за работой службы DNS, установленной на сер вере со следующими параметрами: • однопроцессорный сервер Intel Pentium III (733 МГц); • 256 Мб ОЗУ; • жесткий диск объемом 4 Гб. Конечно, базовый уровень производительности для своей компании следует опреде лять самостоятельно, но и результаты тестирования Microsoft вполне пригодны для оп ределения снижения производительности DNS-сервера со временем. Производитель ность DNS-сервера оценивают, наблюдая за следующими событиями: • общее количество запросов, полученных DNS-сервером; • среднее количество запросов, полученных за секунду; • общее количество откликов, отправленных DNS-сервером; • среднее количество откликов, отправленных DNS-сервером в секунду. DNS-сервер, протестированный Microsoft, выполнял 9500 запросов и 1300 динами ческих обновлений в секунду при загруженности процессора 75 %. Также можно ис пользовать счетчики производительности DNS для наблюдения за другими аспектам:.работы DNS-сервера. Например, счетчик Отправлено запросов AXFR (AXFR Request Sen позволяет выяснить, не отправляет ли дополнительный DNS-сервер слишком мнсс; запросов полной зонной передачи. Чтобы определить, укладывается ли число запрос:: в норму или превышает ее, сравните значение этого счетчика с ранее зарегистрирован ным базовым уровнем.
Кэширующие серверы Для повышения скорости зонной передачи и снижения трафика применяют кэшир\--сщие серверы, не хранящие зон (рис. 6-7). Такие DNS-серверы лишь кэшируют запр-ссы, чтобы затем немедленно обслуживать аналогичные запросы с использованием ко тированных записей ресурсов. Другими словами, кэширующий сервер не пересылагидентичные запросы другим DNS-серверам, что ускоряет разрешение имен и снижагтрафик.
Разработка стратегии размещения служб DSS
Занятие
Гонолулу
уам
1 / i.,n • зрения производительности, отказоустойчивости, балаисироы ii нпГрул и и зашты
Лабораторная работа. Проектирование инфраструктуры DNS На этой лабораторной работе вы оцените проект инфраструктуры DNS для компании Northwind Traders. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытайтесь ответить снова. Ответы для самопроверки— в разделе «Вопросы и от веты» в конце главы.
Сценарий См. сценарий для лабораторной работы занятия 2.
Вопросы к лабораторной работе Исходя из представленного сценария, ответьте на следующие вопросы. 1. Как уменьшить нагрузку по администрированию DNS-зон в сети? 2. Вы обеспокоены безопасностью автоматических обновлений DNS, поступающие клиентов сети. Как защитить автоматические обновлений, не повышая нагрузк; .. администрированию DNS?
Закрепление материала Ответив на вопросы, приведенные ниже, вы сможете лучше усвоить основные темы ;: НЯТИЙ. Если вы не сумеете ответить на вопрос, повторите материал занятия и попытай?,:-;; ответить снова. Ответы для самопроверки — в разделе «Вопросы и ответы» в конце T;ia=^ 1. При проектировании инфраструктуры DNS вам потребовалось выбрать размещс-: ••. DNS-еервера. У вас имеются схемы и документация по топологии и инфрастр;,.-. \ ре сети. В чем значение этих сведений для выбора размещения сервера? 2. После установки дополнительного DNS-сервера в сети удаленного офиса пояьнл_ . проблема из-за перегрузки медленного WAN-канала трафиком зонной передач.; : результате работа сети замедлилась, а пользователи стали жаловаться на задер-л,. _ при доступе к электронной почте и Web-страницам, Как снизит, график э.лщ:. передачи через медленный WAN-канал? 3. Почему рекомендуется устанавливать в сети несколько DNS-серверов?
Пример из практики
2il/
Резюме •
Сведения, собранные во время создания документации сели, в частности ТОПОЛОГИЙ сети и пропускная способность каналов связи, чрезвычайно важны при проектиро вании размещения служб DNS. • Наличие нескольких DNS-серверов повышает производительность благодари ба лансировке нагрузки, а применение кзшируюших серверов в удаленных сетях сни жает загруженности медленных каналов связи трафиком зонных передач. • Настраивать DNS-сервер следует с учетом размещения на этом сервере других служб. Например, серверу, совмещающему роли DNS-сервера и контроллера домена, по требуется больше памяти. Помните: размер необходимой DNS-еерверу памяти зави сит от величины зонного файла и количества записей ресурсов.
I
Пример из практики
Вам поручено разработать проект новой инфраструктуры DNS для iviTS Consulting. Inc — консалтинговой компании, занятой в гостиничном бизнесе, со штаб-квартирой в Гонолулу, штат Гавайи. Недавно наемный специалист обновил все серверы до Windows Server 2003 и установил Active Directory. На клиентских компьютерах используются ОС Windows 98 и Windows 2000 Professional. MTS наняла вас для проектирования инфра структуры DNS, интегрированной с существующей инфраструктурой Active Directory. На всех клиентских компьютерах планируется применять Windows XP Professional.
Общие сведения о компании За последние два года компания MTS расширилась и стала одной из ведущих компаний по консалтингу в сфере гостиничного бизнеса в странах Тихоокеанского региона В про шлом месяце было открыты представительства в Японии, Гонконге, на Тайване и не большой офис на Гуаме. В настоящее время под управление?..! MTS находится более 300 отелей по всему региону. В компетенцию компании входят все операции, от бронирова ния номеров (клиенты могут самостоятельно забронировать номер на сайте компании; до ведения хозяйства (услуг прачечной, питания, коммунальных услуг, безопасности) и бух галтерии (расчета заработной платы и т. д.). В компании применяются трехуровневые приложения, требующие для работы Web-браузер и подключение к Интернету.
География Кроме офиса в Гонолулу, у MTS имеются филиалы на островах Мауи и Кауаи, откуда можно выполнять все операции по управлению отелями на Гаваях. Филиалы полно стью укомплектованы ИТ-специалистами.
Сетевая инфраструктура Офис в Гонолулу подключен с филиалами на Мауи и Кауаи по 256-килобитному кана лу Fractional Tl и резервному ISDN-каналу, офис на Гуаме сообщается с Гонолулу по 128-килобитному каналу Fractional Tl. Отделения в Японии, Гонконге и на Тайване связываются с офисами Тихоокеанского региона через Интернет и зависят от местных поставщиков услуг Интернета. Во всех офисах Тихоокеанского региона установлены
208
Проектирование структуры ВШ
Глава 6
LAN со скоростью передачи данных в 10/100 Мбит/с. На рис. 6-9 показана схема части сети компании.
Рис. 6-9. Схема части сети
Планы на будущее На данный момент не планируется значительное расширение штата имеющихся офисов, но в течение ближайших двух лет возможно открытие филиала в Пекине.
ИТ-менеджмент ИТ-специалисты в Гонолулу отвечают за филиалы в Гонолулу, на Мауи, Кауаи и Гуа ме. Отдельные ИТ-отделы имеются в Токио, Тайбее, Гонкоге. Однако за проектирова ние и поддержку инфраструктуры DNS отвечает руководство ИТ-отдела в Гонолулу.
Вопросы Исходя из этого сценария, ответьте на следующие вопросы. 1. Какую дополнительную информацию потребуется собрать для размещения DNSсерверов? 2. Предположим, что файлы DNS-зон реплицируются из офиса Гонолулу в Токио ; помощью зонных передач. О чем следует позаботиться, принимая во внимание су ществующую топологию сети? Как снизить или полностью исключить угрозы безо пасности репликации, связанные с текущей инфраструктурой сети? 3. Пользователи в офисе на Гуаме жалуются на медленный доступ к ресурсам чере: Интернет. Хотя в этом офисе есть DNS-сервер, оказалось, что канал, связываю щий Гуама и Гонолулу, загружен в основном зонной передачей. Как решить эту проблему?
Резюме главы
4. Вы заключили с MTS контракт на участие в организации филиала в Китае. Менед жеры филиала говорят, что уже используют DNS на основе UNIX-службы BIND и не собираются отказываться от нее, поскольку у администратора DNS китайского филиала имеется большой опыт работы с этой реализацией DNS. Таким образом, важно интегрировать текущую реализацию DNS в Active Directory. О чем нужно позаботиться, чтобы выполнить поставленную задачу?
Ц Резюме главы •
•
•
•
•
•
•
•
•
•
•
Первый этап анализа существующей инфраструктуры DNS — создание ее схемы, в отдельных случаях соответствующая схема создается во время анализа структуры Active Directory. Чтобы определить компоненты существующей инфраструктуры DNS, прежде всего следует разобраться в ее работе. DNS — это, в сущности, база данных, в которой хранятся записи ресурсов, поддерживаемых DNS-серверами. Эти данные должны реплицироваться на другие DNS-серверы для обеспечения отказоустойчивости и балансировки нагрузки. Репликация зонных файлов происходит с помощью так называемых зонных пере дач; реализация DNS в Windows Server 2003 поддерживает три типа зонных передач: добавочную (IXFR), полную (AXFR) и быструю зонную передачу. Проектирование пространства имен DNS начинается с изучения существующей среды Active Directory. Сначала спроектируйте инфраструктуру Active Directory, a затем добавьте к ней инфраструктуру DNS. Один из важнейших аспектов проектирования DNS — защита компонентов DNS. Разведка сети, DoS-атаки и «отравление» кэша DNS — это лишь некоторые из потенциальных угроз безопасности инфраструктуры DNS. Зонный файл можно хранить двумя способами: в виде текстового файла в папке systemroot\System32\DNS на каждом DNS-сервере, либо (для зон, интегрированных в Active Directory), в БД Active Directory. Раздел каталога приложений позволяет хранить в Active Directory специфичные для приложений данные, которые следует реплицировать только на определенные кон троллеры доменов. Зоны обратного просмотра проектируют так же, как зоны прямого просмотра. По мните о репликации зон с целью обеспечения отказоустойчивости и балансировки нагрузки. Сведения, собранные во время создания документации сети, в частности топология сети и пропускная способность каналов связи, чрезвычайно важны при проектиро вании размещения служб DNS. Наличие нескольких DNS-серверов улучшает производительность благодаря балан сировке нагрузки, а применение кэширующих серверов в удаленных сетях снижает загруженности медленных каналов связи трафиком зонных передач. Настраивать DNS-сервер следует с учетом размещения на этом сервере других служб. Например, серверу, совмещающему роли DNS-сервера и контроллера домена, по требуется больше памяти. Помните: размер необходимой DNS-серверу памяти зави сит от величины зонного файла и количества записей ресурсов.
2i0
Проектирование структуры DNS
S«s!»a 0
Ц Рекомендации по подготовке sc экзамену Прежде чем сдавать экзамен, повторите основные положения и термины, ирньойенкьк ниже, чтобы выяснить, какие темы нужно проработать дополнительно.
Основные положения ы Для анализа существующей инфраструктуры DNS критически ьажио наличии д., кументации и схем сети, это основа проекта сети. * Проектирование пространства имен DNS начинаете,! . IU,I,HI,,I . , ii • Due. {.,,>, л затем добавьте к ней инфраструктуру DNS * Защита инфраструктуры DNS начинается с анализа возможных рисков Развелч-а сети; DoS-атаки и «отравление» кэша DNS — зто лишь некоторые из ногеппиши. ных угроз безопасности инфраструктуры DNS,, * Проектировать стратегию разрешения DNS-имен следует с учетом погребли, ти D интеграции с другими сетевыми службами, такими как DHCP и WII IS — з;о позво лит обеспечить высокую производительность этих служб.
Основные термины Зона - гене — непрерывная часть пространства имен DNS, управляемая DNS-cepacpo..! как единое целое. Зонная передача ~ zone transfer — процесс репликации DNS-данных с ОД11ОГ0 сервера на другой. Windows Server 2003 поддерживает три типа зонных шреиач. добавочна.-, (IFXR), полная (AXFR) и быстрая. Жьшарутщш сервер - caching-only server — DMS-еервер, который котирует о'пошкп п_ запросы и возвращает клиентам кэшированные данные. Это уменьшает врг.мя полимя^ь, это вачгао не только размещение серверов, но и скорость передачи данных но WAN- началам, связывавшим подсети, от которой во многом зависят зонные переда чи Fc.ni! Г1ПСТТПНМ только медленные каналы, лучше поискать другие способы обтовле нчя яачнсей ресурсов. Плинии? 5 Лабораторная работа
По cy.tM= ле г "? и доменов, приведенной в сценарии, разработайте стратегию им? ис"?яииа гггтя .компании Northwirtd Traders. Обоснуйте свое предложение, П[»з««л*>рчЦ '»т5ет'- возможны различные варианты, одна из подходящих стратегий изо*)ряш-сня ня .г (к»ду¥ш,ей схеме. Так как доменные имена не зарегистрированы в Интернет», и г п п г и - . Э Т е т с л .поигРЛЬНОе ПРОСТРЯИСГВО ИМ8Н. r^nfJ^/hr^rjersJOOe!
NWtraders.local
/ .л Глазго
Asia Pacific Гс.Г; гпцпг*
NAeast
НИПКР
NAwest
Лес NWtraders
з.янятио ?_ закрепление материала 1
В .чашей организации более 350 пользователей, работающих с ОС Windows 98 и Wmdovs T-.IT 'Workstation. Пользователи постоянно перемещаются по территории ком панич, при этом вам требуется обновлять записи хостов в DNS. Какие функции г у т позволят снизить нагрузку на администратора по созданию и обновлению этих Правильный ответ: можно настроить DHCP-сервер так, чтобы он выполнял обновления от имени DHCP-клиентов, DHCP-сервер зарегистрирует записи типа А (хост) и РТР для «кеч DHCP-клиентов, В результате администратору не придется вводить эту ий-
? Прочитав в компьютерном журнале статью про перехват зонной передачи при помо щи анализатора протокола, ваш начальник считает, что репликация DN8-данных по сети слишком уязвима для атак. Как успокоить начальника? Правильный ответ: скажите ему, что зонные передачи можно разрешить только на определенные тр..я.дреса и защитить шифрованием, '• Какая версия B'HD рекомендуется для использования с Active Directory? Правильный ответ; 8Л,2 или выше.
феплвнмв мау£#ш£Ш£> S^*™™™**-
6ЫЯ7
гле работает унаследованная-программа.
Эта
S^=^2S^5S?S^^^
программа
4
>OuKfe&S>X?& ъ u T a * i t ъ даст^тл та-^ъ отсутствия р а з р е ш е н и й . % о может быть п р и ч и н о й этой проблемы?
Правильный ответ: так как UNIX-программа проверяет подлинность рабочей тгтищг по ее хост-имени, требуется зона обратного просмотра. Зоны обратного просмотра рав-Ч решают IP-адрес в хост-имена, а зоны прямого просмотра — хост-имена в IP-адреса. Из вопроса ясно, что пользователи не могут получить доступ к программе, стало быть, DNS-сервер с зоной обратного просмотра недоступен. Администратор должен убедить ся, что зона обратного просмотра доступна пользователям, а также подумать о созда нии дополнительной зоны для обеспечения отказоустойчивости. 2. Вы готовитесь подключить в сеть сервер с Windows Server 2003. Это первый сервер сети, и после установки ОС вы собираетесь повысить его до контроллера домена. Перечислите этапы установки DNS на этот компьютер. Правильный ответ: так как в сети нет других DNS-серверов, мастер установки Active Directory предложит установить DNS и автоматически настроит ее по ТСРДР-параметрам сервера. 3. Вы только что установили Active Directory и создали зону для домена sales.contoso.com. Назовите два способа хранения зонного файла для этого домена. Правильный ответ: файл стандартной зоны хранится в текстовом формате; зона, инте грированная в Active Directory, хранится в дереве Active Directory, расположенном в разделе каталога домена или приложений.
Занятие 4. Лабораторная работа 1. Как уменьшить нагрузку по администрированию DNS-зон в сети? Правильный ответ: рекомендуется использовать DNS-серверы на основе Windows Server 2003 и Windows 2000 Server, а также зоны, интегрированные в Active Directory. 2. Вы обеспокоены безопасностью автоматических обновлений DNS, поступающих от клиентов сети. Как защитить автоматические обновлений, не повышая нагрузку по администрированию DNS? Правильный ответ: на всех серверах следует разрешить только безопасные динамические обновления.
Занятие 4. Закрепление материала 1. При проектировании инфраструктуры DNS вам потребовалось выбрать размещение DNS-сервера. У вас имеются схемы и документация по топологии и инфраструкту ре сети. В чем значение этих сведений для выбора размещения сервера? Правильный ответ: в документации указана доступная полоса пропускания каналов, связывающих филиалы компании, а также подробности о числе серверов, размещении маршрутизаторов, распределении пользователей по подсетям и другие сведения, от ко торых зависит размещение DNS-серверов и требования к их оборудованию.
Проектирование структуры DMS
Глава 6
Занятие 3. Закрепление материала 1. Вы — администратор сети с Windows Server 2003, в которой имеется компьютер под управлением UNIX, где работает унаследованная программа. Эта программа требу ет проверки подлинности подключающихся к ней рабочие станции по хост-именам. Пользователи жалуются, что они не могут работать с этой программой и получают сообщение о отказе в доступе из-за отсутствия разрешений. Что может быть причи ной этой проблемы? Правильный ответ: так как UNIX-программа проверяет подлинность рабочей станции по ее хост-имени, требуется зона обратного просмотра. Зоны обратного просмотра раз решают IP-адрес в хост-имена, а зоны прямого просмотра — хост-имена в IP-адреса. Из вопроса ясно, что пользователи не могут получить доступ к программе, стало быть, DNS-сервер с зоной обратного просмотра недоступен. Администратор должен убедить ся, что зона обратного просмотра доступна пользователям, а также подумать о созда нии дополнительной зоны для обеспечения отказоустойчивости. 2. Вы готовитесь подключить в сеть сервер с Windows Server 2003. Это первый сервер сети, и после установки ОС вы собираетесь повысить его до контроллера домена. Перечислите этапы установки DNS на этот компьютер. Правильный ответ: так как в сети нет других DNS-серверов, мастер установки Active Directory предложит установить DNS и автоматически настроит ее по TCP/IP -парамет рам сервера. 3. Вы только что установили Active Director)' и создали зону для домена sales.contoso.com. Назовите два способа хранения зонного файла для этого домена. Правильный ответ: файл стандартной зоны хранится в текстовом формате; зона, инте грированная в Active Directory, хранится в дереве Active Directory, расположенном в разделе каталога домена или приложений.
Занятие 4. Лабораторная работа 1. Как уменьшить нагрузку по администрированию DNS-зон в сети? Правильный ответ: рекомендуется использовать DNS-серверы на основе Windows Server 2003 и Windows 2000 Server, а также зоны, интегрированные в Active Directory. 2. Вы обеспокоены безопасностью автоматических обновлений DNS, поступающих от клиентов сети. Как защитить автоматические обновлений, не повышая нагрузку по администрированию DNS? Правильный ответ: на всех серверах следует разрешить только безопасные динамические обновления.
Занятие 4. Закрепление материала 1. При проектировании инфраструктуры DNS вам потребовалось выбрать размещение DNS-сервера. У вас имеются схемы и документация по топологии и инфраструкту ре сети. В чем значение этих сведений для выбора размещения сервера? Правильный ответ: в документации указана доступная полоса пропускания каналов, связывающих филиалы компании, а также подробности о числе серверов, размещении маршрутизаторов, распределении пользователей по подсетям и другие сведения, от ко торых зависит размещение DNS-серверов и требования к их оборудованию.
Вопросы и ответы
213
2. После установки дополнительного DNS-сервера в сети удаленного офиса появилась проблема из-за перегрузки медленного WAN-канала трафиком зонной передачи, в результате работа сети замедлилась, а пользователи стали жаловаться на задержки при доступе к электронной почте и Web-страницам. Как снизить трафик зонной передачи через медленный WAN-канал? Правильный ответ: установите в удаленной сети кэширующий сервер. Поскольку он не хранит зон, это уменьшит объем трафика через WAN-каналы. 3. Почему рекомендуется устанавливать в сети несколько DNS-серверов? Правильный ответ: преимуществ несколько. Во-первых, при неисправности одного DNSсервера пользователи смогут обратиться к резервному DNS-серверу. Во-вторых, ис пользование нескольких DNS-серверов в сети рекомендуется для балансировки нагруз ки, которая увеличивает возможности служб DNS по сравнению с возможностями оди ночного сервера.
Пример из практики 1. Какую дополнительную информацию потребуется собрать для размещения DNSсерверов? Правильный ответ: в сценарии не указано число пользователей в различных филиалов в Тихоокеанском регионе и количестве запросов, отправляемых ими DNS-серверам. Эта информация очень важна, так как от нее зависит размещение и число DNS-серверов. Также следует узнать доступную полосу пропускания и задержку каналов связи между офисами. 2. Предположим, что файлы DNS-зон реплицируются из офиса Гонолулу в Токио с помощью зонных передач. О чем следует позаботиться, принимая во внимание су ществующую топологию сети? Как снизить или полностью исключить угрозы безо пасности репликации, связанные с текущей инфраструктурой сети? Правильный ответ: в существующей инфраструктуре зонные передачи между Гонолулу и Токио будут осуществляться через Интернет, и потому будут уязвимы для множества атак, включая разведку сети, DoS-атаки и перехват. Защититься от них можно созда нием виртуальной частной сети (VPN) между Токио и Гонолулу, которая будет шифро вать все зонные передачи, а также использованием зон, интегрированных в Active Directory, и разрешением зонных передач только между авторизованными DNS-серверами. 3. Пользователи в офисе на Гуаме жалуются на медленный доступ к ресурсам через Интернет. Хотя в этом офисе есть DNS-сервер, оказалось, что канал, связываю щий Гуама и Гонолулу, загружен в основном зонной передачей. Как решить эту проблему? Правильный ответ: по-видимому, проблема возникает из-за зонных передач, поэтому быстрее и проще всего сделать имеющийся DNS-сервер кэширующим сервером. Пользо ватели должны заметить повышение скорости доступа к Web-сайтам, поскольку их за просы будут кэшироваться сервером, снижая тем самым потребность в рекурсивных запросах. Кроме того, поскольку сервер кэширования не хранит зонные файлы, связы вающий офисы канал больше не будет использоваться для зонной передачи, что освобо дит его для передачи других данных.
Проектирование структуры DNS
Глава 8
Вы заключили с MTS контракт на участие в организации филиала в Китае. Менед жеры филиала говорят, что уже используют DNS на основе UNIX-службы BIND и не собираются отказываться от нее, поскольку у администратора DNS китайского филиала имеется большой опыт работы с этой реализацией DNS. Таким образом, п ажно интегрировать текущую реализацию DNS в Active Directory. О чем нужно позаботиться, чтобы выполнить поставленную задачу? Прзвильный ответ: в первую очередь убедитесь, что в пекинском офисе используется версия BIND 8.1.2 или более поздняя, согласно требованиям к DNS для Active Directory, Текущая версия BIND ня обязана поддерживать динамические обновления записей ре сурсов, но должна поддерживать записи ресурсов типа SRV, поскольку они используют ся для поиска служб, необходимых в сети с Active Directory.
ГЛ ABA
7
Проектирование структуры WINS
Зэыягиа
1
Р!о,