ВЫПОЛНИТЬ!
1. Настроить виртуальную сеть между основной ОС и виртуальной машиной
Windows Server 2003 таким образом, чтобы существовала возможность се- тевого доступа к ресурсам Windows Server 2003. Для этого в свойствах се- тевого адаптера виртуальной машины установить возможность прямого соединения (Bridged).
2. Добавить в ОС Windows Server 2003 службу MSTS. Для этого установить компоненты Terminal Server и Terminal Server Licensing (Control Panel
⇒
Add or Remove Programs
⇒
Add/Remove Windows Components). В процес- се установки понадобится дистрибутив ОС Windows Server 2003.
3. Разрешить сетевой доступ к каталогу «C:\Windows\System32\ clients\tsclient», содержащему установочный комплект клиента MSTS. В основной ОС установить программу-клиента MSTS из данного каталога.
4. С использованием установленного клиента MSTS выполнить подключе- ние к серверу терминального доступа, указав в параметрах подключения его IP-адрес, имя и пароль учетной записи администратора сервера.
5. Открыть в терминальном окне произвольный текстовый документ, убе- диться в возможности копирования его содержимого на диски основной
ОС.
6. Разорвать терминальное соединение, выполнив в терминальном окне ко- манду Start
⇒
Logoff…
7. Выполнив команду netstat -aon, получить перечень открытых сервером се- тевых портов.
8. Выполнить настройки ОС Windows Server 2003, последовательно отклю- чив сетевые службы, функционирующие по умолчанию (см. п. 6.2.1), за исключением службы Terminal Services.
9. Повторно выполнив команду netstat -aon, проанализировать перечень ос- тавшихся открытых сетевых портов.
172 10. Активизировать в ОС Windows Server 2003 программу «Брандмауэр Win- dows» (Windows Firewall). Выполнить настройки, запрещающие использо- вание всех портов за исключением TCP-порта 3389 (см. п. 6.2.1).
11. Из основной ОС с использованием сетевого сканера nmap убедиться в не- возможности подключения к сетевым ресурсам ОС Windows Server 2003 за исключением TCP-порта 3389.
12. В ОС Windows Server 2003 создать учетную запись пользователя терми- нального доступа, включив его в состав группы «Remote Desktop Users»
(см. п. 6.3).
13. Выполнить настройки службы MSTS в соответствии с п. 6.3.
14. Выполнить настройки протокола RDP в соответствии с п. 6.4.
15. В основной ОС выполнить попытку подключения к серверу терминально- го доступа с учетной записью администратора. Убедиться в невозможно- сти подключения.
16. Выполнить подключение к серверу терминального доступа от имени соз- данной учетной записи. Убедиться в невозможности копирования инфор- мации из терминального окна на носители основной ОС.
17. С использованием анализатора сетевого трафика выяснить объем и содер- жание сетевых пакетов, циркулирующих между клиентом и сервером в режиме терминального доступа.
18. Проанализировать вычислительные ресурсы (объем оперативной памяти, загрузка процессора, загрузка сети) сервера терминального доступа, выде- ляемые MSTS при подключении одного терминального клиента.
173
7. СЛУЖБЫ КАТАЛОГОВ 7.1. Общие сведения о службах каталогов На заре компьютеризации предприятий нагрузка на администраторов компьютерных систем была невелика. Дело было не столько в количествен- ных характеристиках (общее число серверов, сетевого оборудования, рабочих станций и т.п. было значительно ниже в те времена), сколько в качествен- ных — до появления достаточно мощных и дешевых персональных компью- теров работа в системе велась через
терминалы. С точки зрения администра- тора это означало, что все управление пользователями сводилось к админист- рированию одного единственного сервера. Со
временем ситуация стала ме- няться, во-первых, предприятия приобретали все большее количество серве- ров, во-вторых, вопросам безопасности стало уделяться все больше внимания, что потребовало большего контроля каждого действия пользователя (как следствие, введения строгой аутентификации для каждого значимого для сис- темы действия).
Со временем это привело к тому, что администратор был вынужден соз- давать учетную запись пользователя на каждом сервере в сети предприятия, а также на каждой рабочей станции, которой имеет право пользоваться сотруд- ник. Пользователь, в свою очередь, должен был постоянно предоставлять ау- тентифицирующую информацию (каждому сервису корпоративной сети).
Решением этой проблемы стало создание так называемых
служб ката-логов — систем централизованного хранения информации о пользователях.
Международная организация по стандартизации (ISO) предложила стандарт
X.500, который описывал функционирование такой системы. Однако прото- кол взаимодействия, описанный в рамках стандарта, оказался слишком пере- груженным для сетей TCP/IP. По этой причине какое-то время службы ката- лога создавались производителями с использованием различных протоколов взаимодействия (NDS, NIS, NT4 domain). Такое разнообразие реализаций при- вело к тому, что независимые разработчики сетевых сервисов либо совсем не обеспечивали совместимости со службами каталогов, либо обеспечивали со- вместимость с какой-то конкретной реализацией. Как следствие, каждый про- изводитель службы каталога должен был обеспечить клиентов и базовым на- бором служб (например, собственным файл-сервером).
Ситуация изменилась только тогда, когда Интернет-сообщество опуб- ликовало «облегченный» вариант стандарта X.500 — протокол LDAP
(Lightweight Directory Access Protocol
1
, RFC 4510). Протокол обеспечивал про- стой доступ к каталогу в рамках TCP-соединения, касался также вопросов ау- тентификации и собственно структуры каталога. Позже стандарт претерпел
1
Название так и переводится: облегченный протокол доступа к каталогу.
174
некоторое количество редакций и в настоящее время поддерживается практи- чески любым сетевым приложением и реализован в любой службе каталога.
Развитие протокола продолжается и сегодня. Уже используется версия 3 данного протокола, а также опубликован целый ряд расширений (например, поддержка language tags, позволяющая хранить имя пользователя, записанное на нескольких языках, и отправлять клиенту имя на его родном языке).
Многие современные сетевые приложения также обладают встроенной поддержкой LDAP (почтовые клиенты способны производить поиск адреса по имени пользователя, web-серверы и СУБД могут извлекать список пользова- телей из каталога LDAP, распределенные приложения могут хранить свои на- стройки в каталоге LDAP и т. п.)
После
того как все данные о пользователях, группах, в которые они входят, и их правах доступа переместились в централизованное хранилище, разработчики стали задумываться и о решении другой проблемы современных компьютерных систем — о постоянной необходимости пользователей в ау- тентификации. Производители стали выпускать системы с концепцией едино- го входа в сеть (так называемые системы SSO — single sign on), т. е. пользова- тель при однократном вводе пароля получал доступ ко всем ресурсам сети. На практике это работало только с сервисами самого производителя, поскольку слишком различались протоколы сетевой аутентификации у различных при- ложений. Те способы решения проблемы, которые пытались предложить кон- кретные производители, не были универсальны. Решения от Microsoft позво- ляли хранить пароль пользователя не в виде хэша, а в восстанавливаемом виде
(т. е. практически в открытом), Novell позволял хранить пароль различными способами (зашифрованный хэшем пароля секретный ключ для сервисов
Novell, NTLM-хэш для доступа к сервисам Microsoft). Такие решения позво- ляли пользователю не вводить свой пароль лишний раз, но не были ни безо- пасными, ни универсальными.
Ситуация вновь изменилась благодаря открытым стандартам. С не- большим промежутком времени появились описания методов, позволяющих разделить сам сетевой сервис и процесс аутентификации пользователя, что позволяло использовать любой сетевой сервис с нужным методом аутентифи- кации. В настоящее время три этих метода распространены достаточно широ- ко — это SASL (Simple Authentication and Security Layer, RFC 4422), GSSAPI
(Generic Security Service Application Program Interface, RFC 2743) и SPNEGO
(Simple and Protected GSSAPI Negotiation, RFC 2478). Все перечисленные ме- тоды реализуют примерно одну и ту же идею — существует четкий интерфейс взаимодействия сетевого сервиса с библиотекой, которая, как правило, явля- ется расширяемой при помощи модулей (опять же со строго зафиксирован- ным интерфейсом). При этом в стандарт закладывается механизм согласова- ния используемого модуля для аутентификации клиента и сервера.
Подобные механизмы часто встречались в рамках одного протокола
(например, согласование диалекта SMB или метода аутентификации NFS),
175
однако они были уникальными для каждого протокола, что усложняло воз- можность использования одних и тех же методов аутентификации для разных сетевых сервисов.
Удобство заключается также в том, что универсальные методы аутен- тификации можно вкладывать друг в друга. Иными словами, если сервис был написан с поддержкой механизма GSSAPI, а у производителя службы катало- га есть только модули SASL, реализующие необходимые методы аутентифи- кации, то любое заинтересованное лицо может создать GSSAPI-модуль, кото- рый реализует аутентификацию по механизму SASL (рис. 7.1).
Рис. 7.1. Пример вложенности механизмов сетевой аутентификации
Однако использование универсальных механизмов лишь частично ре- шает проблему единой аутентификации при входе в сеть. Необходим также некоторый безопасный протокол, который аутентифицирует клиента перед сервером (сервисом), с учетом того, что сам сервер ничего о пользователе не знает и должен использовать в качестве посредника сервер службы каталогов.
В качестве универсального протокола аутентификации можно исполь- зовать инфраструктуру открытых ключей (например, на базе сертификатов
X.509) или протокол Kerberos (см. ниже).
В данной главе рассмотрена реализация службы каталога корпорации
Microsoft — Active Directory (AD) на примере интеграции ее в среду сторон- них сервисов. А именно, решение задачи аутентификации пользователей на web-сервере Apache при помощи протокола Kerberos, а также настройка меха-
176
низмов аутентификации и авторизации на рабочей станции под управлением
ОС 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».
177 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».
7.2. Структура каталога LDAP
Для дальнейшей работы с каталогом LDAP необходимо более подробно ознакомиться с его основными понятиями и компонентами, а также с набором утилит, которые позволяют производить манипуляции с ним.
7.2.1. Схема LDAP
Каталог LDAP имеет древовидную структуру. Узлы дерева называются
объектами. Объекты делятся на листья и контейнеры. Каждый объект со- держит набор свойств (различную информацию об объекте, например его имя, дата создания и т. п.). Список свойств каждого объекта зависит от класса этого объекта. По аналогии с объектно-ориентированным программированием классы выстраиваются в иерархическое отношение — предок-потомок. Класс- потомок содержит свойства своего предка, при этом поддерживается множе- ственное наследование. Описание всех классов и их свойств хранится в самом каталоге LDAP и называется схемой каталога.
178
Схема содержит описания двух типов — описание атрибутов и описа- ние классов.
Атрибут — описание некоторого свойства, включающее в себя
синтаксис (аналог типа данных, но кроме информации о типе он содержит также функцию сравнения, например есть синтаксис для строки чувствитель- ной и нечувствительной к регистру). Кроме синтаксиса атрибут содержит ин- формацию о своем имени, а также некоторые дополнительные данные (на- пример, ограничения на синтаксис или указание, что атрибут хранит несколь- ко значений).
Классы бывают
абстрактными, структурными и
вспомога-тельными. Для каждого класса задается набор обязательных (значение этих атрибутов не может быть пустым) и необязательных (значение может отсутст- вовать) атрибутов. Кроме этого у класса указывается список возможных кон- тейнеров для него, таким образом, объект является контейнером, если хотя бы один класс указывает его в качестве своего возможного контейнера.
Схема LDAP-каталога хранится в самом каталоге. Для описания схемы
Active Directory существует два объекта: attributeSchema для атрибутов и classSchema для классов (оба эти класса, как и все их атрибуты также описаны внутри схемы).
7.2.2. Система имен LDAP Для того чтобы LDAP-клиент имел возможность получать данные от
LDAP-сервера, необходимо указать конкретный объект в каталоге. Для этого служат специальные атрибуты, для которых схемой задается требование уни- кальности в пределах одного контейнера. Такие атрибуты называются
отно-сительным различимым именем (relative distinguished name, rdn). Теперь для того, чтобы идентифицировать объект в пределах дерева, достаточно указать относительные различимые имена всех объектов в цепочке, начиная от корня дерева. Полученная последовательность различимых имен называется
полным различимым именем (fully distinguished name, fdn). Для обозначения полного различимого имени принята запись
<имя атр.1>=<знач. атр.1>,
<имя атр.2>=<знач. атр.2>,..,
<имя атр.N>=<знач. атр.N>
Например, контейнер, хранящий схему каталога Active Directory (в до- мене example.com), имеет следующее полное различимое имя: CN=Schema,
CN=Configuration, DC=example, DC=com. Как видно из примера, атрибут, яв- ляющийся относительным различимым именем у каждого объекта может быть свой (здесь CN — у объектов-контейнеров Schema и Configuration, DC — у объектов example и com). Указание того, какой атрибут
может выступать в роли различимого имени, задается в схеме для каждого класса.
179
7.2.3. Инструментарий для работы с LDAP-каталогом
Для работы с произвольными LDAP-каталогами существует огромное количество программ как бесплатных, так и коммерческих. В данном разделе будут рассмотрены два основных инструмента: оснастка MMC ADSI Edit (ко- торая обладает большим функционалом, если речь идет о LDAP-каталоге Ac- tive Directory), а также утилиты пакета ldap-utils (преимущество этих утилит в том, что они реализованы практически для каждой ОС).
Оснастка ADSI Edit входит в пакет Support Tools ОС Windows Server
2003. Для вызова этой утилиты необходимо в окне Start
⇒ Run набрать «ad- siedit.msc». Загрузится консоль управления Microsoft с оснасткой ADSI Edit, подключенной к трем разделам каталога (рис. 7.2): Domain (собственно дан- ные каталога Active Directory), Configuration (служебная информация) и
Schema (схема каталога). При необходимости можно подключиться и к дру- гим разделам каталога, выбрав соответствующий пункт контекстного меню корневого узла оснастки.
Для того чтобы просмотреть содержимое раздела, достаточно раскры- вать соответствующие узлы (в роли узлов будут выступать объекты- контейнеры, обычные объекты будут отображаться в правом окне).
Рис. 7.2. Оснастка ADSI Edit
Для каждого объекта-контейнера из контекстного меню доступен сле- дующий набор действий: переместить объект, переименовать объект, удалить объект, вызвать свойства объекта, а также создать внутри новый объект, до- пустимый по схеме. У обычных объектов доступно только перемещение, из- менение имени, удаление и вызов свойств.
Пункт меню «Свойства» (Properties) позволяет редактировать свойства объекта при помощи редактора атрибутов (рис. 7.3), а также настраивать раз- решения на практически любое действие над атрибутами, объектом и его со- держимым (в случае объекта-контейнера).
Внешний вид редактора прав доступа представлен на рис. 7.4.
Основное применение оснастки ADSI Edit — детальное управление пра- вами пользователей на объекты и атрибуты каталога, также ADSI Edit приме-
180
няется для редактирования тех атрибутов объектов, которые не редактируют- ся стандартными средствами администрирования Active Directory (в данном пособии это будут атрибуты Unix пользователя).
Рис. 7.3. Редактор атрибутов
Пакет ldap-utils включает в себя следующие основные утилиты:
− ldapsearch — служит для поиска объектов в каталоге от указанного узла и на указанную глубину,
− ldapmodify — служит для модификации объектов LDAP,
− ldapadd — то же, что и ldapmdify с опцией -a (добавление),
− ldapdelete — утилита для удаления объектов из каталога,
− ldapmodrdn — утилита для смены имени объекта.
При запуске каждой утилиты пакета необходимая информация берется из трех источников (каждый последующий перекрывает предыдущий): файла
«/etc/ldap/ldap.conf», файла «/.ldaprc» и опций командной строки. Основными параметрами являются:
− пользователь LDAP, от имени которого будет происходить подключе- ние (вообще говоря, это может быть любой объект каталога),
− LDAP-сервер, к которому будет осуществляться подключение,
−
метод проверки подлинности,
181
− количество выводимой отладочной информации,
− учетные данные.
Рис. 7.4. Редактор прав доступа
Каждая из утилит имеет также собственные параметры. В случае с ути- литами ldapmodify и ldapadd – это LDIF-файл, который описывает необходи- мые изменения. Информация о формате LDIF содержится в RFC 2849. Утили- та ldapsearch ожидает параметры фильтра для запросов, а также список атри- бутов, которые возвратит сервер для каждого объекта, удовлетворяющего фильтру (по умолчанию возвращаются все атрибуты).
Фильтры LDAP определены в самом протоколе и описаны в RFC 4515.
Например, пусть необходимо найти в LDAP-каталоге объект-компьютер, у ко-
182
торого имя начинается на win-. Тогда соответствующий фильтр будет иметь вид: (&(objectClass=computer)(cn=win-*))
1
Полностью запрос приведен на рис. 7.5. В данном примере утилита ldapsearch вызвана с наиболее часто употребляемыми опциями: -h — задает LDAP-сервер (по имени или IP-адресу), -b — задает различимое имя объекта, с которого начнется поиск, -D — задает различимое имя объекта LDAP, от имени которого производятся запросы к серверу (с точки зрения стандарта LDAP это может быть абсолютно любой объект, в Active Di- rectory только пользователь или компьютер), -x — задает режим аутентифика- ции simple bind (пароль передается открытым текстом), -w
— за- дает пароль.
Также при вызове ldapsearch указано, что сервер должен возвратить только атрибуты cn у найденных объектов.
Рис. 7.5. Использование утилиты ldapsearch
Рассмотрим ответ LDAP-сервера (рис. 7.5). Для удобства чтения, а так- же дальнейшего использования ldapsearch отображает информацию, получен- ную от сервера, в виде LDIF-файла (строки, начинающиеся с «#», являются комментариями). Сначала перечисляются объекты и их атрибуты, которые вернул сервер на посланный запрос. В нашем примере это компьютеры win-
1
Важно отметить, что использование метасимволов в фильтре возможно не для каждого атрибута (в Active Directory метасимволы в запросах доступны для атрибутов с флагом in- dexed, который задается в схеме).
183
ws1 и win-ws2, затем идет несколько особых ответов, которые называются re- ferral или external reference (внешние ссылки). Эти ссылки содержат указатели на другие
разделы каталога (здесь раздел — это некоторая часть каталога, ко- торая может храниться на другом сервере). Внешняя ссылка приведена в виде
URL, имеющего формат ldap[s]://<сервер>/
, где ldap или ldaps обычный или SSL-вариант протокола соответственно.
Конечной целью данной главы является интеграция рабочей станции под управлением ОС Linux в среду Active Directory, данная операция требует целого ряда настроек, в частности расширения схемы каталога для хранения
Unix-атрибутов пользователя. Существует множество готовых расширений для схемы AD, поставляющихся с различными продуктами интеграции Unix систем в среду AD.
Кроме того, для дальнейшей работы создадим специального вспомога- тельного пользователя и группу для рабочих станций под управлением ОС
Linux. Дело в том, что при авторизации рабочая станция должна иметь воз- можность определить следующие параметры пользователя: его идентифика- тор (uid), домашний каталог, командный интерпретатор, а также членство в группах. Эта информация по умолчанию недоступна для анонимного пользо- вателя, поэтому необходимо создать специального непривилегированного пользователя, от имени которого рабочие станции будут осуществлять доступ.
Скачать 9.2 Mb.