Работаем с NTLM-авторизацией Apache в домене MS Windows 2003

Владимир Василькин

Работаем с NTLM-авторизацией Apache в домене MS Windows 2003

Несбыточный сон каждого пользователя – чтобы компьютер всё делал «сам». Технология NTLM поможет немного приблизить мечту. По крайней мере будет вводить логин и пароль при обращении к сайту для пользователей вашего домена.

Многие фирмы создают различные веб-ресурсы для использования только внутри компании (intranet-серверы). Если политика компании позволяет использовать технологии не только «монстра» Microsoft, то выбор часто останавливается на самом популярном http-сервере Apache. Бывает, что веб-ресурсы требуют разделения прав и контроля доступа к некоторым разделам или ко всему сайту. Разделять и контролировать можно различными способами: на уровне ОС (firewall), веб-сервера и средствами самих приложений.

Если авторизация во внутренней сетке построена на домене Windows, то разумно использовать доменные аккаунты (чтобы не плодить учетные записи) и прозрачную для конечных пользователей NTLM-авторизацию.

Недавно передо мной и была поставлена подобная задача. Особенности инсталляции:

• Первое – сервер Sun sparc, ОС соответственно Solaris 9. Есть своя специфика, но приведенное решение должно работать на большинстве других ОС.
• Второе – как обычно, как можно меньше трогать системные настройки и настройки других программ на сервере.
• Третье, самое интересное – домен в моей организации самый модный, Active Directory (AD или ADS в дальнейшем) на сервере Windows 2003 со всеми возможными новшествами. Отношения к управлению доменом я никакого не имею, этим занимаются совершенно другие люди. В этой сетке я просто пользователь.

Что имеем на клиенте:

• Solaris 9 9/04.
• Apache (Apache/1.3.31) из стандартной поставки Solaris 9.

Для авторизации 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-аутентифицикации работает по принципу запрос-ответ. Он содержит три типа сообщений, также известных как:

• Type 1 – начало переговоров.
• Type 2 – запрос.
• Type 3 – аутентификация (проверка подлинности).

Обычно создание NTLM-сессии выглядит следующим образом:

• Клиент посылает сообщение 1-го типа на сервер. Это сообщение содержит список опций, поддерживаемых клиентом и запрашиваемых у сервера.
• Сервер отвечает сообщением 2-го типа. Второе сообщение содержит список опций, принятых сервером. Более того, часто в этом сообщении передается дополнительный запрос, генерируемый сервером.
• Клиент отвечает на запрос сообщением 3-го типа, где содержится различная информация о клиенте (в том числе домен, имя пользователя, пароль) и информация, запрошенная сервером на второй стадии 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-аутентификации делятся на три категории:

• клиентская часть сетевого приложения (client);
• серверная часть сетевого приложения (application server);
• сервер аутентификации Kerberos (часто используется аббревиатура KDC).
• Наверное, иногда можно добавить и четвертого участника – злоумышленника, но подробные вопросы безопасности сетевых технологий выходят за рамки данной статьи.

Первый и второй типы участников являются 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], это:

• SMCgcc342;
• SMCiconv;
• SMCossl98b;
• SMCsasl;
• SMColdap;
• SMCdb.

Скачиваем, устанавливаем, например, так:

#  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.

Успехов!

1. http://httpd.apache.org.
2. http://support.microsoft.com/kb/244474.
3. http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx.
4. http://de.samba.org/samba.
5. http://download.samba.org/ftp/unpacked/lorikeet/mod_ntlm_winbind.
6. http://www.unixdoc.ru/index.php?mode=2&podmode= 1&arcicle_id=145&theme=Samba%20ADS.
7. http://www.sunfreeware.com/indexsparc9.html.
8. http://web.mit.edu/Kerberos/dist/index.html.
9. http://shearer.org/Solaris9_Samba_ADS.
10. http://davenport.sourceforge.net/ntlm.html.
11. http://devel.squid-cache.org/ntlm/client_proxy_protocol.html.
12. http://meta.cesnet.cz/cms/opencms/en/docs/software/devel/negotiate.html.
13. http://meta.cesnet.cz/cms/opencms/en/docs/software/devel/draft-brezak-spnego-http-04.txt.
14. http://gazette.linux.ru.net/lg82/shekhar.html.

Комментарии могут оставлять только зарегистрированные пользователи