Как настроить Ubuntu + Apache + Active Directory?

Kerberos - ваш друг! (это то, что AD фактически использует для Auth)

Как использовать Kerberos с PHP

Источник Soureforge и как установить модуль Kerberos в Apache

Вам, вероятно, сначала понадобится: libapache2-mod-auth-curb, согласно:

http://www.microhowto.info/howto/configure_apache_to_use_kerberos_authentication.html

---

Полный текст:

Чтобы настроить Apache для использования аутентификации Kerberos Фон

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

В случае HTTP поддержка Kerberos обычно предоставляется с использованием механизма аутентификации SPNEGO (простое и защищенное согласование GSS-API). Это также известно как «интегрированная аутентификация» или «согласованная аутентификация». Сам Apache не поддерживает SPNEGO, но поддержку можно добавить с помощью модуля аутентификации mod_auth_kerb. Сценарий

Предположим, вы хотите ограничить доступ к веб-сайту. http://www.example.com/. Аутентификация будет выполняться с использованием Kerberos и SPNEGO. Веб-сайт не обязательно должен быть доступен для веб-браузеров, не поддерживающих SPNEGO.

Пользователи, которым будет предоставлен доступ, являются членами области Kerberos EXAMPLE.COM и называются dougal, brian, ermintrude и dylan. Областью можно управлять с помощью главного bofh / admin. Предпосылки

В приведенном ниже описании предполагается, что вы уже установили и Apache, и Kerberos на веб-сервере.

Apache должен находиться в состоянии, в котором вы можете запросить хотя бы одну страницу с соответствующего веб-сайта для целей тестирования. Он не обязательно должен содержать какой-либо реальный контент (и если он есть, вы, вероятно, захотите предпринять шаги для изоляции сервера от неавторизованных пользователей, пока он не будет должным образом защищен).

Kerberos должен находиться в состоянии, в котором EXAMPLE.COM был настроен как область по умолчанию, и можно получить билет для этой области на веб-сервере. Обзор метода

Описанный здесь метод состоит из шести шагов:

Установите модуль аутентификации mod_auth_kerb. Создайте субъект-службу для веб-сервера. Создайте keytab для субъекта-службы. Укажите используемый метод аутентификации. Укажите список авторизованных пользователей. Перезагрузите конфигурацию Apache.

Обратите внимание, что помимо включения SPNEGO на веб-сервере, может также потребоваться явное включение его в веб-браузере. Как известно, это относится к Mozilla Firefox. Видеть:

Настройте Firefox для аутентификации с использованием SPNEGO и Kerberos

Установите модуль аутентификации mod_auth_kerb

Как отмечалось выше, Apache сам по себе не поддерживает SPNEGO, но его можно добавить с помощью модуля mod_auth_kerb. Он включен в большинство основных дистрибутивов GNU / Linux, но поскольку это сторонний модуль, он обычно упаковывается отдельно от Apache. В системах на основе Debian он предоставляется пакетом libapache2-mod-auth-curb:

apt-get install libapache2-mod-auth-kerb

а в системах на базе Red Hat - пакетом mod_auth_kerb:

yum install mod_auth_kerb

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

LoadModule auth_kerb_module /usr/lib/apache2/modules/mod_auth_kerb.so

(где путь к модулю следует заменить на то, что подходит для вашей системы). Создайте субъект-службу для веб-сервера

SPNEGO требует, чтобы для веб-сервера был создан субъект службы Kerberos. Имя службы определено как HTTP, поэтому для сервера www.example.com требуемое имя участника службы - HTTP/www.example.com@EXAMPLE.COM.

Если вы используете MIT Kerberos, то субъект-службу можно создать с помощью команды kadmin:

kadmin -p bofh/admin -q "addprinc -randkey HTTP/www.example.com"

См. MicroHOWTO Создание субъекта-службы с использованием MIT Kerberos для получения дополнительной информации о том, как можно создать субъект-службу и зачем он нужен. Создайте keytab для субъекта-службы

Keytab - это файл для хранения ключей шифрования, соответствующих одному или нескольким участникам Kerberos. mod_auth_kerb нужен для того, чтобы использовать созданный выше принципал службы. Если вы используете MIT Kerberos, тогда keytab (например, субъект-службу) можно создать с помощью команды kadmin. Его право собственности должно быть таким, чтобы его мог читать процесс Apache.

В системах на основе Debian подходящим местом для keytab будет /etc/apache2/http.keytab, а соответствующим владельцем является www-data:

kadmin -p bofh/admin -q "ktadd -k /etc/apache2/http.keytab HTTP/www.example.com"
chown www-data /etc/apache2/http.keytab

В системах на основе Red Hat подходящим расположением будет /etc/httpd/http.keytab, а соответствующим владельцем будет apache:

kadmin -p bofh/admin -q "ktadd -k /etc/httpd/http.keytab HTTP/www.example.com"
chown apache /etc/httpd/http.keytab

Параметр -k указывает путь к ключевой вкладке, которая будет создана, если она еще не существует.

См. MicroHOWTO Добавление хоста или принципала службы на вкладку ключей с помощью MIT Kerberos для получения дополнительной информации о создании вкладок ключей, их назначении и почему вкладка ключей по умолчанию (обычно /etc/krb5.keytab) не подходит для использования сетевыми службами, которые не запускайте от root.

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

kinit -k -t /etc/apache2/http.keytab HTTP/www.example.com
klist

Укажите метод аутентификации, который будет использоваться

Apache необходимо сообщить, какие части каких веб-сайтов должны использовать аутентификацию, предоставляемую mod_auth_kerb. Это делается с помощью директивы AuthType со значением Kerberos. Затем необходимы дополнительные директивы для настройки поведения mod_auth_kerb.

Если цель состоит в том, чтобы применить эти директивы ко всему данному веб-сайту, они могут быть помещены в контейнер с путем, соответствующим корню сайта:

<Location />
 AuthType Kerberos
 AuthName "Acme Corporation"
 KrbMethodNegotiate on
 KrbMethodK5Passwd off
 Krb5Keytab /etc/apache2/http.keytab
</Location>

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

В дополнение к протоколу SPNEGO, mod_auth_kerb имеет возможность запрашивать у пользователя пароль с использованием базовой аутентификации, а затем проверять этот пароль, пытаясь аутентифицироваться в KDC. Это может быть полезно, если необходимо, чтобы веб-сайт был доступен для авторизованных пользователей с компьютеров, которые не являются частью области Kerberos, однако это значительно менее безопасно, чем настоящая проверка подлинности Kerberos. По умолчанию включены SPNEGO и парольная аутентификация. В этом примере не требуется, чтобы сайт был доступен для веб-браузеров, не поддерживающих SPNEGO, поэтому аутентификация по паролю была отключена с помощью директивы KrbMethodK5Passwd. Для полноты картины SPNEGO был явно включен с помощью директивы KrbMethodNegotiate.

Директива Krb5Keytab указывает путь к таблице ключей, в которую был добавлен участник службы HTTP. Он должен соответствовать тому, что было передано команде ktadd kadmin ранее в этой процедуре.

Хотя в этом примере использовался контейнер, было бы в равной степени приемлемо, если бы вышеуказанные директивы были размещены внутри, или контейнера, или внутри файла .htaccess. Укажите список авторизованных пользователей

Установка метода аутентификации сама по себе не ограничивает доступ к серверу. Это связано с тем, что Apache по умолчанию разрешает доступ анонимным пользователям, и если это поведение не будет отменено, метод аутентификации (каким бы он ни был) не будет вызываться.

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

<Location />
 # ...
 Require user dougal@EXAMPLE.COM brian@EXAMPLE.COM ermintrude@EXAMPLE.COM dylan@EXAMPLE.COM
</Location>

Обратите внимание, что каждое имя определяется областью Kerberos, членом которой оно является.

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

См. «Заставить системную службу перезагрузить свою конфигурацию». В последних системах на базе Debian требуется следующая команда:

service apache2 force-reload

Соображения безопасности Парольная аутентификация

Как отмечалось выше, mod_auth_kerb имеет возможность запрашивать имя пользователя и пароль из веб-браузера с использованием базовой аутентификации HTTP, а затем проверять, действительны ли это имя пользователя и пароль, с помощью Kerberos. У этого подхода есть три серьезных недостатка по сравнению с настоящей аутентификацией Kerberos:

The password is sent unencrypted as part of the HTTP stream.
The password is exposed to the Apache server.
The password must be entered mid-session.

Первый из этих вопросов можно решить, разрешив доступ через TLS (SSL) и отключив простой HTTP. Второй и третий пункты менее понятны и подрывают многие преимущества безопасности, обеспечиваемые моделью единого входа в целом и Kerberos в частности.

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

Аутентификация с использованием SPNEGO решает перечисленные выше проблемы, но способ ее интеграции с HTTP далек от идеала. Когда клиент аутентифицируется в сетевой службе Kerberos, одним из продуктов процесса аутентификации является ключ шифрования, который клиент и сервер могут использовать для защиты любой дальнейшей связи между ними. Это не используется, когда HTTP-соединение аутентифицируется с помощью SPNEGO, что означает, что если соединение перехватывается после завершения аутентификации, то ничто не может помешать злоумышленнику выполнить несанкционированные HTTP-команды.

Этот риск можно значительно снизить, используя TLS (SSL) для защиты соединения. Это предотвращает захват соединения после того, как оно было установлено, и не позволяет серверу принимать соединения с веб-сайтом, для которого у него нет действующего сертификата. Это не идеальное решение из-за большого количества организаций, которые могут выдавать сертификаты. Существует решение, которое использует привязку канала для связывания ключа TLS с Kerberos, однако на момент написания оно не было широко реализовано (и не поддерживается mod_auth_kerb).