Apache авторизация по пользователю операционной системы. Применение логики и упорядочения

12.04.2019

Защита сайта средствами самого сервера Apache является одним из самых простых и в тоже время достаточно надежных способов. В этом случае Вам не нужно досконально продумывать стратегию безопасности, осуществлять ее проектирование и реализацию в коде. К тому же, для того, чтобы создать хорошую систему защиты нужно обладать достаточной квалификацией в этом вопросе. Используя встроенную защиту WEB-сервера Apache, Вы значительно упрощаете себе задачу - все, что Вы должны сделать - это выполнить несложную последовательность действий и Ваш сайт будет в достаточной мере защищен. В данной статье будут подробно описаны шаги и действия, которые Вам необходимо совершить. А в конце статьи будут приведены примеры файлов.htaccess .

Базовая аутентификация

В данной статье будет рассмотрен самый простой и доступный способ защиты - базовая аутентификация.

Замечание

Аутентификация - процесс, с помощью которого проверяется, что некто является именно тем, за кого он себя выдает. Как правило, проверка включает в себя ввод имени и пароля.

Рассмотрим, как работает базовая аутентификация.
При обращении посетителя в защищаемую директорию, сервер Apache в ответ на запрос посылает заголовок с кодом 401 (401 authentication required header). Браузер посетителя принимает заголовок с кодом 401 и выводит окно с полями для ввода имени пользователя и пароля. После ввода имени и пароля эти данные отсылаются назад серверу, который проверяет имя пользователя на предмет нахождения в специальном списке, а пароль на правильность. Если все верно, то посетитель получает доступ к ресурсу. Вместе с заголовком браузеру посылается специальной имя, называемое областью действия. Браузер кэширует не только имя и пароль, чтобы передавать их при каждом запросе, но и область действия. Благодаря этому, ввод имени и пароля в защищаемой директории осуществляется только раз. В противном случае их необходимо было бы вводить при каждом запросе к защищаемой директории. Кэширование параметров аутентификации (имя, пароль, область действия), обычно осуществляет только в пределах одного сеанса.

Замечание

При базовой аутентификации имя пользователя и его пароль передаются в сеть в открытом виде в течении всего сеанса, когда посетитель работает с защищенной директорией. Хакер может перехватить эту информацию, используя сетевой анализатор пакетов. Данный вид аутентификации не должен использоваться там, где нужна реальная защита коммерческо-ценной информации.

Замечание

WEB-сервер Apache поддерживает еще один вид защиты - digest-аутентификацию. При digest-аутентификации пароль передается не в открытом виде, а в виде хеш-кода, вычисленному по алгоритму MD5. Поэтому пароль не может быть перехвачен при сканировании трафика. Но, к сожалению, для использования digest-аутентификации необходимо установить на сервер специальный модуль - mod_auth_digest. А это находится только в компетенции администрации сервера. Также, до недавнего времени, digest-аутентификация поддерживалась не всеми видами браузеров.

Защита сайта - это просто

Для того чтобы защитить сайт, нужно выполнить следующую последовательность действий: создать файл с паролями, переписать его на сервер, создать файл.htaccess и тоже переписать его на сервер.
Для организации защиты понадобится.

  1. WEB-сайт и FTP-доступ к нему.
  2. Права на создание файлов.htpaccess и организацию защиты с помощью них.
  3. Утилита генерации паролей htpasswd.exe

Проверка работы файла.htaccess на сервере

Для того чтобы проверить есть ли у Вас права на организацию защиты с помощью файлов.htaccess создайте текстовый файл с именем.htaccess (первым символом идет точка, расширение отсутствует).

Замечание

Удобно создавать файлы.htaccess с помощью встроенного редактора в оболочках Far, WindowsCommander, TotalCommander и т.п., а также в редакторе Блокнот.

Замечание

Чтобы блокнот не подставлял автоматически расширение txt, в диалоге сохранения в выпадающем списке "тип файла" следует выбрать опцию "Все файлы".


Рис. Сохранение файлов.htaccess в блокноте

Проверка работы.htaccess

AuthType Basic
AuthName admin
require valid-user

Затем, через FTP-доступ, перепишите файл.htaccess на сайт, в ту директорию, которую вы хотите защитить.

Замечание

Действие файлов.htaccess распространяется не только на ту директорию, где лежит файл, но и на все поддиректрии, лежащие уровнем ниже.

Далее через браузер обратитесь к этой директории. Если Вы защищаете директорию admin и переписали туда файл.htaccess, то для проверки Вам следует вписать в адресную строку браузера следующий URL: http://www.mysite.ru/admin/.

Если после этого Вам открылся запрос на ввод логина и пароля, как на рисунке ниже, то тестирование прошло успешно и можно продолжать защиту директории.

Рис. Окно ввода логина и пароля


Если вы все сделали правильно, но окошко ввода пароля не появилось, то это значит, что настройки сервера запрещают Вам использовать файлы.htaccess для защиты директорий. Для решения данного вопроса Вам следует связаться с администрацией сервера, либо использовать другой тип защиты.
После того, как было выяснено, что файлы.htaccess работают, следует удалить с сайта только что написанный тестовый файл.

Замечание

Если по каким либо причинам Вы не можете удалить файл.htaccess, то создайте пустой файл.htaccess и замените им файл, лежащий на сервере.

Создание файла с паролями.htpasswd

Файл с паролями создается утилитой htpasswd.exe . Если у Вас на машине установлен WEB-сервер Apache, то данная утилита находится в директории с установленным Apache -ем в подкаталоге bin .

Замечание

Если у Вас не установлен Apache, то утилиту htpasswd.exe можете скачать по ссылке: .

Для работы с утилитой htpasswd.exe необходим интерфейс работы с командной строкой. Интерфейсом работы с командной строкой обладают такие программы как Far, WindowsCommander и т.п. Здесь будет рассмотрена работа с командной строкой с помощью утилиты cmd, которая входит в поставку Windows 2000/XP и т.п.
Нажмите "Пуск"->"Выполнить" , введите в строку ввода cmd и нажмите ОК . Вам откроется окно утилиты CMD.

Рис. Окно утилиты CMD


Далее необходимо перейти в директорию, где находится утилита htpasswd.exe . Допустим, сервер Apache установлен в директории с:/Apache2, тогда введите в командную строку команду: cd../../apache2/bin и нажмите ввод.


Вы перешли в директорию с:Apache2in. Теперь нужно дать команду на создание файла с паролем. Введите в командную строку следующее:

Htpasswd -cm .htpasswd admin

  • -cm - это ключи для утилиты. Ключ с - указывает, что необходимо создать новый файл с паролями. Если файл с таким именем уже существует, то он будет перезаписан. Ключ m - определяет шифрование по алгоритму MD5.
    .htpasswd - имя файла с паролями (можете использовать любое имя).
    admin - имя посетителя, которому будет разрешен доступ в закрытую область сайта.

В ответ, должен появится запрос на ввод пароля и его повтор. Если все правильно, то в завершении появится сообщение: Adding password for user admin. И в директории c:Apache2in появится файл.htpasswd, к котором будет находиться строка с именем пользователя и хеш-кодом его пароля. Для того, что бы в тот же файл.htpasswd добавить еще одного пользователя следует убрать ключ -c из команды запуска утилиты htpasswd.exe

Htpasswd -m .htpasswd admin


Замечание

Если файл с паролями не был создан, то возможно, некоторые ключи утилиты не поддерживаются в Вашей операционной системе. Например, иногда не поддерживается ключ m. В этом случае, Вам нужно ввести htpasswd -c .htpasswd admin
Для того, чтобы посмотреть ключи и параметры работы утилиты введите htpasswd.exe /? Вам будет выдано описание интерфейса.

Итак, файл с паролями создан. Теперь Вам необходимо переписать его на сервер. Файлы с паролями очень желательно класть выше корневой директории сайта - туда, куда не будет доступа посетителям.
Если это невозможно, то файлы с паролями следует обязательно защитить. Это можно сделать с помощью файлов.htaccess. Чтобы защитить файлы с паролями создайте файл со строками, представленными в следующем листинге.

Защита файлов.htpasswd


deny from all

И положите его в ту директорию, где находится Ваш файл с паролями. Теперь посетители сайта не смогут получить к нему доступ.
Файл с паролем создан и защищен от несанкционированного доступа. Теперь необходимо создать файл.htaccess, который будет использоваться в защищаемой директории.

Создание файла.htaccess

Для защиты директории могут использоваться следующие директивы:

  • AuthType - Тип используемой аутентификации. Для базовой аутентификации эта директива должна иметь значение: Basic
    AuthName - Имя области действия аутентификации. Текст, помогающий посетителю понять, куда он пытается получить доступ. Например, может быть написано: "Private zone. Only for administrator!"
    AuthUserFile - путь к файлу с паролями (.htpasswd).
    AuthGroupFile - путь к файлу групп, если он существует.
    Require - Одно или несколько требований, которые должны быть выполнены для получения доступа к закрытой области.

Пример файла.htaccess

AuthType Basic



require group admins

Следует более подробно описать директивы AuthUserFile и AuthGroupFile. В них прописываются абсолютные пути к соответствующим файлам от корня сервера.

Внимание!

Относительные пути работать не будут!

Путь от корня сервера, можно узнать, спросив у администрации сервера, либо можно попробовать выяснить его самим. Для этого выполните функцию phpinfo(). На экран будет выведена фиолетовая таблица. Значение абсолютного пути от корня сервера можно посмотреть в переменных: doc_root, open_basedir, DOCUMENT_ROOT.
Директива Require определяет кому разрешен доступ к закрытой области. Например,

  • require valid-user - разрешен доступ всем прошедшим проверку
  • require user admin alex mango - разрешен доступ только посетителям с именами admin, alex, mango. Естественно, они должны пройти аутентификацию.
    AuthName "Private zone. Only for administrator!"
    AuthUserFile /usr/host/mysite/.htpasswd
    require valid-user

    Доступ только пользователям admin и root

    AuthType Basic
    AuthName "Private zone. Only for administrator!"
    AuthUserFile /usr/host/mysite/.htpasswd
    require user admin root

    Доступ только пользователей из группы admins

    AuthType Basic
    AuthName "Private zone. Only for administrator!"
    AuthUserFile /usr/host/mysite/.htpasswd
    AuthGroupFile /usr/host/mysite/group
    require group admins

    Запрет доступа только к файлу private.zip


    AuthType Basic
    AuthName "Private zone. Only for administrator!"
    AuthUserFile /usr/host/mysite/.htpasswd
    require valid-user

|

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

В этом руководстве показано, как настроить авторизацию на основе пароля на веб-сервере 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 настраивается по каталогам. Для этого найдите раздел каталога, к которому нужно ограничить доступ, в блоке . В данном примере нужно ограничить доступ к document root (при необходимости укажите другой каталог):

/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

Найдите блок каталога /var/www (как вы понимаете, это настройки каталога document root). Включите поддержку файлов.htaccess, заменив значение директивы AllowOverride на All.

. . .

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: ,

Используя стандартные модули Apache, возможно запрашивать логин и пароль у пользователя при попытке доступа к определенной странице или каталогу. Доступ будет разрешен, если логин и пароль присутствуют в специальном файле.

Создание файла с паролями

Файл с учетными данными обычно называется .htpasswd и располагается в каталоге, доступ к которому необходимо ограничить. По умолчанию в Apache запрещен доступ ко всем файлам, которые начинаются на .ht , так что файл с паролями, как и файл .htaccess , не сможет быть прочитан ни одним посетителем вашего сайта.

В каждой строке файла хранятся данные об одном пользователе. Логин и зашифрованный пароль разделены двоеточием. Пример:

Admin:YFC5nYLiUI2ig vasya:bnqw1eZHP2Ujs

Для шифрации паролей применяется утилита htpasswd , которая поставляется в комплекте с Apache. Чтобы создать новый файл с данными о
пользователе admin , введите команду:

$ htpasswd -c .htpasswd admin

Для добавления в уже существующий файл используется команда:

$ htpasswd .htpasswd vasya

После запуска, утилита попросит дважды ввести пароль и, если они совпадут, данные о пользователе будут добавлены.

Ограничение доступа

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

AuthType Basic AuthName "Administrative zone" AuthUserFile /var/www/example.com/admin/.htpasswd Require valid-user

Вам необходимо будет изменить путь к каталогу (Directory), путь к файлу с паролями (AuthUserFile) и строку-приглашение (AuthName), которая выдается на экран пользователю при запросе пароля. Значение других директив вы можете узнать из документации Apache.

После внесения изменений в файл конфигурации, не забудьте перезагрузить Apache.

Примечания

В данном примере приведено наиболее простой вариант ограничения доступа. В целом же возможность системы аутентификации Apache гораздо шире. Например, пользователи могут быть разбиты на группы, пароли хранится в базе данных или запрашиваться по специальному протоколу с других серверов. Рекомендуем ознакомится со всеми возможностями в документации Apache.

В примере показан простейший типа аутентификации — Basic . Следует знать, что в этом случае пароль передается от клиента к серверу в открытом, незашифрованном виде. Если это вас не устраивает, вы можете использовать другой вид аутентификации или протокол HTTPS.

Часто бывает нужно ограничить доступ пользователей к определенным зонам вашего сайта. Например, к административной части. Часто это делают, создавая свой механизм авторизации. Однако, существует способ защитить зоны сайта с помощью встроенных средств сервера и браузера. Простейшая авторизация носит название Apache Basic authorization. Это будет большая статья, так что приготовьтесь к основательному чтению. Но зато в ней будет все, что вам когда-нибудь понадобится для работы с этим видом авторизации.

Как это работает

Сначала, мы кладем на сервере файл.htaccess. В нем мы указываем, какую зону (или конкретный файл) хотим запаролить. Это может выглядеть примерно так:

AuthType Basic #тип авторизации
AuthName "Name" #имя авторизации
#местоположение файла с паролями
AuthUserFile /usr/host/mysite/.htpasswd
#пропускать любого пользователя,
#который ввел верные логин и пароль

require valid-user

Кроме того, на сайте может присутствовать файл паролей. У него простая структура:

логин:зашифрованный пароль
логин:зашифрованный пароль
...

Путь к этому файлу указывается в htaccess.

Разговор с сервером под увеличительным стеклом

Теперь давайте предположим, что кто-то набрал адрес запароленой директории. Что при этом произойдет? А вот что:

1. Браузер просит у сервера страницу по адресу http://сайт/secret.
Сервер видит, что для этой страницы установлена защита. Он посылает браузеру заголовки:

WWW-Authenticate: Basic realm="My Realm"
Status: 401 Unauthorized
HTTP-Status: 401 Unauthorized

Здесь нужно сказать, что зона (realm) — важный параметр. Если требуется вести пользователя через несколько запароленых зон, не ко всем из которых пользователь должен иметь доступ, то как раз имя зоны будет определять залогинен пользователь для этого места или еще нет.

2. Получив эти заголовки, браузер рисует на экране форму запроса логина и пароля. Если пользователь нажимает "Cancel", браузер выдает все те данные, что шли за этими заголовками.

3. Если пользователь ввел логин и пароль, то они отсылаются серверу. Тот лезет в файл с паролями и смотрит там такую пару. Если находит, то посылает в ответ ту страницу, которую просил браузер в самом начале. Если нет, то вновь посылает заголовки авторизации.

4. В случае, если пользователь ввел верные логин и пароль, а сервер ответил запрашиваемой страницей, браузер запоминает введенные логин и пароль для этой зоны.

5. Затем, если браузер посылает серверу любой (!!!) запрос, он прикрепляет к нему пару — логин и пароль. Выглядит это так:

Authorization: Basic base64(login:pass)

То есть, пара логин-пароль зашифрована в base64. Еще раз обращу внимание — логин и пароль посылается теперь с любым запросом браузера. Для картинок, файлов стилей, скриптов, favico и всего остального. По сути, для получения каждого файла, вы проходите авторизацию. Только браузер это делает за вас.

6. Сервер, когда получает запрос, проверяет, не идут ли с ним еще и логин с паролем. Если идут, то сразу проводит проверку на авторизованность.

Запрос авторизации на Perl и PHP

Теперь настало время разобраться, как же вывести окно авторизации апача не силами htaccess, а силами скрипта на Perl или PHP. Я специально поставил эти два решения, на двух разных языках под один заголовок. Потому что теперь, зная механику, мы можем быстро прийти к выводу, что для появления окошка запроса авторизации, нужно лишь послать нужные заголовки. Этим и займемся.

#Perl
print "WWW-Authenticate: Basic realm=\"My Realm\"\n";
print "Status: 401 Unauthorized\n";
print "HTTP-Status: 401 Unauthorized\n";
print "Content-type: text/html\n\nCancel";

#PHP
header("WWW-Authenticate: Basic realm=\"My Realm\"");
header("Status: 401 Unauthorized");
header("HTTP-Status: 401 Unauthorized");
print "Вы нажали Cancel";

Результатом и в том и в другом случае, будет форма запроса авторизации.

Перехват авторизации на Perl

Допустим, пользователь ввел логин и пароль. Они отправляются на сервер. Но тут возникает проблема. Дело в том, что когда апач получает логин и пароль, он хочет сверить их в файле паролей. Но что если логины и пароли хранятся не в файле паролей а в базе данных? В этом случае, нужно проводить авторизацию скриптом до того, как это сделает апач.

Возникает затруднение: апач не передает в переменных окружения введенные логин и пароль. То есть, получить к ним доступ из Perl проблематично. Но возможно. Самое простое решение — использовать mod_rewrite. Допишите в файл htaccess строки:

RewriteEngine on
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule ^(.*) —

Они добавят новую переменую окружения. Из Perl она будет видна как $ENV{HTTP_CGI_AUTHORIZATION}. Она будет содержать пару логин-пароль, закодированную в base64. Конечно, придется немного повозиться с тем, чтобы их перекодировать обратно, но это уже кое-что. Тем более, что возни там, собственно, не много:

$ENV{HTTP_CGI_AUTHORIZATION} =~ s/basic\s+//i;
my ($REMOTE_USER,$REMOTE_PASSWD) = split(/:/,decode_base64($ENV{HTTP_CGI_AUTHORIZATION}));

Теперь у нас есть две переменные $REMOTE_USER и $REMOTE_PASSWD, с помощью которых можно проводить авторизацию силами скрипта, сверяя логин и пароль с чем душе угодно.

Перехват авторизации на PHP

Поддержка сессии на Perl и PHP

Кроме всего прочего, после того, как авторизация прошла успешно, в переменной окружения будет находиться логин авторизованного пользователя, который вызывает исполняемый скрипт. То есть, вы всегда будете знать кто именно сейчас запустил скрипт. Логин содержится в переменных:

#perl
$ENV{REMOTE_USER}
#php
$_SERVER

Вот такие дела

Большая получилась статья, как я и обещал. Но зато в ней рассмотрены основные принципы работы апачевой base-автроизации, а так же собраны решения некоторых проблем, которые могут возникнуть при работе с ней. Скажу честно, провел не один час, в поисках ответов на некоторые вопросы, решенные в этой статье. Надеюсь, она поможет сэкономить время другим программистам.

Ссылки по теме

  • htaccess и htpasswd — как сделать авторизаию только силами апача
  • htaccess.net.ru — сайт, посвященный возможностям управления сервером, при помощи файлов htaccess

Тема прозрачной авторизации в 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 и добавим в него перед следующий блок:

AuthType Kerberos AuthName "Kerberos Login" KrbMethodK5Passwd off Krb5Keytab /etc/krb5.keytab KrbServiceName Require valid-user

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

  • /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

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