Monday, December 11th, 2017

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

Published on Февраль 18, 2009 by   ·   Комментариев нет

Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:

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

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

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

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

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

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

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

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

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

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

Домены Active Directory domain используют стиль имен DNS, подобно названиям, используемых Web сайтами. В третьей части этой статьи (Part 3), я рассказал о том, как сервера DNS server распознают URL для Web браузеров. Аналогичная технология используется внутри домена Active Directory. Представьте себе на минуту. DNS расшифровывается, как Domain Name Server (сервер доменных имен). В действительности, сервер DNS server – это необходимый компонент для любой установки Active Directory deployment.

Для того, чтобы увидеть, как работает именование доменов, давайте посмотрим, как настроена моя собственная сеть. Основной домен моей сети называется 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 forest может содержать деревья доменов. Вы не ограничены созданием одного дерева домена. В действительности моя собственная сеть использует два дерева домена — production.com и test.com. Домен test.com содержит все сервера, на которых я отрабатываю различные технологии, о которых я пишу в своих статьях. Домен production.com содержит все сервера, которые я использую для своего бизнеса. Этот домен содержит мой почтовый сервер и несколько файловых серверов.

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

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

Заключение

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

www.windowsnetworking.com


Смотрите также:

Tags: , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]