Простое ограничение доступа по паролю.
Первое, что я попытался сделать – это использовать модуль 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.
Теперь производим манипуляции с конфигурационными файлами. Сначала разберемся с Kerberos, создав файл /etc/krb5.conf, заполнив его приблизительно следующим содержимым:
ticket_lifetime = 24000
default_realm = DOMAIN.RU
dns_lookup_realm = false
dns_lookup_kdc = false
DOMAIN.RU = {
kdc = server1.domain.ru:88
kdc = server2.domain.ru:88
}
.domain.ru = DOMAIN.RU
domain.ru = DOMAIN.RU
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:
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.s o
и правила доступа к нашей тестовой директории, в виде вот такого блока:
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
Где SID – это SID группы, которой требуется доступ к этой папке.
Ну и напоследок покажу как при помощи PowerShell быстренько получить SID нужной нам группы:
$sid = (new-object system.security.principal.NtAccount("gro up_name "))
$sid.translate() | Format-List Value
Используя стандартные модули Apache, возможно запрашивать логин и пароль у пользователя при попытке доступа к определенной странице или каталогу. Доступ будет разрешен, если логин и пароль присутствуют в специальном файле.
Создание файла с паролями
Файл с учетными данными обычно называется .htpasswd и располагается в каталоге, доступ к которому необходимо ограничить. По умолчанию в Apache запрещен доступ ко всем файлам, которые начинаются на .ht , так что файл с паролями, как и файл .htaccess , не сможет быть прочитан ни одним посетителем вашего сайта.
В каждой строке файла хранятся данные об одном пользователе. Логин и зашифрованный пароль разделены двоеточием. Пример:
Admin:YFC5nYLiUI2ig vasya:bnqw1eZHP2Ujs
Для шифрации паролей применяется утилита htpasswd
, которая поставляется в комплекте с Apache. Чтобы создать новый файл с данными о
пользователе admin
, введите команду:
$ htpasswd -c .htpasswd admin
Для добавления в уже существующий файл используется команда:
$ htpasswd .htpasswd vasya
После запуска, утилита попросит дважды ввести пароль и, если они совпадут, данные о пользователе будут добавлены.
Ограничение доступа
Теперь, чтобы включить запрос на авторизацию при попытке доступа, необходимо внести изменения в файл конфигурации или в файл .htaccess . Напоминаю, что использование файлов .htaccess нежелательно , так как снижает производительность сервера.
Вам необходимо будет изменить путь к каталогу (Directory), путь к файлу с паролями (AuthUserFile) и строку-приглашение (AuthName), которая выдается на экран пользователю при запросе пароля. Значение других директив вы можете узнать из документации Apache.
После внесения изменений в файл конфигурации, не забудьте перезагрузить Apache.
Примечания
В данном примере приведено наиболее простой вариант ограничения доступа. В целом же возможность системы аутентификации Apache гораздо шире. Например, пользователи могут быть разбиты на группы, пароли хранится в базе данных или запрашиваться по специальному протоколу с других серверов. Рекомендуем ознакомится со всеми возможностями в документации Apache.
В примере показан простейший типа аутентификации — Basic . Следует знать, что в этом случае пароль передается от клиента к серверу в открытом, незашифрованном виде. Если это вас не устраивает, вы можете использовать другой вид аутентификации или протокол HTTPS.
|Почти на каждом сайте есть разделы, к которым нужно ограничить доступ. Веб-приложения, как правило, предоставляют собственный метод авторизации, но если такой вариант по какой-либо причине не подходит, для ограничения доступа можно использовать сам веб-сервер.
В этом руководстве показано, как настроить авторизацию на основе пароля на веб-сервере Apache в Ubuntu 14.04.
Требования
Для выполнения руководства нужен аккаунт не-root пользователя с правами sudo. Чтобы создать такой аккаунт, обратитесь к этому .
Установка утилит Apache
Чтобы создать файл для хранения паролей, понадобится утилита htpasswd. Она входит в пакет apache2-utils, который можно найти в репозитории Ubuntu.
Обновите список пакетов и установите необходимые утилиты и сервер Apache2 при помощи следующей команды:
sudo apt-get update
sudo apt-get install apache2 apache2-utils
Создание файла паролей
Теперь на сервере доступна команда htpasswd, которая позволяет создать файл паролей, необходимый серверу Apache для авторизации пользователей. Создайте скрытый файл.htpasswd в каталоге /etc/apache2.
При первом запуске данной утилиты нужно использовать флаг –c, который и создаст необходимый файл. Укажите имя пользователя в конце команды, чтобы создать новую запись в файле:
sudo htpasswd -c /etc/apache2/.htpasswd 8host
Примечание : Замените условное имя пользователяapache настройка авторизации 8host своим именем.
Программа предложит создать и подтвердить пароль для этого пользователя.
Чтобы добавить других пользователей в файл паролей, используйте команду htpasswd без флага –с:
sudo htpasswd /etc/apache2/.htpasswd another_user
Файл паролей содержит имена пользователей и их пароли в зашифрованном виде:
cat /etc/apache2/.htpasswd
8host:$apr1$lzxsIfXG$tmCvCfb49vpPFwKGVsuYz.
another_user:$apr1$p1E9MeAf$kiAhneUwr.MhAE2kKGYHK.
Настройка авторизации Apache
Итак, необходимый файл паролей готов. Теперь нужно настроить Apache для проверки этого файла перед обслуживанием закрытого контента. Это можно сделать двумя способами.
Первый способ: отредактировать настойки Apache и добавить сведения о файле паролей в виртуальный хост. Такой способ, как правило, более производительный, поскольку позволяет избежать чтения общих конфигурационных файлов. Если вы используете виртуальные хосты, рекомендуется прибегнуть к этому способу настройки.
Второй способ больше подходит пользователям, которые не имеют возможности редактировать виртуальный хост. В таком случае ограничить доступ к некоторым разделам сайта можно при помощи файла.htaccess. Сервер Apache использует файлы.htaccess для того, чтобы настроить определенные элементы конфигурации в каталоге, хранящем контент. Недостатком такого способа является то, что сервер Apache должен перечитывать все эти файлы при каждом запросе к этому каталогу, что может негативно повлиять на производительность.
Выберите наиболее подходящий способ настройки и следуйте инструкциям соответствующего раздела.
Настройка авторизации через виртуальный хост
Откройте файл виртуального хоста сайта, доступ к которому нужно ограничить. В данном примере используется стандартный файл 000-default.conf, содержащий виртуальный хост по умолчанию.
sudo nano /etc/apache2/sites-enabled/000-default.conf
Раскомментированный файл выглядит так:
DocumentRoot /var/www/html
Авторизация в Apache настраивается по каталогам. Для этого найдите раздел каталога, к которому нужно ограничить доступ, в блоке
/etc/apache2/sites-enabled/000-default.conf
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
В блоке этого каталога нужно указать тип авторизации, в данном случае – Basic. В параметре AuthName укажите имя области данных, которое будет отображаться при запросе. Используйте директиву AuthUserFile, чтобы указать созданный ранее файл паролей. Установите значение valid-user для директивы Require, чтобы разрешить доступ к контенту только тем пользователям, которые могут пройти авторизацию.
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
AuthType Basic
Require valid-user
Сохраните и закройте файл. Перезапустите Apache, чтобы обновить конфигурации.
sudo service apache2 restart
Теперь доступ к контенту, находящемуся в этом каталоге, защищён паролем.
Настройка авторизации при помощи файла.htaccess
Для начала нужно настроить Apache для поддержки файлов.htaccess. Откройте конфигурации Apache:
sudo nano /etc/apache2/apache2.conf
Найдите блок
. . .
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
. . .
Сохраните и закройте файл.
Затем нужно добавить файл.htaccess в каталог, доступ к которому нужно ограничить. Опять же, в примере доступ будет ограничен к каталогу document root, /var/www/html (то есть ко всему сайту). Чтобы ограничить доступ к другому каталогу, внесите в код соответствующие поправки.
sudo nano /var/www/html/.htaccess
В этом файле нужно указать тип авторизации, в данном случае это Basic. В директиве AuthName задайте имя области данных, которое будет отображаться при запросе. В директиве AuthUserFile укажите созданный ранее файл паролей для Apache. Для директивы Require укажите значение valid-user, чтобы открыть доступ к контенту только тем пользователям, которые могут пройти авторизацию.
AuthType Basic
AuthName "Restricted Content"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
Сохраните и закройте файл. Перезапустите веб-сервер, чтобы обновить его настройки.
sudo service apache2 restart
Тестирование авторизации
Чтобы убедиться, что требуемые каталоги защищены паролем, попробуйте получить доступ к закрытому контенту в веб-браузере. На экране должна появиться форма авторизации, предлагающая указать имя пользователя и пароль:
Authentication Required
The server requires a username and password. The server says:
Restricted server.
User Name:
Password:
Введите валидные учётные данные, чтобы получить доступ к контенту. В случае получения неверных учётных данных сервер вернёт ошибку «Unauthorized».
Заключение
Теперь контент сайта защищён с помощью пароля. Имейте в виду, что защиту паролем следует комбинировать с шифрованием SSL, в противном случае учетные данные будут передаваться на сервер в виде простого текста, а это очень серьёзная уязвимость для безопасности.
Примечание : Чтобы узнать, как создать SSL-сертификат для Apache, читайте данное .
Tags: ,Помимо этих модулей есть также mod_authn_core и mod_authz_core . Эти модули реализуют основные директивы, которые являются основными для всех модулей auth.
Вы, вероятно, также хотите взглянуть на « Контроль доступа» , в котором обсуждаются различные способы контроля доступа к вашему серверу.
Введение
Если у вас есть информация на вашем веб-сайте, которая чувствительна или предназначена только для небольшой группы людей, методы в этой статье помогут вам убедиться, что люди, которые видят эти страницы, являются людьми, которых вы хотели их видеть.
В этой статье рассматривается «стандартный» способ защиты частей вашего веб-сайта, который большинство из вас собирается использовать.
Заметка:
Если ваши данные действительно должны быть безопасными, рассмотрите возможность использования mod_ssl в дополнение к любой аутентификации.
Предпосылки
Директивы, обсуждаемые в этой статье, должны будут отправляться либо в файл конфигурации вашего основного сервера (обычно в разделе
Если вы планируете использовать файлы.htaccess , вам нужно будет иметь конфигурацию сервера, которая позволяет устанавливать директивы аутентификации в эти файлы. Это делается с AllowOverride директивы AllowOverride , которая указывает, какие директивы, если таковые имеются, могут быть помещены в файлы конфигурации для каждого каталога.
Поскольку мы говорим здесь об аутентификации, вам понадобится директива AllowOverride например:
AllowOverride AuthConfig
Или, если вы просто собираетесь указывать директивы непосредственно в файле конфигурации основного сервера, вам, конечно же, необходимо будет иметь разрешение на запись в этот файл.
И вам нужно немного узнать о структуре каталогов вашего сервера, чтобы узнать, где хранятся некоторые файлы. Это не должно быть ужасно сложно, и я постараюсь это понять, когда мы подошли к этому моменту.
Вам также необходимо убедиться, что модули mod_authn_core и mod_authz_core либо были встроены в двоичный файл httpd, либо загружены конфигурационным файлом httpd.conf. Оба этих модуля обеспечивают основные директивы и функциональные возможности, которые имеют решающее значение для конфигурации и использования аутентификации и авторизации на веб-сервере.
Получение работы
Вот основные принципы защиты паролем каталога на вашем сервере.
Во-первых, вам нужно создать файл паролей. Именно то, как вы это сделаете, будет зависеть от того, какой именно поставщик проверки подлинности вы выбрали. Об этом позже. Для начала мы будем использовать текстовый файл паролей.
Этот файл должен быть размещен где-то недоступным из Интернета. Это значит, что люди не могут загрузить файл паролей. Например, если ваши документы поданы из /usr/local/apache/htdocs , вы можете захотеть поместить файлы с паролями в /usr/local/apache/passwd .
Чтобы создать файл, используйте утилиту htpasswd , поставляемую с Apache. Это будет находиться в каталоге bin везде, где вы установили Apache. Если вы установили Apache из стороннего пакета, это может быть в вашем пути выполнения.
Чтобы создать файл, введите:
htpasswd -c /usr/local/apache/passwd/passwords rbowen
Предоставление более чем одному лицу в
Указанные выше директивы позволяют только одному человеку (в частности, кому-то с именем пользователя rbowen) войти в каталог. В большинстве случаев вы захотите AuthGroupFile более одного человека. Здесь находится AuthGroupFile .
Если вы хотите включить более одного человека, вам нужно создать файл группы, который связывает имена групп со списком пользователей в этой группе. Формат этого файла довольно прост, и вы можете создать его с помощью своего любимого редактора. Содержимое файла будет выглядеть так:
GroupName: rbowen dpitts sungo rshersey
Это всего лишь список членов группы в длинной строке, разделенной пробелами.
Чтобы добавить пользователя в уже существующий файл паролей, введите:
htpasswd /usr/local/apache/passwd/passwords dpitts
Вы получите тот же ответ, что и раньше, но он будет добавлен к существующему файлу, а не к созданию нового файла. (Это -c делает его созданием нового файла паролей).
Теперь вам нужно изменить файл.htaccess или блок
AuthType Basic AuthName "By Invitation Only" # Optional line: AuthBasicProvider file AuthUserFile "/usr/local/apache/passwd/passwords" AuthGroupFile "/usr/local/apache/passwd/groups" Require group GroupName
Теперь любой, кто указан в группе GroupName и имеет запись в файле password , будет включен, если они введут правильный пароль.
Есть еще один способ, чтобы несколько пользователей в этом были менее конкретными. Вместо создания группового файла вы можете просто использовать следующую директиву:
Require valid-user
Использование этой, а не Require user rbowen строки Require user rbowen позволит любому, кто указан в файле паролей, и кто правильно вводит свой пароль.
Возможные проблемы
Из-за того, как указана базовая проверка подлинности, ваше имя пользователя и пароль должны быть проверены каждый раз, когда вы запрашиваете документ с сервера. Это даже если вы перезагружаете одну и ту же страницу и для каждого изображения на странице (если они происходят из защищенного каталога). Как вы можете себе представить, это немного замедляет работу. Объем, который он замедляет, пропорционален размеру файла паролей, потому что он должен открыть этот файл и перейти по списку пользователей до тех пор, пока он не получит ваше имя. И он должен делать это каждый раз, когда страница загружается.
Следствием этого является то, что существует практическое ограничение того, сколько пользователей вы можете поместить в один файл паролей. Это ограничение будет зависеть от производительности вашего конкретного сервера, но вы можете ожидать замедление после получения нескольких сотен записей и, возможно, захотите рассмотреть другой метод аутентификации в то время.
Альтернативное хранение паролей
Поскольку сохранение паролей в текстовых файлах имеет указанные выше проблемы, вы можете захотеть сохранить свои пароли в другом месте, например, в базе данных.
Использование нескольких поставщиков
С внедрением новой архитектуры аутентификации и авторизации, основанной на провайдере, вы больше не заблокированы ни одним методом проверки подлинности или авторизации. Фактически любое количество поставщиков может быть смешано и согласовано, чтобы предоставить вам именно ту схему, которая соответствует вашим потребностям. В следующем примере используются оба поставщика аутентификации на основе файлов и LDAP.
В этом примере поставщик файлов сначала попытается выполнить аутентификацию пользователя. Если он не может аутентифицировать пользователя, будет вызываться поставщик LDAP. Это позволяет расширить область проверки подлинности, если ваша организация реализует несколько хранилищ проверки подлинности. Другие сценарии аутентификации и авторизации могут включать в себя смешивание одного типа аутентификации с другим типом авторизации. Например, аутентификация в отношении файла паролей, который авторизовался в отношении каталога LDAP.
Подобно тому, как могут быть реализованы несколько поставщиков аутентификации, можно использовать несколько методов авторизации. В этом примере используется авторизация группы файлов, а также авторизация группы LDAP.
Чтобы получить авторизацию немного дальше, директивы контейнера разрешений, такие как
Помимо просто авторизации
Применение логики и упорядочения
Контроль того, как и в каком порядке будет применяться авторизация, в прошлом был загадкой. В Apache 2.2 был внедрен механизм аутентификации на основе провайдера, чтобы отделить фактический процесс аутентификации от полномочий авторизации и поддержки. Одним из побочных преимуществ было то, что поставщики аутентификации могли быть сконфигурированы и вызваны в определенном порядке, который не зависел от порядка загрузки самого модуля auth. Этот же механизм, основанный на поставщиках, был также перенесен в авторизацию. Это означает, что директива Require не только указывает, какие методы авторизации следует использовать, но также определяет порядок их вызова. Несколько методов авторизации вызывают в том же порядке, в котором в конфигурации появляются директивы Require .
С введением директив контейнера авторизации, таких как
Кэширование аутентификации
Могут быть случаи, когда аутентификация ставит неприемлемую нагрузку на поставщика или в вашу сеть. Это, скорее всего, затронет пользователей mod_authn_dbd (или сторонних / пользовательских поставщиков). Чтобы справиться с этим, HTTPD 2.3 / 2.4 вводит новый поставщик кэширования mod_authn_socache для кэширования учетных данных и снижения нагрузки на поставщиков (поставщиков) источника.
Это может значительно повысить производительность некоторых пользователей.
Больше информации
Вы также должны прочитать документацию для mod_auth_basic и mod_authz_host которые содержат дополнительную информацию о том, как все это работает. Директива также может помочь в упрощении определенных конфигураций проверки подлинности.
Различные шифры, поддерживаемые Apache для данных аутентификации, объясняются в разделе «Шифрование паролей» .
И вы можете захотеть взглянуть на « Контроль доступа» , в котором обсуждается ряд связанных тем.
Тема прозрачной авторизации в 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, даже если она пустая. Позже пригодится.
#!/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 и добавить строки в следующие блоки:
Default_realm = LAB.LOCAL LAB.LOCAL = { kdc = dc1.lab.local kdc = dc2.lab.local default_domain = lab.local admin_server = dc1.lab.local } .lab.local = LAB.LOCAL lab.local = LAB.LOCAL
Да, именно так, с соблюдение регистра букв. В принципе, исходное содержимое /etc/krb5.conf не нужно, но я оставлял. Суеверие?
Создаем учетную запись компьютера в AD
Исходные данные
- У вас есть аккаунт с правами создавать новые учетные записи компьютеров. Пусть он называется [email protected]
- Учетная запись компьютера в AD отсутствует
- Вы планируете, что для работы с OTRS будет использовать адрес, совпадающей с именем сервера. В нашем случае имя сервера ubuntuadmember , адрес OTRS http://ubuntuadmember/otrs/index.pl
Предупреждение. В иных случаях могут потребоваться дополнительные действия, и я не знаю, какие именно.
Выполняем логин в AD с помощью аккаунта [email protected]
Kinit -V [email protected]
Если нет ошибок — проверка:
Создаем учетную запись компьютера
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 и добавим в него перед следующий блок:
Выделено красным:
- /etc/krb5.keytab — дефолтный путь к файл с ключами. Если хотите поменять, не забудьте переместить и файл
- HTTP/[email protected] — должен в точности совпадать с названием компьютера и доменом
После внесения изменений нужно рестартовать 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 [email protected] ### 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
Во, так гораздо лучше! Замечания/вопросы/дополнения пишите в комментах.