А. Н. Андрончик, В. В. Богданов, Н. А. Домуховский, А. С. Коллеров, Н. И. Синадский, Д. А. Хорьков
 Скачать 9.2 Mb.
|
|
ВЫПОЛНИТЬ! 5. Запустить виртуальную машину DC. 6. Добавить в схему каталога атрибуты для Unix-пользователей. Расширение схемы взято из пакета MS services for Unix: a. Запустить оболочку cmd.exe b. При помощи команды cd перейти в каталог «\schema» c. Схема сохранена в виде ldif-файла, чтобы ее добавить в каталог, необходимо воспользоваться стандартной утилитой для манипу- ляции с ldif файлами — ldifde. Для этого необходимо выполнить команду (здесь опция -i обозначает, что будет происходить им- порт данных, -k позволяет выполнять импорт даже после появле- ния некоторых некритических ошибок, опция -f указывает, что данные необходимо брать из файла): ldifde –i –k –f schema.ldf 7. Создать специального пользователя для рабочих станций под управлением ОС Linux: a. Запустить оснастку управления пользователями в Active Directory (Start ⇒ Programs ⇒ Administrative tools ⇒ Active Directory Users and Computers). b. В контекстном меню контейнера «Users» выбрать пункт «New», объект «User». 184 c. В качестве «First name» и «Users logon name» указать «proxyuser», задать пароль «P@ssw0rd», снять опцию «User must change pass- word at next logon» и выставить опции «User cannot change pass- word» и «Password never expires». d. В контекстном меню контейнера «Users» выбрать пункт «New», объект «Group». e. Указать имя группы «proxygroup», остальные опции оставить по умолчанию. f. В окне свойств пользователя открыть закладку «Member Of», до- бавить группу «proxygroup», сделать эту группу основной (нажать кнопку «Set as primary»), удалить группу «Domain Users». Тем са- мым мы добились того, что пользователь «proxyuser» не обладает никакими правами на объекты каталога. 8. Настроить ограниченные права пользователя «proxyuser» на объекты ката- лога: a. Запустить оснастку ADSI Edit (Start ⇒ Run adsiedit.msc). b. Перейти на закладку «Security» свойств контейнера «Users», на- жать кнопку «Advanced». c. В появившемся окне нажать кнопку «Add». Указать «proxygroup» в качестве объекта. d. В появившемся окне выбрать в разделе «Apply onto» вариант «This object and all child objects». e. Назначить права «List contents» и «Read all properties». 9. Запустить виртуальную машину WS-Linux. 10. Получить список групп, членом которых является пользователь «Adminis- trator», зарегистрировавшись на LDAP-сервере с правами пользователя «proxyuser». Для чего на виртуальной машине WS-Linux запустить коман- ду: ldapsearch –h dc –b cn=Users,dc=example,dc=com -D cn=proxyuser,cn=Users,dc=example,dc=com –w P@ssw0rd –x “(&(objectClass=user)(cn=Administrator))” memberOf 11. Убедиться, что список групп присутствует в выводимой на экран инфор- мации. 7.3. Система единого входа в сеть на основе протокола Kerberos 7.3.1. Общие сведения о протоколе Kerberos Протокол Kerberos является универсальным протоколом аутентифика- ции, основанным на распределении симметричных ключей шифрования неко- 185 торым доверенным сервером. Протокол Kerberos является открытым стандар- том и описан в документе RFC 1510. С помощью протокола Kerberos распределяются криптографические ключи в некоторой области (realm), которая имеет строковый идентификатор, как правило, совпадающий с именем DNS-домена. Например, для компьюте- ров DNS-домена example.com можно определить область Kerberos EXAMPLE.COM (имя области всегда заглавными буквами). Каждая учетная запись в системе Kerberos называется сущностью (prin- cipal), причем учетные записи существуют не только для пользователей, но и для каждого сервиса. Имя учетной записи имеет следующий вид: «user@REALM» (где user — имя пользователя, а RELAM — имя области). Например, имя учетной записи пользователя root из домена «example.com» — «root@EXAMPLE.COM». Учетные записи сервисов имеют вид Например, «HTTP/ws-linux.exampel.com@EXAMPLE.COM». Важно отметить, что имена сущностей Kerberos чувствительны к регистру. Рис. 7.6. Аутентификация по протоколу Kerberos Информация обо всех учетных записях, а также их долговременные ключи (в случае пользователя это, например, хэш его пароля, т. е. ключ, кото- рый будет действителен не меньше месяца) хранятся на специальном сервере, называемом центром распределения ключей (Key Distribution Centre — KDC). Когда у пользователя появляется необходимость в использовании некоторого сервиса, то он обращается в центр распределения ключей с запросом кратко- 186 временного сеансового ключа. KDC возвращает ключ в двух вариантах — один зашифрован долговременным ключом пользователя, другой зашифрован долговременным ключом сервиса. Ответ KDC называется билетом, поскольку кроме ключа содержит и некоторую дополнительную информацию. После этого пользователь самостоятельно пересылает билет сервиса, и у них появля- ется некоторый общий секрет, который уже можно использовать как для ау- тентификации, так и для защиты канала (рис. 7.6). Применение доверенного сервера, который хранит секреты всех своих пользователей, дает возможность обойтись без асимметричных алгоритмов шифрования, что делает протокол Kerberos более легким в реализации и управлении. На приведенной схеме видно, что каждый сервис должен хранить собст- венный долговременный ключ. В Unix-системах ключи сервисов хранятся в так называемом keytab-файле (понятно, что данный файл не должен быть дос- тупен для чтения всем пользователям), в ОС Windows ключ хранится в ло- кальной базе учетных записей SAM (стандартными средствами просмотреть информацию о ключе невозможно). Долговременный ключ пользователя, как уже упоминалось выше, — это, например, некоторая хэш-функция его пароля. Таким образом, в приве- денной выше схеме пользователь все равно должен вводить свой пароль при обращении к очередному сервису. Для обеспечения реальной возможности однократной аутентификации схема взаимодействия клиента, сервера и KDC реально несколько отличается от приведенной на рис. 7.6. В процессе аутен- тификации при входе в сеть пользователь получает специальный билет, назы- ваемый ticket granting ticket (TGT), использующийся для аутентификации пользователя в KDC (рис. 7.7). Полученные пользователем билеты сохраняются в специальном защи- щенном кэше (в случае Unix-систем это файл, доступ к которому имеет только пользователь, получивший билет, в Windows — это защищенное хранилище модуля SSPI, т. е. оперативная память). При необходимости билет может пе- реместиться на другой компьютер (например, если пользователь открыл сеанс по SSH или RDP), но при этом действительным он останется только в том случае, если в нем присутствует специальный флаг (соответственно, на KDC можно задавать, какие из пользователей будут получать этот флаг в билете, а какие нет). Из изложенного выше механизма следует, что KDC не аутентифицирует клиента перед самим собой. Аутентификация есть только неявная — смог ли клиент воспользоваться тем сеансовым ключом, который он получил, или нет. Это создает две проблемы: во-первых, злоумышленник может получить билет пользователя и за какое-то время извлечь сеансовый ключ (например, если применялся слабый алгоритм шифрования); во-вторых, злоумышленник мо- жет запросить TGT и после пытаться взломать долговременный ключ пользо- вателя. 187 Рис. 7.7. Механизм однократной аутентификации при помощи вспомогательного билета TGT Первой проблемы на самом деле не существует, поскольку билет Kerbe- ros содержит информацию о своем времени жизни (по умолчанию 8 часов). Поэтому к тому времени, когда злоумышленник сможет извлечь сеансовый ключ, последний окажется уже недействительным. Вторая проблема решается при помощи механизма преаутентифкации. Данный механизм не зафиксирован в RFC 1510, т. е. каждый производитель может добавлять свои механизмы, однако приведен один вариант, который наиболее широко распространен в настоящее время — это преаутентификация по меткам времени. Работает данный механизм следующим образом: клиент в своем запросе, в специальном разделе пакета Kerberos, отправляет зашифро- ванную своим долговременным ключом метку времени, сервер расшифровы- вает эту метку времени и сверяет ее со своим текущим временем. Если разни- ца не превышает некоторого порогового значения (по умолчанию 3 минуты), то считается, что клиент прошел преаутентифкацию, и ему можно выдавать 188 билет. Понятно, что данный механизм требует синхронизации времени между всеми клиентами Kerberos и всеми KDC. 7.3.2. Реализация Kerberos для Unix-систем В Unix-системах распространены две схожие реализации протокола Kerberos — это MIT Kerberos и Heimdal Kerberos. Реализации во многом схо- жи, поэтому рассмотрим канонический вариант 1 от MIT. Все библиотеки и утилиты, имеющие отношение к Kerberos, распреде- лены по нескольким пакетам, в случае Debian Linux это следующие пакеты: − libkrb5 — библиотеки Kerberos (оригинальный интерфейс MIT и GSSAPI интерфейс), − krb5-config — набор примеров конфигурационных файлов Kerberos, − krb5-doc — документация по Kerberos, − krb5-user — набор утилит для управления билетами пользователя (полу- чение, уничтожение, просмотр), − krb5-clients — некоторые клиенты классических сетевых сервисов: ftp, telnet, rsh, rcp и т.п., − krb5-servers — сервер KDC, сервис kadmind для удаленного управления базой KDC. Основой всей системы MIT Kerberos являются, конечно же, библиотеки, которые должны быть правильно настроены для своего функционирования при помощи конфигурационного файла «krb5.conf». Данный файл имеет структуру типичного ini-файла, т.е. он поделен на разделы (каждый раздел на- чинается с имени, заключенного в прямые скобки), внутри раздела перечисле- ны пары <опция> = <значение>. Основными разделами файла krb5.conf явля- ются: − libdefaults — различные значения по умолчанию, − realms — раздел, описывающий информацию об областях Kerberos. Со- стоит из записей вида <имя области> = { набор опций в виде <опция> = зна- чение }, − domain_realm — эта секция описывает принадлежность узла (или целого DNS-домена) к области Kerberos. Она содержит строки вида: name = REALM, где name — может быть имя хоста или имя домена, имя домена выделяется ведущей точкой (т.е., если указать example.com, то это обозначает одноимен- ный узел, а если — .example.com, то весь DNS-домен example.com). Если имя области — это просто имя DNS-домена в верхнем регистре, то соответствую- щую запись можно опустить. Опции раздела libdefaults: − ticket_lifetime — время жизни билета в секундах (не может превышать максимального времени жизни, разрешенного на KDC); 1 Дело в том, что Kerberos был разработан в Массачусетском Технологическом Институте (MIT) 189 − default_realm — имя области Kerberos по умолчанию; − dns_lookup_kdc — разрешить поиск KDC при помощи SRV-записей dns (будет производиться поиск записи _kerberos._udp.<имя домена> или _kerberos._tcp.<имя домена>); − default_tgs_enctype и default_tkt_enctype — какие алгоритмы шифрова- ния будут запрашиваться для билетов и ключей; − kdc_timesync — если значение отлично от 0, то библиотека Kerberos бу- дет пытаться синхронизировать время локальной системы с временем на KDC, однако если время отличается слишком сильно, и на KDC применяется преау- тентификация, то синхронизировать время не удастся; − default_keytab_name — задает имя keytab-файла (файла, хранящего дол- говременные ключи сервисов). По умолчанию используется «/etc/krb5.keytab». Опции раздела realms: − kdc — IP-адрес или имя KDC (также допускается указание порта KDC через двоеточие, по умолчанию используется порт 88 TCP или UDP); − admin_server — IP-адрес или имя сервера с сервисом kadmind, также может содержать номер порта. Управление билетами пользователь осуществляет через 3 основные утилиты: kinit — для получения билетов, klist — для просмотра билетов в кэ- ше и kdestroy — для уничтожения билетов. Утилита kinit, вызванная без параметров, старается получить на KDC TGT для сущности <имя пользователя>@REALM, где REALM берется из па- раметра default_realm файла «krb5.conf». Кроме того, возможен вызов утилиты kinit следующим образом: kinit user@REALM. Такой вызов позволяет за- просить TGT для произвольной сущности Kerberos. Опция -k, указывает, что получать билет для указанной сущности необходимо при помощи ключа, со- храненного в keytab-файле, опция -t позволяет задать расположение keytab- файла, если оно отличается от заданного в «krb5.conf». Утилита klist выводит список всех билетов, полученных данным поль- зователем, или информацию о содержимом keytab-файла. Опция -e позволяет посмотреть типы шифрования для билета и ключа, опция -f выводит флаги каждого билета. Для просмотра содержимого keytab-файла применяется опция -k, если добавить опцию -K, то кроме информации о сущностях в keytab-файле будут выведены также и сами ключи. Утилита kdestroy очищает кэш текущего пользователя. Для того чтобы в дальнейшем обеспечить аутентификацию пользовате- лей рабочей станции ws-linux в домене AD, необходимо произвести настройку клиента Kerberos. ВЫПОЛНИТЬ! 12. На виртуальной машине WS-Linux открыть текстовым редактором файл «/etc/krb5.conf», удалить имеющуюся в нем информацию и внести в него следующую: 190 [libdefaults] ticket_lifetime = 36000 default_realm = EXAMPLE.COM kdc_timesync=1 [realms] EXAMPLE.COM = { kdc = 192.168.0.1:88 } 13. На виртуальной машине DC запустить оснастку «Active Directory Users & Computers» (Start ⇒ Programs ⇒ Administration Tools). 14. В контекстном меню контейнера «Users» выбрать пункт «New ⇒ User». Указать «First Name» и «User logon name» — «root», указать пароль «P@ssw0rd», убедиться, что не отмечен пункт «User must change password at next logon». 15. В консоли виртуальной машины WS-Linux выполнить команду kinit от имени пользователя «root», на запрос ввода пароля ввести «P@ssw0rd». После чего ввести команду klist и убедиться, что ее вывод аналогичен вы- воду, изображенному на рис. 7.8. Рис. 7.8. Вывод билетов пользователя в ОС Linux 7.3.3. Реализация Kerberos в ОС Windows Server 2003 Клиент Kerberos встроен во все ОС Windows семейства NT5, а реализа- ция KDC — во все серверные версии NT5. Однако изначально реализация Kerberos не рассматривалась Microsoft как самостоятельное решение (а лишь только как средство аутентификации в AD), поэтому в стандартной поставке Windows отсутствуют утилиты для работы с Kerberos напрямую. Некоторые возможности предоставляют инструменты из пакетов Support Tools и Resource Kit. Служба KDC активизируется в серверной ОС только при повышении роли сервера до контроллера домена AD. Как уже отмечалось, контроллер до- 191 мена AD — это KDC и LDAP-серверы, плюс некоторые утилиты администри- рования этих серверов. Сущность Kerberos создается параллельно с созданием учетной записи пользователя, при этом происходит прямое отображение име- ни пользователя в сущность Kerberos (пользователю user домена example.com будет сопоставлена сущность «user@EXAMPLE.COM»). Сложнее обстоит ситуация с учетными записями сервисов. Поскольку имя пользователя Windows не может содержать символ «/», то прямого соот- ветствия быть не может. Для разрешения этой проблемы в схеме каталога оп- ределен специальный многозначный атрибут — servicePrincipalName. Минус заключается в том, что все эти сущности Kerberos используют один и тот же ключ. Для обеспечения взаимодействия с Unix-системами пакет Windows Sup- port tools содержит утилиту для создания сущностей Kerberos и экспортирова- ния их ключей в виде keytab-файла. Данная утилита обладает достаточно большим количеством параметров, рассмотрим те из них, которые необходи- мы при создании keytab-файла. Вызов утилиты будет иметь вид: ktpass –princ <сущность> -crypto des-cbc-md5 +desOnly –out Ниже приведены комментарии по каждому из параметров: -princ <сущность> — задает сущность Kerberos; -crypto — задает, для какой криптосистемы следует генерировать ключ (в на- стоящее время реализации от Microsoft и MIT пересекаются только по режиму шифрования des-cbc-md5); +desOnly — указывает, что в базе KDC должен генерироваться ключ только для алгоритма DES; -out +rndPass — генерация случайного ключа; -mapuser -mapop set — указывает, что необходимо заменить сущность по умолчанию (а не добавить к списку servicePrincipalName). Для мониторинга кэша билетов Kerberos используется утилита kerbtray из пакета Windows Resource Kit. После запуска эта утилита размещает свою иконку в системном трее, и по двойному нажатию левой клавиши мыши вы- водит на экран окно со списком билетов пользователя и информации в них. 7.3.4. Пример реализации системы SSO Применение протокола Kerberos для аутентификации достаточно рас- пространено как в сервисах Microsoft, так и в сервисах других производите- лей. Например, Kerberos используется для аутентификации клиента перед 192 web-сервером. Рассмотрим ее на примере модуля mod_auth_kerb для web- сервера Apache. Выполнение следующего задания создаст защищенную web-страницу на сервере Apache, при этом аутентификация для пользователей домена AD бу- дет происходить прозрачно. ВЫПОЛНИТЬ! 16. На виртуальной машине WS-Linux открыть текстовым редактором файл «/etc/apache2/sites-available/default», в разделе # подключить модуль mod_auth_kerb AuthType Kerberos # расположение keytab-файла Krb5Keytab /etc/apache2/http.keytab # разрешить аутентификацию # при помощи сеансового ключа KrbMethodNegotiate on # запретить аутентификацию уровня Basic KrbMethodK5Passwd off # разрешить доступ только # аутентифицированным пользователям Require valid-user 17. На виртуальной машине DC запустить «Windows Support Tools Shell» (Start ⇒ Programs ⇒ Windows Support tools ⇒ Command Prompt) 18. Создать сущность Kerberos, соответствующую учетную запись и keytab- файл для web-сервера Apache. Для этого создать пользователя ws- linux_http при помощи оснастки «Active Directory Users and Computers». Создать файл «keytab» при помощи следующей команды: ktpass –princ HTTP/ws-linux.example.com@EXAMPLE.COM –crypto des-cbc-md5 +desOnly –ptype KRB5_NT_PRINCIPAL –out c:\http.keytab +rndPass –mapuser ws-linux_http@example.com –mapop set 19. Скопировать файл «http.keytab» в каталог «/etc/apache2» виртуальной ма- шины WS-Linux. 20. Перезапустить web-сервер Apache при помощи команды /etc/init.d/apache2 force-reload 193 21. На виртуальной машине DC запустить и настроить обозреватель Internet Explorer. Для этого в меню Tools ⇒ Internet Options выбрать закладку «Se- curity», выбрать зону «Local Intranet», нажать кнопку «Sites», нажать кноп- ку «Advanced», добавить к списку сайтов строку «*.example.com». В раз- деле «Security level for this zone» нажать кнопку «Custom level». Убедиться, что в подразделе «logon» раздела «User authentication» выбран пункт «Automatic logon only in Intranet zone». Перейти на закладку «Ad- vanced». Убедиться, что в разделе «Security» активизирована опция «En- able Integrated Windows Authentication». Если она не была выбрана, то вы- брать и перезагрузить виртуальную машину. 22. Запустить утилиту kerbtray.exe (Start ⇒ Programs ⇒ Windows Resource Kit Tools ⇒ Command Shell, набрать в консоли kerbtray). Просмотреть теку- щий список билетов пользователя, вызвав окно утилиты при помощи иконки в системном трее (иконка в виде билета зеленого цвета). 23. В адресной строке обозревателя набрать «http://ws-linux.example.com». Убедиться, что в обозревателе отобразилась стартовая страница web- сервера Apache. 24. Убедиться, что в списке билетов пользователя добавился билет «HTTP/ws- linux.example.com@EXAMPLE.COM». 25. На рабочей станции WS-Linux выполнить команду tail /var/log/apache2/access.log 26. В выводе команды найти запись, аналогичную представленной на рис. 7.9. Рис. 7.9. Запись в лог-файле web-сервера Apache о доступе Kerberos-сущности «Administrator@EXAMPLE.COM» 27. Попробовать зайти на web-страницу с основной рабочей станции (может понадобиться перенастройка IP-адреса виртуального сетевого подключе- ния VMWare VMNet1, адрес должен быть из сети 192.168.0/24), убедиться, что в окне обозревателя выводится сообщение об ошибке 401 (Unauthor- ized). |