Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
IIS / AvIS / 1 AD / ЛР - Active Directory - 1.doc
Скачиваний:
97
Добавлен:
31.03.2015
Размер:
1.2 Mб
Скачать

Планирование доменного пространства имен

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

  • Имеете ли вы опыт выбора и регистрации доменных имен DNS для использования в Интернете?

  • Будет ли внутреннее пространство имен Active Directory совпадать с внешним пространством имен Интернета?

  • Какие требования и концепции именования следует применить при выборе доменных имен DNS?

Выбор доменного имени DNS

При настройке DNS-серверов рекомендуется сначала выбрать и заре­гистрировать уникальное родительское имя DNS, оно будет представ­лять вашу организацию в Интернете. Например, Microsoft использует имя microsoft.com. Это имя является доменом второго уровня внутри одного из доменов верхнего уровня, используемых в Интернете. Прежде чем задавать родительское имя DNS для вашей организации убедитесь, что это имя не присвоено другой организации. В настоящее время большей частью пространства имен DNS Интернета управляет фирма Network Solutions, Inc., хотя есть и другие фирмы. Родительское имя DNS можно соединить с именем местоположения или подразделения внутри вашей организации для формирования других имен поддоменов. Например, добавим к домену второго Microsoft поддомен Chicago, создав пространство имен chicago.microsoft.com.

Внутреннее и внешнее пространства имен

Для внедрения Active Directory существуют два вида пространств имен. Пространство имен Active Directory совпадает с заданным зарегистрированным пространством имен DNS или отличается от него.

Совпадающие внутреннее и внешнее пространства имен

Согласно этому сценарию, организация использует одно и то же имя для внутреннего и внешнего пространств имен (рис. 4-3). Имя microsoft.com применяется как внутри, так и вне организации. Для реализации этого сценария надо соблюдать следующие условия:

  • пользователи внутренней частной сети компании должны иметь доступ как к внутренним, так и к внешним серверам (по обе стороны брандмауэра);

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

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

Недостаток этой конфигурации — предоставление доступа к внешним ресурсам внутренним клиентам, так как внешняя зона DNS не сконфигурирована для разрешения имен внутренних ресурсов. Один из способов преодоления этого недостатка — создать дубликат внешней зоны во внутренней зоне DNS для разрешения имен ресурсов внутренними клиентами. Если используется прокси-сервер, прокси-клиент надо настроить так, чтобы он обращался к microsoft.com как к внутреннему ресурсу.

Рис. 4-3. Совпадающие внутреннее и внешнее пространства имен

Преимущества:

  • имя дерева, microsoft.com, согласовано в частной сети и Интернете;

  • появляется возможность унифицировать вход в систему — для это­го пользователи локальной сети и Интернета смогут применять одно и то же имя; например, jsmith@microsoft.com будет служить и регистрационным именем и идентификатором электронной почты. Недостатки:

  • усложняется конфигурация — при настройке прокси-клиентов надо учесть, что внутренние и внешние ресурсы отличаются;

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

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

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

Отличающиеся внутреннее и внешнее пространства имен

В этом случае компания использует различные внутреннее и внеш­нее пространства имен (рис. 4-4). Изначально в зонах по разные сто­роны брандмауэра имена различаются. Имя microsoft.com использу­ется вне брандмауэра, а msn.com — внутри.

Рис. 4-4. Отличающиеся внутреннее и внешнее пространства имен

Для этого необходимо зарегистрировать два пространства имен в DNS Интернета. Цель регистрации — предотвратить дублирование внутреннего имени другой общедоступной сетью. Если имя не заре­зервировано, внутренние клиенты не смогут отличить внутреннее имя от имени, зарегистрированном в общедоступной сети пространства имен DNS.

Таким образом, устанавливаются две зоны. Одна отвечает за раз­решение имен в пространстве microsoft.com, другая — в msn.com внут­ри брандмауэра. Пользователям не составит труда различать внутрен­ние и внешние ресурсы.

Преимущества:

  • очевидно различие между внутренними и внешними ресурсами;

  • среда проще в управлении;

  • упрощается настройка прокси-клиентов. так как при опознавании внешних ресурсов списки исключений содержат только micro­soft.com.

Недостатки:

  • регистрационные имена отличаются от имен электронной почты. Например, John Smith входит в систему с именем jsmith@msn.com. а адрес его электронной почты — jsmith@microsoft.com;

  • в DNS Интернета придется зарегистрировать несколько имен.

Примечание. В этом сценарии имена входа в систему различаются по умолчанию. Администратор может воспользоваться консолью уп­равления для изменения суффикса основного имени пользователя (user principal name, UPN), в результате чего имя входа пользователя будет совпадать с его электронным адресом.

Требования и концепции доменного именования

При планировании пространства имен для корневых доменов и под-доменов необходимо учитывать следующие рекомендации:

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

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

  • используйте стандартные символы DNS и Unicode. Windows 20CK поддерживает следующие стандартные символы DNS: A—Z, a—z 0—9 и символ дефиса (-), как определено в документе RFC 1035 Набор символов Unicode включает дополнительные символы, от­сутствующие в ASCII, которые требуются для других иностранных языков;

Примечание Используйте набор символов Unicode, только если его поддерживают все DNS-серверы. О наборе символов Unicode см. также в документе RFC 2044, для этого в поисковой машине Интернета введите ключевое слово «RFC 2044».

  • ограничьте количество уровней доменов. Обычно количество уров­ней в имени, согласно иерархии DNS, не должно превышать трех-четырех. Большое число уровней усложняет администрирование;

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

  • избегайте длинных имен — не более 63 символов, включая разде­лители. Общая длина не должна превышать 255 символов. Строч­ные и заглавные буквы не различаются.

  • На рис. 4-5 изображена структура домена для Microsoft. Корневой юмен компании, microsoft.com, содержит поддомены для ее четырех юдразделений.

Рис. 4-5. Структура домена Microsoft

Планирование структуры ОП

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

В каждом домене разрешается внедрять собственную иерархию ОП. Если ваша организация имеет несколько доменов, вы можете создать структуры ОП внутри каждого домена независимо от струк­туры в других доменах. ОП позволяет:

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

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

  • изменять организационную структуру компании;

  • группировать объекты так, чтобы администраторы легко отыски­вали сетевые ресурсы. Это облегчит обеспечение безопасности и выполнение любых административных задач. Например, вы мо­жете сгруппировать все учетные записи пользователей для времен­ных сотрудников в ОП, названном TempEmployees;

  • ограничить видимость сетевых ресурсов в Active Directory. Напри­мер, разрешить пользователи просматривать только объекты, к которым они имеют доступ.

Планирование иерархии ОП

При планировании иерархии ОП важно соблюсти ряд правил.

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

ОП должны отражать неизменные структурные единицы органи­зации.

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

  • модель деления на ОП согласно выполняемым задачам;

  • геогра­фическая модель деления на ОП;

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

Модель деления на ОП согласно выполняемым задачам

ОП можно создавать, учитывая функции, которые необходимо вы­полнять внутри организации (рис. 4-6.). Верхний уровень ОП — ADMIN, DEVELOPMENT (DEVEL) и SALES - соответствует биз­нес-подразделениям компании. Второй уровень ОП — функциональ­ные подразделения внутри бизнес-подразделений.

Географическая модель деления на ОП

Иногда при создании ОП учитывается местоположение филиалов компании (рис. 4-7). Верхний уровень ОП — WEST, CENTRAL и lAST — соответствует региональным подразделениям организации, а второй представляет физическое местоположение восьми офисов компании.

Рис. 4-6. Модель деления на ОП согласно выполняемым задачам

Рис. 4-7. Географическая модель деления на ОП

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

В некоторых случаях две описанные выше модели создания ОП со­вмещают (рис. 4-8). Верхний уровень ОП — NORTH AMERICA и EUROPE — учитывает, на каких континентах расположены офисы компании. Второй уровень ОП построен на основе функциональных особенностей каждого подразделения внутри организации.

Рис. 4-8. Модель деления на ОП по выполняемым задачам и географическому местоположению

Планирование структуры сайта

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

Настройка сайтов влияет на работу Windows 2000 следующим об­разом.

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

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

Соседние файлы в папке 1 AD