Книги, научные публикации
Pages: | 1 | ... | 3 | 4 | 5 | 6 | 7 | ... | 8 | С. Реймер, М. Малкер Active Directory для Windows Server 2003. Справочник администратора/Пер, с англ. Ч М.: СП ЭКОМ, 2004.Ч 512 с: ил. ...
-- [ Страница 5 ] --4. Раскройте пункт Default DomainControllers Policy\Computer Conf iguration\ Windows Settings\Security Settings\Local Policies\ Audit Policy (Заданная по умолчанию политика контроллеров домена\Кон-фигурация компьютера\Параметры настройки Windows\ Параметры настройки защиты\Локальные политики\Политика аудита), дважды щелкните на Audit Account Management (Управление аудитом учетных записей), а затем выберите обе опции: Success (Успех) и Failure (Отказ).
5. Вызовите принудительную репликацию этого изменения на все контроллеры домена в домене или подождите, пока изменения будут реп-лицированы автоматически.
Чтобы разрешить аудит в исходном домене Windows NT 4, выполните следующие действия.
Откройте инструмент администрирования User Manager For Domains (Менеджер пользователей для доменов), выберите Policies (Политики), а затем выберите Audit (Аудит).
Проверьте, что опция Audit These Events (Проводить аудит этих событий) выбрана и что для User And Group Management (Управление пользователями и группами) выбраны опции Success (Успех) и Failure (Отказ). Кроме того, нужно создать новую локальную группу на исходном контроллере домена для целей внутреннего аудита ADMT. Имя этой новой группы Ч sourcedomainname$$$ (например, Contoso$$$). ADMT создаст группу автоматически при первом запуске, если вы не создадите ее заранее.
Изменение анонимного доступа к целевому домену Если вы не выберете опцию Permissions Compatible With Pre-Windows 2000 Server Operating Systems (Разрешения, совместимые с операционными системами, предшествующими Windows 2000 Server ), при установке Active Directory можно добавить группу Everyone (Все) к группе Pre Windows 2000 Compatible Access (Доступ, совместимый с операционными системами, предшествующими Windows 2000), напечатав net localgrowp "Pre-Windows 2000 Compatible Access" everyone /add в командной строке и нажав Enter.
После того как сделано изменение группового членства, нужна гарантия, что разрешения группы Everyone (Все) применяются к анонимным пользователям. Откройте инструмент Active Directory Users And Computers (Пользователи и компьютеры Active Directory), щелкните правой кнопкой мыши на контейнере Domain Controllers (Контроллеры домена) и выберите Properties (Свойства).
На вкладке Group Policy (Групповая политика) отредактируйте объект Default Domain Controllers Policy (Заданная по умолчанию групповая политика). В поле Group Policy Object Editor (Редактор объектов групповой политики) раскройте опцию Default Domain Controllers Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options (Заданная по умолчанию политика контроллеров домена\Конфигурация компьюте-ра\Параметры настройки Windows\Параметры настройки защиты\Ло-кальные политики\Опции защиты) и дважды щелкните на Network Access: Let Everyone Permissions Apply To Anonymous Users (Сетевой доступ:
Разрешения группы Все применять к анонимным пользователям). Отметьте опцию Define This Policy Setting (Определить настройки этой политики), выберите Enabled (Разрешено), а затем щелкните на ОК.
Перемещение доменов учетных записей Домен учетных записей Windows NT 4 содержит учетные записи пользователей и групп, которые обращаются к сетевым ресурсам. Согласно сценарию перехода путем реструктуризацией домена вы будете перемещать объекты службы каталога в доменах учетных записей перед перемещением доменов ресурсов. Этот порядок операций предпочтителен, потому что при этом сохраняется доступ к ресурсам в процессе перехода.
Чтобы переместить домен учетных записей, выполните следующие действия.
Установите доверительные отношения между целевым доменом Windows Server 2003 и доменом ресурсов Windows NT 4.
Переместите учетные записи глобальной группы.
Переместите учетные записи пользователей (с паролями или без).
Это лучшая практика для перемещения домена учетных записей.
Установление доверительных отношений Чтобы сохранить доступ к ресурсам для пользователей, нужно создать односторонние доверительные отношения от каждого домена Windows NT 4, содержащего ресурсы, к которым должны обращаться перемещенные пользователи, к целевому домену Windows Server 2003.
Создание доверительных отношений состоит из двух шагов.
Первый шаг выполняется на контроллере целевого домена с Windows Server 2003. Добавьте каждый домен ресурсов с системой Windows NT 4 к списку Domains That Trust This Domain (Домены, которые доверяют этому домену) в окне Properties (Свойства) целевого домена, используя инструмент Active Directory Domains And Trusts. Чтобы защитить эти доверительные отношения, создайте пароль, который потребуется при формировании второй половины доверительных отношений.
Второй шаг выполняется на PDC домена ресурсов с системой Windows NT 4. С помощью User Manager For Domains (Менеджер пользователей для доменов) добавьте целевой домен Windows Server 2003 к разделу Trusted Domains (Доверенные домены). Чтобы выполнить эту задачу, вам потребуется пароль, созданный на первом шаге. Будет получено сообщение о статусе, если доверительные отношения успешно создадутся.
Перемещение учетных записей глобальных групп Порядок операций при перемещении учетных записей следующий: сначала глобальные группы, а затем пользователи. Такой порядок позволяет сохранить групповое членство, когда учетные записи пользователя перемещаются в целевой домен позже, и доступ к ресурсам. Когда вы перемещаете глобальные группы с Windows NT 4 на Windows Server 2003, создаются новые идентификаторы SID для новой глобальной группы. SID исходного домена добавляется к атрибуту SID-History для каждого объек та новой группы. Сохраняя SID исходного домена в поле SID-History, пользователи могут продолжать обращаться к ресурсам, расположенным в домене ресурсов с Windows NT, которые еще не перемещены.
Клонируя учетные записи глобальных групп (используя ADMT), вы создадите структуру скелетной группы в целевом домене согласно вашему проекту Active Directory. Поскольку учетные записи пользователя переместятся позже, они будут автоматически присоединены к группе, членами которой они были в исходном домене.
Процесс перемещения глобальных групп с Windows NT 4 на Windows Server 2003 при помощи Group Account Migration Wizard (Мастер модернизации учетных записей групп) инструмента ADMT несложен.
Чтобы перенести глобальные группы с Windows NT 4 на Windows Server 2003 с помощью Group Account Migration Wizard, выполните следующие действия.
1. Идентифицируйте исходные и целевые домены. Если имена доменов не появляются в раскрывающемся списке, их можно напечатать.
2. Выберите глобальные группы Windows NT 4, которые вы хотите переместить на Windows Server 2003.
3. Выберите OU, к которой вы хотите добавить глобальные группы в целевом домене.
Примечание. Инструмент ADMT дает возможность выбрать только одну OU в качестве контейнера адресата для перенесения учетных записей глобальных групп. Имейте это в виду, планируя модернизацию ваших глобальных групп. Вместо выбора всех исходных глобальных групп можно выбрать все группы, которые будут перемещаться в определенную OU. Затем повторно выполняется мастер перемещения учетных записей групп для перемещения групп, которые должны быть сохранены в другой OU.
4. Выберите желательные опции для группы. Сюда входят опция, позво-ляющаю копировать членов группы одновременно с копированием группы. По умолчанию члены группы не должны копироваться вместе с группой. Копирование членов группы одновременно с модернизацией группы является хорошим выбором для маленьких организаций, в этом случае перемещение группами - приемлемый многоступенчатый подход. В больших организациях глобальные группы высшего уровня (типа служащих) имеют слишком большое количество пользователей, чтобы их можно было переместить одновременно.
Как только глобальные группы перемещаются в Windows Server 2003, приходит время перемещения учетных записей пользователя.
Перемещение учетных записей пользователя Перемещение учетных записей пользователей не делается за один раз. Было бы неплохо тщательно спланировать порядок этого перемещения и согласование во времени. Поскольку в процессе перехода будет сохраняться доступ к ресурсам, связанным с Windows NT 4, этот процесс можно растянуть на дни, недели или месяцы. При перемещении учетных записей пользователя следует иметь в виду следующее.
Сколько новых пользователей сможет поддерживать одновременно ваша ГГ-группа?
Какой набор пользователей должен перемещаться вместе?
Какой набор пользователей не сможет за определенное время приспособиться к неудобствам реструктуризации домена?
Этими соображениями нужно руководствоваться при определении порядка и согласования во времени процесса модернизации учетных записей пользователей. На первом шаге выбираются пользователи, которые будут перемещаться одновременно, и время выполнения модернизации.
Фактическое перемещение учетных записей пользователя процедурно очень похоже на перемещение учетных записей глобальных групп.
Чтобы переместить учетные записи пользователя с Windows NT 4 на Windows Server 2003 и в Active Directory с помощью User Account Migration Wizard инструмента ADMT, выполните следующие действия.
1. Выберите исходные и целевые домены.
2. Выберите учетные записи пользователей в Windows NT 4, которые вы хотите переместить.
3. Выберите OU-адресата в целевом домене.
4. Подтвердите, что вы на самом деле хотите переместить пароли учетных записей пользователей.
Используя ADMT, вы можете выбрать одно из следующих действий.
Х Создание новых, сложных паролей. Создается текстовый документ (формат значений, отделенных запятой, [.csv]), который устанавливает соответствие между пользователями и новыми паролями, затем решается задача связывания паролей с мигрированными пользователями.
Х Установление пароля, совпадающего с именем пользователя. Пароль устанавливается на значение username (имя пользователя). Поскольку эта опция и описанная выше создают риск для безопасности, то для перемещенного пользователя в целевом домене устанавливается атрибут User Must Change Password At Next Logon (Пользователь должен изменить пароль при следующем входе в систему).
Х Перемещение паролей. Эта опция позволяет переместить пользовательские пароли с исходного домена в целевой домен, для чего требуется идентификация исходного контроллера домена перемещаемых паролей.
Дополнительная информация. Исходным контроллером домена перемещаемых паролей является контроллер домена в исходном домене, который сконфигурирован как Password Export Server (Сервер экспорта паролей) (PES) путем установки DLL для модернизации паролей. Модернизация паролей - это отдельный компонент ADMT, его можно установить на любом контроллере домена (рекомендуется на BDC) в исходном домене с компакт-диска Windows Server 2003. Чтобы установить DLL для модернизации паролей на контроллере домена с Windows NT 4, откройте папку \I386\ADMT\PWDMIG и дважды щелкните на файле Pwdmig.msi. Сервер PES обслуживает базу данных паролей пользователей исходного домена и создает безопасный канал связи с целевым доменом для перемещения этих паролей. Для получения дополнительной информации об установке и использовании функции перемещения паролей смотрите документ Readme.doc в папке \I386\ADMT на компакт-диске Windows Server 2003 или по адресу: windows2000/downloads/tools/admt/default.asp.
5. Управляйте состоянием учетных записей с помощью опции перемещения учетных записей. С помощью инструмента ADMT можно управлять переходом от исходной учетной записи к целевой учетной записи в окне Account Transition Options (Опции перехода учетных записей). Существует возможность управления состоянием учетной записи целевого домена (разрешать, блокировать или уравнять ее с исходной учетной записью) и учетной записи исходного домена (блокировать или разрешить на установленное количество дней).
Наилучшая практика. Обычный сценарий состоит в том, чтобы перемещать партии учетных записей пользователей, но не активизировать их, пока модернизация не завершится. После завершения модернизации можно программно активизировать все учетные записи пользователя и перейти к целевому домену. Из соображений безопасности лучше не иметь учетных записей, которые активны в исходном и целевом доменах одновременно. Если ваш план состоит в том, чтобы заставить пользователей входить на домен Windows Server 2003 сразу после перехода, используйте инструмент ADMT, чтобы отключить учетную запись исходного домена в процессе перехода. Если вы хотите позволить пользователям иметь доступ к домену Windows NT 4 в процессе перехода, используйте ADMT, чтобы отключить исходный домен через несколько дней после запуска ADMT.
Прекращение эксплуатации домена учетных записей Заключительный шаг в модернизации домена учетных записей к Windows Server 2003 состоит в прекращении эксплуатации исходного домена, которое производится после проверки того, что учетные записи нужных пользователей и групп перемещены к Windows Server 2003, а сетевые службы работают в чистом лесу. Чтобы прекратить эксплуатацию домена учетных записей, контроллеры домена просто выключают. Спустя некоторое время (в течение которого монитор отслеживает любые перерывы в доступе к сети или ресурсам) контроллеры домена или модернизируются до Windows Server 2003, или на них заново устанавливается операционная система Windows Server 2003, а они назначаются контроллерами домена или остаются в роли серверов-членов домена.
Наилучшая практика. Рекомендуется не прекращать эксплуатацию домена учетных записей с системой Windows NT 4 до перемещения домена ресурсов, поскольку совместно используемые локальные группы и локальные группы в доменах ресурсов не смогут разрешать имена своих членов из домена учетных записей.
Вместо этого групповое членство для локальной группы будет отображаться как account unknown (учетная запись неизвестна). Хотя это не влияет на доступ пользователей к ресурсам, важно не удалять входы account unknown, потому что это нарушит доступ к ресурсам, сохраненным с помощью идентификатора SID History. После того как все домены ресурсов будут реструктуризированы, можно прекратить эксплуатацию исходных доменов с Windows NT 4.
Теперь, когда учетные записи глобальных групп и пользователей перемещены, процесс модернизации домена учетных записей завершен. Ваши пользователи входят в домен Windows Server 2003 и легко обращаются к их общедоступным сетевым ресурсам с домена ресурсов Windows NT 4. Благодаря идентификатору SID-History и вашему опыту конечные пользователи не почувствуют, что среда, в которой они работают, является смешанной, и будут работать как обычно. Чтобы завершить проект реструктуризации домена в соответствии с вашим графиком работ, теперь можно перемещать домены ресурсов в Windows Server 2003.
Перемещение доменов ресурсов Чтобы переместить домены ресурсов, необходимо выполнить следующее.
Удовлетворить дополнительные требования защиты.
Идентифицировать учетные записи служб, выполняющихся на серверах-членах домена.
Переместить учетные записи компьютеров (серверы-члены домена и рабочие станции).
Переместить совместно используемые локальные группы.
Переместить учетные записи служб.
Прекратить эксплуатацию всех исходных доменов.
Дополнительные требования защиты Чтобы разрешить перемещение ресурсов Windows NT 4 в Windows Server 2003, выполните действия, связанных с защитой.
1. Удостоверьтесь, что группа Domain Admins (Администраторы домена) целевого домена является членом локальной группы администраторов на домене ресурсов с системой Windows NT 4. Это обеспечит необходимые административные права на каждом сервере члене домена и на каждой рабочей станции в домене ресурсов, чтобы вы могли перемещать ресурсы домена.
2. Создайте второе доверительное отношение от целевого домена к домену ресурсов. В разделе Создание чистого леса этой главы рассказывалось, как это сделать.
Устанавливая второе доверительное отношение, вы создаете два односторонних доверительных отношения между доменом ресурсов и целевым доменом. Используйте оснастку Active Directory Domains And Trusts (Домены и доверительные отношения Active Directory) для проверки того, что это доверительное отношение было установлено.
Идентификация учетных записей служб Учетные записи служб - это специальные учетные записи пользователей, которые используются для оперирования службами, выполняющимися на компьютерах с системами Windows NT 4 и Windows Server 2003. Большинство служб работают под учетной записью Local System Authority (LSA) (Власти локальной системы). При модернизации домена ресурсов сначала нужно идентифицировать службы, сконфигурированные так, чтобы не выполняться под учетной записью LSA.
Модернизация учетных записей служб состоит из двух этапов. Сначала нужно идентифицировать учетные записи служб. После перемещения компьютеров, на которых выполняется система Windows NT 4, в целевой домен с Windows Server 2003 можно переносить учетные записи идентифицированных служб.
Чтобы идентифицировать учетные записи служб, работающих на исходных доменах с Windows NT 4, используя инструмент ADMT, выполните следующие действия:
1. Откройте Service Account Migration Wizard (Мастер модернизации учетных записей).
2. Выберите исходный и целевой домены.
3. В исходном домене выберите все компьютеры, на которых нужно найти учетные записи служб. Чтобы выполнить эту задачу, вы должны посмотреть документацию, касающуюся среды домена, которая существовала до модернизации. 4. Завершите выполнение Service Account Migration Wizard.
Вся информация будет сохранена в базе данных ADMT, пока она не потребуется для фактического перемещения учетных записей. Перемещение учетных записей служб происходит после перемещения учетных записей самих компьютеров.
Перемещение учетных записей компьютеров Учетные записи компьютеров, которые постоянно находятся в домене ресурсов Windows NT 4, включают серверы-члены домена с Windows NT 4 Server, а также компьютеры с Windows NT Workstation 4, Windows 2000 Professional и Windows XP Professional. При модернизации учетных записей будут клонированы все учетные записи компьютеров из исходного домена в OU целевого домена.
Примечание. Вы не сможете переместить учетную запись контроллера домена, потому что нельзя изменить домен, к которому принадлежит контроллер домена с Windows NT 4 без повторной установки операционной системы. Контроллеры домена должны быть переведены в домен Windows Server 2003. Это перевод выполняется путем обновления операционной системы до Windows Server 2003 и последующим назначением компьютера на роль контроллера домена в целевом домене. После обновления операционной системы можно не устанавливать Active Directory, а оставить модернизированный сервер членом домена в целевом домене., Чтобы переместить учетные записи компьютеров с помощью инструмента ADMT, выполните следующие действия.
Откройте Computer Migration Wizard (Мастер модернизации компьютеров).
Выберите исходный и целевой домены.
В исходном домене выберите учетные записи компьютеров, которые нужно перенести.
Выберите в целевом домене организационные единицы OU, в которые нужно перенести учетные записи компьютеров.
Выберите любые компьютерные объекты, для которых нужно переместить защиту учетных записей. При этом обновятся списки разграничительного контроля доступа (DACL) для ресурсов, расположенных на перенесенных компьютерах, новыми идентификаторами SID целевых доменов для учетных записей перемещенных групп и пользователей. Доступны следующие объекты:
Х файлы и папки;
Х локальные группы;
Х принтеры;
Х системный реестр;
Х совместно используемые ресурсы;
Х пользовательские профили;
Х пользовательские права.
Совет. Если вы решите не переводить защиту для перечисленных выше объектов в процессе выполнения Computer Migration Wizard, это можно сделать позже, используя Security Translation Wizard (Мастер перевода защиты) в инструменте ADMT. В состав мастера перевода защиты входит такое же окно Translate Objects (Перевести объекты), как и в мастере модернизации компьютеров. Вначале мастер перевода защиты спрашивает о том, хотите ли вы перевести защиту для перемещенных объектов. Если мастер перевода защиты выполняется после модернизации учетных записей компьютеров, выберите опцию Previously Migrated Objects (Ранее перемещенные объекты).
Установите перезапуск перемещенного компьютера. Чтобы переместить компьютерную учетную запись с одного домена на другой, инструмент ADMT посылает агента, чтобы сделать изменение на самом компьютере. Процесс модернизации компьютерной учетной записи завершается после перезапуска перемещенного компьютера. Инструмент ADMT позволяет задать интервал времени между окончанием работы мастера и перезапуском компьютера.
Выполните Computer Migration Wizard (Мастер модернизации компьютеров). После окончания его работы щелкните на View Dispatch Log (Просмотр журнала отправки), чтобы проверить урпешность работы агента отправки (dispatch agent). Этот компонент обновляет членство компьютера в домене, а затем перезапускает компьютер. Журнал регистрации отправки агента полезен для поиска неисправностей при неудавшейся модернизации учетной записи компьютера.
Перемещение общих локальных групп Общие локальные группы (shared local groups) Ч это просто локальные группы на контроллере домена с Windows NT 4. Они используются для организации прав доступа. Если на вашем предприятии существуют такие группы, то вы должны перенести их на целевой домен для сохранения доступа к ресурсам для перемещенных пользователей. Процесс модернизации общих локальных групп не сильно отличается от процесса модернизации глобальных групп, который был описан выше.
Примечание. Модернизация локальных групп, расположенных на серверах-членах домена или рабочих станциях, не является необходимой. Эти локальные группы используются для предоставления доступа к ресурсам, находящимся на компьютере, и находятся в базе данных SAM на сервере-члене домена или на рабочей станции. Поскольку база данных SAM всегда перемещается с компьютером, то нет необходимости перемещать эти учетные записи. Вы должны перевести защиту для этих локальных групп, чтобы обновить ссылки SID для новых учетных записей домена. Посмотрите описание Computer Migration Wizard, приведенное выше в этой главе, для получения дополнительной информации о переводе защиты в процессе модернизации компьютера.
Чтобы переместить общие локальные группы, используя ADMT, выполните следующие действия.
1. Откройте Group Account Migration Wizard (Мастер модернизации учетных записей групп).
2. Выберите исходные и целевые домены.
3. Выберите общую локальную группу, которую нужно переместить.
4. Выберите организационную единицу OU, в которую нужно переместить учетную запись группы.
5. Обязательно выберите опцию Migrate Group SIDs To Target Domain (Переместить SID группы в целевой домен).
6. Позвольте мастеру перемещения учетной записи группы выполняться до завершения модернизации общих локальных групп в целевой домен.
Перемещение учетных записей служб После перемещения учетных записей компьютера на целевой домен можно завершать вторую стадию процесса перемещения учетных записей служб. В начале процесса модернизации домена ресурсов вы идентифицировали учетные записи служб, которые использовались для оперирования службами серверов-членов домена. Теперь вы будете переносить учетные записи служб домена ресурсов с Windows NT 4 на целевой домен Windows Server 2003. Эта процедура гарантирует, что все службы, не выполняющиеся под LSA, будут запускать требуемые службы после того, как сервер-член домена переместится в целевой домен.
Чтобы переместить учетные записи служб, используя ADMT, выполните следующие действия.
1. Откройте User Account Migration Wizard (Мастер модернизации учетных записей пользователя).
2. Выберите исходные и целевые домены.
3. Выберите учетные записи служб, которые нужно переместить.
1. Совет. Если вы не помните имена учетных записей ранее идентифицированных учетных записей служб, можно просмотреть журнал агентов отправки (Dctlog.txt), который расположен в папке %userprofile %\Temp. Если вы вошли в систему Windows 2. Server 2003 как Migratorl, вы найдете этот файл в папке C:\Documents and Settings\Migratorl\Temp.
3. Выберите организационную единицу OU в целевом домене, в которую нужно перенести учетные записи служб.
4. Генерация сложного пароля будет использоваться для модернизации учетных записей служб. Независимо от того, какую опцию модернизации пароля вы выберете в окне Password Options (Опции пароля), инструмент ADMT будет всегда использовать опцию сложного пароля. ADMT распознает, что учетная запись пользователя, которую вы перемещаете, является учетной записью службы, и предоставит ей право входить в систему в качестве службы.
Примечание. Если учетные записи служб, которые вы переносите, имеют локальные права, унаследованные от членства в локальной группе, например, право log on as a service (входить в качестве службы), имеющееся у членов локальной группы администраторов. Вы должны установить эти права с помощью Security Translation Wizard (Мастер перевода защиты). В окне Translate Objects (Перевод объектов) мастера перевода защиты выберите объекты Local Groups (Локальные группы) и User Rights (Права пользователя) для перемещаемого сервера-члена домена, содержащего локальную группу, через которую эти права были унаследованы. Это тот компьютер, на котором будет происходить перевод защиты.
Прекращение эксплуатации исходных доменов Теперь, когда все домены учетных записей и домены ресурсов были перемещены в Windows Server 2003 и в Active Directory, можно прекратить эксплуатацию исходных доменов Windows NT 4. Ведь единственные компьютеры, оставшиеся в исходных доменах - это контроллеры домена.
Если ваш план перехода требует перемещения этих контроллеров домена в целевой домен Windows Server 2003, можно переместить их. Существует довольно сложный процесс перевода контроллеров домена в автономный режим, их обновления, назначения на роль контролера, отмена этой роли, повторного назначения, чтобы сделать их контроллерами домена в новом домене. Будет лучше, если вы убедитесь, что все необходимые данные перемещены с этих серверов, а затем выполните новую инсталляцию операционной системы Windows Server 2003.
Заключительная задача состоит в том, чтобы удалить все доверительные отношения, которые были созданы для выполнения модернизации. Используя инструмент Active Directory Domains And Trusts, выберите каждое доверительное отношение с более не существующим доменом системы Windows NT 4 и щелкните на кнопке Remove (Удалить).
Обновление с последующей реструктуризацией Третий путь, который мы рассмотрим, Ч обновление с последующей реструктуризацией, или перемещение в пределах леса. Выше говорилось, что в процессе обновления с последующей реструктуризацией контроллеры домена низкого уровня сначала обновляются до Windows Server 2003 (при этом сохраняется первоначальная иерархия домена), а затем происходит реструктуризация домена, при которой объекты службы каталога переносятся с модернизированных исходных доменов в целевой домен (или домены). Вы уже знакомы с задачами, которые необходимо выполнить при модернизации до Active Directory путем обновления с последующей реструктуризацией. Однако, в связи с требованиями защиты Windows Server 2003, вы увидите, что перемещение учетных записей в пределах леса работает иначе, чем в сценарии модернизации между лесами.
Процесс реструктуризации домена после обновления к Windows Server 2003 не обязательно происходит сразу же. Реструктурирование домена может быть проведено, когда вы получите навык управления службой Active Directory, поскольку структура Active Directory может изменяться при изменении вашего бизнеса.
Этот раздел показывает отличия обновления с последующей реструктуризацией от реструктуризации домена, которую вы уже знаете. В этом разделе не обсуждаются инструменты, поскольку технические различия относятся к любому инструменту модернизации домена, который вы выберите.
Модернизация в пределах леса и модернизация между лесами имеют следующие отличия.
Х При модернизации в пределах леса для сохранения доступа к ресурсам, использующим SID-History, учетные записи должны быть перемещены, а не клонированы. Перемещение объектов учетных записей в пределах леса является деструктивным процессом, так как учетные записи пользователей, групп и компьютеров исходного домена удаляются по мере создания новых учетных записей в целевом домене. В результате вы не сможете поддерживать параллельную среду, которая предлагает удобные варианты отступления, которая имеется в сценарии реструктуризации между лесами.
Х При модернизации в пределах леса для поддержки правил группового членства нужно переместить учетные записи пользователей и групп, которым они принадлежат, одновременно. Это называется замкнутым набором (closed set). Этот процесс отличается от модернизации исходного домена Windows NT 4 до целевого домена Windows, в котором учетные записи пользователя и учетные записи группы можно переносить или вместе, или по отдельности. Однако инструмент ADMT не вычисляет полный замкнутый набор, так что нужно очень осторожно перемещать пользователей, которые являются членами глобальных групп. Если вы переносите группу, которая включает учетную запись пользователя, являющуюся членом другой глобальной группы, и если та глобальная группа не является рекурсивно членом какой-либо группы, перемещаемой в это же время, то будет нарушено членство данной учетной записи пользователя в глобальной группе, которая не включена в модернизацию. Другие типы групп (типа универсальных групп) допускают наличие членов, не принадлежащих их собственным доменам.
Конфигурирование доверительных отношений между лесами В качестве альтернативы модернизации между лесами, описанной в предшествующем разделе, можно использовать доверительное отношение между лесами, направленное от одного леса Windows Server 2003 к другому, обособленному, лесу Windows Server 2003, в котором расположены ресурсы, предназначенные для доступа.
Одним из существенных улучшений в Active Directory Windows Server 2003 по сравнению с Windows 2000 является опция создания доверительных отношений между лесами Active Directory.
В Active Directory Windows 2000 можно создавать доверительные отношения только между отдельным доменом в одном лесу и отдельным доменом в другом лесу. В Active Directory Windows Server 2003 можно установить доверительные отношения между корневыми доменами леса. Они могут быть односторонними или двухсторонними доверительными отношениями. После того как доверительные отношения созданы, можно использовать глобальные группы или универсальные группы одного леса для предоставления доступа к ресурсам другого леса.
Примечание. Создание доверительных отношений между двумя лесами допускает только совместное использование ресурсов между лесами. Все другие различия, существующие на уровне леса, сохранятся после создания доверительных отношений. Например, создание доверительных отношений не подразумевает, что леса будут совместно использовать глобальный каталог (GC) или общую схему.
Когда вы создаете доверительные отношения леса в Active Directory, они автоматически допускают маршрутизацию суффикса имени (name suffix routing) между этими лесами. Используя маршрутизацию суффикса имени, пользователи могут использовать свои основные пользовательские имена (UPN) при входе на любой домен любого леса. Например, если вы создаете доверительные отношения леса между лесом NWTraders.com и лесом Contoso.com, пользователи леса Contoso.com могут входить на рабочие станции в лесе NWTraders.com, используя свои UPN alias@contoso.com. Маршрутизация суффикса имени применяется по умолчанию ко всем именам доменов первого уровня, имеющимся в лесу. Это включает заданный по умолчанию UPN-суффикс и любые альтернативные суффиксы, сконфигурированные в лесу.
Маршрутизация суффикса имени не работает между лесами, если один и тот же UPN-суффикс сконфигурирован в обоих лесах. Если UPN-суффикс Contoso.com сконфигурирован в лесе NWTraders.com, пользователи леса Contoso.com не смогут входить в лес NWTraders.com, используя свои UPN.
Когда вы впервые разрешаете доверительные отношения леса, все суффиксы домена первого уровня автоматически направляются на UPN доверительного отношения. Все дочерние суффиксы домена направляются неявно через суффикс родительского домена. Если вы добавляете другой UPN-суффикс к лесу, после того как создано доверительное отношение, вы должны разрешить маршрутизацию суффикса имени для нового суффикса. Вы можете сделать это, проверяя доверительное отношение между доменами или вручную добавляя новый суффикс на вкладку Name Suffix Routing (Маршрутизация суффикса имени) в окне свойств доверительного отношения.
Чтобы создать доверительное отношение леса, лес должен работать на функциональном уровне Windows Server 2003. Только члены группы Enterprise Admins (Администраторы предприятия) имеют разрешение создавать доверительные отношения леса.
Чтобы создать доверительные отношения леса, выполните следующее.
1. Запустите инструмент Active Directory Domains And Trusts. Щелкните правой кнопкой мыши на имени корневого домена леса и выберите Properties (Свойства). Выберите вкладку Trusts (Доверительные отношения).
2. Щелкните на кнопке New Trust (Новое доверительное отношение). Запустится New Trust Wizard (Мастер новых доверительных отношений). Напечатайте имя корневого домена леса в другом лесу.
3. Затем нужно будет выбрать тип доверительных отношений, которые вы хотите установить (см. рис. 7-4). Можно создать внешние доверительные отношения или доверительные отношения леса. Внешние доверительные отношения не являются транзитивными доверительными отношениями, в то время как доверительные отношения леса всегда являются транзитивными. Выберите Forest Trust (Доверительные отношения леса).
4. Выберите направления доверительных отношений (см. рис. 7-5).
Рис. 7-4. Конфигурирование типа доверительных отношений леса Рис. 7-5. Конфигурирование направления доверительных отношений леса 5. Выберите вариант, создавать ли доверительные отношения только для этого домена или также для другого домена. (Эти два домена -корневые домены леса для каждого леса.) Доверительные отношения леса могут быть установлены только между корневыми доменами леса (см. рис. 7-6). Если нужно установить обе стороны доверительных отношений одновременно, впечатайте имя и пароль для учетной записи Enterprise Admins (Администраторы предприятия), которая существует в другом лесу. Если нужно установить доверительные отношения только для этого домена, напечатайте пароль, который будет использоваться для установки начального доверительного отношения.
Затем это пароль должен использоваться для конфигурирования доверительных отношений в корневом домене леса другого леса.
Рис. 7-6. Выбор конфигурирования одной или обеих сторон доверительных отношений 6. Выберите уровень аутентификации, который будет предоставлен для исходящих и входящих доверительных отношений (см. рис. 7-7). Это позволит тщательно контролировать доступ к ресурсам между лесами. Если нужно применить аутентификацию по всему лесу, то пользователи одного леса будут иметь доступ ко всем серверам и ресурсам другого леса. Это такая же конфигурация, как доверительные отношения между доменами в пределах леса. Пользователи из одного домена леса могут обращаться к ресурсам в любом другом домене любого леса при условии, что им дано разрешение на доступ к ресурсу. Можно применять выборочную аутентификацию для доверительных отношений леса. В этом случае вы должны явно дать пользователям или группам из одного леса разрешения на доступ к серверам другого леса. Это можно сделать, предоставляя им права Allowed To Authenticate (Разрешено аутентифицировать) в Active Directory.
7. После конфигурирования доверительных отношений будет выполнена автоматическая проверка доверительных отношений.
Рис. 7-7. Конфигурирование уровня аутентификации для доверительных отношений леса Резюме В этой главе были рассмотрены различные пути перехода от службы каталога Windows NT 4 или Active Directory системы Windows 2000 к Active Directory Windows Server 2003. Были описаны три главных пути перехода: обновление, реструктуризация и обновление с последующей реструктуризацией. Существует несколько критериев, которые можно использовать для определения подходящего пути перехода для вашей организации. Для организаций, которые удовлетворены своей текущей доменной структурой, обновление домена является наименее сложным и опасным средством модернизации службы каталога. Если ваша доменная структура не соответствует организационной модели, вы должны реструктуризировать ваш домен. Независимо от выбранного пути, осторожное планирование, тестирование и пробная реализация вашего плана перехода являются важными условиями для успеха вашего проекта модернизации.
В главе описаны также основные этапы, необходимые при реализации обновления систем Windows NT Server 4 и Windows 2000 Server. Затем показан процесс реструктуризации домена учетных записей и домена ресурсов с системой Windows NT 4 с помощью инструмента ADMT.
Обсуждены отличия пути обновления с последующей реструктуризацией, известного как перемещение в пределах леса, от реструктуризации домена. Заканчивает эту главу обсуждение функции доверительных отношений между лесами, имеющейся в Windows Server 2003.
Часть III. Администрирование службы каталога Active Directory Windows Server В частях I и II этой книги были объяснены концепции и компоненты Active Directory Ч службы каталога Microsoft Windows Server 2003, а также дана информация о том, как проектировать, реализовывать, и развертывать Active Directory. После развертывания Active Directory вы должны управлять ею для обеспечения максимальной выгоды вашей компании. В части III показаны административные процессы, которые вы будете использовать для выполнения этой задачи. Одна иэ основных причин развертывания службы каталога состоит в том, чтобы обеспечить защиту, поэтому глава 8 рассказывает про концепции, лежащие в основе безопасности Active Directory Windows Server 2003. В главе 9 дается описание способов, которыми вы можете делегировать административные разрешения в пределах вашего домена. Глава 10 знакомит вас с управлением объектами службы каталога Active Directory. Одна из наиболее мощных функций в Active Directory - это Group Policy (Групповая политика), которая может применяться для управления тысячами компьютеров, использующих Active Directory. Главы 11, 12 и 13 посвящены групповым политикам, в них объясняется, как использовать эти инструментальные средства, чтобы осуществить распределение программ и управление клиентскими компьютерами.
Глава 8. Защита Active Directory Одна из основных причин развертывания службы каталога Active Directory состоит в обеспечении безопасности корпоративной сети. Каждая компания хранит важнейшую для своего бизнеса информацию на файловых серверах в сети. Управление безопасным доступом к информации должно гарантировать, что доступ к данным получат только должным обраЗЬм уполномоченные пользователи. Почти все компании развертывают почтовые серверы типа Microsoft Exchange Server, и они должны гарантировать пользователям безопасный доступ к почтовым ящикам.
Служба Active Directory Microsoft Windows Server 2003 обеспечивает такой уровень защиты.
Эта глава начинается с введения в основы безопасности Active Directory. Служба каталога Active Directory использует несколько основных концепций для обеспечения безопасности сети Windows Server 2003. После введения в основы защиты будет показан основной компонент этой защиты, состоящий из аутентификации и функций разрешения, который используется в Active Directory для обеспечения гарантии того, что пользователи действительно являются теми, кем они себя представляют (аутентификация), и для обеспечения доступа к тем ресурсам, к которым пользователь должен иметь доступ (разрешение). Система Windows Server 2003, подобно Microsoft Windows 2000, использует Kerberos в качестве основного протокола защиты, поэтому большая часть этой главы посвящена роли Kerberos в аутентификации и разрешениях.
Основы защиты Active Directory Существуют некоторые основные концепции, необходимые для понимания принципов защиты Active Directory в сети Windows Server 2003. Защита Active Directory строится на двух типах объектов и на взаимодействии между ними. Первый объект - участник безопасности, который представляет пользователя, группу, службу или компьютер, который нуждается в доступе к некоторому ресурсу в сети. Второй объект -это сам ресурс, являющийся объектом, к которому нужно получить доступ участнику безопасности. Чтобы обеспечить надлежащий уровень защиты, служба Active Directory должна идентифицировать участников безопасности, а затем предоставлять правильный уровень доступа к ресурсам.
Участники безопасности Только участники безопасности службы Active Directory могут входить в Active Directory и получать разрешения на доступ к ресурсам сети. Участник безопасности - это объект Active Directory, который представляет пользователя, группу, службу или компьютер. Каждому участнику безопасности при создании объекта назначается идентификатор защиты (SID).
Идентификатор SID составлен из двух частей. Первая часть -идентификатор домена, все участники безопасности в домене имеют один и тот же идентификатор домена. Вторая часть идентификатора SID -относительный идентификатор (RID), который является уникальным для каждого участника безопасности в домене Active Directory.
Идентификатор SID является основным компонентом конфигурирования защиты для ресурсов, расположенных в сети Windows Server 2003. При выдаче разрешения на доступ к ресурсу вы используете отображаемое имя участника безопасности, но Windows Server 2003 фактически использует SID для управления доступом к ресурсу. Когда пользователь пытается обратиться к ресурсу, расположенному на сервере в домене, операционная система предоставляет разрешение идентификатору SID пользователя, а не имени человека. Это означает, что если отображаемое имя пользователя изменено, разрешения, представленные пользователю, не изменяются. Однако если пользовательский объект удален, а затем создан заново с тем же самым именем, пользователь не сможет обращаться к ресурсам, так как SID изменится.
Списки управления доступом Еще один компонент, включенный в защиту Active Directory, - это объект, к которому участник безопасности должен обращаться. Этот может быть другой объект Active Directory, например, организационная единица (OU), принтер или участник безопасности. Объект может быть файлом на сервере с системой Windows Server 2003 или почтовым ящиком на сервере с Microsoft Exchange 2000 Server.
Разрешения, которые предоставляются этим объектам, расположены в списке управления доступом (ACL - Access Control List), также называемом дескриптором защиты (security descriptor). Каждый объект в Active Directory или в разделе файловой системы NTFS имеет дескриптор защиты. Дескриптор защиты включает идентификатор SID участника безопасности, который владеет объектом, а также SID для основной группы объекта. Кроме того, каждый объект имеет два отдельных списка ACL: список управления разграничительным доступом (DACL Ч Discretionary Access Control List) и список управления системным доступом (SACL - System Access Control List). Список DACL перечисляет участников безопасности, которым были назначены разрешения на доступ к объекту, а также уровень разрешений, которые были назначены каждому участнику безопасности. Список DACL состоит из записей управления доступом (АСЕ Ч Access Control Entries). Каждая запись АСЕ содержит идентификатор SID и определяет уровень доступа к объекту, который разрешен данному SID. Список АСЕ включает записи для всех типов участников безопасности. Например, учетная запись пользователя может иметь разрешение Read (Чтение) для файла, а группа защиты -разрешение Full Control (Полное управление). Список DACL для файла имеет, по крайней мере, две записи АСЕ, одну - на предоставление пользователю разрешения Read, другую - на предоставление группе разрешения Full Control.
Список SACL перечисляет участников безопасности, чей доступ к ресурсу должен подвергаться аудиту. Список записей АСЕ в SACL указывает, чей доступ должен подвергаться аудиту, а также необходимый уровень аудита.
Примечание. Список DACL может содержать записи АСЕ, которые предоставляют доступ к ресурсу, а также АСЕ, которые запрещают доступ. Записи АСЕ, которые запрещают доступ, всегда перечисляются первыми в ACL, так что подсистема защиты сначала оценивает их. Если АСЕ запрещает доступ к ресурсу, то подсистема защиты не оценивает другие записи АСЕ, т.е.
запись АСЕ, запрещающая доступ к ресурсу, всегда отменяет любую запись АСЕ, которая предоставляет доступ определенному идентификатору SID.
Лексемы доступа Связующей точкой между SID участника безопасности и ACL является лексема доступа. Когда пользователь аутентифицируется через Active Directory, в процессе входа в систему ему назначается лексема доступа. Эта лексема включает основной SID пользователя, идентификаторы SID всех групп, которым принадлежит пользователь, а также права и привилегии пользователя.
Лексема доступа используется подсистемой защиты всякий раз, когда пользователь пытается обратиться к ресурсу. В этом случае лексема предъявляется компьютером клиента любому процессу или приложению, которые запрашивают информацию, касающуюся безопасности, перед получением доступа к ресурсу. Например, когда пользователь пытается обратиться к почтовому ящику сервера, на котором выполняется Exchange 2000 Server, лексема доступа предъявляется серверу. Подсистема защиты Exchange 2000 Server сравнивает идентификаторы SID в лексеме доступа с разрешениями, которые были предоставлены в списке ACL. Пользователь сможет открыть почтовый ящик, если это позволяют разрешения, предоставленные данному идентификатору SID.
Аутентификация Чтобы процессы защиты, включающие использование идентификаторов SID и записей ACL, работали должным образом, должен существовать какой-то способ, которым пользователь получает доступ к сети. По существу, пользователи должны иметь возможность доказать, что они являются теми, кем они себя представляют, чтобы извлечь свою лексему доступа с контроллера домена. Этот процесс называется аутентификацией.
Аутентификация происходит перед входом клиента в систему. Когда пользователь садится за компьютер с системами Windows 2000 или Microsoft Windows XP Professional и вводит Ctrl+Alt+Del, служба Winlogon локального компьютера переключается на экран входа в систему и загружает файл Graphic Identification and Authentication (GINA) (Графическая идентификация и аутентификация) из библиотеки динамической компоновки (DLL). По умолчанию этот файл Ч Msgina.dll. Однако сторонние производители могут создавать альтернативные файлы GINA (например, клиент системы Netware использует файл Nwgina.dll). После того как пользователь впечатал имя пользователя, пароль и выбрал домен, GINA передает введенные верительные грамоты службе Winlogon. Winlogon передает информацию локальной службе безопасности LSA (Local Security Authority). Служба LSA немедленно применяет к паролю пользователя операцию одностороннего кэширования и удаляет понятный текстовый пароль, который пользователь напечатал. Затем вызывается соответствующий провайдер защиты (SSP Ч Security Support Provider) через интерфейс провайдеров защиты (SSPI - Security Support Provider Interface).
Windows Server 2003 обеспечивает двух основных SSP-провайдеров для сетевой аутентификации Ч KerbeVos SSP и NT LAN Manager (NTLM) SSP. Если клиенты с системой Windows 2000, или более поздней, входят в сеть системы Windows 2000 или Windows Server 2003, выбирается SSP Kerberos, и информация передается SSP. Затем SSP связывается с контроллером домена для подтверждения подлинности пользователя. Опознавательный процесс с использованием протокола Kerberos будет описан далее в этой главе.
Если процедура входа в систему прошла успешно, значит, пользователь аутентифицирован, и ему предоставлен доступ к сети. Если пользователь вошел в домен и все ресурсы, к которым пользователю нужно обратиться, находятся в том же самом лесу, то это единственный момент аутентификации пользователя. Пока пользователь не выйдет из системы, все разрешения, которые он получит в сети, будут основаны на начальной аутентификации.
Разрешение Разрешение (authorization) Ч это второй шаг в процессе получения доступа к сетевым ресурсам, он происходит после аутентификации. В про цессе аутентификации вы доказываете свою идентичность, впечатывая правильное имя пользователя и пароль. В процессе разрешения вам дается доступ к сетевым ресурсам. В процессе аутентификации для вас создается лексема доступа. В процессе разрешения вы предъявляете лексему доступа серверу или службе и запрашиваете доступ к ресурсу. Если идентификатор SID в вашей лексеме доступа соответствует идентификатору SID в записи ACL, которая предоставляет доступ, вам предоставляется доступ к ресурсу.
Защита с использованием протокола Kerberos До сих пор в этой главе описывались основы защиты Active Directory без обсуждения фактического механизма, который осуществляет защиту. Основной механизм аутентификации в Active Directory Ч это протокол Kerberos. Протокол Kerberos был впервые разработан инженерами Массачусетского Технологического института (MIT) в конце 80-х годов. Текущая версия Kerberos - это версия 5 (Kerberos v5), которая описана в документе RFC 1510. Реализация Kerberos в Windows Server 2003 полностью совместима с документом RFC-1510 с некоторыми расширениями для аутентификации открытых (public) ключей.
Протокол Kerberos является заданным по умолчанию опознавательным протоколом для Active Directory систем Windows 2000 Windows Server 2003. Всякий раз, когда клиент с системой Windows 2000, или более поздней, подтверждает свою подлинность в Active Directory, он использует протокол Kerberos. Другой протокол, использующийся для подтверждения подлинности в Active Directory, - это NTLM, который поддерживается для обратной совместимости с клиентами, пользующимися более старыми версиями операционных систем.
Протокол Kerberos имеет множество преимуществ по сравнению с NTLM.
Х Взаимная аутентификация. При использовании протокола NTLM аутентификация происходит только в одном направлении, т.е. сервер подтверждает подлинность клиента.
При использовании протокола Kerberos клиент может также подтверждать подлинность сервера, гарантируя, что сервер, который отвечает на запрос клиента, является правильным сервером.
Х Более эффективный доступ к ресурсам. Когда пользователь обращается к сетевому ресурсу в сети, использующему протокол NTLM (например, Microsoft Windows NT 4), то сервер, на котором расположен ресурс, должен контактировать с контроллером домена для проверки разрешения на доступ данного пользователя. В сети, использующей Kerberos, клиент соединяется с контроллером домена и получает билет на сетевое соединение, чтобы получить доступ к серверу ресурса. Это означает, что сервер ресурса не должен соединяться с контроллером домена.
Х Улучшенное управление доверительными отношениями. Доверительные отношения NTLM всегда односторонние, не транзитивные, они конфигурируются вручную.
Доверительные отношения Kerberos конфигурируются автоматически, поддерживаются между всеми доменами леса и являются транзитивными и двусторонними. Кроме того, доверительные отношения Kerberos могут быть сконфигурированы между лесами и доменами Kerberos Windows Server 2003 и другими реализациями протокола Kerberos.
Х Делегированная аутентификация. Когда клиент подключается к серверу, используя аутентификацию NTLM, сервер может использовать сертификаты клиента для доступа к ресурсам, расположенным только на локальном сервере. С аутентификацией Kerberos сервер может использовать сертификаты клиента для доступа к ресурсам, расположенным на другом сервере.
Примечание. Windows Server 2003 поддерживает аутентификацию через протокол SSL/TLS (Secure Sockets Layer/Transport Layer Security Ч Защищенные сокеты/Защита транспортного уровня), аутентификацию Digest и аутентификацию Passport. Так как эти службы используются в среде интернета для аутентификации служб информационного интернет-сервера от Microsoft (IIS - Internet Information Services) версии 6.0, то эти опознавательные опции обсуждаться не будут.
Введение в протокол Kerberos В системе, основанной на протоколе Kerberos, имеется три компонента. Во-первых, клиент, который должен получить доступ к сетевом ресурсам. Во-вторых, сервер, который управляет сетевыми ресурсами и гарантирует, что только должным образом заверенные и уполномоченные пользователи могут получать доступ к ресурсу. Третий компонент Ч центр распределения ключей (KDC - Key Distribution Center), который служит центральным местом хранения пользовательской информации и главной службой, подтверждающей подлинность пользователей.
Протокол Kerberos определяет то, как эти три компонента взаимодействуют между собой. Это взаимодействие основано на двух ключевых принципах. Прежде всего, Kerberos работает, основываясь на предположении, что опознавательный трафик между рабочей станцией и сервером пересекает незащищенную сеть. Это означает, что никакой конфиденциальный опознавательный трафик никогда не посылается по сети открытым, незашифрованным текстом, а пользовательский пароль никогда не посылается по сети, даже в зашифрованной форме. Второй принцип состоит в том, что протокол Kerberos имеет в своей основе опознавательную модель с общим секретом. В этой модели клиент и опознающий сервер владеют общим секретом, который неизвестен кому-либо еще. В большинстве случаев общий секрет Ч это пароль пользователя.
Когда пользователь входит в сеть, защищенную протоколом Kerberos, пароль пользователя используется для шифрования пакета информации. Когда сервер Kerberos получает пакет, он расшифровывает информацию, используя копию пароля, хранящегося на сервере. Если расшифровка прошла успешно, то опознающий сервер знает, что пользователю известен общий секрет, и ему предоставляется доступ.
Примечание. Когда пользователь входит в систему, он обычно впечатывает свой пароль.
Контроллер домена проверяет точность пароля. Однако поскольку Kerberos работает в предположении, что сеть не защищена, то эта проверка делается без пересылки пароля по сети.
Одной из проблем общего секрета является то, что пользователь и сервер, управляющий сетевым ресурсом, должны иметь какой-либо способ владения общим секретом. Если пользователь пробует получить доступ к ресурсу на определенном сервере, то учетная запись пользователя может быть создана на сервере с паролем, который знает только пользователь. Когда пользователь попытается обратиться к ресурсам на этом сервере, он может представить общий секрет (пароль) и получить доступ к ресурсу. Однако в корпоративной среде могут быть тысячи пользователей и сотни серверов. Управление различными общими секретами всех этих пользователей было бы непрактичным. Протокол Kerberos справляется с этой проблемой, используя центр распределения ключей (KDC - Key Distribution Center). Служба KDC выполняется как служба сервера в сети и управляет общими секретами всех пользователей в сети. KDC имеет одну центральную базу данных для всех учетных записей пользователей сети и хранит общий секрет каждого пользователя (в форме одностороннего кэша пароля пользователя). Когда пользователю требуется получить доступ к сети и сетевым ресурсам, служба KDC подтверждает, что пользователь знает общий секрет, а затем подтверждает подлинность пользователя.
Примечание. В терминологии Kerberos центральным сервером, управляющим учетными записями пользователя, является служба KDC. В реализации Kerberos сервера Windows Server 2003 этот сервер называется контроллером домена. Каждый контроллер домена Active Directory является KDC. В Kerberos граница, определенная пользовательской базой данных, расположенной на одном KDC, называется областью (realm). В терминологии Windows Server 2003 эта граница называется доменом.
Каждая служба KDC состоит из двух отдельных служб: службы аутентификации (AS Authentication Service) и службы предоставления билетов (TGS Ч Ticket-Granting Service). Служба AS отвечает за начальный вход клиента в систему и выдает билет TGT (TGT - Ticket-Granting Ticket) клиенту. Служба TGS отвечает за все билеты сеанса, которые используются для доступа к ресурсам в сети Windows Server 2003.
Служба KDC хранит базу данных учетных записей, которая используется для аутентификации протоколом Kerberos. В реализации Kerberos Windows Server 2003 база данных управляется агентом системы каталога (DSA - Directory System Agent), который выполняется в пределах процесса LSA на каждом контроллере домена. Клиенты и приложения никогда не получают прямой доступ к базе данных учетных записей - все запросы идут через агента DSA, используя один из интерфейсов Active Directory. Каждый объект в пределах базы данных учетных записей (фактически, каждый атрибут каждого объекта) защищен с помощью списка ACL. Агент DSA гарантирует, что любые попытки обращения к базе данных учетных записей должным образом санкционированы.
Совет. Когда Active Directory устанавливается на первом контроллере домена в домене, создается специальная учетная запись, которая называется krbtgt. Эта учетная запись не может быть удалена или переименована, ее никогда нельзя разрешать (enable). При создании этой записи назначается пароль, который регулярным образом автоматически изменяется. Этот пароль используется для создания секретного ключа, предназначенного для шифрования и расшифровки билетов TGT, выдаваемых всеми контроллерами домена в домене.
Аутентификация на базе протокола Kerberos На компьютерах с системой Microsoft Windows 2000 Professional или Windows XP Professional, на серверах с Windows 2000 Server или Windows Server 2003 аутентификация по протоколу Kerberos начинается с того, что служба LSA вызывает провайдера защиты Kerberos. Когда пользователь входит в систему, впечатывая имя пользователя и пароль, компьютер клиента применяет одностороннее хэширование к паролю пользователя для создания секретного ключа, который кэшируется в надежной памяти на компьютере. Одностороннее хэширование означает, что пароль не может быть восстановлен исходя из хэш-значения (hash).
Для осуществления процесса входа клиента в систему клиент и сервер выполняют следующие действия.
1. Провайдер Kerberos SSP на рабочей станции посылает опознавательное сообщение службе KDC (см. рис. 8-1). Это сообщение включает: Х имя пользователя;
Х область (realm) пользователя (имя домена);
Х запрос на TGT-билет;
Х предварительные опознавательные данные, которые включают метку времени.
Предварительные опознавательные данные зашифрованы с помощью секретного ключа, полученного из пользовательского пароля.
Рис. 8-1. Получение билета Kerberos TGT 2. Когда сообщение достигдет сервера, сервер исследует имя пользователя, а затем проверяет базу данных каталога в поисках своей копии секретного ключа, связанного с данной учетной записью пользователя. Сервер расшифровывает зашифрованные в сообщении данные с помощью секретного ключа и проверяет временную метку. Если расшифровка прошла успешно, и временная метка отличается от текущего времени на сервере в пределах 5 минут, сервер готов подтвердить подлинность пользователя. Если расшифровка окажется неудачной, это означает, что пользователь ввел неправильный пароль, и аутентификация потерпит неудачу. Если временная метка отличается более чем на 5 минут от текущего времени на сервере, то аутентификация также потерпит неудачу. Причина такой маленькой разницы во времени состоит в том, что она должна предотвратить возможную попытку перехвата опознавательного пакета с последующим повторением его в более позднее время. Заданная по умолчанию максимальная допустимая разница во времени, составляющая 5 минут, может быть сконфигурирована в политике защиты домена.
3. После аутентификации пользователя сервер посылает клиенту сообщение, которое включает ключ сеанса и TGT (см. рис. 8-1). Ключ сеанса - это ключ шифрования, который клиент будет использовать для взаимодействия с KDC вместо секретного ключа клиента.
TGT Ч это билет сеанса, который предоставляет пользователю доступ к контроллеру домена. В течение срока службы TGT клиент предъявляет TGT контроллеру домена всякий раз, когда ему требуется обратиться к сетевым ресурсам. Полное сообщение от сервера зашифровано с помощью секретного ключа пользователя. Кроме того, билет TGT зашифрован с помощью долгосрочного секретного ключа сервера.
4. Когда пакет прибывает на компьютер клиента, секретный ключ пользователя используется для расшифровки пакета. Если расшифровка прошла успешно и временная метка допустима, то компьютер пользователя предполагает, что центр KDC надежно идентифицировал пользователя, потому что ему знаком его секретный ключ. Ключ сеанса затем кэшируется на локальном компьютере, пока не кончится срок его действия или пока пользователь не сделает выход из системы рабочей станции. Этот ключ сеанса будет использоваться для шифрования всех будущих подключений к центру KDC, т.е. клиент больше не должен помнить секретный ключ, и он удаляется из кэша рабочей станции.
Билет TGT сохраняется в зашифрованной форме в кэше рабочей станции.
Примечание. Протокол Kerberos включает в себя Authentication Service (AS) Exchange (Коммутатор аутентификационной службы), который является подпротоколом, предназначенным для выполнения начальной аутентификации пользователя. Только что описанный процесс использует подпротокол AS Exchange. Начальное сообщение, посланное клиентом к центру KDC, называется сообщением KRB_AS_REQ. Ответ сервера клиенту называется сообщением KRB_AS_REP. *Х 5. Пользователь был опознан, но он все еще не имеет никакого доступа к сетевым ресурсам.
TGT - это билет сеанса, который предоставляет доступ к центру KDC, но чтобы получить доступ к каким-либо другим сетевым ресурсам, пользователь должен получить другой билет сеанса от KDC центра (см. рис. 8-2.) Рабочая станция клиента посылает запрос на билет сеанса к центру KDC. Запрос включает имя пользователя, билет TGT, предоставленный в процессе аутентификации, имя сетевой службы, к которой пользователь хочет получить доступ, и временную метку, которая зашифрована с использованием ключа сеанса, полученного в процессе AS Exchange.
Рис. 8-2. Получение билета сеанса Kerberos для сетевого ресурса 6. Служба KDC расшифровывает билет TGT, используя свой долгосрочный ключ. Затем она извлекает ключ сеанса из билета TGT и расшифровывает временную метку, чтобы убедиться, что клиент использует правильный ключ сеанса, и гарантировать, что временная метка допустима. Если ключ сеанса и временная метка приемлемы, то KDC готовит билет сеанса для доступа к сетевой службе.
7. Билет сеанса включает две копии ключа сеанса, который клиент будет использовать для соединения с требуемым ресурсом. Первая копия ключа сеанса зашифрована, используя ключ сеанса клиента, полученный в процессе начального входа в систему. Вторая копия ключа сеанса предназначена для сетевой службы и включает информацию о доступе пользователя. Эта часть билета сеанса зашифрована, используя секретный ключ сетевой службы, который неизвестен рабочей станции клиента, но известен и службе KDC и сетевой службе, потому что сервер, на котором расположен ресурс, является членом сферы KDC.
8. Рабочая станция клиента кэширует обе части билета сеанса в памяти.
Примечание. Процесс, описанный в шагах с 5-го по 8-ой, использует подпротокол Ticket-Granting Service Exchange (Коммутатор службы предоставления билетов ). Запрос на билет сеанса, посланный клиентом, называется сообщением KRB_TGS_REQ;
ответ сервера - сообщением KRB_TGS_REP.
9. Теперь клиент предъявляет билет сеанса сетевой службе для получения доступа (см. рис.
8-3.) Рис. 8-3. Доступ к сетевой службе 10. Сетевая служба расшифровывает ключ сеанса, зашифрованный в билете сеанса, используя долгосрочный ключ, которым она владеет совместно с центром KDC. Если эта расшифровка прошла успешно, то сетевая служба знает, что билет выдан доверенной службой KDC. Затем сетевая служба расшифровывает лексему доступа пользователя, используя ключ сеанса, и проверяет пользовательский уровень доступа. Запрос клиента включает также временную метку, которая зашифрована с помощью ключа сеанса и проверена сервером.
Примечание. Процесс, описанный в шагах 9 и 10, использует под-протокол Client/Server (CS) Exchange. Запрос клиента называется сообщением KRB_AP_REQ.
В предположении, что аутентификация и проверка разрешения прошли успешно, клиенту предоставляется доступ к ресурсам сервера. Если клиент нуждается в дальнейшем использовании ресурса или службы, то билет сеанса перемещается из кэша, предназначенного для билета клиента, и передается на целевой сервер ресурса. Если срок действия билета сеанса истек, клиент должен обратиться к KDC для получения нового билета.
Дополнительная информация. Вы можете посмотреть содержимое кэша клиента, используя инструменты, доступные для загрузки на веб-сайте Microsoft. Инструмент KList.exe предоставляет интерфейс командной строки для просмотра и удаления билетов Kerberos. Инструмент Kerberos Tray (Kerbtray.exe) обеспечивает для просмотра билетов графический интерфейс пользователя (GUI). На рисунке 8-4 показан пример информации, предоставленной инструментом Kerberos Tray. Инструмент Kerberos Tray доступен по адресу windows2000/techinjo/reskit/tools/existing/kerbtray-o.asp, а инструмент KList доступен по адресу existing /klist-o. asp.
Рис. 8-4. Просмотр билетов Kerberos с помощью инструмента Kerberos Tray Процесс получения доступа к сетевому ресурсу показывает, что центр KDC вовлечен только в процесс начального входа в систему клиента, когда клиент первый раз пробует обращаться к ресурсу, расположенному на определенном сервере. Когда пользователь впервые входит в систему, ему выдается билет TGT, который предоставляет клиенту доступ к центру KDC в течение срока службы билета. Когда клиент пробует соединиться с сетевым ресурсом, он снова входит в контакт с KDC и получает билет сеанса для доступа к этому ресурсу. Билет сеанса включает лексему доступа пользователя. Когда эта лексема предъявляется серверу, на котором расположен ресурс, сервер определяет уровень доступа к ресурсу, который должен иметь данный пользователь.
Аутентификация, пересекающая границы домена Тот же самый опознавательный процесс применяется и в том случае, когда при подтверждении подлинности пользователя пересекаются границы домена. Например, компания может иметь лес с тремя доменами, как показано на рисунке 8-5.
Рис. 8-5. Аутентификация, пересекающая границы домена Если пользователь, имеющий учетную записью в домене Fabrikam.com, перейдет в домен NAmerica.Contoso.com и попытается войти в сеть, рабочая станция клиента сможет соединиться с контроллером домена в домене Fabrikam.com. В этом случае компьютер клиента посылает начальный запрос входа в систему на контроллер домена NAmerica.Contoso.com. Контроллер домена определяет, что учетная запись пользователя расположена в домене Fabrikam.com, так что нужно переправить запросы рабочей станции клиента к этому домену. Если все домены были сконфигурированы с прямыми доверительными отношениями (shortcut trusts), то контроллер домена может напрямую направить компьютер клиента к контроллеру домена в домене Fabrikam.com. Однако если прямых доверительных отношений не было создано, то нет и прямого доверительного отношения между доменами NAmerica.Contoso.com и Fabrikam.com. В этом случае контроллер домена NAmerica направит компьютер клиента к контроллеру домена в домене Contoso.com. Направление включает ключ сеанса, предоставляющий доступ к контроллеру домена в домене Contoso.com. Ключ сеанса создается, когда домен NAmerica добавляется к лесу Contoso.com и создаются начальные доверительные отношения между этими двумя доменами.
Ключ сеанса гарантирует, что запрос на вход в систему исходит от доверенного домена. Затем компьютер клиента посылает опознавательный запрос к домену Contoso.com. Теперь клиент направляется к контроллеру домена в домене Fabrikam.com. Снова это направление включает ключ сеанса, необходимый для доступа к контроллеру домена. Далее компьютер клиента посылает запрос TGT на свой домашний контроллер домена в Fabrikam.com.
Аналогичный процесс происходит тогда, когда клиент пробует получить доступ к ресурсу, расположенному за пределами домашнего домена пользователя. В этом случае клиент должен получить билет сеанса от контроллера домена, расположенного в том домене, где находится ресурс, пока он не сможет соединиться с правильным контроллером домена.
Опознавательный процесс влияет на проект леса, особенно если пользователи часто входят на домены, к которым они сами не принадлежат, или обращаются к ресурсам других доменов. Если вы разрабатываете лес с несколькими доменами, клиенту, вероятно, придется пересекать весь путь доверительных отношений между доменами. Если это случается часто, нужно поместить контроллеры домена корневых доменов ближе к пользователям. Можно также использовать прямые доверительные отношения, чтобы направления контроллера домена посылались нужным доменам напрямую.
Делегирование аутентификации Одна из причин сложности доступа к сетевым службам состоит в том, что сетевая служба может быть распределена между несколькими серверами. Например, клиент для получения информации соединяется с крайним сервером внешнего интерфейса цепочки серверов, который должен подключиться к серверу базы данных, являющимся другим концом этой цепочки. Чтобы пользователь получил доступ только к санкционированной информации, для обращения к крайнему серверу базы данных должны использоваться верительные грамоты пользователя (вместо верительных грамот сервера внешнего интерфейса). В системе Windows 2000 протокол Kerberos обеспечивает это двумя способами: путем использования прокси-билетов (proxy tickets) и ретранслированных билетов (forwarded tickets). Если прокси-билеты разрешены, то клиент пошлет запрос на билет сеанса к центру KDC, требуя доступ к крайнему серверу. Служба KDC предоставит билет сеанса и установит на билете флажок PROXIABLE. Затем клиент представит билет сеанса серверу внешнего интерфейса, который использует его для доступа к информации, расположенной на крайнем сервере. Главная проблема с про-кси-билетами состоит в том, что клиент должен знать отличительные характеристики крайнего сервера. Другой вариант состоит в использовании ретранслированных билетов. Если эти билеты разрешены, то кли ент посылает запрос AS Exchange к центру KDC, требуя билет TGT, позволяющий серверу внешнего интерфейса обратиться к крайним серверам. Служба KDC создает билет TGT и посылает его клиенту для пересылки серверу внешнего интерфейса, который использует билет TGT для получения билета сеанса, позволяющего обратиться к крайнему серверу от имени клиента.
Имеется два существенных недостатка, связанных с реализацией делегирования аутентификации в системе Windows 2000. Первый недостаток состоит в том, что делегирование аутентификации может использоваться только в том случае, если клиент аутентифицирован через протокол Kerberos. Клиенты с системами Windows NT, Microsoft Windows 95 и Windows 98 не могут использовать делегирование аутентификации. В Windows Server 2003 клиент может использовать любой опознавательный протокол. Второй недостаток системы Windows 2000 касается защиты делегирования. В Windows 2000 после получения сервером внешнего интерфейса ретранслированного билета от центра KDC он может использовать его для доступа к любой сетевой службе от имени клиента. Windows Server 2003 имеет опцию, ограничивающую делегирование, т.е. учетную запись можно сконфигурировать так, что это делегирование будет применяться только для определенных сетевых служб (основываясь на основных именах служб).
Ограниченное делегирование доступно в случае, если функциональный уровень домена установлен на функциональный уровень Windows Server 2003.
Для успешного делегирования аутентификации нужна гарантия, что и учетная запись пользователя, и учетная запись компьютера (или службы) сконфигурированы так, чтобы поддерживать делегирование аутентификации. Для этого обратитесь к окну Properties (Свойства) пользователя через инструмент Active Directory Users And Computers (Пользователи и компьютеры Active Directory), выберите вкладку Account (Учетная запись), а затем просмотрите список Account Options (Опции учетной записи). Удостоверьтесь, что oпция Account Is Sensitive And Cannot Be Delegated (Учетная запись точна и не может быть делегирована) не выбрана. (По умолчанию опция не выбрана.) Чтобы сконфигурировать учетную запись службы для делегирования, нужно определить, является ли учетная запись, используемая службой для входа в систему, нормальной учетной записью пользователя, или она является учетной записью LocalSystem. Если служба выполняется под нормальной учетной записью пользователя, обратитесь к вкладке Account пользователя и удостоверьтесь, что опция Account Is Sensitive And Cannot Be Delegated не выбрана. (По умолчанию она не выбрана.) Если служба выполняется под учетной записью LocalSystem, то делегирование было сконфигурировано в окне Properties компьютерной учетной записи (см. рис. 8-6). Чтобы реализовать уровень аутентификации Windows 2000, выберите опцию Trust This Computer For Delegation To Any Service (Kerberos Only) (Доверять этому компьютеру при делегиро вании к любой службе (Только протокол Kerberos)). Чтобы реализовать усовершенствованный уровень аутентификации Windows Server 2003, выберите опцию Trust This Computer For Delegation To Specified Services Only (Доверять этому компьютеру только при делегировании к указанной службе). Затем укажите, должен ли клиент подтверждать подлинность только с использованием протокола Kerberos, или он может использовать любой другой протокол, а затем выбрать службы (основываясь на основных именах служб, зарегистрированных в Active Directory), которым компьютер может представлять делегированные верительные грамоты.
Рис. 8-6. Конфигурирование ограниченного делегирования для учетной записи компьютера Конфигурирование Kerberos в Windows Server Как говорилось выше, протокол Kerberos по умолчанию задан в качестве опознавательного протокола для клиентов с системами Windows 2000, или более поздними, которые входят в Active Directory. Вы можете сконфигурировать несколько свойств Kerberos через политику безопасности домена. Чтобы обратиться к параметрам настройки политики Kerberos, откройте пункт Domain Security Policy (Политика безопасности домена) из инструментов администрирования и разверните папку Account Policies (Политики учетных записей) (см. рис. 8-7). Вам станут доступны следующие политики.
Рис. 8-7. Конфигурирование параметров настройки протокола Kerberos через Domain Security Policy (Политика безопасности домена) Х Enforce User Logon Restrictions (Усиление ограничений пользовательского входа в систему). Эта политика устанавливает опцию службы KDC, по которой при каждом запросе на билет сеанса проверяются установки прав пользователя на целевом компьютере. Если эта политика включена, то пользователь, запрашивающий билет сеанса, должен иметь права Allow Log On Locally (Разрешить локальный вход), если он вошел в систему в интерактивном режиме, или права Access This Computer From The Network (Доступ к этому компьютеру из сети) на целевом компьютере. Эти права назначаются в меню Local Policies\User Rights Assignment (Локальные политики\ Назначение прав пользователей) в пункте Domain Security Policy (Политика безопасности домена). По умолчанию эта политика включена.
Х Maximum Lifetime For Service Ticket (Максимальный срок годности служебного билета).
Эта политика устанавливает максимальное время (в минутах), в течение которого билет сеанса может использоваться для доступа к определенной службе. Если установлен нуль минут, то срок годности билета никогда не окончится. Если установлено ненулевое количество минут, то оно должно быть больше, чем 10 минут, и меньше или равно значению, установленному для параметра Maximum Lifetime For User Ticket (Максимальный срок годности для пользовательского билета). По умолчанию эта установка составляет 600 минут (10 часов).
Х Maximum Lifetime For User Ticket (Максимальный срок годности для пользовательского билета). Эта политика устанавливает максимальное время (в часах), в течение которого может использоваться TGT-билет пользователя. После того как истечет срок годности TGT-биле-та, существующий билет должен быть возобновлен, иначе нужно затребовать новый билет в центре KDC. По умолчанию эта установка составляет 10 часов.
Х Maximum Lifetime For User Ticket Renewal (Максимальный срок, в течение которого возможно обновление пользовательского билета). Эта политика устанавливает время (в днях), в течение которого TGT-билет может быть возобновлен (вместо получения нового TGT-биле-та). По умолчанию эта установка составляет 7 дней.
Х Maximum Tolerance For Computer Clock Synchronization (Максимально допустимое расхождение в показаниях компьютерных часов). Эта политика устанавливает максимальную разницу во времени (в минутах) между временем на компьютере клиента и временем на контроллере домена, обеспечивающем аутентификацию по протоколу Kerberos, которую протокол Kerberos считает допустимой. Если разница во времени между показаниями этих двух компьютеров больше, чем допустимый уровень, все билеты Kerberos будут отвергнуты. По умолчанию эта установка составляет 5 минут. Имейте в виду, что в случае изменения этой установки при перезапуске компьютера она возвратится к заданному по умолчанию значению.
В большинстве случаев параметры настройки протокола Kerberos, заданные по умолчанию, являются приемлемыми. В средах с высоким уровнем безопасности можно уменьшить сроки службы билетов. Однако в этом случае клиенты должны будут более часто подключаться к центру KDC, создавая дополнительный сетевой трафик и лишнюю нагрузку на контроллерах домена.
Интеграция с инфраструктурой открытых ключей В основе протокола Kerberos лежит опознавательная модель с общим секретом. Это обеспечивает превосходную защиту, но налагает одно важное ограничение на обеспечение доступа к сети Windows Server 2003. Это ограничение состоит в том, что каждый пользователь, который обращается к сети, должен иметь учетную запись в базе данных учетных записей службы KDC.
Если пользователь не существует в базе данных, ему нельзя предоставить доступ к сети.
Эта модель хорошо работает в тех компаниях, в которых все пользователи, входящие в сеть, известны, и учетная запись может быть создана для каждого пользователя. Однако многие компании расширяют список пользователей, имеющих доступ к сетевым ресурсам, включая в него пользователей, которые не являются служащими. Компания может вступить в краткосрочное партнерство с другой компанией, и ей потребуется обеспечить доступ к сетевым ресурсам для служащих другой компании. Или компания захочет предоставить доступ к ресурсам, имеющимся в сети компании, определенным клиентам. В этих сценариях список людей, которым требуется доступ к сети, может быть очень длинным, так что создание учетной записи для каждого из пользователей будет непрактичным.
Инфраструктура открытых ключей (PKI - Public Key Infrastructure) стала основным средством для решения проблемы предоставления доступа к сети пользователям, не имеющим учетной записи пользователя. Система PKI отходит от модели аутентификации с общим секретом и заменяет ее опознавательной моделью, основанной на сертификате. В системе PKI пользователи аутентифицируются на основании того факта, что они имеют правильный сертификат. Система PKI основана на трех основных концепциях: открытые (public) и личные (private) ключи, цифровые сертификаты и сертификационные власти (СА - certificate authorities). PKI начинается с концепции, согласно которой каждый пользователь или компьютер, вовлеченный в информационный обмен, имеют два ключа: личный ключ и открытый ключ. Личный ключ известен только одному пользователю. Его можно сохранить на жестком диске компьютера, как часть роумингового (roaming) профиля, или на устройстве типа смарт-карты. Открытый ключ доступен любому, кто его попросит. Личные и открытые ключи связаны, но нет никакого способа извлечь личный ключ из открытого ключа. Эти ключи используются различными способами.
Один из способов состоит в шифровке информации при пересылке ее по сети. Открытый ключ пользователя используется для шифровки сообщения. Поскольку открытый ключ доступен любому, кто его запросит, то все могут посылать сообщение, зашифрованное с помощью открытого ключа пользователя. Однако, единственный ключ, с помощью которого можно расшифровать сообщение, Ч это личный ключ пользователя. Он является единственным человеком, способным расшифровывать сообщение. Кто-то другой, перехвативший этот пакет в сети, не имеет правильного личного ключа и не сможет прочитать сообщение.
Другой способ применения состоит в использовании цифровой подписи и печати для сообщений, посылаемых между двумя пользователями. Цифровая подпись используется для гарантии подлинности отправителя сообщения и целостности сообщения. Чтобы создать цифровую подпись, все сообщение подвергается математическому хэшированию. Хэш является сверткой сообщения, или цифровым дайджестом (digest), который зашифрован с помощью личного ключа отправителя сообщения. Зашифрованный хэш посылается вместе с сообщением как цифровая подпись. Когда адресат получает сообщение, к нему применяется тот же самый хэш, создавая второй дайджест сообщения. Затем используется открытый ключ отправителя для расшифровки цифровой подписи. Если дайджест сообщения получателя идентичен расшифрованной подписи, то целостность и подлинность сообщения подтверждены.
Второй компонент PKI Ч цифровой сертификат. Цель применения сертификата состоит в том, чтобы идентифицировать владельца сертификата. Когда человек или компания обращаются к сертификационным властям (СА) для получения сертификата, СА-власти подтверждают подлинность человека или компании, запрашивающей сертификат. Когда пользователю предоставляется сертификат, он получает соответствующий открытый ключ, а также личный ключ для сертификата. Сертификат подписан сертификационными властями с помощью цифровой подписи, добавляя к сертификату штамп подлинности СА-властей. Текущий стандарт для сертификатов -Х.509 v3. Сертификат включает информацию о человеке, компьютере или службе, для которых он был выпущен, информацию о самом сертификате (дата истечения срока годности) и информацию об СА-властях, выпустивших данный сертификат.
Сертификаты, необходимые для инфраструктуры PKI, выпускаются властями СА, которые являются сетевыми серверами, управляющими предоставлением и отменой удостоверений. Из-за важности PKI для интернета в настоящее время доступно множество СА-властей, включая популярные коммерческие СА типа Verisign и Thawte. Большинство интернет-клиентов, таких как Microsoft Internet Explorer, автоматически сконфигурированы доверять удостоверениям, выпущенным коммерческими властями С А. Вы можете установить свои собственные СА-вла-сти, используя Windows Server 2003. Сертификационная служба, поставляемая с Windows Server 2003, является СА-властью с полной функциональностью, которая может использоваться для выдачи удостоверений людям, работающим в пределах вашей компании, представляющим организации партнера.
Дополнительная информация. Планирование и развертывание инфраструктуры PKI требует значительных усилий. Windows Server 2003 обеспечивает опцию для создания PKI с использованием СА-властей предприятия, интегрированных в Active Directory. Развертывая СА-власти предприятия, можно сконфигурировать политики для автоматизации большинства административных усилий, связанных с выдачей и возобновлением удостоверений. Веб-сайт компании Microsoft и Help And Support Center (Центр справки и поддержки) в Windows Server 2003 содержат детальную информацию, необходимую для установки инфраструктуры PKI.
Одна из главных причин использования сертификатов состоит в том, чтобы позволить пользователям, не имеющим учетной записи в Active Directory, получать доступ к ресурсам в сети Windows Server 2003. Например, вы захотите установить безопасный веб-сайт, чтобы партнерские организации или клиенты могли получить доступ к некоторой конфиденциальной информации, касающейся вашей сети. Однако в Windows Server 2003 разрешение на доступ к сетевым ресурсам можно предоставлять только участникам безопасности. Нет никакой опции, позволяющей назначить разрешения, основываясь исключительно на сертификатах. Вы можете предоставить доступ к ресурсам для пользователей, имеющих удостоверения и не имеющих учетных записей пользователя Active Directory, путем отображения сертификата на учетную запись пользователя и использованием учетной записи для назначения разрешений.
Windows Server 2003 обеспечивает два различных способа отображения сертификата на учетную запись пользователя.
Х Однозначное отображение. В этом случае один сертификат отображается на одну учетную запись пользователя Windows Server 2003. При однозначном отображении вы должны назначить сертификат и создать учетную запись для каждого пользователя. Это может быть хорошим решением, если вы хотите дать доступ удаленным служащим компании к безопасным ресурсам через безопасный веб-сайт. Это не упрощает ваше администрирование, тем не менее, с помощью однозначного отображения имен можно управлять уровнем доступа каждого пользователя.
Х Многозначное отображение. В этом случае несколько сертификатов отображаются на одно имя учетной записи Active Directory. Например, если вы создаете партнерские отношения с другой компанией, и служащим компании нужен доступ к безопасному веб сайту, вы можете создать одну учетную запись пользователя. Затем вы можете с этой учетной записью связать такое количество сертификатов, какое захотите. Например, если та компания имеет свою собственную власть СА, вы можете создать правило, по которому все выданные ею удостоверения будут отображаться на одну учетную запись пользователя в вашем домене. Затем, используя эту запись, вы сможете назначать разрешения на сетевые ресурсы.
Совет. Можно отображать сертификаты на учетные запкси пользователя через инструмент Active Directory Users And Computers или Менеджер информационного сервера интернета (IIS) от Microsoft. В Active Directory Users And Computers используйте опцию Name Mappings (Отображение имен^, которая становится доступной при щелчке правой кнопкой мыши на учетной записи пользователя.
Интеграция со смарт-картами Смарт-карты обеспечивают другой способ объединения инфраструктуры PKI с аутентификацией по протоколу Kerberos. Когда Kerberos используется без PKI, общий секрет между клиентом и службой KDC используется для шифрования обмена информацией с опознавательной службой при начальном входе в систему. Этот ключ получен из пароля пользователя, тот же самый ключ используется при шифровании и расшифровки информации. Смарт-карты используют модель инфраструктуры PKI, в которой и открытый, и личный ключи используются для шифрования и расшифровки информации, касающейся входа в систему.
Смарт-карта содержит открытый и личный ключи пользователя плюс сертификат Х.509 v3. Все это применяется при использовании пользователем смарт-карты для аутентификации в Active Directory. Процесс входа в систему начинается в тот момент, когда пользователь вставляет смарт карту в устройство чтения смарт-карт и вводит свой личный идентификационный номер (PIN Ч personal identification number). Это интерпретируется властями LSA на компьютере как последовательность Ctrl+Alt+Del, и процесс входа в систему начинается.
Номер PIN используется для чтения сертификата пользователя и открытого и личного ключей со смарт-карты. Затем клиент посылает обычный TGT-запрос к службе KDC. Вместо посылки данных предварительной аутентификации (временная метка), зашифрованных с помощью секретного ключа пользователя, полученного из пароля, клиент посылает службе KDC открытый ключ и сертификат. Запрос TGT все еще включает в себя данные предварительной аутентификации, но он подписан с помощью личного ключа пользователя.
Когда сообщение достигает службы KDC, она проверяет сертификат клиента, чтобы убедиться в его правильности и в том, что СА-власти, выдавшие сертификат, являются доверенными властями.
Служба KDC проверяет также цифровую подпись данных предварительной аутентификации, чтобы гарантировать подлинность отправителя сообщения и целостность сообщения. Если обе эти проверки дают положительный результат, служба KDC использует основное пользовательское имя (UPN), включенное в сертификат клиента, чтобы искать имя учетной записи в Active Directory. Если учетная запись пользователя правильна, то служба KDC подтверждает подлинность пользователя и посылает в ответ клиенту билет TGT, включающий ключ сеанса.
Ключ сеанса зашифрован с помощью открытого ключа клиента, и клиент использует свой личный ключ для расшифровки информации. Затем этот ключ сеанса используется для всех подключений к службе KDC.
Совет. Установка входа в систему вашей сети с использованием смарт-карты требует значительного объема работы. Прежде всего, нужно развернуть СА-власти для выпуска сертификатов. Затем установить станции регистрации смарт-карт, где пользователи смогут получать свои смарт-карты, и где смарт-картам могут быть назначены правильные сертификаты и ключи. После начального развертывания нужно решить административные задачи, связанные с потерянными или забытыми картами. Смарт-карты обеспечивают превосходную дополнительную защиту вашей сети, но эта дополнительная защита связана со значительными административными усилиями.
Способность к взаимодействию с другими системами Kerberos Поскольку в основе протокола Kerberos лежит открытый стандарт, он обеспечивает превосходные возможности для взаимодействия с другими системами, основанными на протоколе Kerberos.
Любой из компонентов, который являются частью реализации протокола Kerberos Windows Server 2003, может быть заменен эквивалентным элементом, не принадлежащим системе Windows. Эти три компонента следующие:
Х клиент Kerberos;
Х центр распределения ключей Kerberos;
Х сетевой ресурс, использующий протокол Kerberos для разрешений.
Имеются четыре возможных сценария взаимодействия.
Х Клиенты Windows 2000 или Windows XP Professional могут входить на контроллер домена Windows Server 2003 и иметь доступ к ресурсам, расположенным на Windows Server или на других службах, в основе которых находится протокол Kerberos.
Х Клиенты Windows 2000 или Windows XP Professional могут входить на KDC-центры, не принадлежащие Windows-платформе, и иметь доступ к ресурсам, расположенным на Windows Server 2003 или на других службах, в основе которых находится протокол Kerberos.
Х Клиенты Kerberos, не принадлежащие Windows-платформе, могут входить на KDC-центры Windows Server 2003 и иметь доступ к ресурсам, расположенным на Windows Server или на других службах, в основе которых находится протокол Kerberos.
Х Клиенты Kerberos, не принадлежащие Windows-платформе, могут взаимодействовать с реализациями Kerberos, не принадлежащими Windows-платформе, и иметь доступ к ресурсам, расположенных на Windows Server 2003 или на других службах, в основе которых находится протокол Kerberos.
Windows Server 2003 можно сконфигурировать для участия в любом из этих сценариев. Самый легкий вариант Ч это однородное решение, в котором вся среда основана или на Kerberos Windows Server 2003, или на реализации Kerberos, не принадлежащей Windows-платформе.
Однако реализация Kerberos Windows Server 2003 позволяет легко взаимодействовать с другими реализациями Kerberos. Для этого нужно создать доверительные отношения между областями домена Windows Server 2003 и областью Kerberos, не принадлежащей Windows-платформе.
Доверительные отношения сферы могут быть сконфигурированы как транзитивные или нетранзитивные, а так же как односторонние или двухсторонние. Чтобы сконфигурировать доверительные отношения с другой областью, откройте инструмент Active Directory Domains And Trusts (Домены и доверительные отношения Active Directory) и перей дите в окно Properties (Свойства) того домена, в котором вы хотите создать доверительные отношения. На вкладке Trusts (Доверительные отношения) щелкните на кнопке New Trust, запустив New Trust Wizard. С помощью мастера вы можете создать доверительные отношения со стороны Windows Server 2003 с другой областью Kerberos. На рисунке 8-8 показано окно Properties доверительного отношения области после его создания.
Рис. 8-8. Конфигурирование доверительного отношения между областями Дополнительная информация. Microsoft обеспечивает пошаговое руководство для конфигурирования доверительных отношений Kerberos между областями. Это руководство, озаглавленное как Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability доступно на веб-сайте Microsoft по адресу www.microsoft.com/technet/prodtechnol/windows2000serv/ howto/kerbstep.asp.
Безопасность протокола NTLM Второй вариант аутентификации на контроллере домена Windows Server 2003 должен использовать NTLM-аутентификацию. Она поддерживается для совместимости с клиентскими компьютерами, на которых выполняются системы Windows NT 4, Windows 95 и Windows 98. Этот протокол используется в следующих ситуациях.
Х Когда компьютер, на котором выполняются системы Windows 95, Windows 98 или Windows NT, подтверждает свою подлинность на контроллере домена Windows Server 2003. На компьютерах с системами Windows 95 и Windows 98 должна быть установлена служба Directory Services Client, или эти операционные системы смогут подтверждать подлинность только с использованием протокола LAN Manager.
Х Когда компьютер, на котором выполняются системы Windows XP Professional или Windows Server 2003, подтверждает подлинность на Windows NT 4 Server.
Х Когда любой клиент обращается к автономному серверу с системой Windows Server 2003.
Х Когда клиент, на котором выполняются системы Windows XP Professional или Windows 2000, пробует войти на контроллер домена с Windows Server 2003, но не способен подтвердить подлинность, используя протокол Kerberos. В этом случае NTLM аутентификация может использоваться как альтернативный протокол.
Протокол NTLM значительно менее безопасен, чем Kerberos. С пакетом Windows NT 4 Service Pack компания Microsoft представила новую версию протокола NTLM с именем NTLMv2. Эта новая версия включает дополнительную защиту, такую как создание уникального ключа сеанса каждый раз при установлении нового подключения, а также расширенный процесс обмена ключами для защиты ключей сеанса.
Резюме В этой главе сделан краткий обзор основных концепций безопасности службы Active Directory Windows Server 2003, включая участников безопасности, списки управления доступом, аутентификацию и разрешения. Большая часть этой главы посвящена основным средствам обеспечения аутентификации и разрешений службы Active Directory через протокол Kerberos. Протокол Kerberos предлагает безопасный механизм подтверждения подлинности пользователей в Active Directory и получения доступа к сетевым ресурсам. Обсуждена также интеграция протокола Kerberos с инфраструктурой открытых ключей PKI, смарт-картами и другими реализациями Kerberos.
Глава 9. Делегирование администрирования службы Active Directory Как говорилось в предыдущих главах, служба Active Directory операционной системы Microsoft Windows Server 2003 больше не поддерживает единое неструктурированное пространство имен, которое использовалось в доменах Microsoft Windows NT. Вместо этого она обеспечивает иерархическое представление каталога, сначала через иерархию доменной системы имен (DNS) множества доменов, а затем через структуру организационных подразделений (OU) в пределах доменов. Эта иерархия создает важную административную возможность: делегирование административных разрешений. В доменах Windows NT такой возможности не было. Разрешения, полученные в одной части домена, действовали повсюду в домене. Теперь это полностью изменилось. Служба Active Directory Windows Server 2003 имеет мощные опции для управления разрешениями и делегирования административных задач в пределах домена.
Данная глава построена на обсуждении безопасности Active Directory, начатой в главе 8. Глава начинается с повторного рассмотрения защиты Active Directory с целью уточнения списков управления доступом (ACL) на объектах Active Directory. После этого в главе обсуждается делегирование прав. Для делегирования разрешений вы можете напрямую обращаться к спискам ACL индивидуальных объектов. Для назначения разрешений служба Active Directory Windows Server 2003 имеет.также Delegation Of Control Wizard (Мастер делегирования управления).
Разрешения объектов службы Active Directory Как описано в главе 8, когда пользователь входит в сеть Windows Server 2003, ему предоставляется лексема доступа. Лексема доступа включает идентификаторы защиты (SID) для учетной записи пользователя, а также SID для всех групп, к которым принадлежит пользователь. Как только пользователь вошел, он пытается обратиться к сетевому ресурсу, ко торый включает объект Active Directory. Каждый сетевой ресурс или объект Active Directory имеет список ACL, хранящийся в его атрибуте NT Security Descriptor, который состоит из одной или более записей управления доступом (АСЕ), определяющей, какие права на данный объект имеет каждый идентификатор SID. Дескриптор защиты содержит владельца объекта, а также список управления разграничительным доступом (DACL) и список управления системным доступом (SACL). Список DACL определяет разрешения на объект, которые имеют все участники безопасности. Список SACL определяет параметры настройки аудита объекта.
Примечание. Каждый объект в Active Directory имеет список ACL, т.е. разрешения на этом объекте можно изменять. Это справедливо для объектов, отражаемых как через инструменты Active Directory Users And Computers (Пользователи и компьютеры Active Directory), Active Directory Sites And Services (Сайты и службы Active Directory), ADSI Edit или Ldp.exe. Основное внимание в этой главе будет уделено объектам, отображаемым через Active Directory Users And Computers, потому что почти все администрирование защиты выполняется с помощью этого инструмента. Однако многие из концепций и процедур, обсуждаемых здесь, могут применяться и к другим инструментальным средствам администрирования Active Directory. Например, вы можете использовать тот факт, что каждый объект имеет список ACL, чтобы изменить разрешения для объектов сайтов в инструменте Active Directory Sites And Services. Можно использовать также Delegation Of Control Wizard, который будет обсуждаться позже в этой главе.
Есть множество различных инструментов, которые могут использоваться для просмотра дескриптора защиты любого объектов Active Directory. Обычно используется инструмент Active Directory Users And Computers. Он может давать несколько различных представлений списков ACL. Это связано с тем, что разрешения на доступ к объектам Active Directory разбиты на две категории: стандартные (standard) и специальные (special). Просмотр информации о защите через Active Directory Users And Computers осложняется, если вы можете предоставлять разрешения объектам внутри контейнерного объекта или атрибутам объекта.
Стандартные разрешения Чтобы просмотреть стандартные разрешения для любого объекта Active Directory в разделе домена каталога, обратитесь к вкладке Security (Безопасность) в окне Properties (Свойства) нужного объекта в инструменте Active Directory Users And Computers. (Если вкладка Security не видна, выберите Advanced Features (Дополнительные функции) в меню View (Вид), повторно выберите объект и откройте окно Properties). Вкладка Security(Безопасность) показывает стандартные разрешения, которые доступны для каждого объекта (см. рис. 9-1).
Рис. 9-1. Просмотр стандартных разрешений на объекте пользователь Каждый класс объектов в Active Directory имеет свой набор стандартных разрешений. Например, организационная единица (OU) - это контейнерный объект, который может содержать дочерние объекты, поэтому он имеет набор разрешений, применяемых к дочерним объектам, которые не подходят для объектов пользователь. Однако, некоторые стандартные разрешения, например, Full Control (Полный контроль), Read (Чтение), Write (Запись), Create All Child Objects (Создание всех дочерних объектов) и Delete All Child Objects (Удаление всех дочерних объектов), применимы ко всем объектам.
Некоторые объекты Active Directory имеют стандартные разрешения, которые применяются к сгруппированным наборам свойств. Например, каждый объект пользователь имеет несколько наборов свойств типа Public Information (Открытая информация), Personal Information (Личная информация) или Web Information (Веб-информация). Каждый из этих наборов свойств относится к набору атрибутов, так что предоставление доступа к нему обеспечивает доступ к набору атрибутов. Например, набор свойств Personal Information включает атрибуты homePhone, homePostalAddress, streetAddress и так далее. Использование наборов свойств для назначения доступа к группам атрибутов упрощает процесс назначения разрешений.
Дополнительная информация. Чтобы найти полный список атрибутов, включенных в каждый набор свойства, сделайте поиск выражения "property sets" (включая открывающие и закрывающие кавычки) в Help And Support Center (Центр справки и поддержки). Схема Active Directory определяет то, какие атрибуты являются частью каждого свойства, установленного с помощью значения rightsGuid для категории свойства (в разделе конфигурации каталога) и значения attributesSecurityGUID для объекта схемы. Например, значение rightsGuid для cn=Personal Information, cn=Extended-Rights, cn=conf iguration, dc=forestname равно значению attributes ecurityGUID для cn=Telephone-Number, cn=Schema, cn=Configuration, dc=forestname. Это означает, что номер телефона включен в набор свойств Personal Information.
В дополнение к стандартным разрешениям вкладка Security показывает некоторые дополнительные права, такие как Receive As, Send As, Send To (все права, связанные с Microsoft Exchange 2000 Server), Change Password и Reset Password. Список разрешений может также включать разрешение Validated Write (Запись с проверкой ее достоверности). Например, объектам Group требуется разрешение Validated Write на то, чтобы добавить/удалить себя как члена.
Различие между разрешением Validated Write и обычным Write состоит в том, что Validated Write гарантирует, что записанное значение допустимо. В этом случае пользователь, имеющий разрешение добавлять/удалять себя как члена группы, сможет добавлять к группе только себя самого.
Специальные разрешения Одна из записей в стандартном списке разрешений на вкладке Security (Безопасность) - Special Permissions (Специальные разрешения). Вы можете предоставлять объектам Active Directory не только стандартные разрешения, но и специальные. Они более детализированы и специфичны, чем стандартные разрешения. Чтобы получить доступ к ним, щелкните на Advanced (Дополнительно) на вкладке Security (рис. 9-2). В таблице 9-1 объясняется назначение столбцов в окне.
Примечание. Кнопка Default (По умолчанию) на вкладке Advanced сбрасывает разрешения, установленные на объекте к разрешениям, заданным по умолчанию.
Рис. 9-2. Просмотр дополнительных параметров настройки защиты Advanced Security Settings для пользовательского объекта Табл. 9-1. Столбцы конфигурации специальных разрешений Столбец Объяснение Туре (Тип) Значение устанавливается для разрешений Allow (Разрешить) или Deny (Запретить).
Обычно разрешения отсортированы так, что сначала перечисляются все разрешения Deny (Запретить). Порядок сортировки может быть изменен щелчком на любом заголовке столбца.
Независимо от порядка появления в этом столбце сначала всегда оцениваются разрешения Deny (Запретить).
Name (Имя) Имя участника безопасности, к которому применяется запись АСЕ.
Permission (Разрешение) Столбец перечисляет уровень разрешения, предоставленного участнику безопасности.
Уровни разрешений могут быть стандартными, например Full Control, специальными, например, Create/Delete User Objects (Создавать/Удалять пользовательские объекты), или только Special (Специальный).
Доступные типы разрешений зависят от типа объекта.
Inherited From Столбец указывает место, в котором (Унаследованный от) установлено это разрешение.
Apply To (Применяется к) Столбец определяет глубину применения разрешение. Она имеет разнообразные параметры настройки, включая This Object Only (Только этот объект), This Object And All Child (Этот объект и все дочерние объекты) или Only Child Objects (Только дочерние объекты).
Это окно перечисляет все АСЕ-записи для объекта. Во многих случаях одни и те же участники безопасности могут быть перечислены в нескольких записях АСЕ. Например, группе Authenticated Users (Удостоверенные пользователи) дано разрешение Read Permissions (Читать разрешения), Read General Information (Читать информацию общего характера), Read Personal Information (Читать личную информацию), Read Web Information (Читать веб-информацию) и Read Public Information (Читать открытую информацию) в отдельных записях АСЕ.
Вы можете добавлять и удалять участников безопасности или редактировать текущие разрешения, предоставленные участнику безопасности, используя окно Advanced Security Settings (Дополнительные параметры настройки защиты). Если вы добавляете или редактируете разрешения, предоставленные участнику безопасности, вам дается два способа для назначения разрешений. На рисунке 9-3 показан первый способ назначения разрешений на объект.
Рис. 9-3. Назначение специальных разрешений на доступ к объектам Active Directory Вкладка Object (Объект) используется для назначения разрешений, которые применяются только к объекту, ко всем дочерним объектам или к определенным дочерним объектам. Например, на уровне OU можно предоставлять разрешения, которые применяются к объекту (OU), к объекту и всем его дочерним объектам, ко всем дочерним объектам или к определенным дочерним объектам (таким как учетные записи пользователя, группы и компьютера). Список разрешений изменяется в зависимости от типа объекта, с которым вы работаете.
Второй способ назначения разрешений предназначен для управления параметрами настройки свойств объекта (см. рис. 9-4).
Рис. 9-4. Конфигурирование разрешений, применяемых к свойствам объектов Вкладка Properties (Свойства) используется для назначения разрешений на индивидуальные свойства объекта, выбранного в поле Name (Имя) окна Advanced Security Settings (Дополнительные параметры настройки защиты). Например, если вы применяете разрешения к пользовательским объектам, вам предоставляется опция назначения разрешений Read и Write для каждого атрибута, доступного для данного класса объектов.
Примечание. Когда вы увидите эти опции в первый раз, вы, вероятно, отреагируете двумя способами. Первая реакция будет реакцией удовлетворения от того, что, наконец-то, вы сможете назначать разрешения так, как вам всегда хотелось. Другая реакция - недовольство, потому что у вас никогда не было потребности назначать разрешения на таком уровне. Обе реакции отражают существо дела. Так происходит потому, что чаще всего вам не требуется назначать разрешения на таком уровне, но этот уровень является определенно полезным, когда вы сталкиваетесь с очень специфическими требованиями.
Просмотр записей АСЕ с помощью инструмента Ldp.exe Графический интерфейс пользователя (GUI) является инструментом, который очень удобен для управления огромной совокупностью АСЕ-записей. Чтобы получить возможность по-настоящему оценить значение GUI, потратьте некоторое время на знакомство с инструментом Ldp.exe. Чтобы просмотреть список ACL с помощью Ldp.exe, откройте диалоговое окно Run (Выполнить) и напечатайте ldp. (Если Ldp.exe не был установлен на компьютере, откройте папку \SUPPORT\TOOLS на компакт-диске Windows Server 2003 и дважды щелкнете на файле Suptools.msi, чтобы установить средства поддержки Active Directory.) Выберите раскрывающееся меню Connection (Подключения), затем выберите Connect (Подключиться). Если вы оставите пустым поле сервера, то сервер соединится с локальным компьютером. Вы можете напечатать имя сервера. Как только вы свяжетесь с сервером, выберите раскрывающееся меню Connection (Подключения) и выберите Bind (Связаться). Если вы входите не с учетной записью пользователя, имеющей административные права, введите дополнительные мандаты. Другим способом, оставьте пробелы в полях, предназначенных для информации входа в систему. После подключения к домену щелкните на раскрывающемся меню View (Вид), а затем выберите Tree (Дерево). Чтобы просмотреть весь домен, щелкните на ОК. Структура OU домена будет представлена в левой области окна (см. рис. 9-5).
Чтобы просмотреть список ACL для любого объекТа, найдите объект в дереве в левой области окна. Затем щелкните правой кнопкой мыши на объекте и выберите Advanced (Дополнительно), затем - Security Descriptor (Дескриптор защиты). Список ACL хранится в значении NT Security Descriptor каждого объекта Active Directory. Затем инструмент Ldp.exe запишет каждый АСЕ в правую область окна в зашифрованном формате:
(A;
;
CCDCLCSWRPWPDTLOCRSDRCWDWO;
;
;
DA) Каждая пара букв в первом списке АСЕ-записей соответствует определенному разрешению.
Например, СС означает, что пользователь имеет право создать все дочерние объекты. Последние две буквы в АСЕ записи относятся к группе или пользователю, который имеет разрешения DA, т.е.
относится к группе Domain Admins. Если разрешения назначены пользователю или группе, которая не имеет известного иден тификатора SID, то последняя часть каждой записи АСЕ содержит SID пользователя или группы.
(Чтобы увидеть полный список всех возможных разрешений, которые могут быть назначены в записях АСЕ, просмотрите справочную информацию для команды DsAcls, сопровождающую инструменты Active Directory. Инструмент командной строки DsAcls может использоваться для назначения или удаления разрешений к любому объекту в Active Directory).
Рис. 9-5. Использование инструмента Ldp.exe для просмотра свойств домена После строк такого типа информации инструмент Ldp.exe даст более понятное объяснение каждой записи АСЕ. Например, для строки, приведенной выше, это будет выглядеть так:
Асе[О] Асе Туре: 0x0 - ACCESS_ALLOWED_ACE_TYPE Асе Size: 36 bytes Асе Flags: 0x Асе Mask: OxOOOfOiff DELETE READ CONTROL WRITE DAC WRITE_OWNER ACTRL DS CREATE_CHILD ACTRL DS DELETE CHILD ACTRL DS LIST ACTRL DS SELF ACTRL DS READ_PROP ACTRL DS WRITE_PROP ACTRL_DS_DELETE_TREE ACTRL_DS_UST_OBJECT ACTRL_DS_CONTROL_ACCESS Ace Sid: Contoso\Domain Admins S-1 -5-21 -602162358-688789844-1957994488- Наследование разрешений Служба Active Directory Windows Server 2003 использует статическую модель наследования разрешений. Когда изменяется разрешение на контейнерном объекте в структуре Active Directory, то оно рассчитывается и применяется к дескриптору защиты всех объектов, находящихся в этом контейнере. Если изменяются разрешения на высшем уровне и применяются ко всем дочерним объектам, то вычисление нового списка ACL для каждого объекта может быть значительной нагрузкой на процессор. Однако это не означает, что разрешения не должны рассчитываться повторно, когда пользователь или процесс обращаются к объекту.
По умолчанию все разрешения в Active Directory наследуются. Большинство разрешений, установленных на контейнерном уровне, наследуется всеми объектами в пределах этого контейнера, включая другие контейнерные объекты. Например, если пользователь имеет разрешение создавать учетные записи пользователей в OU, он также может создавать учетные записи в любой дочерней OU в пределах этой OU. В большинстве случаев вы, вероятно, примете заданное по умолчанию наследование разрешений. Если вы разработали свою структуру OU с целью делегирования администрирования, то нужно создать OU-структу-ру, в которой на высшем иерархическом уровне предоставляются разрешения администраторам высшего уровня, нуждающимся в разрешениях ко всем объектам Active Directory. По мере продвижения вниз по иерархии вы можете назначать разрешения для других администраторов, которые должны иметь контроль над меньшей частью домена.
В некоторых случаях можно блокировать любые административные разрешения администраторов высокого уровня для определенной дочерней OU. Например, вы создали дочернюю OU для филиала вашей компании и дали локальной административной группе полное управление над этой OU. Возможно, вы не хотите, чтобы эти локальные администраторы имели доступ к учетным записям пользователей, представляющих исполнительную власть в этой OU. Вы можете создать OU Executives (Руководство) в пределах OU-филиала, а затем блокировать наследование разрешений на уровне Executives OU.
Чтобы блокировать наследование разрешений на объекте Active Directory, обратитесь к окну Advanced Security Settings для данного объекта (см. рис. 9-2). Затем очистите опцию Allow Inheritable Permissions From The Parent To Propagate To This Object And All Child Objects (Разрешить наследованным разрешениям распространяться от родителя к этому объекту и всем дочерним объектам). После очистки этой опции вам будет представлена опция, позволяющая копировать существующие разрешения или удалять разрешения перед явным назначением новых разрешений (см. рис. 9-6).
Рис. 9-6. Выбор опции, позволяющей копировать или удалять разрешения при блокировании наследования разрешений После блокировки наследования вы можете сконфигурировать разрешения на объектах.
Блокировка наследования имеет несколько следствий.
Х Разрешения блокируются для объекта и любых дочерних объектов. Вы не можете блокировать наследование разрешений на контейнерном уровне, а затем повторно применять наследование от более высокого контейнера на более низкий уровень.
Х Если вы решите копировать разрешения перед модификацией, наследование разрешений начинается там, где вы блокируете разрешения. Если вы измените разрешения на более высоком уровне, разрешения не будут унаследованы в обход блокированных разрешений.
Х У вас нет большого выбора того, какие разрешения будут блокированы. Когда вы блокируете разрешения, то все наследованные разрешения также блокируются.
Разрешения, которые были назначены на объект или дочерние объекты явно, не блокируются.
Примечание. Одна из возможных проблем с блокированием унаследованных разрешений состоит в том, что можно создать лосиротевший объект, к которому никто не имеет разрешений.
Например, в организационной единице OU можно блокировать все наследование разрешений к ней и назначить разрешения только для административной группы. Вы можете даже удалить группу Domain Admins из списка ACL этой OU, чтобы группа Domain Admins не имела никаких разрешений при нормальных обстоя тельствах, и в OU не будет групп с административным управлением. В этом случае группа Domain Admins всегда может взять объект в собственность и повторно назначить разрешения.
Фактические разрешения Как описано в этой главе к настоящему моменту, пользователь может получить разрешения к объекту в Active Directory несколькими способами.
Х Учетной записи пользователя можно предоставить явные разрешения на доступ к объекту.
Х Одной или более группам, к которым принадлежит пользователь, можно предоставить явные разрешения на доступ к объекту.
Х Учетной записи пользователя или группам, к которым принадлежит пользователь, могут быть даны разрешения на уровне контейнерного объекта и разрешения, унаследованные объектами низшего уровня.
Все разрешения суммируются, т.е. пользователю предоставляется самый высокий уровень разрешений от любой из этих конфигураций. Например, если пользователю явно дано разрешение Read (Чтения) к определенному объекту, при этом он принадлежит к группе с разрешением Modify (Изменять) и группе с разрешением Full Control (Полное управление) на контейнерном уровне, то этот пользователь будет иметь разрешение Full Control. Когда пользователь обращается к объекту, подсистема защиты исследует все записи АСЕ, которые прикреплены к объекту. Они оцениваются, и устанавливается самый высокий уровень разрешения. В дополнение к записям АСЕ, которые предоставляют разрешения, Active Directory поддерживает также блокирование разрешений. Блокирование разрешений может применяться на двух уровнях.
Х Пользовательскому объекту или группе, к которой принадлежит пользователь, может быть блокировано разрешение на доступ к определенному объекту явно.
Х Пользовательскому объекту или группе, к которой принадлежит пользователь, может быть блокировано разрешение на контейнерном уровне, и оно может быть унаследовано объектами низшего уровня.
Блокирование разрешения (Deny) всегда отменяет разрешение (Allow). Например, если пользователь является членом группы, которая имеет разрешение Modify для объекта Active Directory, и если разрешение Modify к этому объекту явно блокировано для данного пользователя, то он не сможет изменять объект. Это происходит потому, что записи АСЕ, которые блокируют разрешения, оцениваются перед оценкой записей АСЕ, которые позволяют разрешения. Если одна из записей АСЕ блокирует разрешение участнику безопасности, то другие записи АСЕ для данного объекта не оцениваются.
Ситуация, в которой разрешения отменяют блокирование разрешения, возникает тогда, когда разрешения Deny унаследованы, а разрешения Allow назначены явно. Например, вы можете блокировать пользователю разрешение изменять любые учетные записи пользователя в контейнере. Но если вы явно позволите разрешение Modify для объекту в пределах контейнера, то данная учетная запись пользователя будет иметь разрешение Modify для этого объекта.
Блокирование разрешения: используйте осторожно Использование блокирования разрешения может привести к тому, что работать с моделью защиты вашей службы Active Directory будет очень трудно. Есть множество различных сценариев, в которых вы можете предусмотреть блокировку разрешения. Один из них состоит в том, что вы можете использовать Deny (Запретить) для удаления некоторых унаследованных разрешений.
Например, вы можете предоставить разрешения Modify на контейнерном уровне, но заменить его на Read-Only (Только для чтения) далее вниз по иерархии. В этом же сценарии вы можете блокировать разрешение Write на любых объектах или свойствах далее вниз по иерархии.
Еще одним сценарием, в котором можно было бы использовать Deny, является создание контейнера, требующего более высокой защиты. Например, имеется контейнер для всех должностных лиц, и нужно сделать так, чтобы обычный пользователь не смог читать свойства учетных записей должностных лиц. Вы можете блокировать разрешение Read для контейнера, используя группу Domain Users (Пользователи домена). В результате пользователям будет запрещено читать объекты каталога, включая администраторов. Из-за осложнений, которые может вызвать использование Deny, вы должны применять эту опцию с осторожностью.
В большинстве случаев вместо блокировки разрешений можно удостовериться, что пользователю или группе не были даны эти разрешения. Если пользователь при этом не является членом группы, которой были предоставлены разрешения, он не будет иметь доступа к объектам. Вам не обязательно блокировать разрешение для предотвращения доступа пользователей к объектам Active Directory.
Один из немногих сценариев, в которых выгодно использовать Deny, состоит в том, что группа должна иметь определенные разрешения, а один или более пользователей этой же группы должны иметь разрешения более низкого уровня. Например, вы можете создать группу по имени Account Admins, которая отвечает за управление всеми учетными записями пользователей в домене.
Некоторые члены этой группы могут быть временными служащими, которые должны управлять всеми учетными записями пользователей в домене, но не имеют права изменять свойства учетных записей должностных лиц. В этом случае вы можете назначить группе Account Admins разрешение управлять учетными записями пользователей в домене, затем создать OU для учетных записей должностных лиц и группу для временных членов группы Account Admins. Затем можно заблокировать право временных пользователей изменять какие-либо учетные записи пользователей в OU должностных лиц.
Таким образом, конфигурирование защиты объектов Active Directory может затрагивать большое количество взаимосвязанных переменных. Многие компании могут начинать с довольно простого проекта защиты, в котором маленькой группе администраторов предоставляются все разрешения в Active Directory. В большинстве случаев начальная конфигурация защиты Active Directory ясно задокументирована. Однако со временем она становится более запутанной. Иногда другой группе администраторов предоставляется набор разрешений для выполнения определенной задачи в течение определенного периода времени. Предоставить разрешение просто, но часто случается так, что впоследствии разрешения забывают удалить. Часто модификации защиты, сделанные после начального развертывания Active Directory, не документируются.
Для любой структуры Active Directory существует возможность того, что текущая конфигурация защиты окажется более сложной, чем первоначально разработанная конфигурация. Иногда это кончается тем, что пользователи имеют больше разрешений, чем следует. К счастью, в Windows Server 2003 есть инструмент, который может использоваться для определения фактических разрешений, представленных участнику безопасности для доступа к объектам Active Directory.
Обратитесь к свойствам объекта через соответствующий инструмент администрирования Active Directory. Выберите вкладку Security (Безопасность), щелкните на Advanced (Дополнительно), а затем выберите вкладку Effective Permissions (Фактические разрешения). На рисунке 9-7 показано окно инструмента Active Directory Users And Computers. Чтобы определить фактические разрешения для определенной учетной записи пользователя или группы, щелкните Select (ВыборХ а затем найдите имя группы или пользователя. Выбрав имя, щелкните на ОК. Окно Effective Permissions (Фактические разрешения) отображает все разрешения, которые предоставлены выбранному участнику безопасности для доступа к данному объекту Active Directory.
Примечание. Данный инструмент имеет некоторые ограничения, которые могут влиять на отображаемые фактические разрешения. Инструмент определяет фактические разрешения, основанные на наследовании и явно определенных разрешениях для учетной записи пользователя и его группы. Однако пользователь может также получить некоторые разрешения на основании того, как он входит в систему и соединяется с объектом. Например, в Windows Server 2003 вы можете назначать разрешения для группы Interactive (членом этой группы становится каждый, кто cделал вход на компьютер) или группы Network Login (каждый, кто обращается к информации по сети). Описанный выше инструмент Active Directory не может определять разрешения, предоставленные пользователю на основании принадлежности к этим типам групп. Кроме того, он может определять разрешения, используя только разрешения человека, выполняющего инструмент. Например, если пользователь, который выполняет инструмент, не имеет разрешения читать состав некоторых групп, к которым принадлежит интересующий его пользователь, то инструмент не способен точно определить разрешения.
Рис. 9-7. Отображение фактических разрешений для объекта Active Directory Право собственности на объекты Active Directory Каждый объект в Active Directory должен иметь владельца. По умолчанию пользователь, создавший объект, является его владельцем. Владелец объекта имеет право изменить разрешения на доступ к объекту, что означает, что даже если владелец не имеет полного управления объектом, он всегда может изменить разрешения на доступ к объекту. В большинстве случаев владельцем объекта является определенная учетная запись пользователя, а не учетная запись группы. Единственное исключение - это когда объект создан членом группы Domain Admins. В этом случае владельцем объекта назначается группа Domain Admins. Если владелец объекта является членом локальной группы Administrators, a не членом группы Domain Admins, то владельцем объекта назначается группа Administrators.
Чтобы определить владельца объекта Active Directory, обратитесь к свойствам объекта, используя соответствующий инструмент Active Directory. Выберите вкладку Security (Безопасность), щелкните на Advanced (Дополнительно), а затем выберите вкладку Owner (Владелец). На рисунке 9-8 показано окно инструмента Active Directory Users And Computers.
Рис. 9-8. Просмотр владельца объекта Active Directory Если вы имеете разрешение Modify Owner (Модификация владельца) для объекта, вы можете использовать это окно для изменения владельца объекта. Вы можете назначить владельцем свою собственную учетную запись, учетную запись другого пользователя или группу. Эта последняя возможность уникальна для Active Directory Windows Server 2003. В Active Directory системы Microsoft Windows 2000 вы сами можете стать владельцем или назначать владельцем другого участника безопасности.
Административные привилегии Административные разрешения являются специфическими для объектов Active Directory и определяют, какие действия администратор может выполнять с этими объектами. Разрешения, которые обсуждались до сих пор, основаны на списках ACL, приложенных к каждому объекту Active Directory. Пользовательские привилегии отличаются тем, что они применяются к учетным записям пользователя. Пользовательские привилегии пользователь получает за то, кем он является, а не за то, что он имеет разрешения изменять специфический объект Active Directory.
Например, есть два способа дать пользователю (или группе) право добавлять рабочие станции к домену. Один способ состоит в том, чтобы дать пользователю (или группе) разрешение Create Computer Objects (Создание компьютерных объектов) на уровне OU или контейнера Computers (Компьютеры). Это позволит пользователю добавить необходимое количество рабочих станций к домену в указанном контейнере.
Другой способ состоит в том, чтобы дать пользователю привилегию добавления компьютеров к домену. Она является частью политики Default Domain Controllers Policy (Заданная по умолчанию политика контроллеров домена). Любой пользователь, имеющий эту привилегию, может добавить к домену до десяти рабочих станций. По умолчанию это разрешение предоставляется группе Domain Users (Пользователи домена).
Аудит использования административных разрешений Важным аспектом обеспечения безопасности службы Active Directory является создание тщательно спланированной конфигурации защиты всего домена. Этот план должен ясно и точно определить, какие разрешения должна иметь каждая административная группа. Другим существенным компонентом защиты домена является аудит использования этих разрешений.
Аудит служит достижению двух целей. Во-первых, он обеспечивает свидетельство изменений, которые были сделаны к каталогу. Если в каталоге были сделаны изменения, вы должны проследить, кто их сделал. Это особенно важно, если в информации домена произведены неправильные или злонамеренные изменения. Второй целью аудита является обеспечение дополнительной проверки административных прав, применяемых по всему домену. Периодически исследуя регистрационные журналы аудита, вы сможете определить, применяет ли административные права тот, кто не должен их иметь.
Включение аудита изменений, сделанных для объектов Active Directory, состоит из двух шагов.
Первый шаг состоит во включении аудита на уровне OU Domain Controllers (Контроллеры домена). Это делается с помощью инструмента администрирования Domain Controller Security Policy (Политика безопасности контроллера домена). На консоли Microsoft Management Console (ММС) выберите оснастку File>Add/ Remove (Файл>Добавление/Удаление), щелкните на кнопке Add (Добавить), а затем добавьте Group Policy Object Editor (Редактор объектов групповой политики). В Group Policy Wizard (Мастер групповой политики), щелкните на кнопке Browse (Просмотр), затем трижды щелкните на Domain Controllers.domainname.com (где domainname Ч имя домена, в котором вы включаете аудит). На рисунке 9-9 показана заданная по умолчанию конфигурация аудита в Active Directory Windows Server 2003.
Pages: | 1 | ... | 3 | 4 | 5 | 6 | 7 | ... | 8 | Книги, научные публикации