Основы работы в сети: Часть 6 — Домен Windows

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

Как я объяснял в части 5 этой серии статей, домены не являются чем-то новым. Первоначально Microsoft представила их в Windows NT Server. Первоначально домены были полностью автономными. В одном домене часто размещались все учетные записи пользователей для всей компании, и администратор домена имел полный контроль над доменом и всем, что в нем было.

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

В подобных ситуациях пользователям из одного домена иногда необходимо получить доступ к ресурсам, расположенным в другом домене. Microsoft создала доверительные отношения как способ облегчить такой доступ. Лучший способ, который я могу придумать для описания трастов, — это сравнить их с тем, как работает служба безопасности в аэропорту.

В Соединенных Штатах пассажиры должны предъявить свои водительские права сотрудникам службы безопасности аэропорта перед посадкой на внутренний рейс. Предположим на мгновение, что я собираюсь куда-то лететь. Сотрудники службы безопасности в аэропорту не знают, кто я такой, и уж точно мне не доверяют. Однако они доверяют штату Южная Каролина. Они предполагают, что штат Южная Каролина проявил должную осмотрительность при проверке моей личности, прежде чем выдать мне водительские права. Поэтому я могу показать им водительские права Южной Каролины, и они пустят меня в самолет, даже если они не обязательно доверяют мне как личности.

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

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

В начале этой статьи я упомянул, что в Windows NT домен был полностью автономной средой, и что доверительные отношения были созданы как способ предоставления пользователям одного домена доступа к ресурсам другого домена. Эти концепции частично верны и сегодня, но модель предметной области резко изменилась, когда Microsoft создала Active Directory. Как вы помните, Active Directory впервые появилась в Windows 2000, но до сих пор используется в Windows Server 2003 и в скором выпуске Longhorn Server.

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

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

Домены Active Directory используют имена в стиле DNS, аналогичные именам, используемым веб-сайтами. В части 3 этой серии статей я объяснил, как DNS-серверы разрешают URL-адреса для веб-браузеров. Тот же метод используется внутри среды Active Directory. Подумайте об этом на мгновение. DNS означает сервер доменных имен. Фактически, DNS-сервер является обязательным компонентом для любого развертывания Active Directory.

Чтобы увидеть, как работает именование доменов, давайте посмотрим, как настроена моя собственная сеть. Основной домен моей сети называется production.com. На самом деле я не владею интернет-доменом production.com, но это не имеет значения, потому что этот домен является частным и доступен только внутри моей сети.

Домен production.com считается доменом верхнего уровня. Если бы это был интернет-домен, он не был бы доменом верхнего уровня, потому что.com был бы доменом верхнего уровня, а production.com был бы дочерним доменом домена.com. Несмотря на это незначительное различие, остается верным один и тот же основной принцип. Я мог бы легко создать дочерний домен, создав другое доменное имя, которое включает в себя production.com. Например, sales.production.com будет считаться дочерним доменом домена production.com. Вы даже можете создавать дочерние домены. Примером дочернего домена для production.com может быть widgets.sales.production.com. Как видите, вы можете легко определить положение домена в дереве доменов, просто взглянув на количество точек в имени домена.

Ранее я упоминал, что лес Active Directory может содержать деревья доменов. Вы не ограничены созданием одного дерева доменов. Фактически, моя собственная сеть использует два дерева доменов; production.com и test.com. Домен test.com содержит все серверы, с которыми я экспериментирую, экспериментируя с различными методами, о которых пишу статьи. Домен production.com содержит серверы, которые я фактически использую для ведения своего бизнеса. Этот домен содержит мой почтовый сервер и несколько файловых серверов.

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

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

Вывод

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