Windows apache доменная авторизация windows

Тема прозрачной авторизации в OTRS с использованием Active Directory неизменно пользуется популярностью. А так как родной средой для OTRS является *nix-среда, первым пунктом в списке стоит настройка прозрачной авторизации веб-сервером Apache пользователей из домена AD. В связи с недавним обновлением системы и переносом ее на другой сервер пришлось еще раз пройти тернистый путь. Как оказалось, есть существенно более короткий и простой путь, нежели описан в ссылках в моей статье. Все действия выполняются из консоли сервера с Apache и не требуют никакого обмена файлами, копи-пасты с контроллером домена и прочей фигни.Фиксирую на память и в помощь коллегам.

Внимание! Данные действия решают задачу прозрачной авторизации пользователей из домена AD на веб-сервере Apache в среде Ubuntu 16.04. Решают ли они еще какие-то задачи (например, авторизацию в консоли с помощью аккаунта из AD), я не знаю, не проверял. Сработает ли решение на другом linux, не знаю, не проверял.

Итак, поехали.

Исходное положение

• Свежеустановленная Ubuntu Server 16.04. Имя сервера ubuntuadmember, запись в DNS присутствует.
• Установленные пакеты Apache и Perl (включая модуль Perl для Apache)
• В Apache настроено исполнение perl-скриптов
• Все перечисленные ниже команды выполняются от учетки root, чтобы не плодить постоянных sudo

Для проверки, что все готово, поместите вот такой скрипт, например, в /var/www/cgi-bin/test.pl, и настройте, чтобы к нему можно было обратиться по http://ubuntuadmember/cgi-bin/test.pl. Скрипт выводит все переменные сервера, а первой строкой специально переменную REMOTE_USER, даже если она пустая. Позже пригодится.

test.pl

#!/usr/bin/perl
 use strict;
 use warnings;

print qq(Content-type: text/plain\n\n);

print "REMOTE_USER -> $ENV{REMOTE_USER}\n\n";

foreach (keys %ENV){
 print "$_ -> $ENV{$_}\n";
 }

Если все работает правильно, получится приблизительно такая картинка:

Обращаю внимание, что переменная REMOTE_USER пустая (в общем списке ее вообще нет), т.е. для сервера подключение не авторизовано, анонимно. Будем устранять.

Ставим нужные пакеты

Нам понадобятся пакеты krb5-user для поддержки авторизации Kerberos в системе, libapache2-mod-auth-kerb для поддержки авторизации Kerberos в Apache и msktutil для создания учетной записи компьютера и всего сопутствующего в AD. Установим их:

apt-get install krb5-user libapache2-mod-auth-kerb msktutil

Настраиваем подключение к AD

Исходные данные про AD:

• Домен, допустим, с названием lab.local
• Контроллер домена 1 с названием dc1.lab.local
• Контроллер домена 2 с названием dc2.lab.local

Необходимо отредактировать файл /etc/krb5.conf и добавить строки в следующие блоки:

[libdefaults]
   default_realm = LAB.LOCAL

[realms]
   LAB.LOCAL = {
      kdc = dc1.lab.local
      kdc = dc2.lab.local
      default_domain = lab.local
      admin_server = dc1.lab.local
   }

[domain_realm]
   .lab.local = LAB.LOCAL
   lab.local = LAB.LOCAL

Да, именно так, с соблюдение регистра букв. В принципе, исходное содержимое /etc/krb5.conf не нужно, но я оставлял. Суеверие?

Создаем учетную запись компьютера в AD

Исходные данные

• У вас есть аккаунт с правами создавать новые учетные записи компьютеров. Пусть он называется admin@lab.local
• Учетная запись компьютера в AD отсутствует
• Вы планируете, что для работы с OTRS будет использовать адрес, совпадающей с именем сервера. В нашем случае имя сервера ubuntuadmember, адрес OTRS http://ubuntuadmember/otrs/index.pl

Предупреждение. В иных случаях могут потребоваться дополнительные действия, и я не знаю, какие именно.

Выполняем логин в AD с помощью аккаунта admin@lab.local

kinit -V admin@LAB.LOCAL

Если нет ошибок — проверка:

klist

Создаем учетную запись компьютера

msktutil -c -s host -s HTTP -s HTTP/ubuntuadmember /
 --computer-name ubuntuadmember --server dc1.lab.local

Эту команду разберем подробнее:

• Ключ -c указывает, что нужно создать учетную запись компьютера.
• Ключи -s указывают, какие значения нужны в атрибуте servicePrincipalName учетной записи компьютера. Если ничего не указать, то не там не будет нужных строчек с префиксом HTTP.
• Ключ —computername указывает имя учетной записи компьютера. Можно пропустить, тогда имя будет соответствовать системному имени сервера.
• Ключ —server указывает имя контроллера домена, на котором будет создана учетная запись. Можно пропустить, тогда будет предпринята попытка самостоятельно определить имя.

!!! Внимание !!! Внимание !!! Внимание !!!
У утилиты msktutil есть ключ —verbose, который призван сделать вывод результатов работы утилиты на экран более «человекочитаемым». Однако в x64 версии тулзы содержится баг, при котором запуск с ключом —verbose останавливается с ошибкой, а без него отрабатывает корректно! Вроде как в x86 версии бага нет. Не попадитесь на этот дешевый трюк, не теряйте время, как я.

Если все сработало, в AD в контейнере Computers должна появиться учетная запись, в нашем случае, ubuntuadmember.

Выставим нужные права на файл с ключами

chown root.www-data /etc/krb5.keytab
chmod 0640 /etc/krb5.keytab

Настроим Apache на авторизацию

Предупреждение. Следующие настройки включают авторизацию Kerberos для всего дефолтного сайта. Если нужно включить более тонко, курите мануалы.

Отредактируем файл /etc/apache2/sites-enabled/000-default.conf и добавим в него перед </VirtualHost> следующий блок:

<Location />
 AuthType Kerberos
 AuthName "Kerberos Login"
 KrbMethodK5Passwd off
 Krb5Keytab /etc/krb5.keytab
 KrbServiceName HTTP/ubuntuadmember.lab.local@LAB.LOCAL
 Require valid-user
</Location>

Выделено красным:

• /etc/krb5.keytab — дефолтный путь к файл с ключами. Если хотите поменять, не забудьте переместить и файл
• HTTP/ubuntuadmember.lab.local@LAB.LOCAL — должен в точности совпадать с названием компьютера и доменом

После внесения изменений нужно рестартовать Apache

service apache2 restart

Настройка закончена

Если все сработало, вызов http://ubuntuadmember/cgi-bin/test.pl должен показать такую картинку (скрин с реального сервера, поэтому цензура). Обратите внимание на REMOTE_USER, там доменная учетка в формате username@DOMAIN. Если делать вызов с доменной машины и от доменного пользователя, а браузер настроен (сайт в зоне Интранет), то авторизация пройдет прозрачно без лишних вопросов. В противном случае просто появится стандартный запрос на ввод логина и пароля.

Блин, хотел покороче, но получилось все равно длинно. Попробую еще раз:

### install modules
apt-get install krb5-user libapache2-mod-auth-kerb msktutil
### edit /etc/krb5.conf for your AD
nano /etc/krb5.conf
### login with AD admin permissions
kinit -V admin@LAB.LOCAL
### create computer account
msktutil -c -s host -s HTTP -s HTTP/ubuntuadmember /
 --computer-name ubuntuadmember --server dc1.lab.local
### change permissions on keytab file
chown root.www-data /etc/krb5.keytab
chmod 0640 /etc/krb5.keytab
### edit apache config
nano /etc/apache2/sites-enabled/000-default.conf
### restart apache
service apache2 restart
### USE and ENJOY

Во, так гораздо лучше! Замечания/вопросы/дополнения пишите в комментах.

Почти в каждой организации используется домен Microsoft Windows, в котором пользователи проходят проверку подлинности. Так же часто в IT инфраструктуре используются сервисы, предоставляемые различными дистрибутивами linux. При выдаче прав доступа администраторам windows и linux приходится вести различные базы пользователей, что конечно не удобно. Реализовав единую базу данных пользователей и прозрачную аутентификации для пользователей (single sign on) можно избавится от массы рутинной работы и устранить риски безопасности. В данном случае реализуем прозрачный доступ пользователей к некому web ресурсу. Для аутентификации будет использоваться протокол Kerberos и «Key Distribution Center» (KDC) реализованный в контроллере домена Windows. В качестве linux системы рассматривается rhel5, для других дистрибутивов возможны не принципиальные отличия в процессе настройки. Если у вас дистрибутив отличный от указанного, то стоит проверить версию библиотеки Kerberos, она должна быть не младше чем 1.5 (MIT Kerberos), т.к. начиная с этой версии поддерживается механизм согласования метода аутентификации SPNEGO (Simple and Protected Negotiate). Веб сервер должен иметь A запись на вашем днс сервере т.к. имя ресурса является частью Kerberos билета. Процесс аутентификации описан в RFC1510, обязательно прочтите как проходит процесс аутентификации.

Термины и команды:
realm — область использующая единую базу Kerberos. По соглашению реалм записывается строчными буквами, для отличия от днс домена.
principal — имя которому поставлено в соответствие набор учетных данных. Делится на три части: 1)primary — первая чать принципала Kerberos. Если это пользователь, то соответствует его имени. Если сервис — имя сервиса. 2)instance — вторая часть, служит для уточнения первой части. Может не содержатся в имени принципала, если есть — то это описание. В случае хоста — его fqdn. 3)realm — реалм идет последней частью.
ticket — набор временных данных которые подтверждают идентичность клиента или сервиса.
TGT — Ticket-Granting Ticket. Билет дающий право на получение других билетов в реалме, где был он выпущен.
keytab — файл содержащий ключи, хост или сервис использует его точно таким же образом как пользователь использует пароль.
KDC — Key Distribution Center, сервер выдающий билеты.
kinit — программа, используется для начала процесса аутентификации принципала и получения билета TGT.
klist — программа, выводит список принципалов и Kerberos билетов содержащихся в кеше, или список список ключей в keytab файле.
kvno — получает билет для указанного принципала и выдает на терминал версию ключей.
ktutil — позволяет управлять записями в keytab файле.

Начальные условия:
локальная сеть — 192.168.1.0/24
сервер Active Directory — dc01.domain.ru(192.168.1.1)
веб сервер — web.domain.ru (192.168.1.130)

Действия по шагам:
Настраиваем синхронизацию времени. 
Установите и настройте службу ntpd. В качестве сервера точного времени нужно использовать сервер Active Directory. Протокол Kerberos требует что бы время у участников аутентификации было синхронизировано.

[root@server ~]# yum install ntpd

Выполните начальную синхронизацию времени с контроллером домена:

[root@server ~]# ntpdate dc01.domain.ru

Конфигурационный файл даемона ntpd:

[user@server ~]$ egrep -v «^#» /etc/ntp.conf
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server dc01.domain.ru
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
keys /etc/ntp/keys

Проверить состояние службы синхронизации времени можно командой:

[user@server ~]$ ntpstat
synchronised to NTP server (192.168.1.1) at stratum 5
   time correct to within 300 ms
   polling server every 512 s

Настройка Kerberos на web.domain.ru.
Ниже приведена минимальная конфигурация для использования протокола аутентификации в реалме domain.ru. Реалм в данном случае будет совпадает с доменом Windows. Обратите внимание, для работоспособности Kerberos, реалм должен быть написан прописными буквами!

[user@server ~]$ cat /etc/krb5.conf
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = DOMAIN.RU
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 forwardable = yes

[realms]
 DOMAIN.RU = {
  kdc = dc01.domain.ru
  admin_server = dc01.domain.ru
 }

[domain_realm]
 .domain.ru = DOMAIN.RU
 domain.ru = DOMAIN.RU

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }

Если у вас в сети несколько контроллеров домена то вы можете их перечислить в секции [realms], что то вроде:

[realms]
 DOMAIN.RU = {
  kdc = dc01.domain.ru
  kdc = dc02.domain.ru
  admin_server = dc01.domain.ru
  admin_server = dc02.domain.ru
 }

Проверить работоспособность Kerberos можно с помощью kinit, и учетной записи в домене Windows. Данная команда позволяет для принципала (в данном случае для пользователя домена) получить TGT билет и поместить его в кеш. Содержимое кеша можно посмотреть командой klist:

[user@server ~]$ kinit domain_user@DOMAIN.RU
[user@server ~]$ klist

Ticket cache: FILE:/tmp/krb5cc_500
Default principal: domain_user@DOMAIN.RU

Valid starting     Expires            Service principal
03/22/11 17:43:35  03/23/11 03:43:38  krbtgt/DOMAIN.RU@DOMAIN.RU
renew until 03/23/11 17:43:35

Далее нам нужно создать аккунт сервера в в Active Directory и связать его с принципалом сервиса  в KDC. Можно сделать это самостоятельно на котроллере домена. Создать сначала аккаунт, а затем связать его с принципалом с помощью команды ktpass. Но мне больше нравится вариант с установкой samba и вводом сервера в домен, в этом случае аккаунт и принципал службы создаются автоматически. Как плюс, samba позволит нам в будущем организовать сетевые ресурсы и получать информацию из AD для разграничения доступа к службам сервера.

Настройка samba, добавление сервера web.domain.ru в домен Windows
Устанавливаем samba:

[root@server ~]# yum install samba

В конфигурации samba необходимо указать используемый реалм, указать что будет используется keytab файл, и указать что самба работает как член домена AD — параметр security=ads. Конфигурация samba достаточная для наших целей приведена ниже:

[root@server ~]# cat /etc/samba/smb.conf
[global]
workgroup = DOMAIN
realm = DOMAIN.RU
server string = Samba Server Version %v
security = ADS
passdb backend = tdbsam
 use kerberos keytab = Yes
local master = No
cups options = raw

Проверить правильность конфигурационного файла можно командой 

[root@server ~]# testparm

Если ошибок нет, то самое время добавить наш сервер в домен Windows, естественно что нужно это делать имея полномочия на добавление в домен:

[root@server ~]# net ads join -U win_admin

win_admin’s password:
Using short domain name — DOMAIN
Joined ‘WEB’ to realm ‘DOMAIN.RU’

Если днс зона на контроллере домена не обновилась, то можно или вручную добавить запись A типа и ассоциированную с ней запись PTR или попытатся провести регистрацию имя сервера в днс следующим образом:

[root@server ~]# net ads dns register -I 192.168.1.130 -U win_admin

Проверить корректность добавления сервера в домен можно следующим образом:

[root@server ~]# net ads testjoin
Join is OK

Создание файла keytab, добавление ключа принципала сервиса «HTTP» в keytab.
Создадим keytab файл. Так как в конфигурации samba не оговорено где должен содержатся keytab файл, то будет создан файл по умолчанию /etc/krb5.keytab:

[root@server ~]# net ads keytab create -U win_admin

Теперь создадим и добавим принципал для сервиса — «HTTP», Если вы сейчас посмотрите, на контроллере домена, через консоль MMC и остнастку ADCI Edit параметр «servicePrincipalName», какие принципалы сервисов созданы для нашего сервера — это будут: «HOST/web.domain.ru» и «HOST/web».

[root@server ~]# net ads keytab add HTTP -U win_admin

Если вы теперь посмотрите в список принципалов, то заметите, что там добавились еще два — «HTTP/web.domain.ru» и «HTTP/web». В принципе это уже значит что добавление прошло успешно. Тем не менее, давайте посмотрим что сейчас находится в keytab:

[root@server ~]# klist -ek /etc/krb5.keytab 
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
—- —————————————————————————
   2 host/web.domain.ru@DOMAIN.RU (DES cbc mode with CRC-32) 
   2 host/web.domain.ru@DOMAIN.RU (DES cbc mode with RSA-MD5) 
   2 host/web.domain.ru@DOMAIN.RU (ArcFour with HMAC/md5) 
   2 host/web@DOMAIN.RU (DES cbc mode with CRC-32) 
   2 host/web@DOMAIN.RU (DES cbc mode with RSA-MD5) 
   2 host/web@DOMAIN.RU (ArcFour with HMAC/md5) 
   2 WEB$@DOMAIN.RU (DES cbc mode with CRC-32) 
   2 WEB$@DOMAIN.RU (DES cbc mode with RSA-MD5) 
   2 WEB$@DOMAIN.RU (ArcFour with HMAC/md5) 
   2 HTTP/web.domain.ru@DOMAIN.RU (DES cbc mode with CRC-32) 
   2 HTTP/web.domain.ru@DOMAIN.RU (DES cbc mode with RSA-MD5) 
   2 HTTP/web.domain.ru@DOMAIN.RU (ArcFour with HMAC/md5) 
   2 HTTP/web@DOMAIN.RU (DES cbc mode with CRC-32) 
   2 HTTP/web@DOMAIN.RU (DES cbc mode with RSA-MD5) 
   2 HTTP/web@DOMAIN.RU (ArcFour with HMAC/md5) 

Для полной уверенности можно получить Kerberos билет от KDC для только что заведенных принципалов:

[root@server ~]# kvno HTTP/web.domain.ru@DOMAIN.RU HTTP/web@DOMAIN.RU

HTTP/web.domain.ru@DOMAIN.RU: kvno = 2
HTTP/web@DOMAIN.RU: kvno = 2

Обратите внимание, что версия ключа идентична. Посмотрим эти билеты подробнее (в выводе только интересующие нас билеты):

[root@server ~]# klist -e
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: domain_user@DOMAIN.RU

Valid starting     Expires            Service principal
03/25/11 15:37:04  03/26/11 01:35:17  HTTP/web.domain.ru@DOMAIN.RU
renew until 03/26/11 15:35:14, Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5 
03/25/11 15:42:26  03/26/11 01:35:17  HTTP/web@DOMAIN.RU
renew until 03/26/11 15:35:14, Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5

Обратите внимание что номера ключей билетов (колонка KVNO), имя принципала в билете и алгоритмы шифрования должны совпадать! Рекомендуется создать свой keytab для службы HTTP, где будет содержатся только нобходимые нам ключи. Сделать это можно с помощью ktutil. Расширеных функций редактирования он не поддерживает, поэтому его можно запустить через rlwrap:

[root@server ~]# rlwrap ktutil

Загрузим содержимое keytab

ktutil:  read_kt /etc/krb5.keytab

Посмотрите текущие записи:

ktutil:  list

Нас интересуют записи в которых фигурирует метка «HTTP». Удалите все лишние записи, указав в команде удаления ненужный слот записи:

ktutil:  delent 1

Должно получится так:

ktutil:  list
slot KVNO Principal
—- —- ———————————————————————
   1    2                  HTTP/web.domain.ru@DOMAIN.RU
   2    2                  HTTP/web.domain.ru@DOMAIN.RU
   3    2                  HTTP/web.domain.ru@DOMAIN.RU

Сохраним оставшиеся в другой keytab файл:

ktutil:  write_kt /etc/httpd/httpd.keytab

Сменим права доступа:

[root@server ~]# chown apache:apache /etc/httpd/httpd.keytab
[root@server ~]# chmod 0440 /etc/httpd/httpd.keytab

Переходим к заключительной части.

Установка и настройка mod_auth_kerb.
Установим модуль mod_auth_kerb:

[root@server ~]# yum install mod_auth_kerb

Вы обнаружите файл /etc/httpd/conf.d/auth_kerb.conf содержащий пример настройки mod_auth_kerb. Воспользуемся этим примером как отправной точкой. В примере ниже примере аутентификация требуется только к части сайта web.domain.ru/private. Параметр KrbServiceName должен содержать имя принципала сервиса (и соответственно ключ), которое будет использовать apache для аутентификации. На место расположения файла keytab указывает параметр Krb5KeyTab. Используйте SSL если вы включите параметр KrbMethodK5Passwd. Данный параметр  включает аутентификацию с поддержкой ввода логин/пароль, причем они будут посланы по сети практически чистым текстом ( кодировка Base64 очень слабая )

[root@snort conf.d]# cat /etc/httpd/conf.d/auth_kerb.conf

Такой вариант настройки не очень удобен в плане гибкости. Гораздо удобнее настроить аутентификацию в .htaccess файле. Прежде чем будете пробовать второй пример — приведите к первоначальному виду файл /etc/httpd/conf.d/auth_kerb.conf, т.е. все закоментированно кроме строчки с загрузкой модуля.

[root@snort ~]# cat /var/www/html/.htaccess
#SSLRequireSSL
AuthType Kerberos
AuthName «Kerberos Login»
KrbMethodNegotiate On
KrbMethodK5Passwd Off
KrbAuthRealms DOMAIN.RU
Krb5KeyTab /etc/httpd/httpd.keytab
KrbServiceName HTTP
#require user win_user@DOMAIN.RU win2_user@DOMAIN.RU
require valid-user

В обоих этих примерах доступ получают все пользователи прошедшие аутентификацию. Можно настроить избирательный доступ, указав принципалы пользователей. В обоих примерах эта строка с указанием списка принципалов закомментирована. Не удобно в эксплуатации? Конечно гораздо удобнее, вдобавок к аутентификации, предоставлять доступ на основании членства в группе, которая содержится в Active Directory. Но это в следующий раз. А сейчас действительно последняя часть.

Настройка интернет браузеров.
Начнем с internet explorer 8. Во вкладке «Безопасность» окна «Свойства обозревателя» выделите «Местная интрасеть» и нажмите на «Узлы».

В появившемся окне нажмите «Дополнительно»

Впишите свой домен как на примере:

Закройте окно, и нажмите на кнопку «Другой» в области «Уровень безопасности для этой зоны». Отметьте параметр автоматического входа в систему как показано на рисунке.

Теперь в окне «Свойства обозревателя» перейдите во вкладку «Дополнительно», и включите параметр «Разрешить встроенную проверку подлинности Windows». Для того что бы настройки вступили в силу, браузер необходимо перезапустить.

Перейдем к настройке Mozilla Firefox, здесь все проще и без перезапусков. Наберите в адресной строке «about:config», в строке фильтра — «network.neg». Впишите свой домен в две строки, как показано на рисунке.

Настройка авторизации NTLM в Apache, установленном во FreeBSD, по доменной группе пользователей, как оказалось, – задача не совсем тривиальная.

Первое, что я попытался сделать – это использовать модуль Apache authnz_ldap_module, по использованию которого в интернете полно информации. Сначала я столкнулся с тем, что авторизация не проходит и сервер отвечает на запрос страницы внутренней ошибкой. Немного покопавшись я сообразил, что все дело в кодировках: локаль у меня koi8-r, а в AD используется, как известно, utf8. Набросав небольшой скрипт на perl, я перевел конфиг Apache в кодировку utf8. После этой операции я смог авторизовать любого пользователя домена (Require valid-user), конкретного пользователя домена (Require ldap-user), но почему-то не смог авторизовать по группе. Потратив n-ное количество времени я понял, что пользователь должен находится в том же OU, что и группа. Это меня очень удивило, так как не совсем понятно, зачем нужна такая странная авторизация. Может я что-то делал не правильно, но в итоге решил отказаться от использования модуля authnz_ldap_module и сделать авторизацию приблизительно на такой же основе, как и авторизацию Squid, используя Samba и модуль auth_ntlm_winbind_module.

Сразу скажу, что готового пакета под FreeBSD я не нашел и пришлось пользоваться тем, что нашлось на просторах интернета, но об этом ниже.

Для успешного разрешения задачи мне понадобилось установить из портов Apache, heimdal, Samba 3 и найти в интернете архив с модулем auth_ntlm_winbind_module. Итак, по порядку.

Первое – это установка Apache. В этом нет ничего сложного и ужасного, особенно при установке портов: make config и make install clean.

Далее устанавливаем heimdal (с опциями по умолчанию) и Samba (тут я оставил практически все по умолчанию, отметив только опции LDAP, ADS, WINBIND).

Теперь производим манипуляции с конфигурационными файлами. Сначала разберемся с Kerberos, создав файл /etc/krb5.conf, заполнив его приблизительно следующим содержимым:

[libdefaults]
ticket_lifetime = 24000
default_realm = DOMAIN.RU
dns_lookup_realm = false
dns_lookup_kdc = false

[realms]
DOMAIN.RU = {
kdc = server1.domain.ru:88
kdc = server2.domain.ru:88
}

[domain_realm]
.domain.ru = DOMAIN.RU
domain.ru = DOMAIN.RU

[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}

У меня два доменных контроллера, соответственно, поэтому в разделе realms я указал два kdc. Также нужно заметить, что в этом файле очень важен регистр букв.

Следующий файл – это файл с настройками Samba. Мне не нужна вся функциональность Samba, поэтому дефолтовый конфигурационный файл я переименовал в smb.conf.old и создал новый /usr/local/etc/smb.conf:

[global]
workgroup = DOMAIN
netbios name = svn
realm = domain.ru
server string = svn
hosts allow = 192.168 127.0.0.1

winbind separator =+

winbind use default domain = yes
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes

template homedir = /tmp/winnt/%D/%U
template shell = /bin/bash

max log size = 50
security = ADS
auth methods = winbind

password server = server1 server2
passdb backend = smbpasswd
case sensitive = no

Теперь нужно получить билет Kerberos при помощи команды kinit:

kinit –p administrator

Теперь добавляем в файл /etc/rc.conf автозапуск Apache (если до этого не добавили) и демонов Samba:

apache22_enable=»YES»
smbd_enable=»YES»
nmbd_enable=»YES»
winbindd_enable=»YES»

И пробуем запуcтить smbd, nmbd, winbindd вручную.Теперь проверяем работу winbindd при помощи команды wbinfo –p, на которую правильной реакцией является ответ «Ping to winbindd succeeded on fd 4».

Следующим шагом будет добавление машины в домен. Эта простая операция выполняется следующей командой:

net rpc join –S server1 –w DOMAIN –U administrator

Итак, наша машина теперь – полноправный член домена.

Как я уже говорил выше, найти модуль под FreeBSD не удалось, но зато нашелся модуль под Debian. Самое главное, чтобы в найденном архиве был файлик mod_auth_ntlm_winbind.с, который нужно скомпилировать и установить. Делаем это следующим образом:

/usr/local/sbin/apxs -DAPACHE2 -c -i mod_auth_ntlm_winbind.c

Теперь приступаем к последней стадии – настройке конфигурационного файла Apache. Перед этим создаем тестовую директорию /usr/local/www/apache22/data/test, в которой создаем тестовый файл index.html с любым содержанием. Итак, добавляем в конфиг /usr/local/etc/apache22/httpd.conf строку загрузки нашего модуля:

LoadModule auth_ntlm_winbind_module libexec/apache22/mod_auth_ntlm_winbind.so

и правила доступа к нашей тестовой директории, в виде вот такого блока:

<Directory «/usr/local/www/apache22/data/test»>
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
AuthName «NTLM Authentication»
AuthType NTLM
NTLMAuth on
NTLMAuthHelper «/usr/local/bin/ntlm_auth —helper-protocol=squid-2.5-ntlmssp —require-membership-of=SID«
NTLMBasicAuthoritative
AuthType NTLM
require valid-user
</Directory>

Где SID – это SID группы, которой требуется доступ к этой папке.

Ну и напоследок покажу как при помощи PowerShell быстренько получить SID нужной нам группы:

$sid = (new-object system.security.principal.NtAccount(«group_name «))
$sid.translate([system.security.principal.securityidentifier]) | Format-List Value

Why Authenticate Apache against Windows AD?

• It is quick to implement
• Nobody likes to have multiple accounts. It’s a human thing to forget usernames and passwords
• There is no need to recreate each single account
• Everything is centralised. Access to the web server is denied if the AD accounts is disabled
• Give access to users who belongs to Active Directory groups

Bind to Active Directory

Active Directory is LDAP (Lightweight Directory Access Protocol) compliant, meaning you can run queries to retrieve information about users and computers on the domain. You can use the ldapsearch client to browse its structure. However, you need to create a special user who binds to the domain controller to get users details.

• Connect to your domain controller and create a new user in “Active Directory Users and Computers”.
• Untick “User must change password at next logon”.
• Username and password will be needed to bind the Apache server to the domain controller.

Next step is to get your LDAP domain name. We’ll assume it is ‘location.company.com’. If you don’t know it, run through the following procedure to find out.
Run ldp.exe on the domain controller.
Click on ‘Connection’ -> ‘Connect’ from the top menu and leave ‘localhost’ in the bottom field.
Click then ‘Connection’ -> ‘Bind’ from the top menu and enter details of the user you have created earlier.
Go now to ‘Browse’ -> ‘Search’ and press ‘enter’. This will return a list of all objects present in the directory. It is a bit austere but you can easily find lines of users on your system. An entry should be similar to this:
 

Dn: CN=John Doe,CN=Users,DC=location,DC=company,DC=com
objectClass: top; person; organizationalPerson; user;
cn: John Doe;
description: John Doe;

 
We are now going to configure the Apache module.
 

Configure Apache Authentication

Check that mod_auth_ldap or mod_authz_ldap is activated in httpd.conf in the load modules section. The module configuration can be added in httpd.conf but it’s always a good idea to keep it in a separate file. Apache on Redhat stores module config files in /etc/httpd/conf.d/. I added the following lines into authz_ldap.conf:
 

<Location /protected>
Order deny,allow
Allow from all
AuthBasicProvider ldap
AuthzLDAPAuthoritative Off
AuthLDAPURL
ldap://your-domain-controller:389/CN=Users,DC=location,DC=company,DC=com?sAMAccountName?sub?(objectClass=user)
# Or eventually with a filter on a group
# ldap://your-domain-controller:389/CN=Users,DC=location,DC=company,DC=com?sAMAccountName?
# sub?(memberOf=CN=MyGroup,CN=Users,DC=location,DC=company,DC=com)
AuthLDAPBindDN cn=myusername,cn=Users,dc=location,dc=company,dc=com
AuthLDAPBindPassword mypassword
AuthType Basic
AuthName "Protected"
require valid-user
</Location>

 
myusername and mypassword must match user and pass you’ve created to bind to Active directory.
Finally, restart the Apache service, you’re done! A window asking for a username and password will pop up when accessing the directory “protected”.
 

Notes on Authentication

<Location "/pub">
    Order allow,deny
    Allow from any
    Satisfy any
</LocationMatch>

Related

I would like to thank my great workmate Phil for helping me out with this. Visit his webpage at www.brassy.net.

Tags: Apache, Authentication, ldap, linux, Windows