 |
|
|
|
Работаем с NTLM-авторизацией Apache в домене MS Windows 2003
Работаем с NTLM-авторизацией Apache в домене MS Windows 2003 Несбыточный сон каждого пользователя – чтобы компьютер всё делал «сам». Технология NTLM поможет немного приблизить мечту. По крайней мере будет вводить логин и пароль при обращении к сайту для пользователей вашего домена. Многие фирмы создают различные веб-ресурсы для использования только внутри компании (intranet-серверы). Если политика компании позволяет использовать технологии не только «монстра» Microsoft, то выбор часто останавливается на самом популярном http-сервере Apache. Бывает, что веб-ресурсы требуют разделения прав и контроля доступа к некоторым разделам или ко всему сайту. Разделять и контролировать можно различными способами: на уровне ОС (firewall), веб-сервера и средствами самих приложений. Если авторизация во внутренней сетке построена на домене Windows, то разумно использовать доменные аккаунты (чтобы не плодить учетные записи) и прозрачную для конечных пользователей NTLM-авторизацию. Недавно передо мной и была поставлена подобная задача. Особенности инсталляции:
Что имеем на клиенте:
Для авторизации NTLM решено доустановить – samba3 и mod_ntlm_winbind из того же проекта (см. [4, 5]). Другие модули NTLM-авторизации, которые я нашел, с доменом 2003 работать не умеют. NTLM – это набор протоколов проверки подлинности и безопасного использования сессий, используемый в различных сетевых приложениях, преимущественно в сетях Microsoft. Первоначально созданный для работы в службах DCE/RPC, NTLM в данный момент используется всюду в сетевых приложениях Microsoft. Вероятно, это лучший способ для HTTP-авторизации в сетях MS Windows. Кроме упомянутых RPC, HTTP, поддержка NTLM встроена в Exchange-сервер (протоколы SMTP, POP3, IMAP); она так же присутствует в Microsoft – в реализациях CIFS/SMB, Telnet, SIP и, возможно, в каких-то еще. Сеанс NTLM-аутентифицикации работает по принципу запрос-ответ. Он содержит три типа сообщений, также известных как:
Обычно создание NTLM-сессии выглядит следующим образом:
Ответы на 3-м этапе NTLM-сеанса – самая критичная часть диалога, т.к. на этом шаге клиент доказывает серверу свою подлинность. После установки подлинности клиент и сервер обмениваются различной информацией о созданной NTLM-сессии, включая ключ сессии, используемый для последующей подписи операций. Более подробно ознакомиться с описанием стека протоколов NTLM и реализацией этого стека для HTTP-аутентификации можно, следуя по ссылкам [10, 11]. В настоящее время NTLM в значительной степени вытесняется технологией Kerberos, как схемой аутентификации в сценариях внутри домена Windows. Однако в некоторых случаях использовать только Kerberos не представляется возможным, например, если сервер или клиент не входит в домен Windows, или они принадлежат различным доменам. Можно настроить прозрачную для пользователя аутентификацию, используя только технологию Kerberos, без NTLM. По ссылке [13] можно ознакомиться с описанием схемы аутентификации через Kerberos, которая используется Microsoft в своих продуктах (сервер IIS – браузер Internet Explorer). По ссылке [12] – описание способа для связки Apache-Mozilla. Думаю, будет работать и с MS Internet Explorer, не пробовал. Сегодня рассматривается решение, которое использует обе технологии. Клиент (браузер Internet Explorer) использует стек протоколов NTLM для аутентификации у веб-сервера Apache. Веб-сервер, в свою очередь, проверяет подлинность клиента в домене MS Windows, авторизуясь в AD через технологию Kerberos. Подробно с работой технологии Kerberos можно ознакомиться, например, по ссылке [14]. Чтобы при дальнейшем чтении статьи не возникало неясностей, вкратце опишу основные моменты. Обычно участники процесса Kerberos-аутентификации делятся на три категории:
Первый и второй типы участников являются Kerberos-клиентами, которые подтверждают свою подлинность у сервера или «центра» Kerberos – KDC (Key Distribution Center). KDC управляет проверкой подлинности всех Kerberos-клиентов. Чтобы два Kerberos-клиента (клиент приложения и сервер приложения) доказали друг другу свою подлинность, они используют соответствующие удостоверения – «тикеты» (ticket). KDC также управляет распределением тикетов. Подобная схема работы называется сторонней системой идентификации, или системой идентификации у третьего лица (third party authentication system). В нашем случае Samba-сервер как член домена MS Windows обращается с информацией к ADS. Оба подтверждают свою подлинность у KDC (обычно это одна из функций контроллера домена MS Windows). Пакет проверки подлинности Windows Kerberos используется по умолчанию в Microsoft Windows Server 2003, Microsoft Windows XP, и Microsoft Windows 2000 и сосуществует с протоколом запрос/ответ NTLM. По умолчанию максимальный размер пакета, для которого Windows Server 2003 использует протокол UDP, составляет 1465 байт. В зависимости от различных факторов, например истории идентификатора безопасности (SID) и членства в группе, некоторые учетные записи будут иметь больший размер пакетов проверки подлинности Kerberos. В конце концов Microsoft рекомендует использовать службу Kerberos через протокол TCP (см. [2]). А точнее – по UDP Kerberos от Microsoft в Windows 2003 не работает без дополнительных настроек. В нашем случае контроллер домена требует использовать только протокол TCP. Так как это настройки по умолчанию в Windows 2003 – скорее всего они используются на большинстве систем. Видел официальное объяснение от Microsoft на английском языке, но на момент написания статьи не нашел его. Kerberos, поставляемый с Solaris 9 (базируется на MIT KRB5 1.2.1), подобных штучек себе не позволяет. Microsoft об этом честно предупреждает: «обновите UNIX KDC до последней версии протокола, которая поддерживает соединения TCP вместо UDP» (см. [3]). Хотя у нас и клиент Kerberos, а не KDC – обновиться все равно придется. В Solaris 9 по умолчанию нет никаких компиляторов, придется установить gcc. Samba собираем с поддержкой AD, т.е. с ключом --with-ads. Так как сервер Active Directory – это, по большому счету, реализация сервера LDAP от Microsoft, то и Samba при включении функционала клиента AD требует поддержку LDAP. Поэтому используем --with-ldap. Не стал мучаться с LDAP-библиотеками от Sun (SunONE ds), поставил OpenLDAP из пакетов. OpenLDAP потянул за собой соответственно OpenSSL и т. д. (в различных сборках OpenLDAP требования могут отличаться). MIT krb5-1.5 использует BerkeleyDB – установил пакет версии db-4.2.52. Все пакеты для Solaris 9 взяты с сайта [7], это:
Скачиваем, устанавливаем, например, так: # for i in *gz do /usr/bin/gunzip $i done # for i in *local do pkgadd –d $i all done Чтобы установленные библиотеки стали видны остальным программам, пропишем путь к /usr/local/lib в crle: # crle -l /usr/lib:/usr/local/lib Собираем Kerberos Скачиваем исходники (см. [8]). Я использовал файл krb5-1.5-signed.tar – последняя стабильная версия на момент установки. Можно использовать любую, лишь бы выбранная версия работала по TCP как Kerberos-клиент и не возникло проблем при сборке. Судя по файлу ./doc/CHANGES, поддержка TCP на стороне клиента появилась 2002-06-10. Для сравнения – версия Kerberos в стандартной поставке Solaris 9 датирована 2002-04-06. Распаковываем: $ tar xf krb5-1.5-signed.tar $ /usr/sfw/bin/gtar xzf krb5-1.5.tar.gz $ cd krb5-1.5/src Читаем, по желанию: $ more ../README Cобираем: $ ./configure --prefix=/usr/local/mit-krb5 --enable-shared --without-krb4 $ make Ставим: # make install Процесс сборки у меня никаких проблем не вызвал. Пожалуй, единственное, на что стоит обратить внимание, чтобы все нужные для сборки программы и библиотеки были доступны. Переменная PATH у меня выглядела следующим образом (crle у нас уже настроен):
Собираем Samba Скачиваем исходники (см. [4]). Я использовал файл samba-3.0.23a.tar.gz. Как и в случае с Kerberos – это последняя стабильная версия на момент установки. Распаковываем: $ /usr/sfw/bin/gtar xzf samba-3.0.23a.tar.gz $ cd samba-3.0.23a/source Собираем: $ ./configure --prefix=/usr/local/samba --with-ldap --with-ads --with-krb5=/usr/local/mit-krb5 $ make Ставим: # make install Процесс сборки также никаких заметных проблем не вызвал. Программы собраны, теперь надо завести машину в домен MS Windows. Настраиваем DNS Настройки брал со своей рабочей станции:
В Solaris 9 по умолчанию можно использовать как раз три DNS-сервера: $ grep MAXNS /usr/include/resolv.h | grep define #define MAXNS 3 /* max # name servers we'll track */ Пишем в /etc/resolv.conf: nameserver 192.168.0.1 nameserver 192.168.1.1 nameserver 192.168.2.1 domain w2003.domain.inside проверяется DNS командой nslookup, кто запамятовал. Не забываем, что в /etc/nsswitch.conf должна присутствовать строчка: hosts: files dns Она говорит о том, что при разрешении имен компьютеров соответствующая запись будет искаться в файле /etc/hosts, в случае неудачи будет использован протокол DNS. Подробнее с использованием сервисов имен в Solaris 9 можно ознакомиться в man-страницах nsswitch.conf, gethostbyname (разрешение имен хостов) и в Интернете. Настраиваем Kerberos Список контроллеров домена я получил через DNS (на рабочей станции): > nslookup w2003 kdc и admin_server взял первым из списка контроллеров. Хотя правильней, пожалуй, было бы спросить у администраторов домена. В моем случае адреса совпали с DNS-серверами, но это может быть не всегда так. Привожу мой /etc/krb5.conf: $ more /etc/krb5.conf [libdefaults] default_realm = W2003.DOMAIN.INSIDE udp_preference_limit = 1 [realms] W2003.DOMAIN.INSIDE = { kdc = pdc1.w2003.domain.inside admin_server = pdc1.w2003.domain.inside } [domain_realms] .pdc1.w2003.domain.inside = W2003.DOMAIN.INSIDE Строчка: udp_preference_limit =1 говорит как раз о том, чтобы по возможности использовался протокол TCP вместо UDP по умолчанию. Теоретически, клиент должен пытаться использовать TCP, если размер сообщения больше 1 байта. Solaris 9 содержит прекрасный анализатор трафика – snoop, который нам четко показывает, что по одному сообщению UDP клиент и сервер все же умудряются обменяться. Проверяем настройки Kerberos командами: $ /usr/local/mit-krb5/bin/kinit -p domainuser Спросит пароль… Если все в порядке, то: $ /usr/local/mit-krb5/bin/klist Выдаст созданный «тикет». Когда писал статью, нашел в Интернете описание сборки samba3 для работы с ADS под Solaris9 (см. [9]). В ней автор предлагает собрать Samba, используя heimdal-реализацию протокола Kerberos, для чего пришлось сильно пропатчить скрипт configure. Возможно, вариант не самый красивый, но статья оформлена превосходно. Вы можете пользоваться любым способом, главное, чтобы Kerberos работал через TCP. Настраиваем Samba Привожу свой файл smb.conf: [global] workgroup = W2003 # имя домена server string = samba for ntlm netbios name = pebs903x # это имя машине дали администраторы домена netbios aliases = argo # hostname, нам так проще обращаться к машине interfaces = eri0 bind interfaces only = yes # параметры необязательные, просто в момент # настройки на сервере уже работала стандартная # Samba Version 2.2.12, поэтому выбор интерфейса # был критичен domain master = No wins server = 192.168.0.2 # смотрим вывод команды "ipconfiog /all" # в MS Windows на машине из домена name resolve order = wins host realm = W2003.DOMAIN.INSIDE security = ads password server = pdc1.w2003.domain.inside encrypt passwords = yes log level = 0 # возможно, в процессе настройки придется увеличить idmap uid = 10000-20000 idmap gid = 10000-20000 winbind separator = + Если $ /usr/local/samba/bin/testparm отрабатывает без ошибок, можно вводить машину в домен. Когда администраторы домена дали права только завести машину в домен – ничего не вышло. Помучился денёк с пересборкой/перенастройкой Kerberos и Samba. Решилось просто – дали полные права администратора домена – машину добавил. Права забрали. Так что в чем конкретно было дело – сказать не могу. Заводим машину в домен командой: # /usr/local/samba/bin/net ads join -U domainlogin После указанных выше настроек и получения прав администратора домена команда отработала без ошибок. Проверить можно, например, получив список групп домена: # /usr/local/samba/bin/net ads group -U domainlogin Команда snoop в Solaris 9 разбирает LDAP-запросы, что оказалось очень удобным, чтобы посмотреть, какие конкретно запросы формирует Samba к AD. Например, полезно для того, чтобы достать из домена специфичные поля учетной записи пользователя – отображать на сайте имя и фамилию пользователя, вместо логина. Команда: $ net ads search sAMAccountName=Administrator -U adusername покажет нам все поля, которые доступны на чтение для adusername у учетной записи Administrator. Для запуска/остановки Samba использую следующий скрипт: #!/sbin/sh case "$1" in start) [ -f /usr/local/samba/lib/smb.conf ] || exit 0 /usr/local/samba/sbin/smbd -D /usr/local/samba/sbin/nmbd -D sleep 30 /usr/local/samba/sbin/winbindd ;; stop) for i in `/usr/bin/ls ? /usr/local/samba/var/locks/*pid 2>/dev/null` do echo killed pid from file:$i /usr/bin/kill `/usr/bin/cat $i` /usr/bin/rm $i done ;; *) echo "Usage: $0 { start | stop }" exit 1 ;; esac exit 0 Собираем и настраиваем mod_smb_winbind Скачиваем mod_ntlm_winbind.с (см. [5]). Использовать стандартный Makefile (и apxs) не получится, т.к. Apache в Solaris 9 собран компилятором от SUN. Опции будут немного отличаться от gcc. Собираем: $ cc -DSOLARIS2=290 -DMOD_PERL -DEAPI -DUSE_EXPAT -I../lib/expat-lite \ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 \ -DUSE_SO_LINGER -DHARD_SERVER_LIMIT=2048 \ -I/usr/apache/include -Wall -o mod_ntlm_winbind.o -c mod_ntlm_winbind.c Линкуем: $ ld -G -o mod_auth_ntlm_winbind.so mod_ntlm_winbind.o Копируем файл: # cp mod_auth_ntlm_winbind.so /usr/apache/libexec/ Теперь осталось добавить строчки в соответствующие места /etc/apache/httpd.conf: LoadModule ntlm_winbind_module libexec/mod_auth_ntlm_winbind.so AddModule mod_ntlm_winbind.c Перед перезапуском httpd можно проверить синтаксис httpd.conf: $ /usr/apache/bin/httpd –t Если видим фразу «Syntax OK» – перезапускаем Apache: # /etc/init.d/apache restart Проверяем работу модуля, для чего создаем тестовую папку, например: # mkdir /var/apache/htdocs/test-ntlm И в этой папке создаем файл .htaccess со следующими строчками: AuthName "NTLM Authentication AD" NTLMAuth on NTLMAuthHelper "/usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp" NTLMBasicAuthoritative on AuthType NTLM require valid-user Теперь можно использовать переменную REMOTE_USER из «Apache Environment» в своих веб-приложениях. Например, прекрасно работает связка с Nagios. К сожалению, модуль не предоставляет возможности раздавать доступ конкретным пользователям (средствами Apache), но можно авторизовать по группам (из AD), используя ключ --require-membership-of=GROUPNAME в команде ntlm_auth. Успехов!
|
Владимир ВасилькинКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
