HOWTO Настройка интегрированной аутентификации в Apache 2
Материал из Gentoo Linux Wiki
- Вернуться в раздел руководства
| Примечание: В данной статье описывается настройка модуля mod_auth_kerb 5-ой версии, который на данный момент является маскированным и не включен в стабильное дерево портежей |
Содержание |
[править] Вступление
Так уж повелось, что во многих организациях рабочие места и многие сервера находятся под управление операционных систем семейства Microsoft Windows. Не будем вдаваться в размышления на тему хорошо это или плохо, но с этим приходится считаться.
В WEB-сервере Internet Information Server фирмы Microsoft есть очень удобный способ аутентификации пользователей: Integrated Authentification.
Вся прелесть его сводится к тому, что данная аутентификация абсолютно прозрачна для пользователя домена на базе Windows 2000/2003.
Данная статья посвящена тому, как можно настроить аналогичную аутентификацию на Gentoo-сервере при использовании WEB-сервера Apache 2.
[править] Умолчания
Для удобства примем, что:
- домен у нас носит гордое название: COMPANY.RU
- DNS-суффикс домена: company.ru
- домен-контроллеры (Windows 2003): dc1.company.ru, dc2.company.ru
- WEB-сервер: web.company.ru
[править] Необходимые пакеты и утилиты
Gentoo
- net-www/apache-2 - собственно WEB-сервер Apache
- net-www/mod_auth_kerb-5 - модуль для аутентификации при помощи Kerberos
- app-crypt/mit-krb5 - система аутентификации Kerberos
- net-misc/ntp - набор утилит для работы с сервером времени
Microsot Windows
- http://www.dynawell.com/reskit/microsoft/win2000/setupmgr.zip - утилита для сопоставления сервиса и пользователя
- http://www.dynawell.com/reskit/microsoft/win2000/ktpass.zip - утилита для экспорта ключа в файл
[править] Идеология Kerberos
[править] Синхронизация времени с контроллером домена
Для корректной работы аутентификации через Kerberos нужно, чтобы время на серверах и рабочих станциях совпадало. По этой причине в контроллер домена Windows 2000/2003 встроен сервер времени и рабочие станции регулярно устанавливают по нему время.
Нам надо будет добиться того, чтобы на контроллере домена и нашем WEB-сервере было одинаковое время.
Добиться этого можно несколькими путями, например:
- Установить время по наручным часам и регулярно следить за его расхождением :) - флаг в руки.
- Настроить сервер времени и заставить домен-контроллер HOWTO Настройка сервера времени домена использовать его как источник точного времени - самый правильный и самый трудоемкий способ
- Синхронизировать время с контроллером домена - не требует изменений настроек контроллера домена
Я лично предпочел испрользовать последний вариант, так как он даёт удовлетворительную точность синхронизации и, повторяюсь, позволяет не менять настроек контроллера домена.
[править] Настройка ntp-client
Для его реализации необходимо поставить пакет net-misc/ntp: emerge ntp
Далее нужно прописать контроллеры домена в файле /etc/conf.d/ntp-client
| Файл: /etc/conf.d/ntp-client |
NTPCLIENT_OPTS="-Q -b -u dc1.company.ru dc2.company.ru" |
Поставить автоматическую синхронизацию при загрузке системы: rc-update add ntp-client default И синхронизировать время: /etc/init.d/ntp-client start
Проверить установку времени можно коммандой: ntpdate -q dc1.company.ru dc2.company.ru Мы должны получить примерно такой результат:
Looking for host dc1.company.ru and service ntp host found : dc1.company.ru Looking for host dc2.company.ru and service ntp host found : dc2.company.ru server 172.16.10.250, stratum 1, offset -0.024856, delay 0.04147 server 172.16.10.251, stratum 2, offset -0.028786, delay 0.04141 22 Mar 17:22:33 ntpdate[763]: adjust time server 172.16.10.250 offset -0.024856 sec
Этими действиями мы произвели синхронизацию времени и включили её автоматический запуск при загрузке системы.
[править] Настройка автоматической синхронизации по cron-у
Так как сервера могут работать годами без перезагрузки, а часы в них далеко не идеальны, то разумно установить регулярную корректировку времени по таймеру.
Для этого необходимо создать файл примерно следующего содержания:
| Файл: /etc/cron.hourly/ntp-client.sh |
/etc/init.d/ntp-client restart > /dev/null |
После чего дать этому файлу права на исполнение: chmod +x /etc/cron.hourly/ntp-client.sh
| Примечание: Настроить синхронизацию с контроллерами домена через демон ntpd мне так и не удалось. Вероятно это связано с тем, что у Microsoft другая реализация ntp-протокола (sntp) |
| Примечание: |
Чтобы синхронизироватся с сервером MS, в описании сервера надо указать версию протокола NTP -- version 1 (по крайней мере 2000 Server работает в NTP v1)
peer dc1.company.ru version 1 minpoll 4 burst
И сначала настроить службу w32tm, в соответствии с http://support.microsoft.com/kb/816042/ru, по умолчанию ntp сервер не включён.
Сервера внутри сети объявлены как peer поскольку они взаимно синхронизируются.
85.140.251.34 18:18, 19 мая 2007 (UTC)}}
[править] Настройка клиента Kerberos
На данном этапе все просто.
Для начала установим пакет с Kerberos: emerge mit-krb5
Далее пропишем наш домен в конфигурационном файле:
| Файл: /etc/krb5.conf |
[libdefaults]
ticket_lifetime = 600
default_realm = COMPANY.RU
default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
[realms]
COMPANY.RU = {
kdc = dc1.company.ru:88
kdc = dc2.company.ru:88
}
[domain_realm]
.company.ru = COMPANY.RU
company.ru = COMPANY.RU
[kdc]
profile = /etc/krb5kdc/kdc.conf
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log
|
Для проверки попробуем авторизоваться под каким-либо пользователем: kinit myuser Если все было настроено нормально, то у нас должны запросить пароль.
Увидеть, выданный нам на основании этого пароля, билет можно командой: klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: myuser@COMPANY.RU
Valid starting Expires Service principal
03/22/05 17:59:29 03/23/05 03:59:35 krbtgt/COMPANY.RU@COMPANY.RU
renew until 03/23/05 17:59:29
Она выводит список полученных билетов и срок их действия.
[править] Настройка модуля mod_auth_kerb
[править] Сборка модуля mod_auth_kerb-5
По скольку на момент написания этой статьи данный модуль не был включен в стабильную ветвь портежей, то его установка сопряжена с некоторыми трудностями.
Лично я собирал его из исходников. Желающим пойти по моим стопам публикую последовательность комманд для сборки этого модуля без установки нестабильной версии Apache:
| Code: root@localhost:~ |
# Скачиваем нужный пакет ACCEPT_KEYWORDS="~x86" emerge --nodeps --fetchonly =net-www/mod_auth_kerb-5.0_rc6 # Распаковываем исходный код tar -xzf /usr/portage/distfiles/mod_auth_kerb-5.0-rc6.tar.gz -C /usr/src/ # Переходим в директорию с исходниками cd /usr/src/mod_auth_kerb-5.0-rc6 # Создаем Makefile APXS=/usr/sbin/apxs2 ./configure --without-krb4 --with-krb5=/usr # Собираем и устанавливаем модуль make install |
[править] Подключение модуля к Apache
Для того, чтобы Apache увидел данный модуль необходимо создать конфигурационный файл примерно следующего содержания:
| Файл: /usr/lib/apache2/conf/modules.d/11_mod_auth_kerb.conf |
LoadModule auth_kerb_module modules/mod_auth_kerb.so
Krb5Keytab conf/apache.keytab
KrbAuthRealms COMPANY.RU
# Директория /var/www/private у меня не существует.
# Здесь содержится пример директив для включения аутентификации.
<Directory /var/www/private>
AuthType Kerberos
AuthName "Please Login"
Require valid-user
</Directory>
|
В данном файле все относительно понятно, кроме строки
Krb5Keytab conf/apache.keytab
Эта строка указывает на файл, который содержит данные, позволяющие WEB-серверу доказать, что он тот, за кого себя выдает.
К формированию этого файла мы вернемся чуть-позже.
[править] Регистрация WEB-сервера в домене
[править] Создание и проверка conf/apache.keytab
Для работы нам необходимо зарегистрированть HTTP-сервер в домене и получить для него два ключа: host/web.company.ru@COMPANY.RU и HTTP/web.company.ru@COMPANY.RU. Первый ключ нужен для авторизации компьютера в целом, а второй - для авторизации сервиса HTTP.
И хосту и сервису должен быть сопоставлен какой-либо пользователь. Прав ему особых не нужно и имя у него может быть любое. Я лично создал пользователя с именем web_http и паролем qwerty.
На домен-контроллере следующими коммандами:
| Code: C:> |
ktpass -princ host/web.company.ru@COMPANY.RU -pass qwerty -mapuser INFORMTEL\web_http -out host.keytab -ptype KRB5_NT_SRV_HST -kvno 1 ktpass -princ HTTP/web.company.ru@COMPANY.RU -pass qwerty -mapuser INFORMTEL\web_http -out http.keytab -kvno 1 setspn.exe -A HTTP/web.company.ru web |
мы экспортируем ключи для host/web.company.ru@COMPANY.RU и HTTP/web.company.ru@COMPANY.RU в файлы host.keytab и http.keytab, а так же регистрируем сервис HTTP/web.company.ru на хосте web.
Полученные файлы надо каким-либо образом переправить на наш WEB-сервер и создать из них файл conf/apache.keytab. Этот файл создается при помощи утилиты ktutil: ktutil
| Code: ktutil |
ktutil: read_kt host.keytab ktutil: read_kt http.keytab ktutil: list slot KVNO Principal ---- ---- ------------------------------------ 1 1 host/web.company.ru@COMPANY.RU 2 1 HTTP/web.company.ru@COMPANY.RU ktutil: write_kt apache.keytab |
Для успокоени души проверим, записались ли ключи в указанный файл: klist -k apache.keytab
Keytab name: FILE:apache.keytab KVNO Principal ---- ----------------------------------------- 1 host/web.company.ru@COMPANY.RU 1 HTTP/web.company.ru@COMPANY.RU
После чего желательно убедиться, что ключи работоспособны:
| Code: root@localhost:~ |
kinit -t apache.keytab -k host/web.company.ru@COMPANY.RU kinit -t apache.keytab -k HTTP/web.company.ru@COMPANY.RU |
Обе комманды должны отработать тихо и бесшумно. Без вывода каких-либо ошибок на экран.
Финальной точкой данного этапа должно быть копирование файла apache.keytab в /etc/apache2/conf и изменение доступа к нему, для того, чтобы Apache имел возможность его прочитать: chown apache:apache apache.keytab
[править] Создание .cgi-скрипта для проверки аутентификации
| Примечание: Здесь подразумевается, что каталог /var/www/localhost/cgi-bin/ соответствует http://web.company.ru/cgi-bin/ |
Наличие или отсутствие аутентификации надо как-то проверять. Для этих целей нам понадобится простенький .cgi-скрипт:
| Файл: /var/www/localhost/cgi-bin/test.sh |
#!/bin/bash echo "Content-type: text/plain" echo "" echo "Remote-addr: $REMOTE_ADDR" echo "Remote-user: $REMOTE_USER" |
Разумеется, что у данного скрипта должно быть право на выполнение: chmod +x /var/www/localhost/cgi-bin/test.sh После этого при попытке зайти на адрес http://web.company.ru/cgi-bin/ мы должны увидеть примерно следующее:
Remote-addr: 127.0.0.1 Remote-user:
Если это так, то скрипт работает.
После чего включим аутентификацию на данный каталог:
| Файл: /var/www/localhost/cgi-bin/.htaccess |
AuthType Kerberos AuthName "Test" Require valid-user |
Если мы все сделали правильно, то при попытке зайти на страницу http://web.company.ru/cgi-bin/ мы должны получить запрос на аутентификацию и при вводе корректного логина/пароля из домена нам должны вывести ответ следующего вида:
Remote-addr: 127.0.0.1 Remote-user: test
[править] Регистрация WEB-сервера в домене
[править] Дополнительное чтение
- http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/http-sso-1.asp - описание схемы аутентификации в MSDN
- http://modauthkerb.sourceforge.net/configure.html - описание модуля mod_auth_kerb
- http://www.grolmsnet.de/kerbtut/ - описание процедуры настройки mod_auth_kerb под Windows 2000 (англ.)
- http://www.onlamp.com/pub/a/onlamp/2003/09/11/kerberos.html?page=1 - еще одна статья на туже тему (англ.)
- http://modgssapache.sourceforge.net/ - альтернативный модуль аутентификации
