СЛУЖБЫ КАТАЛОГОВ

7.1. Общие сведения о службах каталогов

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

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

Решением этой проблемы стало создание так называемых служб ката-

логов — систем централизованного хранения информации о пользователях. Международная организация по стандартизации (ISO) предложила стандарт X.500, который описывал функционирование такой системы. Однако прото- кол взаимодействия, описанный в рамках стандарта, оказался слишком пере- груженным для сетей TCP/IP. По этой причине какое-то время службы ката- лога создавались производителями с использованием различных протоколов взаимодействия (NDS, NIS, NT4 domain). Такое разнообразие реализаций при- вело к тому, что независимые разработчики сетевых сервисов либо совсем не обеспечивали совместимости со службами каталогов, либо обеспечивали со- вместимость с какой-то конкретной реализацией. Как следствие, каждый про- изводитель службы каталога должен был обеспечить клиентов и базовым на- бором служб (например, собственным файл-сервером).

Ситуация изменилась только тогда, когда Интернет-сообщество опуб- ликовало   «облегченный»  вариант   стандарта   X.500   —   протокол   LDAP (Lightweight Directory Access Protocol1, RFC 4510). Протокол обеспечивал про- стой доступ к каталогу в рамках TCP-соединения, касался также вопросов ау- тентификации и собственно структуры каталога. Позже стандарт претерпел

Рис. 7.1. Пример вложенности механизмов сетевой аутентификации

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

В качестве универсального протокола аутентификации можно исполь-

зовать инфраструктуру открытых ключей (например, на базе сертификатов

X.509) или протокол Kerberos (см. ниже).

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

Microsoft — Active Directory (AD) на примере интеграции ее в среду сторон-

них сервисов. А именно, решение задачи аутентификации пользователей на

web-сервере Apache при помощи протокола Kerberos, а также настройка меха-

низмов аутентификации и авторизации на рабочей станции под управлением

ОС Linux с целью получения авторизующей информации из Active Directory.

Служба Active Directory состоит из целого набора сервисов, связанных между собой. Основой Active Directory является система разрешения имен, при  помощи  которой  рабочие  станции  способны  прозрачно  обнаруживать серверы домена, например LDAP-серверы. В существующей реализации сер- виса каталога в качестве службы разрешения имен выбрана система DNS (в отличие   от   предыдущих   версий,   которые   использовали   систему   имен NetBIOS). Для хранения каталога LDAP, а также для обеспечения аутентифи- кации по протоколу Kerberos в сети Microsoft выделяются специальные серве- ра, которые называются контроллерами домена. В целом контроллер доме- на —  это  выделенный сервер, предназначенный для  обеспечения сервисов LDAP и KDC (см. ниже)

В качестве первого упражнения предлагается установить службу Active

Directory на ОС Windows Server 2003. В качестве промежуточного шага тре-

буется установить и настроить DNS-сервер.

ВЫПОЛНИТЬ!

1.   Запустить виртуальную машину Windows Server 2003 (далее DC).

2.   Установка и настройка DNS-сервера. Этот шаг состоит из двух основных действий: настройка клиента DNS и установка и настройка сервера DNS.

a. Настроить имя компьютера (после внесения изменений потребуется

перезагрузка): name: DC, DNS suffix: example.com.

b. Установить DNS-сервер (Add/Remove programs ? Windows components

? Network services ? DNS).

c. Запустить оснастку администрирования DNS (Start ?  Administrative

Tools ? DNS).

d. Создать зону прямого просмотра. Выбрать из контекстного меню объ-

екта  «Forward lookup zones» пункт  «New zone». Выбрать тип  зоны

«Primary», имя зоны «example.com», разрешить динамические обнов- ления для зоны. Эта зона будет хранить информацию о создаваемом нами домене Active Directory. Имя домена Active Directory совпадает с именем DNS домена, в котором и будет храниться информация о сер- верах и рабочих станциях Active Directory.

e. Создать зону  обратного просмотра. Выбрать из  контекстного  меню объекта «Reverse lookup zones» пункт «New zone». Выбрать тип зоны

«Primary», network id 192.168.0.

f. Создать запись для рабочей станции ws-linux (это пригодится позже,

когда будет производиться настройка соответствующей виртуальной машины).    Выбрать    в    списке    зон    прямого    просмотра    зону

«example.com», выбрать из контекстного меню зоны пункт «New host

(A)», указать имя хоста «ws-linux», IP-адрес 192.168.0.2, выбрать оп-

цию «Create associated pointer (PTR) record».

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

a. Запустить утилиту dcpromo.

b. Выбрать пункт «New domain controller in a new domain». c. Выбрать пункт «New domain in a new forest».

d. Указать имя домена «example.com».

e. NetBIOS-имя и расположение служебных файлов оставить по умолча-

нию.

f. Убедиться, что тест динамических обновлений на DNS-сервере прошел успешно.

g. Выбрать режим совместимости только с ОС Windows 2000 и 2003.

h. Указать пароль режима восстановления «P@ssw0rd».

i. Дождаться окончания работы мастера и перезагрузиться.

4.   Установка дополнительных инструментов администрирования.

a. Установить    пакет    «adminpak.msi»,    расположенный    в    каталоге

«WINDOWS\System32». Данный пакет содержится во всех серверных версиях ОС Windows и содержит набор оснасток MMC для админист- рирования различных сервисов ОС Windows.

b. Установить пакет «suptools.msi». Пакет Windows Support Tools постав- ляется вместе с дистрибутивом операционной системы (обычно распо- лагается в каталоге SUPPORT установочного диска).

c. Установить пакет «rktools.exe».

Источник: Андрончик А. Н., Богданов В. В., Домуховский Н. А., Коллеров А. С., Синадский Н. И., Хорьков Д. А., Щербаков М. Ю., Защита информации в компьютерных сетях. Практический курс

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий