Для того, чтобы не заводить учетную информацию на одного и того же пользователя в разных доменах, между доменами можно установить доверительные отношения.
Доверительные отношения обеспечивают транзитную аутентификацию, при которой пользователь имеет только одну учетную запись в одном домене, но может получить доступ к ресурсам всех доменов сети.
Рис. 6.1. Доверительные отношения между доменами
Доверяющий домен - trusting - предоставляет доступ к своим ресурсам пользователям из другого домена - доверяемого или trusted. Иногда доверяющий домен называют ресурсным, так как в нем находятся серверы, к ресурсам которых получают доступ пользователи, учетная информация которых находится в SAM контроллеров доверяемого домена, который называют поэтому учетным.
Доверительные отношения не являются транзитивными. Например, если домен А доверяет домену В, а В доверяет С, то это не значит, что А автоматически доверяет С.
Отношение доверия означает, что администратор доверяющего, ресурсного, домена может определять права доступа к ресурсам своего домена не только для своих пользователей, но и для пользователей доверяемого, учетного, домена. Таким образом, право доступа к ресурсам доверяющего домена для пользователей доверяемого домена является потенциальным, реализуемым только при условии согласия администратора доверяющего домена.
Практически же ситуация обычно выглядит следующим образом. В некотором учетном домене формируются глобальные группы. Во всех доменах, доверяющих данному домену, администраторы включают глобальные группы учетного домена в локальные группы своего ресурсного домена. Эти локальные группы уже наделенны определенными правами по доступу к внутренним ресурсам домена. Возникает интересная ситуация: с одной стороны, доступ к ресурсам регулируется администратором доверяющего домена, но с другой стороны, именно администратор учетного домена решает, в какую глобальную группу включить того или иного пользователя.
Пользователи могут входить в сеть из рабочих станций не только того домена, где хранится их учетная информация, но и из рабочих станций доменов, которые доверяют этому домену.
При входе в учетный домен с компьютера ресурсного домена также выполняется транзитная аутентификация. Пользователь в многодоменной сети полностью идентифицируется в сети составным именем в форме имя_домена\имя_пользователя.
Транзитная аутентификация происходит в двух случаях:
Транзитная аутентификация выполняется в следующей последовательности:
Существует только один основной контроллер домена (PDC). Он управляет главной копией учетной базы данных домена, которая автоматически реплицируется на резервные контроллеры домена (BDC). Иногда может возникнуть потребность в повышении статуса резервного контроллера домена до основного, например, при проведении профилактических работ на первичном контроллере домена. Если PDC находится в рабочем состоянии, то он может поменяться ролями с BDC. Повышение статуса BDC до PDC приведет к тому, что статус PDC автоматически понизится до BDC.
Если же PDC отключен, то BDC также можно повысить до статуса PDC, но все последние изменения в его базе будут утеряны.
Синхронизация заключается в копировании новой информации о пользователях, группах и паролях с PDC на заданный BDC. Можно синхронизировать контроллеры двумя способами:
Синхронизация с основным контроллером домена может быть необходима, когда администратор производит изменения в его учетной базе данных и хочет немедленно проверить их последствия без задержки во времени, связанной с периодичностью репликации.
Полная синхронизация учетной базы данных не является необходимой, если PDC и BDC работают на основе Windows NT Server. Это происходит потому, что PDC отслеживает уровень синхронизации для каждого BDC, что позволяет PDC управлять интенсивностью процесса частичной синхронизации. PDC посылает сообщение об изменении своей базы данных только тому BDC, который нуждается в изменениях, вместо того, чтобы синхронизировать все BDC. В каждом цикле репликации сообщения посылаются некоторому подмножеству BDC домена, что предотвращает одновременные ответы сразу от всех BDC. Это уменьшает пиковые значения сетевого трафика и загрузки PDC.
Параметры репликации: период репликации (по умолчанию - 5 минут), количество одновременно реплицируемых BDC (по умолчанию - 20), максимальное значение периода репликации и некоторые другие параметры. Все они хранятся в базе Registry.
Механизм доменов можно использовать на предприятии различными способами. В зависимости от специфики предприятия можно объединить ресурсы и пользователей в различное количество доменов, а также по-разному установить между ними доверительные отношения.
Microsoft предлагает использовать четыре типовые модели использования доменов на предприятии:
6.4.1. Модель с одним доменом
Эта модель подходит для организации, в которой имеется не очень много пользователей, и нет необходимости разделять ресурсы сети по организационным подразделениям. Главный ограничитель для этой модели - производительность, которая падает, с увеличением числа серверов в сети.
Преимущества и недостатки модели с одним доменом
| Преимущества | Недостатки |
| Наилучшая модель для предприятий с небольшим числом пользователей и ресурсов.
Централизованное управление пользовательской учетной информацией. Нет нужды в управлении доверительными отношениями. Локальные группы нужно определять только однажды. |
Низкая производительность, если домен имеет слишком много пользователей и/или серверов.
Невозможность группирования ресурсов. |
Использование только одного домена также означает, что один сетевой администратор должен администрировать всю сеть. Разделение сети на несколько доменов позволяет назначать несколько администраторов, каждый из которых может администрировать отдельные серверы, входящие в разные домены.
6.4.2. Модель с главным доменом
Эта модель хорошо подходит для предприятий, где необходимо разбить ресурсы на группы в организационных целях, и в то же время количество пользователей и групп пользователей не очень велико. Эта модель сочетает централизацию администрирования с организационными преимуществами разделения ресурсов между несколькими доменами.
Рис. 6.2. Модель с главным доменом
Главный домен удобно рассматривать как чисто учетный домен, основное назначение которого - хранение и обработка пользовательских учетных данных. Остальные домены в сети - это домены ресурсов, они не хранят и не обрабатывают пользовательскую учетную информацию, а поставляют ресурсы (такие как разделяемые файлы и принтеры) для всей сети. В этой модели пользовательскую учетную информацию хранят только основной и резервный контроллеры главного домена.
Преимущества и недостатки модели с главным доменом
| Преимущества | Недостатки |
| Наилучшая модель для предприятия, у которого не очень много пользователей, а разделяемые ресурсы должны быть распределены по группам.
Учетная информация может централизованно управляться. Ресурсы логически группируются. Домены отделов могут иметь своих администраторов, которые управляют ресурсами отдела. Глобальные группы должны определяться только один раз (в главном домене). |
Плохая производительность, если в главном домене слишком много пользователей и групп.
Локальные группы нужно образовывать в каждом домене, где они используются. |
6.4.3. Модель с несколькими главными доменами
Эта модель предназначена для больших предприятий, которые хотят поддерживать централизованное администрирование. Эта модель в наибольшей степени масштабируема.
В данной модели имеется небольшое число главных доменов. Главные домены используются как учетные домены, причем учетная информация каждого пользователя создается только в одном из главных доменов. Сотрудники отдела Автоматизированных Информационных Систем (АИС) предприятия могут администрировать все главные домены, в то время как ресурсные домены могут администрировать сотрудники соответствующих отделов.
Каждый главный домен доверяет всем остальным главным доменам. Каждый домен отдела доверяет всем главным доменам, но доменам отделов нет необходимости доверять друг другу.
Рис. 6.3. Модель с несколькими главными доменами
Так как все ресурсные домены доверяют всем главным, то данные о любом пользователе могут использоваться в любом отделе предприятия.
Использование глобальных групп в этой модели несколько сложнее, чем в предыдущих. Если нужно образовать глобальную группу из пользователей, учетная информация о которых хранится в разных главных доменах, то фактически приходится образовывать несколько глобальных групп - по одной в каждом главном домене. В модели с одним главным доменом нужно образовать только одну глобальную группу.
Чтобы упростить решение этой проблемы, целесообразно распределять пользователей по главным доменам по организационному принципу, а не по какому-либо иному, например, по алфавитному.
Преимущества и недостатки модели с несколькими главными доменами
| Преимущества | Недостатки |
| Наилучшая модель для предприятия с большим числом пользователей и центральным отделом АИС.
Хорошо масштабируется. Ресурсы логически группируются. Домены отделов могут иметь своих администраторов, которые управляют ресурсами отдела. |
Как локальные, так и глобальные группы должны определяться по несколько раз в каждом учетном домене.
Необходимо управлять большим количеством доверительных отношений. В одном домене локализуются не все данные о пользователях. |
6.4.4. Модель с полными доверительными отношениями
Эта модель обеспечивает распределенное администрирование пользователей и доменов. В этой модели каждый домен доверяет каждому. Каждый отдел может управлять своим доменом, определяя своих пользователей и глобальные группы пользователей, и они могут использоваться во всех доменах предприятия.
Рис. 6.4. Модель с полными доверительными отношениями
Из-за резкого увеличения числа доверительных отношений эта модель не подходит для больших предприятий. Для n доменов нужно установить n(n-1) доверительных отношений.
Перед созданием доверительных отношений с другим доменом администратор действительно должен быть уверен, что он доверяет администратору этого домена. Администратор доверяющего домена должен отдавать себе отчет в том, что после того, как он предоставляет права глобальным группам учетного (доверяющего) домена, администратор последнего может добавить в глобальную группу нежелательных или непроверенных пользователей. При администрировании главных доменов такая опасность также имеется. Но риск здесь ниже из-за того, что пользователей в главные домены добавляют сотрудники центрального отдела АИС, а не произвольно назначенный администратором сотрудник производственного отдела предприятия.
Преимущества и недостатки модели с полными доверительными отношениями
| Преимущества | Недостатки |
| Наилучшим образом подходит для предприятий, на которых нет централизованного отдела АИС
Хорошо масштабируется в отношении количества пользователей. Каждый отдел имеет полное управление над своими пользователями и ресурсами. Как ресурсы, так и пользователи группируются по отделам. |
Модель не подходит для предприятий с централизованным отделом АИС.
Нужно управлять очень большим количеством доверительных отношений. Каждый отдел должен доверять администраторам других отделов том, что те не включат в состав своих глобальных групп нежелательных пользователей. |
6.5.1. Установление доверительных отношений между доменами
Цель работы: ознакомится с процедурой установления доверительных отношений между доменами.
Упражнение 1. Еще до установления доверительных отношений проверьте права пользователей ( с помощью Network Neighborhood) и администраторов (с помощью Server Manager и User Manager for Domains) по отношению:
При проверке пользователь должен просматривать имеющиеся разделяемые ресурсы (компьютеры и share) и иметь возможность к ним подключаться.
Администратор должен проверить свои возможности по созданию новых пользователей, а также созданию новых разделяемых каталогов и контролю за их использованием.
Упражнение 2. Установить доверительные отношения между доменами:
Пусть домен А нужно сделать ресурсным (trusting), а домен B - учетным (trusted).
Для этого:
В результате установлены односторонние доверительные отношения, в которых домен А является доверяющим (ресурсным), а домен В - доверяемым (учетным).
6.5.2. Тестирование возможностей пользователей в сети с доверительными отношениями
Для того, чтобы убедиться, что пользователи учетного домена В имеют доступ к ресурсам доверяющего домена А, выполните следующие действия:
Проведите эксперименты, по результатам которых определите правильность следующих утверждений:
Назад | Содержание | Вперед