WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 || 3 | 4 |   ...   | 7 |

«Л Федор Зубанов Active Directory подход профессионала Издание исправленное Москва 2003 УДК 004 ББК 32.973.81-018.2 391 Ф. В. ...»

-- [ Страница 2 ] --

Теперь поговорим о расписании репликации. Расписание позволяет открывать «окна* для выполнения межсайтовой репликации. По умол чанию такое окно открыто 24 часа в 7 дней в неделю. Если ка налы его можно оставить таким. Если же канал загружен в рабочее то на этот период можно закрывать. Если при этом есть незагруженный альтернативный но с более высокой стоимостью межсайтовой связи, то у него можно открыть окно на то же самое время, Замечание Если репликация началась незадолго до закрытия окна, то она завершится тиражированием всех изменений, которые долж ны переданы в сайт или из него. Окно при этом не сможет быть Очень тесно с расписанием понятие интервала репликации, т. е. времени, по истечении контроллеры доменов в разных сайтах обмениваются данными. По умолчанию он длится 1$ минут, что вполне приемлемо и сравнимо с максимальным временем репли кации сайта.

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

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

Последний параметр межсайтовой связи — протокол репликации, мы обсудим в главе «Репликация Active — здесь лишь отмечу, что протокол SMTP используется в основном на ненадеж ных линиях и для него нельзя определить расписание Объекты связи Для каждой межсайтовой связи создаются объекты связи — они отве чают за передачу сведений о репликации от одного контроллера до мена к другому. Объект связи характеризуется:

• направлением;

именем;

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

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

Создание объектов связи мы обсудим в разделе «Отка зоустойчивые Объекты связи могут три вида имен. У созданных ISTG имя бу дет безликим — generatedx Если вы измените свойства этого объекта, то его имя также изменится и станет, с точки зрения администратора, менее осмысленным. Оно превратится в На конец, если объект связи создан вами, вам его и называть.

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

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

Отсюда второй если сервер-фор пост и КСС работает в сайте, создайте хотя бы еще один ный форпост.

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

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

Форпост тиражирование:

• из центра в филиалы;

из филиалов в • SYSVOL — из центра в филиалы (предполагаем, что в филиалах не происходит изменений в сценариях или расширениях групповой политики), При тиражировании из центра в филиалы каждый сайт филиала об ращается к центральному сайту, как только открывается окно репли кации. Обращение выполняется от контроллера домена в филиале к форпосту в центре. Обработка таких обращений на форпосте идет параллельно и ограничена только объемом тиражируемых данных и вычислительной форпоста в центре. Максимальное чис ло партнеров по репликации для одного сервера-форпоста при ти ражировании в филиалы рассчитывается по формуле:

партнеров по репликации на один цикл где;

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

К — число циклов репликации в день;

Т — время репликации.

Замечание Указанное одновременных подключений реали стично для сервера с 4 процессорами Хеоп-500 и хорошей дисковой подсистемой. Примеры конфигурации см. в главе «Установка Active репликация возможна в течение 14 часов в день (Н), число одновременных подключений максимально — 30 (О), репликация в 2 цикла а время выполнения одной репликации — час (Т). Получим, что для рассматриваемого сервера форпоста до пустимо иметь 210 партнеров по исходящей репликации.

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

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

R Число партнеров по репликации на один цикл N где:

R — продолжительность работы окна репликации в минутах;

N — длительность тиражирования изменений с одного контроллера домена в минутах.

Оба параметра зависят от факторов. Пусть в нашем при мере окно репликации открыто 60 минут, а для выполнения тиражи рования изменений из каждого филиала нужно 2 Тогда один форпост не может иметь более 30 партнеров по репликации, Учтите также, что его партнерами по репликации являются контроллеры до мена внутри сайта, поэтому количество сайтов, обслуживаемых одним форпостом, должно быть меньше на эту величину. Если предположить, что следующее за окно репликации откроется для другой группы сайтов, то число возможных партнеров по репликации удвоится. В нашем примере репликация доступна 14 часов в сутки в два интервала. Значит, в течение каждого интервала можно использовать 7 одночасовых окон. Если каждое из окон обслуживает разные группы филиалов, то наш сервер-форпост способен иметь до 210 партнеров по репликации. Предполагая, что внутри сайта у этого сервера есть два партнера, получим максимальное число внешних партнеров — 196.

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

= Мин. количество форпостов Число по на один цикл Если в нашем примере к центру подключено 390 филиалов, то мальное число форпостов — 2.

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

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

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

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

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

резервных каналов:

1 — основной канал, 2 — коммутируемый канал, 3 — виртуальный отказоустойчивого и сбалансированного филиалов или Мелочей не полезно интегрировать с балансировкой нагруз ки. Допустим, сайт связан с большим количеством алов. Помимо создания объекта связи для каждого из филиалов с дву мя разными форпостами в центре, имеет смысл сделать рас писание репликации. Пусть контроллер домена в первом филиале свя зан с первым и вторым форпостами в контроллер во втором филиале — со вторым и третьим контроллер в третьем филиале — с третьим и первым и т. д. Расписание репликации состав ляется так, чтобы репликация с четными форпостами в центре выпол нялась по четным часам, а с нечетными — по нечетным. Это позволит разгрузить форпосты и создать временной запас на тот случай, репликация не завершится в отведенное Мастера операций и Глобальный каталог.

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

Мастер схемы Как вы знаете, это единственный во всем лесу мастер операций, от ветственный за внесение изменений в схему. Изменять схему может администратор с правами группы Schema Admins. Так как эта группа располагается только в корневом домене леса, то целесообразно и мастер схемы держать там же. Если используется пустой корневой домен, именно он — идеальное место для мастера схемы.

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

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

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

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

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

Мастер имен отвечает за имен в лесу.

Когда домен, мастер обращается к серверу в такого имени. Именно поэтому он должен располагаться на одном сервере с сервером ГК. Но почему он не может обратиться к серверу ГК другом компьютере? Теоретически может, но... Пред ставьте, что в момент добавления нового домена сервер ГК недосту пен. При этом появляется вероятность добавления домена с уже су ществующем в лесу именем, что неминуемо приведет к конфликтам.

Поэтому ГК и должен быть на том же самом компьютере.

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

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

Имитатор Имитатор прежде всего для клиентов старого типа (ранее Windows 2000), так как с их точки зрения он играет роль контроллера домена. Кроме того, он основным обозревате лем домена (master browser) для на NetBIOS. Если они используют функцию то она об служивается только имитатором PDC. Если домен работает в смешан ном режиме и в нем есть контроллеры домена Windows NT, то ими татор PDC для них — контроллер, с которого они получают реплики базы SAM, Но даже если не используются старые клиенты и нет контроллеров домена Windows NT, роль имитатора равно важна. Он отве чает за срочное тиражирование изменений в Active Directory, таких как смена паролей или учетных записей. Он также отве чает за аутентификацию сменивших пароль (см. гла ву «Репликация Active или не бывает Планируя учтите:

для каждого домена должен быть свой имитатор PDC;

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

в больших доменах имитатор PDC несет повышенную и его целесообразно размещать на отдельном сервере.

Мастер RID О RID можно прочитать практически например, в [1], [3], [б], так что описывать его не буду. Мастер относительных идентификаторов • хранит общий пул идентификаторов и выдает их контрол лерам по мере необходимости;

при этом обеспечивается уникаль RID в домене;

переносит объекты из одного домена в другой;

дело в что при переносе учетной записи между доменами у нее меняется DN и SID, а вот уникальный ID остается неизменен;

мастер RID что бы в домене не двух объектов с одним уникальным ID.

Компьютер с мастером RID относительно не загружен и поэтому может располагаться на тех же где находятся другие мастера доменных операций.

Мастер инфраструктуры Чтобы понять, как правильно расположить мастер инфраструктуры, как он работает.

Когда объект на одном контроллере домена ссылается на отсутству ющий в локальной базе объект, этот объект представляется в виде содержащей объекта, его (если это участник безо пасности) и отличительное имя DN. При перемещении этого объекта меняются его и SID (если он перемещается в домен), но не Мастер инфраструктуры периодически проверяет такие ссылки в доступной ему реплике базы Active Directory. Для этого он обращается к ГК и проверяет, не изменились ли у объекта с данным GUID его и SID. Если да, то соответствующие изменения вносятся в локальную реплику и тиражируются на остальные контроллеры в домене.

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

Таким образом, размещая мастер помните, что он:

должен быть один в каждом домене;

не должен располагаться на сервере ГК;

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

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

Когда в лесу только один домен, то надобности ГК нет.

Все контроллеры домена имеют информацию обо объектах в лесу. Может, и от него? Не стоит. Во-первых, для работы ряда программ требуется обращение именно к серверу ГК. Во-вторых, есть вероятность расширения Active и добавления новых доменов иди деревьев. А тут уж без ГК уже не обойтись.

Поэтому рассмотрим две весь домен в одном сайте и до мен по сайтам. В первом случае достаточно иметь один ГК.

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

Совет Серверы ГК можно поместить на всех контроллерах кроме мастера инфраструктуры.

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

Оптимальным считается создание двух ГК в центре и по одному в сайтах с числом пользователей от 50 человек. Если структура связи сайтов сложная, то в крупных сайтах, можно иметь по 2 ГК.

Примеры размещения вы познакомились с общими рекомендациями по мастеров операций и ГК — рассмотрим пару примеров оптимально го размещения.

или бывает Контроллер домена схемы, доменных имен Глобальный каталог Контроллер домена Контроллер домена инфраструктуры, Глобальный имитатор Контроллер домена Глобальный каталог Пример распределения в домене Вариант для одного домена в лесу:

все контроллеры домена в сайте А, кроме одного, являются серве рами мастера, имеющие отношение ко всему лесу, отделены от масте относящихся к домену;

• сайт Б не очень крупный, поэтому в нем нет ГК;

сайт В крупный, и в нем присутствует ГК.

Вариант для нескольких доменов в лесу;

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

• мастера, имеющие отношение ко всему лесу, расположены в кор невом домене;

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

сайт Б не очень крупный, поэтому в нем нет ГК;

Active Directory: профессионала сайт В крупный, и в нем присутствует ГК;

сайт Г содержит домен, поэтому в нем как ГК, так и доменные мастера операций.

мастер RID домена домена домена каталог на.

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

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

предъявляемые к нему требования.

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

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

3. Подготовительный сайт должен обеспечивать надежный к корневому домену и к серверу DNS в нем, а также мастерам RID, доменных имен и инфраструктуры.

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

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

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

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

Схема представляет собой набор классов объектов и атрибутов, из ко торых создаются экземпляры объектов Active Directory. По умолчанию она содержит более 140 классов и 850 атрибутов. Такого количества с лихвой хватает для выполнения всех операций с Active Director/. И все же довольно часто схему приходится модифицировать. Например, вы не представляете работу некоторого атрибута у пользователей либо устанавливаете приложение, которое модифицирует схему и заносит в нее классы своих объектов.

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

Безобидная, казалось, модификация схемы порой вызывает последствия. Допустим, вы хотите, чтобы некий атрибут реплициро вался на серверы ГК. Вы указываете это в оснастке диспетчера схемы и... Все серверы ГК устанавливают свой USN в 0. Результат — полная репликация абсолютно всех объектов в ГК и перегрузка в сети.

Замечание При установке Microsoft Exchange 2000 в ГК добавляются Следовательно, выполнять это надо чтобы репликация не шла по медленным каналам.

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

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

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

Способы модификации схемы Ситуация Решение Ни один из существующих новый класс.

классов не отвечает вашим требованиям Существующий класс Создайте:

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

класс па существующего и добавьте новые атрибуты к классу.

ИЛИ:

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

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

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

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

Вот правила политики модификации схемы.

Инициализация процесса модификации схемы:

• передача списка предлагаемых изменений на рассмотрение специальной комиссии;

• проверка необходимости в изменениях;

• определение потенциального воздействия на существующие объекты, сетевой трафик;

• разработка процесса модификации;

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

• получение разрешения от комиссии.

74 Directory: подход профессионала • Тестирование модифицированной схемы;

• тестирование предлагаемого решения в тестовой зоне в отдель ном лесу;

• определение изменений требуемым спецификациям;

• разработка эффективного плана восстановления оригинальной схемы;

• получение разрешения на выполнение изменения в рабочей сети.

• Выполнение модификации:

• ограничение членства в группе Schema Admins;

• разрешение выполнения записи на мастере схемы;

• проверка того, что все контроллеры доменов получили версию схемы;

• перевод мастера схемы в режим только для чтения.

Данная политика должна быть разработана и применена в обязатель ном порядке. При модификации схемы:

семь раз убедитесь в том. что без изменения не обойтись;

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

• постарайтесь начать с самого простого решения;

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

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

• тщательно документируйте все сделанные изменения;

• следите за тем, кто входит в группу Schema Admins, и за разреше нием записи на мастере схемы.

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

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

Ниже показан общий подход к решению этих проблем. Вот наиболее типичные случаи:

• подключение домена к дереву через VPN: характерно для филиалов, связанных с основной частью сети предприятия через частные сети или через Интернет;

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

авторизация ресурсов в демилитаризованной зоне вариант применяется при авторизованном доступе к ру, почтовому серверу и пр.

Подключение доменов через VPN Связь с центром или между собой через Интернет дает зна чительную экономию по сравнению с арендой выделенных каналов.

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

Я забыл сказать про межсетевой экран. Естественно, он позволит ис ключить нежелательный доступ из столь агрессивной среды, как Ин тернет. Межсетевой экран настраивается так, чтобы пропускать толь ко нужный трафик. Например, если для пользователей внутренней сети предоставляется доступ к ресурсам Web, необходимо открыть трафик HTTP и Как вы понимаете, контроллеры домена обмениваются между собой по совершенно иным протоколам. Нужно открывать трафик DNS.

(с огромным числом портов), SMB, при необходимости — Net BIOS и др.). Взгляните на список служб и протоколов, используемых при взаимодействии контроллеров домена.

Перечень и портов, используемых службами Windows Служба Порт/протокол NetBIOS (служба имен) Active Directory: подход профессионала Служба Порт/протокол RPC порты поверх \Р 445/tcp.

Lightweight Directory Access Protocol (ШАР) 389/tcp через SSL ГК LDAP ГК LDAP SSI. 3269/tcp 88/tcp, Name 53/udp Windows Internet Naming (WINS) (если надо) 42/tcp, Разрешив этот трафик через межсетевой экран, вы оголите сеть. Фак тически это то что убрать экран вообще.

Еще одна проблема — В корпоративной сети обычно ис пользуют адреса, не в Интернете. А тре буется механизм трансляции адресов вроде NAT. Но при этом для связи нужно обеспечить однозначное назначение ком пьютеру во внутренней сети еще и адреса из интернетовского пула, что опять же практически этот компьютер наружу. Если он к тому же контроллер домена, то все Directory будут поэтому применяется Главное при этом — правильную межсетевых экранов, и кон троллеров домена. Схематично такое подключение изображено на рисунке. Начнем с первого экрана. Пусть оба межсете вых экрана выполнены на ISA Server. Если у вас иные сред ства вы сможете адаптировать параметры. Эти же компьюте ры будут выполнять роль серверов удаленного доступа.

Итак, в качестве протокола используем РРТР.

А • Межсетевой экран или Мелочей не бывает Замечание Если у вас развернута PKI, можно ис L2TP/IPSec.

• Разрешаем передачу и указываем, что соедине ние может инициировать как этот сервер, так и удаленный.

В качестве источника второго конца туннеля указываем адрес уда межсетевого экрана.

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

Сохраняем конфигурационную информацию в файле.

В результате будут созданы и сконфигурированы как VPN-интерфейс, так и 4 пакетных фильтра доступа.

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

находясь в удаленном офисе, надо что доменные имена в центральном офисе разрешаются без проблем. Особое вни мание — к параметрам DNS (см. главу «Установка Active Помните: успеха зависит от правильной конфигурации на сервере, который станет контроллером домена.

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

Если все прошло можно создать и подключить домен.

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

Филиал нужно выделить в отдельный сайт независимо от качества канала, предоставленного вашим поставщиком услуг Интернета.

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

Можно, конечно, организовать туннель, но вряд ли это оптимальное решение. Лучше всего использовать протокол IPSec. He стану вдаваться в подробносги насчет его работы. вы это и сами знаете, а если нет, то прочитайте в Основной эффект от IPSec в том, что число портов, которые надо открыть на межсетевом экране, резко сокраща ется. Вот они.

IPSec Служба Протокол/Порт DNS 53/tcp, 88/tcp, IKE, Internet Key Exchange IPSec ESP. security IP protocol IPSec AH. authenticated header IP protocol Заметьте: все эти порты следует только если политика IPSec сконфигурирована для контроллеров домена, а серверы DNS распо лагаются раздельно. Если же расположены на кон троллерах, порт 53 можно закрыть.

Еще дальше можно пойти, если внедрить инфраструктуру PKI. Тогда для установления связи IPSec можно использовать сертификаты, а не Такой подход позволит закрыть порт 88.

AD, или Мелочей не бывает двух через экран с IPSec К какому результату приведет такое решение?

1. Любой пользователь из внешней сети, для которого определе на соответствующая политика IPSec. не получит доступа в защи щенную зону.

2. Репликация между контроллерами домена в защищенной зоне и вне ее будет выполняться только между теми контроллерами до мена, для которых сконфигурирована политика IPSec. Пример политики для этого случая см. в главе "Групповая 3. Любой пользователь в защищенной сети может быть цирован в но при этом может не иметь доступа за преде лы своей закрытой зоны.

Не стану описывать точную контроллеров домена и параметров межсетевого экрана, так как это выходит за рамки дан ной главы. Если вам это интересно, обратитесь к Microsoft Technet, книга Top IT Active Directory replication over firewalls.

Совет Будьте внимательны при политик IPSec. Нужно чет ко представлять, какие категории пользователей и какие компьюте ры могут а какие — нет.

• 80 Active подход профессионала Авторизация ресурсов в Одна из распространенных — предоставление авторизованным предприятия доступа к ресурсам из Интернета. Под черкну: речь идет именно об авторизованных пользователях, т. е. тех.

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

Типовое решение — разместить такие ресурсы в демилитаризованной зоне (DMZ), отделенной и Интернета, и от внутренней сети меж сетевыми экранами. При экранов проблему безопасности решить легко. организуется что к ресурсам в можно пройти либо из внутренней сети, либо из но пройти DMZ насквозь нельзя.

Авторизация же подразумевает, что прежде чем полу чить доступ к ресурсу, обратиться к центру авторизации, по лучить у него сеансовый билет, а потом, предъявив его серверу, на котором лежат нужные ресурсы, получить к ним доступ. Так как сквоз ной проход через DMZ закрыт, то, на взгляд, центр авториза ции может находиться только внутри Исходя из этого, возмож ны три варианта его размещения:

• каждый сервер сам авторизует доступ к своим ресурсам;

• в помещается не входящий в дерево Active Directory внутренней сети;

между доменом и внутренним деревом ус танавливаются односторонние нетранзитивные отношения;

• в DMZ помещается контроллер домена и ГК основного который и выполняет доступа.

Преимущества и каждого из этих способов таковы.

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

Проектируем или Мелочей не бывает Тип авторизации Преимущества Недостатки Неудобный из внут ренней сети: надо роваться на каждом сервере.

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

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

Никто не даст 100% гарантии того, что хакер не проникнет в DMZ. A раз нельзя считать эту сеть надежной и размещать в ней критичес ки важные серверы. Контроллер домена с относится к самым кри тическим элементам Active Directory, так как на нем хранится инфор мация обо всех пользователях сети. Выходит, данный вариант отпада ет по соображениям безопасности. Первые два просто неудобны. Я знаю компании, использующие их, но они были бы рады от них избавиться.

сделать так, чтобы и волки были сыты, и овцы целы, нельзя?

Отнюдь нет. Решение есть: это сервер аутентификации RADIUS. (В Windows 2000 это Internet Authentication Server — IAS.) О его работе см. [2]. В размещается который по связан через межсетевой экран с контроллером домена во внутренней сети.

Так как на этом сервере нет компонентов Active то компро метация учетных записей исключена.

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

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

Наиболее предпочтителен вариант с туннельным доступом, так как обеспечивает степень безопасности, защищая трафик, проходящий от клиента к серверу удаленного доступа через Интер нет. Туннель может работать как по протоколу РРТР, так и по L2TP/ Добавьте сюда аутентификацию пользователя по смарт-карте (по протоколу ЕАР) и получите сытых волков (руководство довольно, что пароли не надо вводить вообще) и целых овец (объекты Active Direc tory надежно защищены).

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

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

Штаб-квартира ГРТ Москве. В окрестностях столицы земельные участки, на которых сооружаются круглогодичные базы отдыха: зимой предлагаются искусственные горные склоны с подъем никами и трассы для катания на летом — верховая езда, бассейны, и пр. Каждая база будет иметь свою гостиницу.

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

Для привлечения иностранных туристов планируется создать подоб ные базы в Польше, Чехии, Германии, Болгарин и Хорватии через года. Потенциал системы по оценке специалистов ГРТ — 400- тысяч отдыхающих в год.

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

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

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

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

В штаб-квартире ГРТ находится который занимается под держкой локальной сети, но будет отвечать и за работу общей сети, Здесь же будет расположен центр авторизации клиентов. Каждая база отдыха имеет 1-2 сотрудников, ответственных за рабо тоспособности локальной сети, установку новых версий приложений и развитие системы. В штаб-квартире ДальТур также имеется ИТ-от дел, полностью ответственный за работу сети.

Штаб квартира имеет связи со всеми базами отдыха в Мос ковской области. Пропускная способность каналов — 256 кб/с. 50% трафика по этим каналам используется для передачи телефонных сигналов. Канал между базой в Санкт-Петербурге и штаб-квартирой имеет полосу пропускания 1,5 Мбит/с. База отдыха в Карелии связа на только с базой в Санкт-Петербурге. Планируется, что базы на Сред нем Урале и Алтае будут иметь спутниковые каналы 64 кб с базы связаны пока со штаб-квартирой ДальТур во Владивостоке. Все каналы спутниковые 64 кб/с. что между Московской штаб-квартирой и штаб-квартирой ДальТур будет канал 1,5 Мб/с. Связь с европейскими базами отдыха будет осуществ ляться по виртуальным выделенным каналам через Интернет. Штаб квартира имеет канал в Интернет с полосой 1,5 но его про пускную способность планируется увеличить до 10 Мбит/с.

Численность персонала в московской штаб-квартире — в штаб квартире ДальТур — 30 человек. На каждой базе отдыха число со трудников варьируется, но число пользователей невелико — В качестве ОС выбрана 2000, в качестве службы каталогов — Active Directory. Нужно спланировать архитектуру Active Directory.

Описанная топология сети такова:

Проектируем AD, или Мелочей Базы отдыха в Подмосковье База отдыха База на Среднем на на Камчатке в Москве, человек, служба База Приморье Базы отдыха в Европе общей сети Предложенная архитектура Беглый анализ задачи позволяет выделить две разные категории пользователей: клиенты баз отдыха и обслуживающий персонал. В то время как клиенты должны авторизоваться на любой базе, персонал не выходит за пределы своей базы. Более того, нет нужды в том, что бы персонал авторизовался где-либо еще. Фраза о том, что на каждой из баз используются свои приложения учета персонала, интегриро ванные с Active Directory, означает, что схемы Active Directory различ ны для разных баз отдыха.

Леса Можно сделать вывод о том, что данной организации требуется не сколько лесов доменов:

• один лес — для клиентов;

• остальные — для каждой из баз отдыха и штаб-квартир.

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

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

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

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

корневой — для штаб-квартиры ДальТур и дочерние для баз отдыха.

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

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

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

Сайты Говорить о сайтах имеет смысл только применительно к лесу клиен тов и к лесу ДальТур. Все остальные леса располагаются в отдельных сайтах.

Лес клиентов разбит на столько сайтов, сколько существует баз отды ха. Это следует из анализа пропускной способности каналов. То, что скорость доступа штаб-квартиры в Интернет составит 10 Мбит/с, значения не имеет, так как полагаем связь по виртуальному каналу через Интернет ненадежной, а значит, создания удален ных сайтов. Дополнительный сайт сделан в московской штаб-кварти ре. Именно здесь находится тот Web-сервер, через который клиенты могут бронировать места в гостиницах и планировать заезды на базы.

В сайте ДальТур нет надобности, так как клиенты не имеют доступа в офис ДальТур.

Проектируем или Мелочей не бывает Лес клиентов одного Топология лесов и Контроллеры доменов В каждом сайте клиентского леса по два контроллера домена, каждый из которых является сервером ГК. Контроллеры до мена в московском сайте также исполняют роли мастеров схемы, доменных RID. имитатора Эти же кон троллеры являются выделенными серверами-форпостами, и на них созданы связи. Для надежности для каждого сайта созда но по две связи. Расписание репликации по ним так, что по четным часам выполняется репликация с первым контрол лером домена удаленном сайте, а по нечетным — со вторым.

Лес разбит на три сайта. Это определяется пропускной спо собностью каналов. В центральном сайте расположены два контрол лера домена. В сайтах баз отдыха — по одному контроллеру. Ни один из серверов не является выделенным сервером-форпостом.

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

Active подход Домен клиентов содержит следующие ОП.

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

• ОП администраторов Здесь находятся учетные записи сотруд ников службы ИТ.

ОП штаб-квартиры Здесь размещаются приложения и серверы, используемые для обслуживания клиентов. К ним относится, на пример, сервер Web.

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

В штаб-квартире в Москве должны быть ОП:

• службы ИТ;

• финансового отдела;

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

Группы безопасности В домене клиентов должны такие группы безопасности:

• администраторов домена;

администраторов схемы;

• администраторов каждого из ОП;

этим группам делегируются пра ва управления соответствующими ОП;

• администраторов сервера Web В доменах баз отдыха должны быть:

• группа администраторов домена;

• схемы;

глобальная группа доступа к отчетам на просмотр;

глобальная доступа к отчетам на запись;

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

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

локальная группа доступа к отчетам на просмотр;

локальная доступа к отчетам на запись;

• локальная группа доступа к инвентарной информации на про смотр;

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

В домене московской штаб-квартиры должны быть:

• группа своего домена;

• группа администраторов своей схемы;

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

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

• глобальная группа к инвентарной информации на про смотр;

локальная группа доступа к отчетам на просмотр;

• локальная группа доступа к инвентарной информации на про смотр.

быть и иные группы для отделов в штаб-квартире.

Сервер Web и доступ к нему У сервера Web две основные функции;

являться лицом компании ГРТ в Интернете;

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

В соответствии с этим на сервере должны существовать две зоны:

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

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

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

90 Active Directory: подход профессионала Замечание сертификатов нуждается в инфраструк туре открытых которой выходит за рамки данной Закрытый ключ пользователя в смарт-карту с другой персональной информацией.

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

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

Вот мы и создали структуру Directory эффективного туристи ческого агентства.

Заключение Прочитав эту главу, вы, надеюсь, поняли, насколько серьезно надо подходить к Из опыта что от начала проек тирования до внедрения проходит минимум 5-6 месяцев в зависимо сти от объема организации. И все это время вы занимаетесь тем, о чем написано в этой главе!

Рассмотренные вопросы проектирования Active Directory охватыва ют такие как оценка нужного количества лесов, критерии разбиения на домены и ОП, общие рекомендации по применению групп безопасности, мастеров операций и ГК, но очень слабо затрагивают планирование групповой политики. Чтобы соста полную картину, обратитесь к главе "Групповая Если же вы не до конца разобрались в почему выбираются те или иные модели, советую почитать главы «Устанавливаем Active и "Репликация Active Установка Active Directory В любом учебнике или книге по Active Directory или Windows Server вы прочтете, что установить службу каталогов очень просто — достаточно выполнить команду Уны. на практике проходит гладко далеко не всегда. И виноваты в этом не Microsoft и не Windows 2000 — мы сами. Корень всех проблем либо в недоста знании сетевых сервисов Windows 2000. либо в излишней самоуверенности. Поясню последнее. Допустим, вы большой специа лист по сетям и работали преимущественно в UNIX-системах. Вы счи таете, что ваше знание, скажем. DNS является исчерпывающим. Мо жет, это и так, приступая к установке Active Directory, вы не ознакомились со специфическими требованиями к DNS, а в результа те — неудачная установка службы каталогов.

С чего же начинать установку? С планирования. Этой важной задаче посвящена предыдущая глава, а также написано немало книг, и я не стану повторяться. Если вы еще ничего не читали, то обратитесь к [8].

Допустим, вы спланировали структуру Active Directory (или для это сделал кто-то иной) и собираетесь приступить к тестированию. (За метьте: я пишу а не «к разворачиванию в боевых Не торопитесь — прочтите советы, приведенные Лишними они не будут.

Что делать с DNS Служба DNS — одна из основных служб Windows 2000, на которую опирается Active Directory. От правильности ее настройки зависит работа службы каталогов в целом. Обычно меньше всего проблем возникает при использовании службы DNS, встроенной в Windows 2000. Однако это не что нельзя использовать другие например BIND. Откройте любую книгу по Active и найдите требования к DNS — везде будет написано, что сервер DNS должен быть BIND не ниже 8.2.2, т. е. среди прочего он должен под держивать:

• записи типа СИМВОЛ динамические обновления;

расширенный набор символов (опционно).

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

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

нет ни одного сервера DNS — может быть сеть либо сеть на базе Windows NT или Novell Netware;

сервер DNS уже существует — возможно, он служит для доступа пользователей в Интернет или для разрешения имен хостов UNIX;

• создается много доменов Directory — при этом существует масса способов организации DNS;

создается лес доменов Active Directory — ситуация похожа на пре дыдущую, но имеет некоторые особенности.

Что ж, начнем по порядку — с самого простого случая.

Мой первый DNS Итак, вы приступаете к созданию домена Windows 2000. Не имеет никакого значения, устанавливаете ли вы контроллер «с нуля» или выполняете обновление контроллера домена Windows NT, — сер вер DNS необходим.

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

• Установите ОС Windows 2000 Server или Advanced Server.

• Установите необходимые драйверы устройств и убедитесь, что система работает нормально.

Проверьте параметры сетевого интерфейса. Адрес IP должен назначен статически. В качестве адреса сервера DNS укажите ад рес этого же компьютера.

Установка Active Directory • Далее можно установить и сконфигурировать сервис DNS самостоятельно, либо приступить сразу к установке контроллера домена. Если раньше вы никогда не лучше всего доверить мастеру установки службы каталогов Active Direc tory сделать это за вас. По крайней мере так вы застрахуетесь от неудачи при первой установке, а также позволит ознакомиться с правильными записями и параметрами DNS.

Если вы все же хотите сконфигурировать сервис сами:

• установите службу DNS через консоль управления;

• откройте оснастку DNS;

• создайте Forward lookup zone с тем которое вы хоти те дать своему домену Active эта зона должна быть первичной;

созданием зоны занимается программа-мастер;

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

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

. ] - Pause ' j Свойства зоны DNS. Обратите внимание на tynamic updates Active После этого вас и поджидают мелкие неприятности. Итак, запускаем На мастера отвечаем, что это новый домен в новом дереве в новом лесу. Вводим имя домена (полностью совпадающее с именем ранее созданной зоны DNS) и... получаем со общение о том, что программа не может определить, поддерживает ли сервер обновления. Такое сообщение выводит ся в 90% случаев. Программа не только предупреждает вас об но и автоматически сконфигурировать сервер Если вы уверены, что сконфигурировали зону правильно, не поддавайтесь искушению согласиться с этим предложением. Кстати, программа все равно не сможет сконфигурировать так как вы ее уже создали.

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

Если вы домена Windows NT, не забудьте в про цессе установки сказать, что требуется установить сервер Боль ше у вас не будет возможности его сконфигурировать. Программа обновления сделает это сама.

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

Так он работает?

По завершении работы мастера установки Active Directory и переза грузки компьютера вы все ли сделано правильно.

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

Понимаю, что не все «подозрительно дол гая поэтому выделю те на которые стоит обратить Во-первых, загрузка контроллера домена выполняется много дольше загрузки сервера, что определяется большим числом служб, запускаемых при старте системы. Во-вторых, самая заг рузка контроллера домена выполняется еще дольше, и степень задер жки определяется исключительно быстродействием жесткого диска. В после перехода процесса загрузки в графический режим вы полняется применение правил к компьютеру и запуск ката лога, о чем дают знать сообщения Networking» и group policy». Компьютер, надолго задумавшийся на этапе запуска се тевых служб, — первый сигнал о том, что не все в порядке с Active В таком случае компьютера до приглашения аутентификации занимает десятки минут и сопровождается сообщени ем о что одна или несколько служб не были В наихуд ших случаях даже после ввода вашего и пароля проходит не сколько десятков минут до появления привычного Windows Я. и сгущаю краски, рассказывая о достаточно редких ситуаци как из-за сбоев компьютера в процессе ус тановки Active Directory, и все же надо знать, что такое и не суетиться, нажимая кнопку Reset. В любом случае надо дождаться заг рузки и аутентификации для выяснения причины сбоя.

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

' * n cf го Вот так вы можете узнать, что не все записи о домене записаны в Так как DNS у вас только один и стоит на том же компьютере, что контроллер домена, то причину надо искать здесь же. Если вы разре шили динамическое обновление то почти наверняка причина в том, что DNS запускается на 1-3 секунды позже службы Виноват в этом только ваш компьютер. Скорее всего быстродействие Active Directory: подход системы в целом не соответствует предъявляемым к серверам. Чтобы исправить положение и внести нужные записи в перезапустите службу Net stop netlogon Net start netlogon Можно и проигнорировать запись об этой ошибке, так как через минут служба вновь попытается обновить информацию в DNS. Следующие попытки обновления будут выполнены через 10, и 60 а регулярно с интервалом в 1 час.

А что если наблюдаются проблемы?

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

Ну, это совсем просто. Вы их увидите, открыв файл Они могут выглядеть, так:

600 IN A 10.1.1. 600 IN SRV 0 600 IN 0 100 600 IN CNAME 600 IN SRV 0 100 600 IN SRV 0 100 600 IN SRV 0 100 600 IN SRV 0 100 600 IN 0 100 600 IN SRV 0 100 600 IN SRV 0 100 fyodor.home. 600 IN SRV 0 100 600 IN SRV 0 100 600 IN SRV 0 100 600 IN SRV 0 100 600 IN SRV 0 100 600 IN SRV 0 600 IN SRV 0 homei, 600 IN SRV 0 100 600 IN A 10,1.1. 600 SRV 0 100 600 IN SRV 0 100 600 IN SRV 0 100 600 IN SRV 0 100 600 IN SRV 0 100 600 IN SRV 0 100 He думаю, что этот листинг нуждается комментариях. Хорошо вид но, что речь идет о добавлении в домен контроллера домена Кстати, если вы сделали зону не обновляемой динамичес ки по забывчивости или то данный файл можно импор тировать в DNS, что позволит создать нужные для работы записи.

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

Server:

Address: 10.1.1, Name:

Addresses: 10.1.1. Если вместо этого появится сообщение о том, что сервер не найден, проверьте параметры сетевого интерфейса.

Одним из средств анализа проблем регистрации в DNS записей, полняемых службой является просмотр файла нужно модифицировать в ветви реестра значение параметра DbFlag и установить его в 2000FFFF.

Еще одна из причин возникновения ошибки — различие между именем домена и суффиксом в имени компьютера. Эта ошибка наи более вероятна при обновлении контроллера домена Windows NT до Windows 2000. В этом случае флажок в диалоговом окне свойств компьютера primary DNS suffix when domain membership оказывается сброшенным, что и приводит к расхождению имени домена и суффикса. Чтобы решить эту запустите верните контроллер домена в состояние а затем Directory: профессионала снова сделайте его контроллером домена, предварительно отметив указанный флажок.

Замечание Если установка Windows 2000 производилась со дистрибутива, т. е. такого, к которому применен пакет обслу живания SP1 и выше, подобного не случается.

Если в журнале регистрации все еще появляются сообщения об ошиб ках в работе службы DNS, обратитесь к статье «Windows 2000 DNS Event Messages 1 Through 1614* Microsoft Выводы Подведем первые итоги.

Если вы доверили установку и службы про грамме то сервер будет сконфигурирован на контролле ре домена, а на нем будут созданы две зоны: с именем, совпадающем с именем созданного домена, и корневая зона — Обе интег рированы с Active Directory, что для вас автоматически решит пробле му тиражирования информации между различными серверами DNS.

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

Два первого сервера Установка сервер DNS самостоятельно, вы можете разместить его как на контроллере домена, так и на отдельном сервере. В первом случае зоны можно будет интегрировать с Active Directory, во ром — нет. Однако второй вариант использовать не толь ко сервер DNS Windows 2000, но и любой другой, удовлетворяющий определенным требованиям, речь о которых пойдет далее. Кроме при расположении сервера DNS на компьютере отличном на котором находится домена, вы избавляетесь от ошибки, связанной с поздним стартом службы DNS уже есть. Ну, и что с ним делать?

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

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

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

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

Поговорим о версиях DN К DNS ряд обязательных (например, поддерж ка записей типа и факультативных (например, поддержка дина мических обновлений) требований, необходимых для поддержки Directory. В настоящее время существует несколько реализаций службы среди которых можно выделить службу DNS Windows 2000, службу DNS Windows NT а также самые разные реализации серверов BIND. Взгляните на сравнение разных реализаций в плане поддержки функций, требуемых для работы Active свойств различных реализаций DNS Свойство Windows 2000 Windows NT Bind 8.2.2 8.2.1 4.9. SRV Да Да (с 4) Да Да Динамические Нет Да Нет Да Нет Нет Нет ческие WINS / WINS-R Да Да Нет Нет Нет передача Да Да Да передача Да Да Нет Нет Нет Нет Нет Нет Да Directory: подход Полагая, что поддержка динамических обновлений, раз решения NetBIOS-имен путем интеграции со службой WINS, поддержка являются функциями, видим, что для работы Active Directory полностью подходят только службы DNS Windows 2000 (что и понятно) и BIND версии 8.2.2 и выше.

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

DNS Windows 2000 или BIND версии лучше Это простейший случай. Вряд ли стоит говорить об использовании сервера DNS Windows 2000, Это для Active Directory сервер, и проблем с ним быть не должно. (Хотя, как мы уже видели, они все таки бывают.) Замечание Использование для построения Active Directory серве ра DNS, расположенного в незащищенном участке сети, например в демилитаризованной зоне, крайне нежелательно.

Использование сервера BIND версии 8.2.2 и выше должно быть оправ данно. Например, сеть построена что сетевая инфраструктура (службы DHCP и DNS) реализована на базе от фирмы Nortel. Архитектура данной реализации такова, что на центральном сервере работает «движок», осуществляющий доступ к центральной СУБД (например, Oracle) и управляемый с отдельной консоли. С «движ ком» агенты, расположенные в различных частях сети и полняющие роль серверов DNS/DHCP. Агентами нельзя управлять иначе, нежели через центральную консоль, что предопределяет жест кую централизацию управления. С другой стороны, единая база гаран тирует надежную выдачу уникальных адресов и их регистрацию, Раз вертывание такой службы весьма дорого, так как приходится пла тить не только за лицензию на СУБД, но и за количество обслужива адресов. Если вы не используете совместимый тип СУБД, то экономически выгоднее служба DNS Windows 2000.

версии хуже 8.2. Если же в настоящее время в сети имеется сервер DNS версии ниже то могу предложить несколько сценариев его использования.

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

• для поддержки Active Directory устанавливается новый сервер DNS;

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

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

Первый вариант тривиально прост. На любом из серверов в сети ус танавливается дополнительный сервер DNS, скажем, тот, что в Windows 2000. На нем создается дочерняя зона, например msk.my corp.ru, для которой динамические обновления. Сам сер вер конфигурируется так, что все неразрешенные запросы перенап равляются на существующий сервер DNS, На всех клиентских компь ютерах в качестве первичного сервера DNS адрес нового сервера. И устанавливаем Active Directory.

10.1.1. Сервер DNS BIND <8.2. DNS: 111 --> 10.1.1 • Клиент Домен Для поддержки Active устанавливается новый независимый сервер Недостаток такого решения — необходимость смены адреса первич ного сервера DNS на всех клиентах в сети. Однако служба DHCP зна чительно упрощает решение этой задачи.

Второй вариант посложнее. Как и в предыдущем случае для поддерж ки Active Directory создается отдельный сервер DNS. На нем конфигу рируется соответствующая например и устанав ливается одноименный домен Active Directory. Затем на сервере DNS, поддерживающем зону создается делегирование зоны msk.mycorp.ru на новый сервер На всех клиентах параметры TCP/IP не изменяются, но они все же получают возможность полно ценной регистрации и поиска в домене.

102 Directory: подход Делегирование зоны msk.mycorp.ru mycorp.ru Существующий управление зоной на новый сервер Совсем иное дело, когда имена зоны существующего сервера DNS и домена Active Directory совпадают. Так как мы рассматриваем случай сервера DNS, не совместимого с Active то его нельзя исполь для построения домена. А надо бы... Что ж, попробуем!

Установите новый сервер совместимый с Active Directory.

Создайте на нем зоны:

dp.mycorp.ru;

rp.ru.

• Разрешите динамическое этих зон.

• На старом сервере DNS делегируйте перечисленные выше зоны на новый сервер. Это позволит контроллерам домена динамически информацию в записях типа Чтобы клиенты смогли динамически регистрироваться в DNS:

• на новом сервере специальную зону, например cli разрешите для нее динамические обновления;

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

на всех клиентах в первичного суффикса укажите cli mycorp.ru и сбросьте Change primary DNS suffix when domain membership changes в свойствах компьютера;

после загрузки клиенты себя в новой зоне.

Установка Active Directory Однако это не все. Дело в том, что контроллеры домена регистриру ют не только записи типа но и типа А для всех своих сетевых интерфейсов и для всех сетевых интерфейсов глобального каталога (ГК). Так как описанный выше трюк не придется соответствующие записи в зону на «старом» сервере DNS вруч ную. Эти записи можно взять из файла Выше л упомянул о том. что служба периодически обновля ет записи в DNS. В нашем случае всякий раз при попытке записей типа А в журнал регистрации будет заноситься ошибка 5773 — «The DNS server for this DC does not support dynamic DNS. Add the DNS records from the file to the DNS server the domain referenced in that file». Чтобы исключить ее появление, запретите службе Netlogon обновление этих записей: в ветви реестра rameters установите параметр RegisterDnsARecords в 0.

Делегирование зон mycorp.ru mycorp.ru mycorp.ru mycorp.ru clients.mycorp.ru 10.1.1. udp.rnycorp.ru Сервер DNS DNS:

Суффикс DNS:

Клиент Клиент Домен mycorp.ru При совпадении имен зоны с именем домена более А если сервер DNS расположен за межсетевым экраном?

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

104 Active подход профессионала Независимо от совместим ли он с Active Directory, использовать данный сервер для хранения зон Active Directory не рекомендуется.

Этим вы серьезно компрометируете безопасность сети. А раз так, то целесообразнее всего установить новый сервер DNS во внутренней сети, создать на нем зоны для домена Active Directory и передать все неразрешенные запросы на внешний сервер DNS через межсетевой экран. Для этого на межсетевом экране надо открыть порты UDP 53 и TCP 53 для пропуска трафика между двумя серверами DNS. На всех клиентах в качестве первичного сервера DNS указывается ад рес нового сервера.

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

53, Клиент Домен Если сервер за межсетевым надо открыть соответствующие порты между серверами DNS Описанное решение годится для когда имя домена Active Directory не совпадает с именем зоны на сервере в DMZ. А теперь представьте себе организацию с зарегистрированным в Интернете именем mycorp.ru. Принято решение использовать его в качестве имени домена Active Directory. Допустим также, что сотруд ники должны иметь доступ к корпоративному corp.ru, расположенному в DMZ, и к своей почте, используя Outlook Web Access как изнутри, так и извне, т. е. из Интернета.

Установка Directory Контроллер домена, Контроллер домена, DNS. 10.1.1.1 Сервер 10.1.2. Клиент 10.1.2. Сайт Сервер Контроллер домена контроллер домена 10.1.2. 10.1.2. Клиент 10.1.2. Сервер BIND, Пример реализации структуры DNS при размещении доменов в отдельных сайтах Active подход профессионала Я уже говорил, что размещать информацию о зонах Active Directory за межсетевым экраном недопустимо, поэтому описанное ранее ре шение невозможно. И все же решение есть.

Итак, сначала во внутренней сети устанавливаем сервер DNS для ра боты Active На нем создается зона mycorp.ru, для которой разрешены динамические обновления. В этой же зоне статически создаются записи типа А для серверов, расположенных в (Воз можно и создание записей типа Неразрешенные запросы переадресуются на сервер в DMZ. На межсетевом экране откры ваются порты для обмена между серверами и для всех пользова телей открываются нужные порты для доступа к серверу Web и На всех клиентах в качестве адреса основного сервера DNS указыва ется адрес внутреннего сервера.

Доступ Интернета осуществляется через межсетевой экран и NAT (Network Address Translation). Сервер DNS в DMZ содержит записи о Web и OWA, но адресация для них указана внешняя, т. е. та, по которой они доступны извне через NAT.

10.1.1. A Сервер DNS A 10.5.1, Интернет КЛИЕНТ Для доступа к серверам в статически их адреса на внутреннем сервере Строим лес доменов Строительство дерева доменов можно вести по-разному в зависимо сти от конкретных условий. Главное влияние на структуру DNS ока зывает разбросанность дерева по сайтам, т. е. по участкам сети, свя занным между собой относительно медленными каналами связи.

Установка Active Допустим, что структура дерева состоит из трех доменов: корневого mycorp.ru, дочернего к нему msk.mycorp.ru и домена test.msk.mycorp.ru, дочернего ко второму. Мы рассмотрим следующие варианты:

• все домены расположены в одном сайте;

• каждый из доменов располагается в отдельном сайте;

+ один из доменов на несколько сайтов.

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

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

Если же эти зоны интегрированы с Active то серверы DNS располагаются на контроллерах доменов и содержат одинаковую информацию. Клиентам безразлично, адрес какого сервера указан как первичный, а какого — как альтернативный. Но вот для самих кон троллеров домена это важно. В их параметрах адрес основного сер вера DNS должен указывать на другой а адрес альтернативно го — на себя. Почему это я расскажу в разделе «Проблема островов*.

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

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

Если домены содержат огромное число контроллеров, потребуется дополнительная настройка (см. раздел «Ну очень большая А теперь — прямо противоположный пример: каждый домен распо лагается в своем сайте.

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

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

Если служба организована посредством серверов BIND либо вы не хотите использовать зоны, интегрированные с Active Directory, то для отказоустойчивости желательно иметь по два сервера DNS в каж дом сайте, На первом будет первичная зона для домена данного сай та. В ней должно быть делегирование остальных зон на соответствующие серверы DNS в других сайтах. Второй содержит вторичную зону для локального домена. На клиентах прописаны ад реса сайта. Если нужно обеспечить разреше ние других имен, например хостов в Интернете, каждый из серверов DNS должен иметь настроенную неразрешенных запросов (forwarding) к внешнему серверу DNS.

В теории ясно, а вот как на практике? Есть одна тонкость, кото рую надо учесть. Каждый контроллер домена в DNS два набора записей: один, касающийся своего домена, второй — леса в целом. Первый заносится зону, соответствующую имени например, в нашем случае для домена msk.mycorp.ru, а второй в зону Последняя существует только в корневом до т, е. в mycorp.ru.

Внимание Записи, заносимые в зону леса>, весьма важ ны для Active например, адреса каталогов или имена партнеров по репликации.

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

Описанный подход решает еще одну проблему. Допустим, в нашем примере домен test.msk.mycorp.ru расположен в сайте, связанном с остальными коммутируемой линией. В этом случае всякий раз, когда понадобится разрешение имени из зоны леса>, будет генерироваться траффик по коммутируемой линии. Разместив эту Active подход профессионала на локальных серверах мы избавимся от трафика, а и от лишнего дозвона по коммутируемой линии.

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

Мораль проста: при расположении доменов в отдельных сайтах в каждом сайте должно быть минимум два сервера DNS. Сервер DNS корневого домена должен содержать;

первичную (или интегрированную с Active Directory) зону для сво его домена, реплицируемую как минимум на еще один сервер DNS в сайте;

первичную (или интегрированную с Active Directory) зону <имя леса>, реплицируемую на все сервера DNS во всех сайтах;

• делегирование для зон дочерних доменов.

Каждый из серверов в дочерних доменах должен иметь:

• первичную (или интегрированную с Active Directory) зону для сво его домена, реплицируемую как минимум на еще один сервер DNS в сайте;

вторичную зону леса>;

• переадресацию на сервер DNS в корневом домене и/или делегирование для зон дочерних доменов.

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

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

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

• один из сайтов подключен по каналу Active Используя информацию, приведенную делаем выводы:

Характеристики сайта DNS Подключение по медленному выделен- Можно обойтись без сервера ному каналу, не более 20 DNS в сайте. Все клиенты в ИЛИ адреса ис по быстрому незагружен- пользуют адреса в других сай каналу, большое число пользова- связанных с Подключение по медленному выделен- Минимум один ному каналу, более 20 имеющий зону для пред почтительно интегрированную Подключение по выделенному каналу с Active либо вторич ную зону. Также имеет вторич ную зону леса> Проблема Речь пойдет не о взаимоотношениях Японии с Россией, а о довольно распространенной ошибке, допускаемой администраторами при кон фигурировании Рассмотрим случай, когда на контроллере домена, так же сервером DNS, в параметрах TCP/IP в качестве адреса сервера содержащего зону леса>, указан собственный адрес. Это например, для контроллера корневого домена, являю щегося сервером DNS с интегрированной с Active Directory. Как я уже говорил, зона леса> содержит записи о партнерах по репликации. (Это записи типа которые связывают контроллера домена с его именем.) Пусть у контроллера домена из менился IP-адрес. Так как первичным сервером DNS для него являет ся он сам, то он внесет соответствующее изменение в запись в собственный сервер Любой другой контроллер домена, настро енный аналогично, не сможет реплицировать эти изменения, так как в «его» сервере DNS записан старый адрес контроллера домена, на котором произошло изменение. Таким контроллер домена окажется в изоляции, или «на поскольку ни одно из измене ний, вносимых на нем в Active не будет тиражироваться на другие контроллеры домена.

Избежать проблемы «островов» несложно: на любом контроллере домена нельзя в качестве первичного сервера указывать собствен ный сервер. Как первичный надо указать адрес сервера на дру гом контроллере а как альтернативный — свой.

Как это сделать? Пусть в домене mycorp.ru сервер DNS установлен на контроллере rootl.mycorp.ru. Соответствующая зона интегрирова на с Active Directory. Вы устанавливаете дополнительный контроллер подход профессионала домена root2, на котором также установлен, но еще не сконфигури сервер Перед запуском в качестве адреса ос новного сервера укажем адрес сервера а в качестве альтер нативного — собственный. По окончании работы DCPROMO. но до перезагрузки компьютера надо на rootl указать как адрес пер вичного сервера DNS адрес сервера а как альтернативный собственный. После все будет работать.

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

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

* для контроллеров домена с «плоским» именем динамическая ре гистрация записей в по умолчанию невозможна.

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

Для того чтобы члены домена с именем могли находить контроллеры в домене, можно либо соответствующим образом на строить NetBIOS (допустим, сконфигурировав службу WINS), либо на клиентах установить в реестре значе ние в ветви 1.

2. Для того чтобы клиентские компьютеры на базе Windows XP Pro fessional или Windows 2000 SP4 могли динамически регистриро вать записи в DNS, следует установить в реестре парамет ра в Parameters равным 1.

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

Допустим, в организации существует дерево доменов mycorp.ru. Все в этом дереве работает нормально. И тут принимается решение о созда нии нового дерева в леет доменов, в которое нужно включить пока толь ко один домен — Подключение этого домена в виде отдель ного дерева обусловлено административными Из сообра Установка безопасности выдвигается требование: никто из этого домена не должен иметь административных прав в основном дереве, а лучше даже ограничить доступ на уровне сети. С другой стороны, админист раторы основного дерева иметь доступ к новому домену.

Исходя из этого системный администратор:

устанавливает новый сервер Windows 2000;

• на нем сервер DNS, конфигурирует первичную зону int.filial.ru. указывает необходимость пересылки неразрешенных на внешний сервер DNS filial.ru, обслуживающий запро сы на доступ в Интернет;

указывает в качестве адреса основного сервера DNS собственный адрес, а в качестве альтернативного — адрес сервера DNS в корне вом домене основного дерена;

запускает и конфигурирует контроллер домена int.filial.ru;

• на всех клиентских компьютерах указывает в качестве адреса сер вера DNS адрес нового контроллера домена.

После перезагрузки все работает нормально. Пользователи домена int.filial.ru входят в домен без проблем. Окрыленный успехом адми нистратор решает установить второй контроллер в домене Он повторяет практически те же шаги за исключением того, что сер вер DNS автоматически конфигурирует программой DCPROMO, a после перезагрузки указывает адрес первого контроллера в домене как адрес первичного сервера а как альтернативный — свой.

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

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

Что делать? Правильно. Создать вторичную зону orp.ru на обоих контроллерах домена и синхронизировать ее с основной.

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

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

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

Внимание Возможность типа записей, регист рируемых службой в DNS, появилась Windows 2000 SP2.

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

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

Перечень параметра Значение Тип в DNS DC SRV DcAtSite SRV SRV Pdc SRV Gc SRV SRV _lt ia p._tcp.< Имя frra>._si SRV SRV GcIpAddress A CNAME Kdc SRV SRV SRV SRV см. след. стр.

Установка Тип Запись в DNS LdapIpAddress A SRV SRV SRV kerberos, SRV kpasswd.

SRV kpasswd.

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

Если да, список обслуживаемых сайтов формируется динамически на основании следующих метрик (в порядке приоритета):

стоимость подключения — имеется в виду стоимость подклю с точки зрения топологии сети (см. главу «Репликация Active Directory») количество контроллеров в сайте — чем больше контролле тем лучше;

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

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

Дабы исключить такую возможность, на всех контроллерах домена надо отключить функцию задав нулевое значение параметру AutoSiteCoverage в ветви реестра ra Замечание По умолчанию в реестре данного параметра нет.

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

Ну очень крупная компания Наверняка вам интересно знать, есть ли ограничения DNS Windows 2000? Конечно, но в нашей стране они относятся к разряду скорее гипотетических. Чтобы с ними столкнуться, надо полнить одновременно минимум три условия:

организация (или большая ее часть) сосредоточена в одном домене;

• контроллеров домена 850;

• вся информация хранится в зоне интегрированной с Active Directory.

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

Так нужна ли служба WINS?

вопрос я слышу довольно часто. Бывает, администраторы, читав в Windows 2000 Resource Kit фразу о том, что Windows может обходиться без WINS, не устанавливают его в своей сети. Хо рошо это или плохо? Давайте разберемся. Но начнем с NetBIOS.

Краткий экскурс в историю NetBIOS NetBIOS — это интерфейс уровня, используемый сетевы ми приложениями для взаимодействия через совместимый транспорт.

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

Если вы выполните на компьютере с ОС Windows команду nbtstat -n, то получите результат, аналогичный этому:

Local Area Connection:

Node IpAddress: [10.1.1.3] Scope Id: [] Установка Active NetBIOS Local Name Table Status DC01 UNIQUE Registered <20> UNIQUE Registered GROUP Registered MYCORP <1C> GROUP Registered HYCORP <1B> UNIQUE INet~Services <1C> GROUP MYCORP <1E> GROUP Registered <00> UNIQUE Registered MYCORP <1D> GROUP Registered DC01 <03> UNIQUE Registered FYODORZ UNIQUE Registered В этой таблице имя DC01 соответствует имени контроллера домена.

Для него определены NetBIOS имена:

00 (Имя службой workstation);

• 03 (служба 20 (служба Server).

Имя имени домена и для него определены имена:

00 (экземпляр доменного имени, зарегистрированный службой Workstation для использования в сети LAN Manager);

1В (экземпляр зарегистрированный службой Server и ис пользуемый при просмотре содержимого домена);

1C (групповое имя. может содержать до 25 адресов;

первый адрес соответствует первичному контроллеру домена, остальные — ВТОрИЧНЫМ);

• [уникальное имя указывающее на адрес главного браузера (master Имя.. используется для широковещательных и приема доменных оповещений в локальной подсети. Благодаря это му имени, главные браузеры в доменах узнают о существовании друг друга и других доменов.

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

Я не случайно так подробно перечислил эти имена. В дальнейшем будет легче понять роль сервера WINS или результаты отсутствия поддержки NetBIOS.

Active профессионала Как разрешаются имена NetBIOS Думаю, ни для кого не секрет, что в сетях Microsoft могут применять ся три механизма разрешения имен NetBIOS:

поиск в файле • широковещательные рассылки;

• сервер WINS.

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

ftlNCLUDE Очевидно, что определяет адрес сервера SERVER, а вторая по зволяет загрузить централизованный файл LMHOSTS, хранящийся на этом сервере. Знаете ли вы, что надо предпринять, чтобы это работа ло? Одно из условий — предоставить группе Everyone доступ Change к ресурсу Просто лафа злоумышленникам!

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

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

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

При этом есть 4 способа разрешения имен клиентскими компьюте рами: b-node, m-node и предполагает только широковещательные второй — только серверы WINS.

Третий и четвертый являются комбинацией первого и второго спо но если в режиме m-node сначала рассылаются широковеща тельные сообщения, а потом идет обращение к серверу WINS, то в режиме h-node все выполняется с точностью до наоборот. С точки зрения нагрузки на сеть, более предпочтителен режим h-node.

Установка Active Directory Замечание Все эти режимы в случае неудачи обращаются сначала к файлу (если это разрешено на клиенте), а потом к сер веру DNS.

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

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

А нужен ли NetBIOS?

В самом может, ну его? Удалим, и дело с И широковеща тельных рассылок не будет, и сервер WINS ставить не надо, а?

Из документации известно, что для работы Windows 2000 интерфейс NetBIOS больше не нужен, если используется только среда Windows 2000. То есть в сети нет больше других клиентов Windows или NT).

Проверим это, Советую провести простой опыт. Запретите на двух компьютерах с Windows 2000 (или Windows XP) NetBIOS, а потом на одном из них зайдите в Сетевое окружение и просмотрите содержи мое домена (или рабочей группы), в котором расположены данные компьютеры. Много увидели? Ага: НИЧЕГО. А все потому, что нет боль ше главного браузера и нет механизма, который бы позволил про смотреть содержимое домена. Помните, мы выписывали имена для них? Попробуйте выполнить команду nbtstat -n на любом из этих компьютеров. Никаких записей вы больше не увидите, Так все пропало и больше ничего не работает? Отнюдь нет. По шлите сообщение с одного компьютера на другой командой net send.

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

подход it la Отключение поддержки Итак, отказываемся от Постойте, а вы проверили приложе ния? Как они обойдутся без этого интерфейса? в начале этого раздела я сказал, что NetBIOS приложениями для Так вот, составьте список ваших программ и проте стируйте их на работоспособность. Microsoft SMS 2.0 можно не тес тировать: он работать не будет.

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

Краткие советы по установке серверов WINS Нет смысла подробно описывать конфигурирование серверов WINS — все это уже сделано в разных книгах, в первую очередь в [4]. Поэтому ограничусь только самыми главными советами.

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

Однако из соображений надежности и постоянной доступности этой службы нужно иметь не менее 2 серверов WINS. Оба должны быть push-pull по репликации.

Установка Active Directory При настройке параметров TCP/IP на серверах в качестве адреса сервера WINS указывать свой адрес. Это дол жны быть адреса партнеров по репликации.

Если ваша сеть разбита на несколько сайтов, то целесообразность размещения серверов WINS внутри сайта определяется количеством компьютеров в сайте, а также установленной на них ОС. Если на всех компьютерах Windows 2000 или Windows XP нет приложений, для работы которых требуется NetBIOS, его можно вообще не использо вать. В противном случае обращаем внимание как на количество ком так и на необходимость для пользователей обращаться по к ресурсам на других Если компьютеров мало (10 20) и нет нужды просматривать ресурсы вне сайга, можно обойтись без сервера WINS и применять широковещательные рассылки для разрешения имен. Если же просмотр внешних для сайта ресурсов все таки нужен, то компьютеры как клиенты WINS в другом а маршрутизатор должен пересылать запросы к WINS.

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

Обычно серверы WINS можно размещать на контроллерах домена.

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

И последнее. Вы, наверное, знаете, что сервер WINS можно задейство вать совместно с сервером DNS для разрешения имен NetBIOS. Для этого на сервере DNS используются записи типа WINS. В сетях на базе Windows NT 4.0 это было удобно, так как служба DNS в Windows NT не поддерживает динамических обновлений. Актуально ли это для Windows 2000/XP? Теоретически эту функцию можно использовать.

Особый смысл она имеет, когда клиенты (не Windows 2000/XP) не используют службу DHCP для получения адресов IP. В противном же случае лучше применять службу DHCP для регистрации клиентов в DNS. Вот мы и подошли к рассмотрению особенностей использова ния этой службы в Windows 2000.

Active Directory: подход Как правильно настроить DHCP Служба DHCP в Windows уже довольно и, казалось бы, не должна проблем или вопросов. Однако многие, даже довольно опытные администраторы порой не знают некоторых свойств DHCP, что приводит к возникновению проблем в сети, по крайней мере к недоумениям. Конечно, разобравшись в источнике проблем, так и хочется ударить себя по лбу и сказать что-то типа «Семен Семен но лучше побеспокоиться и предотвратить появление нежелательных Среди тем, незнание или неполное понимание которых обычно при водит к нештатным ситуациям, отмечу такие:

авторизация сервера DHCP;

суперобласти и плоская сеть;

сервера DHCP в сегментированной сети;

• параметры, определяемые для сервера, областей и исключений и порядок их назначения;

• работа с пользовательскими идентификаторами;

динамическая имен в разрешение конфликтных ситуаций.

Что дает авторизация кто работал с Windows NT, знает, что наличие двух серверов DHCP в сети может при определенных условиях привести к ее частичной и даже полной неработоспособности. Рассмотрим пример. В сегменте сети установлен сервер на котором определена область с диа пазоном адресов 137.45-45.1 — исследовательс ких целях устанавливает собственный сервер DHCP и активизирует на нем область с диапазоном 10.1.1.1 — 10.1.1.50. Ясно, что спустя некоторое время многие машины потеряют доступ к ресурсам сети.

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

Появившаяся в Windows 2000 авторизация серверов в Active Directory вселила надежду, что с этим покончено. И правда, как написано в упомянутой выше книге, для того, чтобы служба DHCP стартовала и обслуживала она должна быть авторизована в Active Directory. А такую операцию можно проделать, только имея чия Enterprise Admins. Но, увы, радость была преждевременна.

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

Установка Directory если в той же установить контроллер домена Windows 2000, не принадлежащего существующему и на этом контролле ре домена установить службу DHCP, ее можно будет а продолжить свою вредоносную деятельность.

И лишь только для серверов, которые входят в основной домен.

такая подрывная деятельность будет При попытке запус тить службу DHCP происходит обращение к Active Directory, где про сматривается список адресов IP для всех авторизованных в домене серверов DHCP. Если адреса рассматриваемого сервера нет. то служ ба DHCP будет автоматически на нем терминирована.

Замечание До выхода Windows 2000 SP2 в Active Directory могло хранится не более 852 адресов авторизованных серверов DHCP.

Зачем нужны суперобласти в сегменте сети используются т. е. несколь ко логических подсетей. Пусть это 10.1.1.0/22, 10.1.2.0/22 и 10.1.3.0/22.

Чтобы один сервер DHCP мог эти мультисети, на нем нуж но создать три соответствующие области и объединить их в супероб ласть.

А если этот сегмент сети обслуживается не одним, а тремя DHCP, каждый из которых отвечает только за одну область? Допустим, у клиентского компьютера был адрес выданный первым сер DHCP. После перезагрузки клиент посылает запрос без указания идентификатора сервера. Если этот запрос пер вым получит сервер, на котором не определена нужная область, он ответит клиенту сигналом что его в режим поиска нужного сервера DHCP. Клиент разошлет широковещательное сообщение Пусть первым откликнется сервер, на котором определена область 10.1.2.0/22. Тогда клиент пошлет ему запрос на тот ответит и предоставит адрес из своего диапазона. Таким клиент окажется в другой мультисети. Но это не самое страшное — хуже, что выданные данно му клиенту заняты как на первом DHCP, так и на вто ром. При перезагрузке клиента он может получить адрес с третьего сервера. Если подобное поведение распространить на все оставшиеся станет понятно, что очень скоро доступные ад реса в областях будут исчерпаны, так как каждый клиент зарезерви рует по 3 адреса. Такое возможно, когда серверы DHCP ничего не знают друг о друге.

124 Active подход Суперобласть Область 1-10.1.1. Область 10.1.2 1-10.1.2. Область 1-10.1.3. Клиент ер Сер Маршрутизатор 10.1.3. DH Клиент Клиент 10.1.1.15 10.1.2. для поддержки Дабы исключить такую ситуацию:

на каждом сервере DHCP области для каждой из подсетей;

эти области включим в суперобласть;

• на каждом из серверов определим по две области исключений.

Например, на первом в нашем примере для областей и 10.1.3.0 формируются исключения на весь диапазон их адресов. На втором — исключения формируются для областей 10.1.1.0 и 10.1.3.0, а на третьем для областей 10.1.1.0 и 10.1.2.0. Тогда второй сервер не откликнется на сообщением так как уви дит, что за запрашиваемую область отвечает другой сервер.

Исключение Суперобласть Суперобласть Область Исключение Область 10.1.2.1-10.1.2. Исключение DHCP 10.1.3.1-10.1.3. Исключение 10.1.3.1-10 1.3. Исключение 10.1,3.1-10.1.3. Конфигурирование для недопущения выдачи адресов Установка DHCP сервер в сегментированной сети Если сеть не является плоской, а сегментирована, то использование DHCP практически ничем не отличается от того, как это было в Windows NT. В связи с этим два основных правила развер тывания серверов DHCP.

• между сегментами должен выполнять роль агента передачи ВООТР (ВООТР relay или DHCP, когда один сер вер DHCP обслуживает несколько сегментов. В качестве агента DHCP может выступать сервер Windows 2000, на кото ром служба and Remote Access Server). При этом данный компьютер может заодно выполнять роль маршрутизатора.

Если в двух сегментах сети свой сервер DHCP, а маршрутизатор выполняет роль агента передачи ВООТР, то серверы DHCP можно сконфигурировать так, чтобы выступать в качестве друг для друга. этом руководствуются известным правилом 80/20: на каждом из серверов создаются области для каждой из но так, что область, в которую входит сам сервер содержит 80% доступных адресов, а зона для другого сегмента — только 20%, Тогда при отказе «своего» сервера DHCP клиенты смогут запросить адреса у сервера в соседнем сегменте.

Рассмотрим типичный пример. Несколько филиалов компании (в каж дом от 50 до 200 чел.) связаны с центральным офисом 000 чел.) вы линиями с относительно небольшой пропускной способ ностью. У каждого сотрудника свой компьютер. Сеть в центральном офисе разбита на 4 сегмента: 145.12.1.0/24, 145.12.3.0/ и 145.12.4.0/24. Для филиалов выделены подсети В централь ном офисе планируется установить два сервера DHCP, а в каждом фи лиале — по одному. Нетрудно что для обеспечения отка зоустойчивости филиальные серверы должны содержать по адре сов своей подсети, а остальные 20% — отдать серверам DHCP в центре.

Те в свою очередь должны поделить эти адреса между собой пополам.

Кроме они должны разделить пополам адреса для тех сегментов, к которым они не принадлежат, а адреса для «своих» сегментов — раз делить в соотношении 80/20.

Динамическая регистрация имен в DNS Теперь обсудим динамическую регистрацию имен клиентов в DNS че рез DHCP. что клиенты Windows 2000/XP могут ди намически свое имя в DNS Windows 2000. Если отме чен соответствующий флажок в параметрах то всякий раз при загрузке клиента в будет обновляться запись типа А. Однако спра ведливости ради стоит отметить, что запись типа PTR при не об новляется.

126 Active Directory: подход Область Область 145.12.2.1 - 145.12.1. Область 145.12.3.201 - 145.12.3. Область 145.12.4. Область 10.1.2. - 145.12.1. Область - 145.12.3. Область 145.12.4. 1.225 Область - 10.1.1. Филиал 10.1.1. распределения по серверам DHCP в многосегментной сети С другой стороны, в корпоративной сети применяются и иные кли енты, например Windows 9x или NT, которые не умеют обновлять свои в DNS, а значит, компьютер становится недоступен по имени.

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

Итак, если флажок Automatically update DHCP client information in DNS снят, то DHCP не обновляет записи DNS. В с клиентами Установка Active Directory Windows это что они обновляют только записи типа А, да и то если это установлено в их параметрах. Для всех остальных клиентов это означает, что информация о них не заносится в DNS.

Замечание Если клиенты DHCP являются одновременно клиента ми WINS, а сервер DNS сконфигурирован для имен через WINS, будет обновление записей типа А.

Если этот флажок установлен, то дальнейшее поведение зависит от положения переключателя. Если это Update DNS only if DHCP client requests, то обновления будут выполняться только для клиентов Win dows да и то, только если необходимость обновлений на них задана. В отличие от самостоятельного режима обновлений в режи ме обновлений через DHCP в DNS заносятся как типа А, так и PTR. Для всех остальных клиентов все остается без изменений.

Если переключатель в положении Always update DNS. то сервер DHCP будет обновлять записи как типа так и PTR абсолютно для всех сво их клиентов Windows 2000/ХР независимо от того, хотят они этого или нет.

| up DHCP to • tea do режимами записей в DNS сервера DHCP Флажок Discard forward lookups when lease expires задает удаление из DNS записей типа А о клиентах, для которых ис тек срок аренды адреса. Если флажок не установлен, удаляются толь ко записи типа PTR.

Active Флажок Enable updates for DNS that do not support dynamic update предписывает динамически обновлять информацию в DNS о любых клиентах DHCP, включая такие, как сетевые принтеры.

Внимание принтер является клиентом DHCP и прин теру не было присвоено имя, то в DNS для него будет зарегистриро ван его IP-адрес вместо имени. Причем октеты адреса будут интер претированы как субдомены. Так, для принтера с адресом 10.1.12. в домене mycorp.ru в DNS будет занесена запись типа А для хоста 1 О* в Чтобы этого не случилось, надо присвоить принтеру имя согласно инструкции.

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

Параметр 003 Router Указывается адрес по а также адреса остальных маршрутизаторов, о которых надо знать клиенту 006 DNS Servers адреса DNS, димых для работы клиента 015 Domain Name Суффикс указать только суф фикс домена, но нельзя указать возможных суффиксов для Это ограничение DHCP 044 Servers Адреса серверов WINS Node Type Способ разрешения NetBIOS-имен. Подробнее см, раздел, Дополнительно можно запретить использование NetBIOS для клиен тов Windows в диалоговом окне свойств области откройте вкладку в списке Vendor щелкни те Microsoft, выберите параметр и установите его в 1, Последовательность применения параметров Вы наверняка уже обратили внимание, что параметры можно опре делить для сервера DHCP в целом, для областей и для каждого исклю чения в отдельности. Кроме того, есть параметры, определяемые для клиентов различных производителей (отличаются идентификатором Vendor ID) и для клиентов с пользовательскими идентифи Active (User class ID). должно быть правило приме всех этих параметров к клиентам. Вот оно:

первыми параметры, для сервера DHCP в целом;

затем применяются параметры для клиентов с Vendor ID и User ID, определенные для всего сервера;

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

применяются параметры для клиентов с раз личными Vendor ID и User Class ID, определенные для области;

• наконец, если конкретный адрес подпадает под исключения, то к нему применяются определенные для исключе а также соответствующие параметры для клиентов с различ ными Vendor ID и User Class ID.

Как использовать идентификатор пользовательского класса Как видим, возможностей немало. Но есть еще одно кото рое позволит сделать назначение параметров более целенаправлен ным. Рассмотрим сеть, в которой один из сайтов связан с централь ным сайтом медленным каналом так. что в нем используется та же самая подсеть, что и в центральном сайте. В этом филиале работает 5-7 и у них нет своего сервера DHCP и Для аренды адресов IP они используют сервер DHCP в центральном сайте. Доступ к ресурсам центрального сайта им нужен крайне редко. Все клиенты работают под Windows 98. Ясно, конечно, что обращения к серверу WINS в центральном офисе, мягко говоря, неуместны — проще исполь зовать рассылки.

Можно каждый из компьютеров сконфигурировать вручную и настро ить TCP/IP. Но лучше, однако, сделать иначе. На сервере DHCP в цен тральном офисе надо свой User Class ID и сконфигуриро вать для него параметр равный 4 Затем на всех клиен тах в удаленном сайте выполнить команду сетевого <идентификатор классах Теперь, получив запрос на аренду адреса от клиента из удаленного сайта, DHCP что данному клиенту присвоен опре деленный User Class ID. Сравнив его со списком определенных для и обнаружив идентичность, сервер пере даст на клиент 046 равный 4, а не 8. как это имеет место всех остальных клиентов.

Active подход Как проконтролировать работу DHCP Контролировать сервера DHCP особо не требуется. Если он не работает или работает не так, как это должно быть, вы сразу поймете.

Однако вот общие способы контроля.

1. Загрузите клиентский компьютер и с помощью команды проверьте правильность параметров, полученных от сервера DHCP. Здесь же вы какой именно сервер выдал адрес в аренду. Если параметры не соответствуют ожидаемым, выясните причину, устраните ее и выполните подряд команды ipconfig /re lease и ipconfig /renew.

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

3. Если вы запустили административную консоль DHCP, а в ней нет команды Authorise, значит, вы учетную запись, не об ладающую правами Enterprise Admins.

Замечание Часто нужно авторизовать сервер DHCP, расположенный в удаленном филиале. Если этот филиал расположен в отдельном до мене, управляемом администраторами, то по умолчанию они не смогут авторизовать сервер. Чтобы предоставить им соответ ствующее право, надо изменить права доступа к объекту CN=Dhcp леса> и к кон тейнеру леса>.

4. Если сервер, роль сервера DHCP, был некорректно удален из сети, используйте команду a dhcp a delete для уда ления его имени из Active Directory, 5. Регулярно просматривайте журнал регистрации системных событий.

DCPROMO т все, что с этим связано Как вы хорошо знаете, для перевода сервера в статус контроллера до мена служит программа DCPROMO, расположенная в каталоге 2. Вот что она делает.

• Изменяет функциональность сервера так, что он исполь зовать хранимые в реестре учетные записи SAM и переключается на каталог, основанный на ESE Storage Engine).

Установка Active Directory Замечание Если вы контроллер домена NT 4.0.

то запустится автоматически и перенесет учетные записи из SAM в Active Directory.

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

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

• На локальном диске создается иерархия каталогов а так же общедоступные ресурсы SYSVOL и NETLOGON. При обновле нии контроллера домена Windows NT 4.0 вее содержимое ресурса NETLOGON переносится в одноименный ресурс в иерархии SYSVOL • Изменяются стартовые параметры некоторых служб. Они перехо дят из разряда Manual Automatic.

• Служба Windows 2000 Win32 Time выполняет времени с внешним источником эталонного времени.

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

Требования, предъявляемые DCPROMO Что нужно знать перед запуском DCPROMO? Главное — хорошо по нимать, что именно вы собираетесь сделать. Более того, если с одним и тем же компьютером вы экспериментируете не первый раз (без переустановки ОС), то надо что вы сделали в прошлый раз не так и к чему это могло привести. Возможно, после некоторых ваших действий все попытки установить контроллер домена будут неудач ны. Но не будем о грустном — рассмотрим все по порядку.

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

Во-вторых, убедитесь, что параметры TCP/IP заданы верно. Проверь те, что нужные серверы доступны (см. раздел «Что делать с Воз можно, придется проверить сеть на физическом уровне. Ведь если вы устанавливаете контроллер в удаленном филиале, должна су ществовать связь с компьютером, роль мастера имен доменов (domain naming master), расположенным скорее всего в цен тральном офисе.

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

В-четвертых, вам нужны соответствующие административные права.

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

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

with pre-Windows ИЛИ:

Permissions compatible only with Windows 2000 servers Когда Active Directory будет установлена, в списки контроля доступа ко всем объектам каталога будет добавлена встроенная группа Pre Windows 2000 Compatible Access. Если при установке контроллера вы указали первую возможность н рассматриваемом диалоговом окне (а она предлагается по умолчанию), то в группу Pre-Windows 2000 Com Access будет включена группа Everyone. Это что не толь ко в домене пользователи получат доступ к объектам Directory, но и анонимные пользователи. Но не спе шите переключать домен в режим Permissions compatible only with Windows 2000 servers. в домене есть серверы Windows NT 4.0, на которых исполняются нужные вам приложения, требующие ано нимного доступа к каталогу. Тогда придется оставить значение, по умолчанию. В вы всегда можете добавить в группу Pre Windows 2000 Compatible Access или исключить из нее группу Everyone.

Установка Active Directory Замечание Группу Even-one нельзя добавить (или исключить) в группу 2000 Compatible Access через оснастку Active Directory Users and Используйте net localgroup 2000 Access* everyone /add для добавления и net localgroup «Pre-Windows 2000 Compatible Access* everyone /remove для удаления.

Наконец, вы должны представлять, какими ограничениями обладает Active Directory. Например, полное имя домена не может превышать 64 символов UTF-8. Скажем, вы хотите создать домен с именем (не улыбайтесь — чудаков на свете полно):

Для удобства снизу отмерено 64 символа. Понятно, что такое имя создать не удастся, Но само по себе имя может и не быть очень длинным, но его длины хватит, чтобы для какого-либо ресурса превысить значение МАХ_РАТН, установленное 260 символам. Например, для доступа к нилищу групповой политики используется путь:

flOMena>\Poli.cies\\

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

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

это файл базы Именно здесь хранится вся информация Active Directory. Если вы создаете новое то его размер — 10 Мб. Обратите внимание и на фай лы resl.log и res2.log. Пусть вас не вводит в заблуждение их расшире ние. К файлам журналов регистрации они не имеют никакого отно шения. Они «оккупируют» место на жестком диске на тот если файл Active увеличится, а на диске не окажется свободного места. Тогда один из будет удален, a NTDS.DIT вырастет Active Directory: профессионала на его величину. Кстати, в журнал регистрации событий будет зане сено предупреждение. Размер этих двух так же равен 10 Мб, что дает запас 20 Мб для роста базы Active Directory.

Pages:     | 1 || 3 | 4 |   ...   | 7 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.