Главная > Active Directory > Microsoft University Online 2011 – Active Directory (Развертывание Active Directory Domain Services)

Microsoft University Online 2011 – Active Directory (Развертывание Active Directory Domain Services)

Доброго времени суток коллеги. Это моя первая статья из цикла “Microsoft University Online 2011 – Active Directory”. Каждая статья из этого цикла будет рассказывать о той же теме, что была рассказана на самом мероприятии. В этой статье будут раскрыты следующие темы

1. Что такое Active Directory Domain Services

2. Требование к Active Directory Domain Services

3. Необходимость в DNS

4. Планирование Active Directory Domain Services

Что такое Active Directory Domain Services?

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

Active Directory Domain Services — в первую очередь это одна из ролей Microsoft Windows Server 2008/2008R2, в Microsoft Windows Server 2000 и Microsoft Windows Server 2003 эта роль называлась Active Directory. Active Directory Domain Services — это централизованная система аутентификации, которая хранит информацию о всех объектах вашей инфраструктуры. Данная служба является сердцем вашей инфраструктуры, так как на неё положены важные задачи, такие как аутентификация пользователей и централизованная система управления рабочими станциями. Для хранения данных используется LDAP база, что позволяет использовать более гибко её настроить. Для аутентификации используется протокол Kerberos, который тоже является стандартизированным. Использование стандартизированных протоколов облегчает разработку программного обеспечения для компании. Если рассмотреть Active Directory Domain Services с точки зрения Microsoft Infrastructure Optimization, то Active Directory Domain Services присутствуете на всех уровнях зрелости, начиная со стандартного уровня. Если рассматривать Active Directory Domain Services с точки зрения безопасности, то Active Directory Domain Services очень важный элемент безопасности, так как на нем лежит задача аутентификации и распространения настроек для ПК, а соответственно настроек и самой безопасности. Конечно, Active Directory Domain Services это не единственная служба, которая обеспечивает безопасность вашей инфраструктуры. Если мы посмотрим требования программного обеспечения компании Microsoft, которое помогает в управлении и настройке инфраструктуры, а также службы, которые помогают оптимизировать работу бизнеса, то увидим что для их полноценной роботы необходима служба Active Directory Domain Services. Так как Active Directory Domain Services являться единой точкой аутентификации то помогает упростить работу пользователей, так как им необходимо единожды аутентифицироваться, хотя в этом есть и ряд своих недостатков. Также в Active Directory Domain Services входят Group Policy. Group Policy это мощный инструмент который помогает администратору стандартизировать настройки компьютеров, а также стандартизировать настройки пользователя. В случае отсутствия такой системы, стоимость содержания инфраструктуры высока, и требует больших финансовых и физических затрат. Присутствие Active Directory Domain Services помогает сократить усилия на обслуживание вашей инфраструктуры, что в свою очередь повлечёт за собой уменьшение финансовых затрат, и повысит работоспособность инфраструктуры. По этому, как говорит Игорь Шаститко — “Must have!”.

Требование к Active Directory Domain Services.

Так как мы хотим шагать в ногу со временем системные требования к Active Directory Domain Services, я буду приводить с учетом того что мы будем использовать Microsoft Windows Server 2008R2.

Пользователей в домене

Минимальное количество процессоров и домен контролеров

1–499

Один – Один процессор (ядро)

500–999

Один – Два процессора (ядра)

1,000–2,999

Два – Два процессора (ядра)

3,000–10,000

Два – Четыре процессора (ядра)

Пользователей в домене

Минимальное количество памяти на домен контролерах

1–499

512 MB

500–999

1 GB

> 1,000

2 GB

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

Необходимость в DNS

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

Планирование Active Directory Domain Services

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

Шаг 1: Определиться с количеством лесов

Шаг 2: Определиться с количеством доменов

Шаг 3: Назначить имена доменов

Шаг 4: Выбрать корневой домен

Шаг A1: Дизайн структуры OU

Шаг B1: Определиться с размещением домен контролеров

Шаг B2: Определиться с количеством домен контролеров

Шаг B3: Определиться с размещением глобального каталога

Шаг B4: Определяться с размещением FSMO

Шаг C1: Создание дизайна сайта

Шаг C2: Создание дизайна линков между сайтами

Шаг C3: Создание дизайна мостов

Шаг D1: Определиться с конфигурацией домен контролеров

Определиться с количеством лесов

На самом-то деле, на этом шаге нам необходимо определится, будем ли мы использовать много лессовую структуру. Есть несколько основных причин использования много лессовой инфраструктуры. Во первых это разница в схемах, как пример слияние двух компаний которые используют свои приложения которым необходима определенная схема, или в разных отделах используют разное программное обеспечение работоспособность которого напрямую зависит от схемы. И как следствие может возникнуть конфликт схем. Одной из причин может быть требование безопасно использования двух лесов, или опять же при слиянии 2 компаний ни одна из компаний не желает передавать управление своей инфраструктурой Active Directory Domain Services ИТ отделу другой компании. Так же существуют примеры использование отдельного леса для разворачивания в нём ресурсов. Для данной ситуации необходимо определится, будет ли компания дальше развивать. Так как при развитии компании база Active Directory Domain Services будет неуклонно расти, а при больших размерах базы её репликация может оказаться большой проблемной. Если компания планирует дальше развиваться и открывать свои представительства в других городах, то стоит задуматься о создании нескольких лесах. Но хочу обратить ваше внимание на то, что с самого начало необходимо всё согласовать, начиная от программного обеспечения, которое будет использовать Active Directory Domain Services для своих нужд, до отдела безопасности, и только после этого принимать решение о количестве лесов в вашей компании. Также не стоит забывать что много лёссовая инфраструктура требует больше финансовых затрат, как на оборудование, так в прочем и на персонал который будет этим заниматься.

Определиться с количеством доменов

Для любой начинающей компании достаточно будет одного домена, обслуживание такого инфраструктуры Active Directory Domain Services менее затратное, так как не требует покупки дополнительного программного обеспечения и оборудования, но такой вариант не всегда может отвечать требованиям, которые выдвигает бизнес, служба безопасности и т.д. Также используя один домен ресурсы на его управления намного меньше. Но как я уже говорил раньше не всегда подходит однодоменная структура. Обычно необходимость в создании дополнительных доменов связана с проблемами в репликации. Основные проблемы это или большой размер реплицируемых данных и часто меняющиеся атрибуты. Когда мы говорим о репликации данных, необходимо учитывать каналы для обеспечения репликация. Также необходимость в создании нового домена может быть связана с необходимостью использовать разные уровни домов. Иногда потребность много доменной структуре вызвана необходимостью создания автономных подразделений и предоставления для них отдельного подразделения (OU) в домене не достаточно. Некоторые компании создают N+1 доменов. Это связано с тем, что один домен является корневым и используется исключительно для управления инфраструктурой и предоставления некоторых ресурсов. Такое решение бесспорно является более затратным, но помогает достичь более высокого уровня безопасности.

Дизайн структуры OU

Есть несколько подходов к дизайну OU

1) Исходя из требований к делегации прав.

2) исходя из применения групповых политик.

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

· Определить или создать административные группы, которым будут делегированы права.

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

· Назначить права административным группам в рамках каждого OU.

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

Дополнительную информацию о планирование вы всегда можете найти на сайте компании Microsoft, по адресу http://microsoft.com/ipd

http://www.techdays.in.ua/LectureViewer.aspx?LectureId=2c868829-c6e9-46ca-8967-ef09f20ff133

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: