3-2 Основи планування та адміністрування служб доступу до інформаційних ресурсів / ЛБ / Книга Active directory

маркеров, списков контроля доступа ACL (Access Control List) и атрибута sIDHistory.

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

(Access Control Entries) связывают конкретное разрешение с S I D - и д е н т и ф и - катором принципала безопасности. Элементы АСЕ т а к ж е могут разрешать и запрещать права доступа.

Когда пользователь пытается получить доступ к ресурсу, локальная подсистема авторизации LSASS (Local Security Authority Subsystem) сравнивает SID-идентификаторы в маркере пользователя с SID - идентификаторами в элементах разрешений АСЕ в списке контроля доступа (ACL) к ресурсу.

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

^ Занятие 2 Управление множеством доменов и доверительными связями 5 7 9

П ри желании атрибут sIDHistory можно загрузить вместе с SID-идентифи- катором учетной записи в начальном домене. Когда пользователь входит в домен Active Directory, маркер пользователя заполняется SID-иденти- фикатором принципала, а также значениями атрибута sIDHistory учетной записи пользователя и групп, которым принадлежит пользователь. Подсистема авторизации LSASS использует SID-идентификаторы из атрибута sIDHistory аналогично всем остальным S ID-идентификаторам в маркере для поддержки доступа пользователя к ресурсам в начальном домене.

с с ы л а ю щ и й с я на учетную запись в начальном домене идентифицируется и заменяется SID - идентификатором в конечном домене. Процесс повторного сопоставления списков ACL (и других элементов в дескрипторе безопасности) с м и г р и р о в а в ш и м и учетными записями в конечном домене также называется по - английски re-ACLing. Преобразование безопасности (re - ACLing) вручную представляет собой утомительный процесс даже в простой среде. Такие инструменты миграции, как ADMT, автоматизируют преобразование безопасности. Инструмент A D M T может преобразовать дескрипторы безопасности и политики ресурсов в начальном домене для ссылки на соответствующие учетные записи в конечном домене. В частности, утилита A D M T может преобразовать:

•разрешения ф а й л о в и папок;

•разрешения принтеров;

•разрешения общего доступа;

•разрешения реестра;

•права пользователей;

•локальные п р о ф и л и с изменением разрешений доступа к файлам, папкам и реестру;

•членство в группах.

Вбольшинстве проектов реструктуризации и миграции доменов для поддержки доступа и функциональности во время миграции используется атрибут

sIDHistory, а затем выполняется преобразование безопасности.

Подробная информация о миграции доменов, SID-идентификаторов и атрибуте sIDHistory содержится в статье -«Domain Migration Cookbook» по адресу http://techneL microsoft.com/en-us/library/bb727135.aspx.

Членство в группах

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

5 80 Домены и леса

Глава 12

Для решения этого вопроса в процессе миграции между лесами вначале нужно выполнить миграцию глобальных групп в конечный домен. Эти глобальные группы будут поддерживать S I D - и д е н т и ф и к а т о р ы начальных групп в" своих атрибутах sIDHistory, поддерживая таким образом доступ к ресурсам. Затем выполняется миграция пользователей. П р и м и г р а ц и и пользователей утилита ADMT оценивает членство начальной учетной записи и добавляет новую учетную запись в ту же группу в конечном домене. Если группа еще не существует в конечном домене, утилита A D M T может создать ее автоматически. После миграции учетная запись пользователя в конечном домене будет принадлежать глобальным группам в конечном домене. Пользователь и группы пользователя будут содержать S I D - и д е н т и ф и к а т о р ы начальных учетных записей в своих атрибутах sIDHistory. Поэтому пользователь сможет получать доступ к ресурсам в начальном домене с разрешениями доступа для начальных учетных записей.

В миграции внутри леса процесс выполняется по-другому. Глобальная группа создается в конечном домене как универсальная группа и может содержать пользователей из начального и конечного доменов. Эта новая группа получает новый SID-идентификатор, однако ее атрибут sIDHistory заполняется SID - идентификатором глобальной группы в начальном домене, в результате чего

глобальная облачъ действия вместо универсальной.

Другие проблемы миграции

Впроцессе планирования и выполнения миграции объектов между доменами

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

СОВЕТ К ЭКЗАМЕНУ

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

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

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

• Т р а н з и т и в н о с т ь О д н и доверительные связи являются транзитивными, другие — нет. На рис. 12-6 домен А доверяет домену Б, а домен Б доверяет домену В. Если эти доверия являются транзитивными, то домен А будет доверять домену В. Если же доверие не является транзитивным то домен А не будет доверять домену В. В большинстве случаев можно создать третью доверительную связь, указывающую доверие домена А к домену В. При использовании транзитивного доверия третья доверительная связь становится лишней, поскольку она подразумевается по умолчанию.

Рис. 12-6. Пример доверительной связи

•Н а п р а в л е н и е Доверительная связь может быть односторонней и двухсторонней. В одностороннем доверии (см. рис. 12-5) пользователи в дове-

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

• Создание автоматически или вручную Доверительные связи создаются как автоматически, так и вручную.

Внутри леса все домены доверяют друг другу. Причина заключается в том, что корневой домен каждого дерева в лесу доверяет корневому домену леса

5 84 Домены и леса

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

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

Протоколы проверки подлинности и доверительные связи

Проверка подлинности пользователей Active Directory в Windows Server 2008 выполняется одним из двух протоколов — Kerberos v5 и л и NT LAN Manager (NTLM). Протокол Kerberos v5 по умолчанию используется компьютерами Windows Server 2008, Windows Vista, Windows Server 2003, W i n d o w s ХР и Windows 2000 Server. Если компьютер, участвующий в транзакции проверки подлинности, не поддерживает Kerberos v5, вместо него применяется протокол NTLM.

Проверка подлинности Kerberos внутри домена

Когда пользователь входит на клиентский компьютер, использующий протокол Kerberos v5, на контроллер домена отправляется запрос проверки подлинности. Каждый контроллер домена Active Directory выполняет роль центра распределения ключей KDC (Key Distribution Center), являющегося ядром Kerberos. После подтверждения подлинности пользователя центр K D C на контроллере домена выдает прошедшему проверку пользователю так называемый билет на получение билетов TGT (Ticket-Granting Ticket).

Когда пользователю нужен доступ к ресурсам на компьютере в том же до- | мене, то вначале он должен получить подлинный сеансовый билет для компьютера. Сеансовые билеты выдаются центром K D C контроллера домена, так что пользователь возвращается к контроллеру домена и делает запрос, представляя билет TGT в подтверждение того, что он уже прошел проверку подлинности. Поэтому центр KDC отвечает на запрос сеансового билета без повторной проверки подлинности объекта идентификации пользователя. Пользовательский запрос сеансового билета указывает компьютер и службу, к которой требуется доступ. Центр KDC идентифицирует расположение службы в том же домене на основе имени участника службы SPN (Service Principal Name) запрашиваемого сервера, а затем выдает пользователю сеансовый билет для нее.

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

Путь доверия используется в проверке подлинности Kerberos д л я предоставления пользователю в одном домене сеансового билета доступа к службе в другом домене. Если пользователю в домене usa.wingtiptoys.com требуется доступ к общей папке на сервере в домене europe.tailspintoys.com, выполняется следующая транзакция.

1.Пользователь входит на компьютер в домене usa.wingtiptoys.com и проходит проверку подлинности на контроллере в домене usa.wingtiptoys.com с помощью процесса проверки подлинности, описанного в предыдущем разделе. Пользователь получает билет T G T для контроллера в домене usaiwingtiptoys.com. Пользователю требуется подключиться к общей папке на сервере в домене europe.tailspintoys.com.

2. Пользователь связывается с центром K D C к о н т р о л л е р а в д о м е н е usa. wingtiptoys.com для запроса сеансового билета сервера в домене europe. tailspintoys.com.

3. Контроллер в домене usa.wingtiptoys.com на основе имени участника службы SPN определяет, что требуемая служба расположена в домене europe. tailspintoys.com, а не в локальном домене.

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

Чтобы определить следующий шаг, центр K D C использует простой алгоритм. Если домен службы доверяет непосредственно домену K D C , центр KDC выдаст клиенту реферрал на контроллер в домене службы. Если эти домены не являются непосредственными участниками доверия, но между KDC и доменом службы установлено транзитивное доверие, центр K D C выдаст клиенту реферрал на следующий домен в пути доверия .

4.Домены usa.wingtiptoys.com и europe.tailspintoys.com не являются непосредственными участниками доверия, однако между ними существует транзитивная связь, поэтому центр K D C в домене usa.wingtiptoys.com выдает клиенту реферрал на контроллер в следующем домене wingtiptoys.com на пути доверия.

5. Клиент связывается с центром K D C в домене реферрала wingtiptoys.com.

6. Опять-таки, центр KDC определяет, что запрашиваемая служба расположена не в локальном домене, а домены europe.tailspintoys.com и wingtiptoys. com не являются непосредственными участниками доверия. Поэтому центр KDC возвращает реферрал на контроллер в следующем домене tailspintoys. com на пути доверия.

7. Клиент связывается с центром K D C в домене реферрала tailspintoys.com.

8.Центр KDC определяет, что запрашиваемая служба расположена не в локальном домене, а домены europe.tailspintoys.com и tailspintoys.com являются непосредственными участниками доверия. Поэтому он возвращает реферрал на контроллер в домене europe.tailspintoys.com.

9. Клиент связывается с центром K D C в домене реферрала europe.tailspintoys. com.

10.Центр K D C в домене europe.tailspintoys.com возвращает клиенту сеансовый билет доступа к службе.

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

Этот процесс может показаться довольно сложным, однако он управляется в режиме, полностью прозрачном для пользователя.

Если п о л ь з о в а т е л ь из домена usa.wingtiptoys.com входит на компьютер в домене europe.tailspintoys.com, выполняется обратный процесс. Начальный запрос проверки подлинности пользователя должен пройти путь доверия до центра K D C в домене usa.wingtiptoys.com.

Хотя д л я сдачи сертификационного экзамена 7 0 - 6 4 0 не нужно быть специалистом в области проверки подлинности Kerberos между доменами в лесу, эти знания помогут определять путь доверия в лесу при проверке подлинности между доменами.

Доверительные связи, создаваемые вручную

Вручную создаются такие доверительные связи:

•прямые доверительные отношения;

•внешние доверительные отношения;

•доверительные связи сферы;

•доверительные связи леса.

Все они описаны в следующих подразделах.

Создание доверительных связей вручную

Связи создаются примерно одинаковым способом; при этом необходимо быть членом группы Администраторы домена (Domain Admins) или Администраторы предприятия (Enterprise Admins).

1.Откройте оснастку Active Directory — домены и доверие (Active Directory Domains And Trusts).

2. Щелкните правой кнопкой мыши домен, который будет участником в доверительной связи, и выполните команду Свойства (Properties). Оснастку Active Directory — домены и доверие следует запустить от имени учетной записи с разрешением на создание доверия в этом домене.

3. Перейдите на вкладку Доверия (Trusts).

4. Щелкните кнопку Создать доверие (New Trust).

Мастер создания отношения доверия (New Trust Wizard) поможет создать доверительную связь.

5. На странице И м я доверия (Trust Name) введите DNS-имя другого домена в доверительной связи и щелкните Далее (Next).