Настройка SSO (Single Sign On) авторизации на Apache в Active Directory Windows на Debian 10 Buster.

SSO (Single Sing-on) – позволяет пользователям вошедшим в систему не вводить пароль при авторизации на доменных сетевых ресурсах. Этот же механизм можно запросто прикрепить к Apache, что бы позволить доменным пользователям проходить аутентификацию, например на внутреннем сайте компании, не вводя имя пользователя и пароль.

 

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

  • Контроллер домена (DC1) на Windows Server 2012 R2, домен JAKONDA.LOCAL
  • Веб-сервер (webserver) (Apache 2.4.10) на Debian 10 Buster.

 

ИНФОРМАЦИЯ. Данная статья так же применительная будет ко всем debian-like системам.

 

Подготовка системы

# Обновляем информацию о репозиториях и обновляем установленные пакеты:

apt-get update && apt-get upgrade -y

 

Указываем FQDN (Fully Qualified Domain Name) имя системы, в файле /etc/hostname:

webserver.jakonda.local

Файл /etc/hosts приводим к виду таким образом, чтобы в нём была запись с полным доменным именем компьютера и с коротким именем, ссылающаяся на один из внутренних IP хоста:

127.0.0.1 localhost 
127.0.1.1 webserver.jakonda.local webserver

 

Настраиваем синхронизацию времени с контроллером домена, выполняем установку NTP, выполняем синхронизацию времени с контроллером домена:

apt-get install ntp ntpdate

ntpdate dc1.jakonda.local
Более подробно о синхронизации времени на Debian можно почитать в этой статье

 

Настройка Active Directory

В DNS зону (JAKONDA.LOCAL), добавляем A-запись веб-сервера:

 

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

 

Создаем KEYTAB-файл (необходим для аутентификации пользователей в Active Directory). В командной строке с правами администраторы выполняем команду (соблюдая регистр):

ktpass -princ HTTP/webserver.jakonda.local@JAKONDA.LOCAL -mapuser apache@JAKONDA.LOCAL -pass Aa1234567 -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out C:\webserver.keytab

 

Полученный KEYTAB-файл, передаем любым удобным способом на Веб-сервер (расположение KEYTAB-файла на моем веб-сервере — /etc/webserver.keytab). Как передать файл посредством утилиты PuTTY можно прочитать тут

 

Настройка Kerberos

Установка Kerberos:

apt-get install krb5-user libapache2-mod-auth-kerb
В ходе установки может появится запрос указать область по-умолчанию для Kerberos, область необходимо его указать в заглавном виде (прим. JAKONDA.LOCAL)

 

Файл конфигурации Kerberos /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 = JAKONDA.LOCAL
 default_keytab_name = /etc/webserver.keytab
 dns_lookup_kdc = false
 dns_lookup_realm = false
 forwardable = true
 ticket_lifetime = 24h

[realms]
 JAKONDA.LOCAL = {
 kdc = dc1.jakonda.local
 default_domain = JAKONDA.LOCAL
 admin_server = dc1.jakonda.local
 }

[domain_realm]
 .jakonda.local = JAKONDA.LOCAL
 jakonda.local = JAKONDA.LOCAL

 

Проверка работы Kerberos, выполним авторизацию в Active Directory:

kinit -kV -p HTTP/webserver.jakonda.local

Using default cache: /tmp/krb5cc_0
Using principal: HTTP/webserver.jakonda.local@JAKONDA.LOCAL
Authenticated to Kerberos v5

Удаляем полученный билет:

kdestroy

 

Настройка Apache

Выставляем права на KEYTAB-файл для веб-сервера:

chown root:www-data /etc/webserver.keytab
chmod 640 /etc/webserver.keytab

 

В качестве примера Kerberos аутентификации в Apache, в конфигурацию веб-сервера по-умолчанию (000-default.conf), добавляем:

<VirtualHost *:80>
 # ... ServerName webserver.jakonda.local

  <Location /> 
    AuthType Kerberos 
    AuthName "Kerberos authenticated intranet" 
    KrbAuthRealms JAKONDA.LOCAL 
    KrbServiceName HTTP/webserver.jakonda.local 
    Krb5Keytab /etc/webserver.keytab 
    KrbMethodNegotiate On
    KrbMethodK5Passwd On
    KrbSaveCredentials Off
    KrbLocalUserMapping On
    KrbVerifyKDC Off
    Require valid-user 
  </Location> 
</VirtualHost>

 

Чтобы SSO аутентификации проходила корректно, необходимо добавить веб-сервер в зону местной интрасети:

 

Хочу обратить внимание, что при попытке доступа на сайт по IP-адресу SSO аутентификация работать не будет. Необходимо обязательно использовать доменное имя (прим. http://webserver)
 

ПОНРАВИЛАСЬ ИЛИ ОКАЗАЛАСЬ ПОЛЕЗНОЙ СТАТЬЯ, ПОБЛАГОДАРИ АВТОРА

БесполезноСлабоватоПриемлемоОтличноПревосходно (Еще нет оценок)
Загрузка...

Всего комментариев: 7 Комментировать

  1. Иван /

    Подскажите а сервер нужно в домен вводить?

    1. Жаконда / Автор записи

      Нет, сервер в домен вводить не нужно

  2. Сергей /

    а как сделать чтобы при листинге директории через apache были видны при монтированные разделы nfs

  3. Игорь /

    Добрый день!

    Подскажите, можно ли сделать аутентификацию на основе групп AD? Т.е. пользователи не принадлежащие группе, не смогли бы войти на сервер?

  4. Артём /

    Я вот развернул ejabberd в docker, настроил ldap авторизацию все работает, а вот как прикрутить SSO к этому делу разобраться не могу. Это вообще реально? может кто делал?

  5. Нариман /

    подскажите, я развернул APACHEDS настроил его, а как теперь на виндовсе ввести компьютер в этот домен apacheds а?

    1. Жаконда / Автор записи

      Не пробовали штатными способами как и в случае с доменом на базе Windows ?
      Я с ApacheDS не работал.

Оставить ответ

7 + 19 =

© IT-блог Жаконды All Rights Reserved.
Яндекс.Метрика