Доверительные отношения службы каталогов active directory windows используют протокол

Доверительные отношения в Active Directory еще важнее, чем в NT 4.0. При создании доменов в «лесу доменов» такие отношения устанавливаются автоматически, но, в отличие от NT 4.0, они «транзитивны». Это важное понятие мы разъясним ниже. Кстати, Windows Server 2008 хоть и предлагает множество новинок, но доверительные отношения по-прежнему действуют так же, как в Windows Server 2003.

Для большинства администраторов процесс установления доверительных отношений все еще требует привыкания, поскольку отдельные понятия немного запутаны. В результате в техническом плане возможность связи доменов Windows друг с другом представляется более «загадочной», чем есть на самом деле (см. Рисунок 1). Поэтому сначала остановимся на основных понятиях.

В Active Directory существует два различных вида доверительных отношений: «однонаправленные» и «двунаправленные». В первом случае один домен доверяет другому, но не наоборот. Пользователи Домена 1 могут получить доступ к ресурсам Домена 2, однако у пользователей Домена 2 нет доступа к ресурсам Домена 1. Естественно, возможен и обратный случай. Другие варианты доверительных отношений: «исходящие» и «входящие». При исходящих доверительных отношениях Домен 1 доверяет Домену 2, т. е. пользователи Домена 2 могут обращаться к ресурсам Домена 1.

При таком процессе домен, от которого доверительные отношения исходят, является доверяющим доменом (Trusting Domain). Домен с входящими доверительными отношениями — доверенный домен (Trusted Domain), в нем создаются учетные записи пользователей, обладающих правами в доверяющем домене.

В Windows NT 4.0 тоже можно было устанавливать доверительные отношения, но не транзитивные. Если в Windows NT 4.0 создавались доверительные отношения между доменами А и В, а также между доменами В и С, то это не значило, что домен А автоматически будет доверять домену С или, наоборот, домен С — домену А. Эту связь приходилось устанавливать вручную. В Active Directory делается иначе. Домены можно связывать практически без ограничений через домены, дочерние домены и деревья с автоматическим установлением между ними доверительных отношений. В Active Directory каждый домен доверяет любому другому домену, если является частью того же леса. Устанавливать доверительные отношения вручную возможно, но необходимости в этом уже нет (ключевая фраза: урезанные доверительные отношения).

В отдельном лесу существует определенный регулирующий алгоритм: доверительные отношения автоматически создаются между выше- и ниже-стоящими доменами. Microsoft обозначает этот тип как «подчиненные доверительные отношения». Кроме того, доверительные отношения автоматически создаются между корневыми доменами отдельных деревьев. Однако доверительных отношений между подчиненными доменами различных деревьев не существует. Они доверяют друг другу на основе транзитивных доверительных отношений (см. Рисунок 2). Доверительные отношения между корневыми доменами различных лесов называются «доверительными отношениями между лесами» (Forest Trust).

Как уже говорилось, дополнительные доверительные отношения можно определять и вручную. Это требуется по различным причинам. Так, возможны, к примеру, внешние доверительные отношения к доменам Windows NT 4.0 или отдельным доменам другого леса.
В Windows Server 2003 появились сохранившиеся в Windows Server 2008 доверительные отношения между лесами, когда связываются корневые домены двух различных лесов. В результате все домены обеих структур связаны автоматически транзитивными доверительными отношениями. Доверительные отношения можно создавать между подчиненными доменами разных деревьев в пределах одного леса. Они называются «прямыми доверительными отношениями» (Shortcut Trusts). Этот вид доверительных отношений часто используется, чтобы ускорить доступ к ресурсам между подчиненными доменами различных деревьев в одном лесу.

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

Управление доверительными отношениями осуществляется с помощью дополнительного модуля (Snap-in) «Домены Active Directory и доверительные отношения». Если вызвать в нем свойства какого-либо домена, то на соответствующей вкладке можно найти все его доверительные отношения и задать новые. Если требуется создать доверительное отношение с внешним доменом, то сначала нужно убедиться в том, что распознавание имен между доменами осуществляется без ошибок. Лишь когда обеспечено стабильное и надежное разрешение имен, можно устанавливать доверительные отношения. Здесь будет полезна оптимальная инфраструктура серверов DNS/WINS. Дело в том, что если нужно создать доверительные отношения с доменом Windows NT 4.0, то сервер WINS подходит лучше, чем DNS. В принципе, связь между доменом Windows NT 4.0 и доменом Active Directory можно установить и без WINS, но она будет нестабильной и сложно реализуемой.

Чтобы создать доверительные отношения, в дополнительном модуле «Домены Active Directory и доверительные отношения» необходимо вызвать свойства того домена, от которого они должны исходить. Во вкладке «Доверительные отношения» нужно нажать на кнопку «Новое доверительное отношение». Windows запускает ассистента. На второй странице отображается имя домена, к которому будет устанавливаться доверительное отношение. Если это домен Active Directory, то следует использовать имя DNS, в то время как для соединения с доменом Windows NT 4.0 лучшим выбором будет имя NetBIOS. Затем ассистент проверяет, возможна ли связь с доменом и должны ли доверительные отношения быть однонаправленными или двунаправленными (см. Рисунок 3).

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

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

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

ФИЛЬТРАЦИЯ SID В ДОВЕРИТЕЛЬНЫХ ОТНОШЕНИЯХ

После завершения установления внеш-них доверительных отношений автоматически высвечивается указание, что для этих отношений был активирован фильтр идентификаторов пользователей (SID). Это происходит автоматически, если доверительные отношения создаются контроллером домена под управлением Windows Server 2003 или Windows Server 2000 (SP4 и выше). Фильтрация SID защищает исходящие доверительные отношения. Она призвана воспрепятствовать раздаче администраторами доверенных доменов неправомерных полномочий в пределах доверяющих доменов. Фильтр SID следит за тем, чтобы в доверяющем домене аутентифицировались только те пользователи доверенного домена, чьи SID содержат SID этого домена. Если деактивировать фильтрацию SID, то внешний пользователь, обладающий правами администратора в доверенном домене, сможет прослушать сетевой трафик доверяющего домена, определить SID администратора, а затем присоединить этот SID к своей истории SID и заполучить права администратора в доверяющем домене.

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

Универсальные группы состоят из локальных и глобальных групп. Как локальные, они могут включать участ-ников из всего леса. Как глобальные, они видны во всех доменах. В случае универсальных групп на глобальные серверы каталогов тиражируются не только сведения о существовании этой группы, но и информация обо всех ее членах. Иными словами, если в универсальной группе много членов, то придется тиражировать большой объем информации. Деактивация фильтрации SID осуществляется через программу командной строки netdom.exe (см. Рисунок 4). Этот инструмент включен в комплект инструментов поддержки Windows, которые находятся в папке Support на диске Windows Server 2003. Их рекомендуется инсталлировать на каждый сервер, поскольку они включают полезные диагностические инструменты, к примеру, dcdiag.exe или netdiag.exe. Такие инструменты требуются во многих местах для администрирования Active Directory. Чтобы деактивировать фильтрацию SID, в командной строке необходимо ввести команду Netdom trust <ДоверяющийДомен> /domain:<ДоверенныйДомен> / quarantine:no /userD:<АдминистраторДомена> / passwordD:<ПарольАдминист-ратораДомена>.

ДОВЕРИТЕЛЬНЫЕ ОТНОШЕНИЯ К ДОМЕНАМ NT 4.0

Фильтрация SID активируется заново очень простым способом. Опцию /quarantine нужно установить на :yes: Netdom trust <ДоверяющийДомен> /domain:<ДоверенныйДомен> /quarantine:yes /userD:<АдминистраторДомена> /passwordD:<ПарольАдминистратораДомена>.

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

#pre #dom: <Домен>
”<Домен> x1b” #pre

Важно соблюдать регистр символов. IP-адрес должен совпадать с адресом контроллера домена. Между кавычками во второй строке следует ввести 20 символов, иначе разрешение не будет работать. Сразу после первой кавычки помещается имя NetBIOS домена Windows, с которым устанавливаются доверительные отношения. Данное имя не может быть длиннее 15 символов; если имя домена короче, то его необходимо дополнить до 15 символов пробелами. За 15-м символом следуют символы ox1b, а затем — закрывающая кавычка. Обрат-ная косая черта должна занимать 16-ю позицию. После этих изменений нужно либо перезапустить сервер, либо перезагрузить кэш NetBIOS с помощью команды nbtstat -R. Команда nbtstat- показывает содержимое кэша. Правильный результат: домен обозначается как «тип 1В». Если домен не отображается, то надо либо перезапустить серверы, либо заново проверить конфигурацию. Правда, конфигурация достаточно сложна, поэтому использование одного или нескольких серверов WINS гораздо более эффективно, так как необходимые данные создаются автоматически и могут запрашиваться задействованными серверами.

ДОВЕРИТЕЛЬНЫЕ ОТНОШЕНИЯ МЕЖДУ ЛЕСАМИ

При создании доверительных отношений между корневыми доменами двух лесов можно выбрать опцию «доверительные отношения между лесами». Ее преимущество заключается в том, что все подчиненные домены всех деревьев в задействованных лесах сразу же начинают транзитивно доверять друг другу. Для доверительных отношений между лесами должны быть соблюдены некоторые предпосылки: такой тип отношений поддерживается только в лесах Windows Server 2003/2008. Кроме того, важно, чтобы функциональные уровни домена и леса находились в однородном режиме Windows Server 2003 или 2008. Естественно, между лесами должно функционировать разрешение имен. Специфическую для доменов переадресацию лучше всего создавать на отдельных серверах DNS лесов.

Создание доверительных отношений между лесами идентично созданию доверительных отношений других типов. Для них точно так же можно установить, будут ли отношения одно- или двунаправленные, а кроме того, предоставить права отдельным доменам или всему лесу. Если в лесах используется несколько деревьев, то можно определить, какие диапазоны имен, а следовательно, и деревья, смогут пользоваться установленными доверительными отношениями. Но имена NetBIOS и DNS отдельных доменов должны быть разными. Если в лесах встречаются совпадающие имена NetBIOS или DNS, то эти домены взаимно лишаются доступа к ре-сурсам другого леса. Для управления различными деревьями в свойствах доверительных отношений используется вкладка «Маршрутизация суффиксов имен».

Томас Йоос – независимый профессиональный консультант по ИТ. Он консультирует средние и крупные предприятия относительно построения сетей Microsoft, Active Directory, Exchange Server и безопасности ИТ.

© AWi Verlag

Рисунок 1. Терминология или результаты доверительных отношений иногда несколько запутаны.

Рисунок 2. Доверительные отношения в Active Directory транзитивны.

Опубликовано: 18.06.2019

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

Мы будем рассматривать процесс настройки на примере двустороннего транзитивного доверия между доменами primary.local (192.168.0.15) и secondary.local (192.168.0.16). Саму настройку разделим на 2 этапа — конфигурирование DNS и создания доверий. В качестве операционной системы по данной инструкции можно настроить Windows Server 2008 / 2012 / 2016 / 2019.

Определяемся с типом доверительных отношений

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

Одностороннее или двустороннее

Определяют направление доверия одного домена к другому.

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

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

Внешнее или доверие леса

Внешнее или нетранзитивное отношение устанавливается между двумя доменами напрямую вне леса.

Доверие леса или транзитивное отношение связывает леса и все их домены.

Настройка DNS

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

На DNS домена primary.local

Открываем Диспетчер серверов — кликаем по Средства — DNS:

В открывшемся окне выбираем нужный сервер, если их несколько — раскрываем его — кликаем правой кнопкой мыши по Серверы условной пересылки — Создать сервер условной пересылки:

В «DNS-домен» пишем второй домен (в нашем случае, secondary.local), затем задаем его IP-адрес, ставим галочку Сохранять условный сервер пересылки в Active Directory и реплицировать ее следующим образом — выбираем Все DNS-серверы в этом домене:

Открываем командную строку и вводим команду:

nslookup secondary.local

Мы должны получить ответ на подобие:

На DNS домена secondary.local

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

Открываем Диспетчер серверов — Средства — DNS:

Раскрываем сервер — Серверы условной пересылки — Создать сервер условной пересылки:

На данном шаге небольшие изменения. В «DNS-домен» пишем первый домен (primary.local), затем задаем его IP-адрес (192.168.0.15), ставим галочку Сохранять условный сервер пересылки в Active Directory и реплицивовать ее следующим образом — выбираем Все DNS-серверы в этом домене:

В командной строке второго сервера проверяем настройку:

nslookup primary.local

Мы должны получить ответ на подобие:

Настройка доверительных отношений

После настройки DNS можно переходить к созданию доверительных отношений.

В домене primary.local открываем Диспетчер серверов — кликаем по Средства — Active Directory — домены и доверие:

В открывшемся окне кликаем правой кнопкой по нашему домену — Свойства:

Переходим на вкладку Отношения доверия — кликаем по Создать отношение доверия…:

Нажимаем Далее — вводим имя для второго домена (secondary.local) и кликаем Далее:

Выбираем Доверие леса (если нам не нужно внешнее доверие) — Далее:

В окне «Направление отношения доверия» выбираем Двустороннее:

… и нажимаем Далее.

В следующем окне выбираем, на каком из доменов мы применяем настройку — если у нас есть права администратора для обоих доменов, то выбираем Для данного и указанного доменов:

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

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

Далее нужно выбрать «Уровень проверки подлинности исходящего доверия» — если оба домена принадлежат нашей организации, предпочтительнее выбрать Проверка подлинности в лесу, чтобы предоставить доступ ко всем ресурсам:

После последуют два окна — «Выбор доверия завершен» — Далее — «Создание доверия завершено» — Далее.

В окне «Подтверждение исходящего доверия» оставляем Нет, не подтверждаю это исходящее доверие, так как на другой стороне нами не создавалось доверия.

Тоже самое в окне «Подтверждение входящего доверия».

Нажимаем Готово — доверительные отношения созданы.

Active Directory. Понимание доверительных отношений.

Многие предприятия имеют в своей сети несколько доменов Windows. Доверительные отношения между ними порой очень сложны, особенно в случае иерархических структур Active Directory. Я вам расскажу о функционировании доверительных отношений, о способах их установления, а также о том, какая базовая информация для этого необходима.
Доверительные отношения в Active Directory еще важнее, чем в NT 4.0. При создании доменов в «лесу доменов» такие отношения устанавливаются автоматически, но, в отличие от NT 4.0, они «транзитивны». Это важное понятие мы разъясним ниже. Кстати, Windows Server 2008 хоть и предлагает множество новинок, но доверительные отношения по-прежнему действуют так же, как в Windows Server 2003.

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

В Active Directory существует два различных вида доверительных отношений: «однонаправленные» и «двунаправленные». В первом случае один домен доверяет другому, но не наоборот. Пользователи Домена 1 могут получить доступ к ресурсам Домена 2, однако у пользователей Домена 2 нет доступа к ресурсам Домена 1. Естественно, возможен и обратный случай. Другие варианты доверительных отношений: «исходящие» и «входящие». При исходящих доверительных отношениях Домен 1 доверяет Домену 2, т. е. пользователи Домена 2 могут обращаться к ресурсам Домена 1.

При таком процессе домен, от которого доверительные отношения исходят, является доверяющим доменом (Trusting Domain). Домен с входящими доверительными отношениями — доверенный домен (Trusted Domain), в нем создаются учетные записи пользователей, обладающих правами в доверяющем домене.

В Windows NT 4.0 тоже можно было устанавливать доверительные отношения, но не транзитивные. Если в Windows NT 4.0 создавались доверительные отношения между доменами А и В, а также между доменами В и С, то это не значило, что домен А автоматически будет доверять домену С или, наоборот, домен С — домену А. Эту связь приходилось устанавливать вручную. В Active Directory делается иначе. Домены можно связывать практически без ограничений через домены, дочерние домены и деревья с автоматическим установлением между ними доверительных отношений. В Active Directory каждый домен доверяет любому другому домену, если является частью того же леса. Устанавливать доверительные отношения вручную возможно, но необходимости в этом уже нет (ключевая фраза: урезанные доверительные отношения).
В отдельном лесу существует определенный регулирующий алгоритм: доверительные отношения автоматически создаются между выше- и ниже-стоящими доменами. Microsoft обозначает этот тип как «подчиненные доверительные отношения». Кроме того, доверительные отношения автоматически создаются между корневыми доменами отдельных деревьев. Однако доверительных отношений между подчиненными доменами различных деревьев не существует. Они доверяют друг другу на основе транзитивных доверительных отношений.
Доверительные отношения между корневыми доменами различных лесов называются «доверительными отношениями между лесами» (Forest Trust).
Как уже говорилось, дополнительные доверительные отношения можно определять и вручную. Это требуется по различным причинам. Так, возможны, к примеру, внешние доверительные отношения к доменам Windows NT 4.0 или отдельным доменам другого леса.
В Windows Server 2003 появились сохранившиеся в Windows Server 2008 доверительные отношения между лесами, когда связываются корневые домены двух различных лесов. В результате все домены обеих структур связаны автоматически транзитивными доверительными отношениями. Доверительные отношения можно создавать между подчиненными доменами разных деревьев в пределах одного леса. Они называются «прямыми доверительными отношениями» (Shortcut Trusts). Этот вид доверительных отношений часто используется, чтобы ускорить доступ к ресурсам между подчиненными доменами различных деревьев в одном лесу.

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

Управление доверительными отношениями осуществляется с помощью дополнительного модуля (Snap-in) «Домены Active Directory и доверительные отношения». Если вызвать в нем свойства какого-либо домена, то на соответствующей вкладке можно найти все его доверительные отношения и задать новые. Если требуется создать доверительное отношение с внешним доменом, то сначала нужно убедиться в том, что распознавание имен между доменами осуществляется без ошибок. Лишь когда обеспечено стабильное и надежное разрешение имен, можно устанавливать доверительные отношения. Здесь будет полезна оптимальная инфраструктура серверов DNS/WINS. Дело в том, что если нужно создать доверительные отношения с доменом Windows NT 4.0, то сервер WINS подходит лучше, чем DNS. В принципе, связь между доменом Windows NT 4.0 и доменом Active Directory можно установить и без WINS, но она будет нестабильной и сложно реализуемой.

Чтобы создать доверительные отношения, в дополнительном модуле «Домены Active Directory и доверительные отношения» необходимо вызвать свойства того домена, от которого они должны исходить. Во вкладке «Доверительные отношения» нужно нажать на кнопку «Новое доверительное отношение». Windows запускает ассистента. На второй странице отображается имя домена, к которому будет устанавливаться доверительное отношение. Если это домен Active Directory, то следует использовать имя DNS, в то время как для соединения с доменом Windows NT 4.0 лучшим выбором будет имя NetBIOS. Затем ассистент проверяет, возможна ли связь с доменом и должны ли доверительные отношения быть однонаправленными или двунаправленными.
При двунаправленном соединении пользователи каждого из доменов могут аутентифицироваться в другом домене для получения доступа к ресурсам. При выборе «Однонаправленные: входящие» устанавливается, что данный домен является доверенным,
т. е. пользователь этого домена может аутентифицироваться в другом домене и обращаться к его ресурсам. В варианте «Однонаправленные: исходящие» пользователи другого домена могут регистрироваться в нем, а вот пользователи этого домена в другом — нет.

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

Теперь следует отменить отказ для каждого отдельного сервера, а затем установить пароль для доверительных отношений, который позднее потребуется для верификации и установления доверительных отношений в другом направлении. В следующем окне нужно выбрать, будет ли доверительное отношение проверяться. При создании доверительных отношений с доменом Windows NT 4.0 необходимо сначала установить их со стороны этого домена. Пользователи получают доступ к ресурсам лишь после верификации доверительных отношений как активных. Если создание доверительных отношений не удается, то обычно это происходит из-за проблем с разрешением имен или наличием прав.
ФИЛЬТРАЦИЯ SID В ДОВЕРИТЕЛЬНЫХ ОТНОШЕНИЯХ

После завершения установления внеш-них доверительных отношений автоматически высвечивается указание, что для этих отношений был активирован фильтр идентификаторов пользователей (SID). Это происходит автоматически, если доверительные отношения создаются контроллером домена под управлением Windows Server 2003 или Windows Server 2000 (SP4 и выше). Фильтрация SID защищает исходящие доверительные отношения. Она призвана воспрепятствовать раздаче администраторами доверенных доменов неправомерных полномочий в пределах доверяющих доменов. Фильтр SID следит за тем, чтобы в доверяющем домене аутентифицировались только те пользователи доверенного домена, чьи SID содержат SID этого домена. Если деактивировать фильтрацию SID, то внешний пользователь, обладающий правами администратора в доверенном домене, сможет прослушать сетевой трафик доверяющего домена, определить SID администратора, а затем присоединить этот SID к своей истории SID и заполучить права администратора в доверяющем домене.

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

Универсальные группы состоят из локальных и глобальных групп. Как локальные, они могут включать участников из всего леса. Как глобальные, они видны во всех доменах. В случае универсальных групп на глобальные серверы каталогов тиражируются не только сведения о существовании этой группы, но и информация обо всех ее членах. Иными словами, если в универсальной группе много членов, то придется тиражировать большой объем информации. Деактивация фильтрации SID осуществляется через программу командной строки netdom.exe.Этот инструмент включен в комплект инструментов поддержки Windows, которые находятся в папке Support на диске Windows Server 2003. Их рекомендуется инсталлировать на каждый сервер, поскольку они включают полезные диагностические инструменты, к примеру, dcdiag.exe или netdiag.exe. Такие инструменты требуются во многих местах для администрирования Active Directory. Чтобы деактивировать фильтрацию SID, в командной строке необходимо ввести команду Netdom trust <ДоверяющийДомен> /domain:<ДоверенныйДомен> / quarantine:no /userD:<АдминистраторДомена> / passwordD:<ПарольАдминист-ратораДомена>.
ДОВЕРИТЕЛЬНЫЕ ОТНОШЕНИЯ К ДОМЕНАМ NT 4.0

Фильтрация SID активируется заново очень простым способом. Опцию /quarantine нужно установить на :yes: Netdom trust <ДоверяющийДомен> /domain:<ДоверенныйДомен> /quarantine:yes /userD:<АдминистраторДомена> /passwordD:<ПарольАдминистратораДомена>.

Иногда возникают проблемы с установлением доверительных отношений. Виной тому — ошибочное распознавание имен, защищенные маршрутизаторы между различными подсетями или ошибки на серверах WINS. Если не получается создать доверительные отношения между двумя контроллерами доменов, то часто помогает создание файла lmhosts на обоих серверах. Этот файл находится в папке Windows/system32/drivers/etc. Для обеспечения распознавания имен файл нужно переименовать в lmhosts без расширения. В указанном файле настраивается разрешение доменов, так что серверы DNS или WINS будут пропускаться. Для этого нужно добавить в файл следующие строки:

#pre #dom: <Домен>
”<Домен> x1b” #pre
Важно соблюдать регистр символов. IP-адрес должен совпадать с адресом контроллера домена. Между кавычками во второй строке следует ввести 20 символов, иначе разрешение не будет работать. Сразу после первой кавычки помещается имя NetBIOS домена Windows, с которым устанавливаются доверительные отношения. Данное имя не может быть длиннее 15 символов; если имя домена короче, то его необходимо дополнить до 15 символов пробелами. За 15-м символом следуют символы ox1b, а затем — закрывающая кавычка. Обратная косая черта должна занимать 16-ю позицию. После этих изменений нужно либо перезапустить сервер, либо перезагрузить кэш NetBIOS с помощью команды nbtstat -R. Команда nbtstat- показывает содержимое кэша. Правильный результат: домен обозначается как «тип 1В». Если домен не отображается, то надо либо перезапустить серверы, либо заново проверить конфигурацию. Правда, конфигурация достаточно сложна, поэтому использование одного или нескольких серверов WINS гораздо более эффективно, так как необходимые данные создаются автоматически и могут запрашиваться задействованными серверами.
ДОВЕРИТЕЛЬНЫЕ ОТНОШЕНИЯ МЕЖДУ ЛЕСАМИ

При создании доверительных отношений между корневыми доменами двух лесов можно выбрать опцию «доверительные отношения между лесами». Ее преимущество заключается в том, что все подчиненные домены всех деревьев в задействованных лесах сразу же начинают транзитивно доверять друг другу. Для доверительных отношений между лесами должны быть соблюдены некоторые предпосылки: такой тип отношений поддерживается только в лесах Windows Server 2003/2008. Кроме того, важно, чтобы функциональные уровни домена и леса находились в однородном режиме Windows Server 2003 или 2008. Естественно, между лесами должно функционировать разрешение имен. Специфическую для доменов переадресацию лучше всего создавать на отдельных серверах DNS лесов.

Создание доверительных отношений между лесами идентично созданию доверительных отношений других типов. Для них точно так же можно установить, будут ли отношения одно- или двунаправленные, а кроме того, предоставить права отдельным доменам или всему лесу. Если в лесах используется несколько деревьев, то можно определить, какие диапазоны имен, а следовательно, и деревья, смогут пользоваться установленными доверительными отношениями. Но имена NetBIOS и DNS отдельных доменов должны быть разными. Если в лесах встречаются совпадающие имена NetBIOS или DNS, то эти домены взаимно лишаются доступа к ресурсам другого леса. Для управления различными деревьями в свойствах доверительных отношений используется вкладка «Маршрутизация суффиксов имен».

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

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

Windows NT

Windows 2003 и Windows 2000 Server

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

Windows Server 2008/Windows Server 2008 R2

Если домен Windows 2008 работает в смешанном режиме и в домене присутствуют контроллеры домена Windows Server 2003 или клиентские компьютеры, работающие под управлением устаревших версий операционных систем, то динамический диапазон портов по умолчанию будет с 1025 по 5000. Для Windows Server 2008 и Windows Server 2008 R2, в соответствии с рекомендациями Internet Assigned Numbers Authority (IANA), был увеличен стартовый диапазон используемых портов. Новый диапазон теперь с 49152 по 65535. Следовательно, нужно увеличить диапазон портов RPC на своих файрволлах.

Чтобы служба каталогов Active Directory надлежащим образом работала в сети, содержащей межсетевые экраны, они должны пропускать пакеты протокола ICMP (Internet Control Message Protocol) от клиентских компьютеров к контроллерам домена. Это необходимо для получения клиентами сведений групповой политики. С помощью протокола ICMP определяется, является ли подключение быстрым или медленным. Протокол ICMP – это стандартный протокол, используемый службой каталогов Active Directory для определения максимального размера передаваемого блока данных (MTU) и определения доступности сервера, с которого должна загружаться групповая политика.
Чтобы свести к минимуму объем данных, передаваемых по протоколу ICMP, создайте на межсетевом экране правила, аналогичные приведенному ниже.

<any> ICMP -> IP-адрес_контроллера_домена = allow

В отличие от протоколов, принадлежащих уровням TCP и UDP, в протоколе ICMP отсутствует номер порта, поскольку протокол ICMP расположен на уровне IP.

По умолчанию DNS-серверы под управлением Windows Server 2003 и Windows 2000 Server используют динамические номера портов при отправке запросов другим DNS-серверам. Чтобы изменить это поведение, необходимо изменить параметр реестра, описанный в следующей статье базы знаний Майкрософт:

260186 (http://support.microsoft.com/kb/260186/ ) Параметр реестра SendPort работает ненадлежащим образом

Подробнее о настройке службы каталогов Active Directory и брандмауэра можно прочитать в документе White Paper Майкрософт:

http://www.microsoft.com/downloads/details.aspx?FamilyID=c2ef3846-43f0-4caf-9767-a9166368434e&displaylang=en

Кроме того, для установки доверительных отношений можно использовать туннель, созданный с использованием протокола PPTP (Point-to-Point Tunneling Protocol). Это позволит уменьшить число портов, которые должны быть открыты на межсетевом экране. Чтобы компьютеры могли создать туннель PPTP, на межсетевом экране должны быть открыты следующие порты:

Необходимо также разрешить прохождение пакетов протокола IP с полем типа протокола, равным 47 (GRE).

Примечание. Windows 2000 и Windows NT 4.0 по-разному ведут себя при предоставлении пользователю из доверенного домена прав доступа к ресурсам доверяющего домена. Если компьютеру не удается получить список пользователей удаленного домена, выполняются следующие действия.

• Компьютер под управлением Windows NT 4.0 пытается выполнить разрешение имен, указанных вручную. Для этого он обращается к основному контроллеру удаленного домена пользователя. При этом используется порт 138 протокола UDP. Если выполнить данное подключение не удается, Windows NT 4.0 обращается к основному контроллеру своего домена и пытается выполнить разрешение имен.
• Windows 2000 и Windows Server 2003 также обращаются к основному контроллеру домена пользователя, используя порт 138 протокола UDP. Однако, если выполнить данное подключение не удается, Windows 2000 и Windows Server 2003 не обращаются к основному контроллеру своего домена. Поэтому необходимо удостовериться, что все рядовые серверы под управлением Windows 2000 и Windows Server 2003, которые будут предоставлять доступ к общим ресурсам, могут подключиться по протоколу UDP к порту 138 основного контроллера домена пользователя.

Оригинальная статья — How to configure a firewall for domains and trusts

Опубликовано: 18.06.2019

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

Мы будем рассматривать процесс настройки на примере двустороннего транзитивного доверия между доменами primary.local (192.168.0.15) и secondary.local (192.168.0.16). Саму настройку разделим на 2 этапа — конфигурирование DNS и создания доверий. В качестве операционной системы по данной инструкции можно настроить Windows Server 2008 / 2012 / 2016 / 2019.

Определяемся с типом доверительных отношений

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

Одностороннее или двустороннее

Определяют направление доверия одного домена к другому.

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

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

Внешнее или доверие леса

Внешнее или нетранзитивное отношение устанавливается между двумя доменами напрямую вне леса.

Доверие леса или транзитивное отношение связывает леса и все их домены.

Настройка DNS

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

На DNS домена primary.local

Открываем Диспетчер серверов — кликаем по Средства — DNS:

В открывшемся окне выбираем нужный сервер, если их несколько — раскрываем его — кликаем правой кнопкой мыши по Серверы условной пересылки — Создать сервер условной пересылки:

В «DNS-домен» пишем второй домен (в нашем случае, secondary.local), затем задаем его IP-адрес, ставим галочку Сохранять условный сервер пересылки в Active Directory и реплицировать ее следующим образом — выбираем Все DNS-серверы в этом домене:

Открываем командную строку и вводим команду:

nslookup secondary.local

Мы должны получить ответ на подобие:

На DNS домена secondary.local

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

Открываем Диспетчер серверов — Средства — DNS:

Раскрываем сервер — Серверы условной пересылки — Создать сервер условной пересылки:

На данном шаге небольшие изменения. В «DNS-домен» пишем первый домен (primary.local), затем задаем его IP-адрес (192.168.0.15), ставим галочку Сохранять условный сервер пересылки в Active Directory и реплицивовать ее следующим образом — выбираем Все DNS-серверы в этом домене:

В командной строке второго сервера проверяем настройку:

nslookup primary.local

Мы должны получить ответ на подобие:

Настройка доверительных отношений

После настройки DNS можно переходить к созданию доверительных отношений.

В домене primary.local открываем Диспетчер серверов — кликаем по Средства — Active Directory — домены и доверие:

В открывшемся окне кликаем правой кнопкой по нашему домену — Свойства:

Переходим на вкладку Отношения доверия — кликаем по Создать отношение доверия…:

Нажимаем Далее — вводим имя для второго домена (secondary.local) и кликаем Далее:

Выбираем Доверие леса (если нам не нужно внешнее доверие) — Далее:

В окне «Направление отношения доверия» выбираем Двустороннее:

… и нажимаем Далее.

В следующем окне выбираем, на каком из доменов мы применяем настройку — если у нас есть права администратора для обоих доменов, то выбираем Для данного и указанного доменов:

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

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

Далее нужно выбрать «Уровень проверки подлинности исходящего доверия» — если оба домена принадлежат нашей организации, предпочтительнее выбрать Проверка подлинности в лесу, чтобы предоставить доступ ко всем ресурсам:

После последуют два окна — «Выбор доверия завершен» — Далее — «Создание доверия завершено» — Далее.

В окне «Подтверждение исходящего доверия» оставляем Нет, не подтверждаю это исходящее доверие, так как на другой стороне нами не создавалось доверия.

Тоже самое в окне «Подтверждение входящего доверия».

Нажимаем Готово — доверительные отношения созданы.

Понятия:
служба каталогов, виды, Active Directory,
система, система безопасности сети.
Администрирование сети (безопасность).

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

Служба
каталогов Active Directory

Согласно
словарю Ожегова, каталог
— это составленный в определенном
порядке перечень каких-либо однородных
предметов (книг, экспонатов, товаров)’.
Точно так же, как каталог выставки
содержит информацию об экспонатах,
каталог файловой системы предоставляет
информацию о файлах. Отличительная
особенность такого каталога — возможность
систематизации хранимой информации,
быстрого поиска нужной, а также добавления
и расширения самого каталога. Служба
каталогов операционной системы хранит
информацию об объектах системы и
позволяет манипулировать ими.

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

Служба
каталогов NTDS

NTDS
представляет собой плоскую модель
доменов, при этом под доменом понимается
совокупность компьютеров собщей базой
учетных записей пользователей и единой
политикой защиты. 
У каждого домена
свое уникальное имя. Оно может отражать
либо его функциональное назначение
(например, DEVELOPERS_DOM), либо географическое
расположение (например, MOSCOW_EAST), либо
что-то, понятное лишь одному автору
этого имени (например, MASTER_DOM1). 
Каждый
домен представляет собой замкнутое
пространство со своими учетными записями
пользователей и ресурсами. По умолчанию
пользователи одного домена не имеют
доступа к ресурсам другого домена. Для
предоставления им такой возможности
между доменами устанавливаются
доверительные отношения. Эти отношения
могут быть как односторонними (например,
домен А доверяет домену Б, но не наоборот),
так и двусторонними (оба домена доверяют
друг другу). Доверительные отношения
не транзитивны, иными словами, если
домены А и В доверяют домену Б, то это
не означает по умолчанию, что А и В
доверяют друг другу. При организации
корпоративных сетей используются четыре
модели доверительных отношений: модель
с одним доменом, модель с одним
мастер-доменом, модель с несколькими
мастер-доменами и модель полностью
доверительных отношений. Подробно об
этих моделях см. [I]. 
Недостаток
доменной службы каталогов NTDS — сложность
администрирования для крупных организаций.
Например, перемещая учетную запись
пользователя из одного домена в другой,
администратор вынужден заново
переопределять права доступа, что
зачастую непросто. Кроме того, эта служба
каталогов не предоставляет средств
эффективного поиска объектов сети.
Например, невозможно найти в нескольких
доменах пользователя UserPo, определить
объекты, к которым он имеет доступ, а
также вид этого доступа.

Еще
одно слабое место NTDS — относительно
невысокая емкость доменов. В одном
домене может быть не более 40 000 учетных
записей, что опять-таки мало пригодно
для крупных организаций. 
Кроме
того, в домене может существовать только
один первичный контроллер домена и
несколько резервных. Модификация базы
учетных записей выполняется только на
первичном контроллере, а если последний
временно недоступен — сеть становится
неуправляемой.

Что такое Active
Directory

Служба
каталогов Active Directory (AD) — сервис,
интегрированный с Windows NT Server. Она
обеспечивает иерархический вид сети,
наращиваемость и расширяемость, а также
функции распределенной безопасности.
Эта служба легко интегрируется с
Интернетом, позволяет использовать
простые и интуитивно понятные имена
объектов, пригодна для использования
в организациях любого размера и легко
масштабируется. Доступ к ней возможен
с помощью таких знакомых инструментов,
как программа просмотра ресурсов
Интернета. 
AD не только позволяет
выполнять различные административные
задачи, но и является поставщиком
различных услуг в системе. На приведенном
ниже рисунке схематично изображены
основные функции службы каталогов.

В
Active Directory концепция пространства имен
Интернета объединена с системными
службами каталогов, что дает возможность
единым образом управлять различными
пространствами имен в гетерогенных
средах корпоративных сетей. В качестве
основного в AD используется легкий
протокол доступа к каталогу LDAP (lightweight
directory access protocol), позволяющий действовать
за рамками операционной системы,
объединяя различные пространства имен.
Active Directory может включать в себя каталоги
других приложений или сетевых операционных
систем, а также управлять ими, что
значительно снижает нагрузку на
администраторов и накладные расходы.

Каталог
— поставщик услуг в системе

HTTP
— стандартный протокол для отображения
страниц Web. Active Directory дает возможность
просмотреть любой объект в виде страницы
Web. Расширения Internet Information Server, поставляемые
совместно со службой каталога, преобразуют
запросы к объектам каталога в страницы
HTML. 
Active Directory позволяет централизовано
администрировать все ресурсы, любые
произвольные объекты и сервисы: файлы,
периферийные устройства, базы данных,
подключения к Web, учетные записи и др. В
качестве поискового сервиса используется
DNS. Все объекты внутри домена объединяются
в организационные единицы (OU), составляющие
иерархичные структуры. В свою очередь,
домены могут объединяться
в деревья. 
Администрирование
упростилось по сравнению с предыдущими
версиями: больше нет первичного и
резервных контроллеров домена. Все
контроллеры доменов, используемые
службой каталогов, равноправны. Изменения
можно вносить на любом контроллере, а
на остальные они
будут тиражироваться
автоматически. 
Еще одна особенность
Active Directory — поддержка нескольких
хранилищ, в каждом из которых может
находиться до 10 миллионов объектов.
Понятно, что при таких возможностях эта
служба каталогов прекрасно проявляет
себя как в малых сетях, так и в больших
системах.

Сфера
влияния

Сфера
влияния службы каталогов велика: любые
объекты (пользователи, файлы, принтеры
и др.), серверы в сети, домены и даже
глобальные сети. А раз так, напрашивается
вывод: возможности такой службы каталогов,
как AD, практически безграничны, что
делает ее полезной на отдельном
компьютере, в большой сети, и в нескольких
сетях.

Пространство
имен 

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

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

Контейнер 
Контейнер
— это объект каталога, который может
содержать в себе другие объекты (как,
например, папка —это контейнер для
документов, а шкаф — контейнер для
папок). Контейнер каталога является
контейнером объектов каталога.

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

Имя 
Имена
используются для идентификации объектов
в Active Directory. Существует два вида имен:
отличительное имя DN (distinguished name) и
относительно отличительное имя RDN
(relatively distinguished name). Отличительное имя
объекта содержит имя домена, в котором
находится объект, а также полный путь
к этому объекту в иерархии контейнера.
Например, отличительное имя для
идентификации пользователя Fyodor Zubanov в
домене MicrosoftAO.RU будет выглядеть следующим
образом: /0=Internet/DC=RU/DC=MiсrosoftAO/CN=Users/CN=Fyodor
Zubanov. Относительное отличительное имя
объекта — часть отличительного
имени, являющаяся атрибутом объекта. В
приведенном примере таковым для объекта
пользователя Fyodor Zubanov является CN=Fyodor
Zubanov, a RDN его родительского объекта —
CN=Users.

Контексты
имен и разделы 

Active
Directory состоит из одного или нескольких
контекстов имен или разделов. 

Контекст
имени — это любое смежное поддерево
каталога. Контексты имен являются
единицами тиражирования. Для любого
одиночного сервера всегда есть три
контекста имен: 

• схема; 

• конфигурация
  (топология тиражирования и относящиеся
  к нему
  метаданные); 

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

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

Дерево
доменов

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

Доверительные
отношения Kerberos

Деревья
можно рассматривать и с точки зрения
доверительных отношений, и с точки
зрения пространства имен. 
В Windows
NT 5.0 доверительные отношения между
доменами основываются на протоколе
защиты Kerberos. Эти отношения транзитивны
(сравните с описанием доверительных
отношений для NTDS), то есть если домен А
доверяет домену Б, а домен Б доверяет
домену В, то домен А также доверяет
домену В. На рисунке изображены домены
с точки зрения доверия. 

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

Взгляд
на домены с точки зрения пространства
имен

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

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

Несколько
деревьев в лесу

Узлы 
Узел
— это место расположения в сети
серверов с Active Directory, В качестве узлов
могут выступать одна или несколько
подсетей TCP/IP, что позволяет конфигурировать
доступ к каталогу и тиражирование с
учетом физической сети. Когда пользователь
входит в сеть, сервер с Active Directory не надо
долго искать — ведь он находится в том
же самом узле и рабочей станции «известно»,
как добраться до него по TCP/IP.

Схема 
Схема Active
Directory представляет собой набор экземпляров
классов объектов, хранящихся в каталоге.
Это отличает ее от схем других каталогов,
которые, как правило, хранятся в текстовых
файлах и прочитываются при загрузке.
Хранение схемы в каталоге имеет ряд
преимуществ. Например, приложения могут
обращаться к каталогу и читать списки
доступных объектов, а также динамически
изменять схему, добавляя в нее новые
атрибуты и классы. Модификация схемы
сопровождается созданием или модификацией
объектов, хранящихся в каталоге. Все
внесенные изменения незамедлительно
становятся доступны для других приложений.
Любые объекты схемы (впрочем, как и любые
объекты Active Directory) защищены списками
контроля доступа, что гарантирует их
от изменений лицами, не имеющими на это
прав.

Модель
данных

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

Глобальный
каталог 

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

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

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

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

Архитектура
Active Directory 

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

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

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

Архитектура
Active Directory

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

Как
уже упоминалось, внутри каждого домена
— своя политика безопасности (подробнее
об этом — в главе 2). Этой политикой
определяются, в частности, требования
к паролям, время жизни билетов Кегberos,
блокировки учетных записей и т. д. При
создании учетной записи в домене для
нее генерируется идентификатор
безопасности (SID), частью которого
является идентификатор домена, выдавшего
SID. Это позволяет легко определять,
какому домену принадлежит пользователь
или группа и каковы их права доступа к
ресурсам. Таким образом, можно говорить
о физических границах безопасности
домена, в рамках которых и выполняется
его администрирование. 

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

Использование
схемы

Определение
схемы, данное при первом ознакомлении
с этим термином, несколько расплывчато
и, возможно, не дает общего понимания
ее назначения. В схеме задано, какие
объекты и с какими свойствами допустимы
в каталоге. Во время установки Active
Directory на первый контроллер доменов в
лесу, служба каталогов по умолчанию
создает схему, где содержатся все объекты
и заданы свойства, необходимые
для
нормального функционирования
службы каталогов. Предусматривается
также тиражирование каталога на все
контроллеры домена, которые будут
включены в лес позднее. 
Каталог
содержит необходимую информацию о
пользователях и объектах данной
организации. Такие свойства Active Directory,
как отказоустойчивость и расширяемость,
позволяют использовать этот сервис в
различных приложениях, например, по
учету кадров. Стандартно в Active Directory уже
определены такие атрибуты пользователя,
как его имя, фамилия, номера телефонов,
название офиса, домашний адрес. Но если
понадобятся такие сведения, как зарплата
сотрудника, его трудовой стаж, медицинская
страховка, сведения о поощрениях и т.
п,, то эти параметры можно задать
дополнительно. Active Directory позволяет
«наращивать» схему, добавлять в нее
новые свойства и классы на основе
существующих и с наследованием их
свойств.  Также можно задавать новые
свойства, в том числе и существующим
классам. При этом все свойства можно
разделить на обязательные и возможные. Все
обязательные свойства необходимо
указывать при создании объекта. Например
объект «пользователь» обязательно
должен иметь общее имя en (common name), пароль
и SamAccountName (имя, используемое для обратной
совместимости с предыдущими версиями). 

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

Понятно,
что такая свобода модификации и
наращивания каталога должна опираться
на мощные механизмы хранения и поиска
информации. В Active Directory таким механизмом
хранения служит ESE (Extensible Storage Engine) —
улучшенная версия Jet-базы данных,
использующейся в Microsoft Exchange версий 4 и
5.х2. В новой базе может содержаться до
17 терабайт данных, до 10 миллионов
объектов.

 Пример
модификации схемы

Еще
одна особенность ESE — там хранятся
только реально используемые значения
свойств. Например, для объекта user
определено по умолчанию порядка 50
свойств. Но если Вы описали только 4
(имя, фамилию, общее имя и пароль), то
место для хранения будет отведено только
для этих атрибутов. По мере описания
других атрибутов место для них будет
выделяться динамически.

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

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

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

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

Хорошая
политика обеспечения безопасности
включает несколько элементов, в том
числе следующие:

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

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

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

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

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