Настройка SSO на основе Kerberos в среде сервера приложений Weblogic
- Когда зарегистрированный пользователь (РС) запрашивает ресурс из Oracle WebLogic Server (WLS), он отправляет исходный HTTP GET-запрос.
- Сервер Oracle WebLogic Server (WLS), выполняющий код обработчика токенов SPNEGO, требует аутентификации и выдает ответ 401 Access Denied, WWWAuthenticate: Negotiate.
- Клиент (Браузер на PC) запрашивает билет сессии из TGS / KDC (AD).
- TGS / KDC (AD) предоставляет клиенту необходимый билет Kerberos (при условии, что клиент авторизован), завернутый в токен SPNEGO.
- Клиент повторно отправляет запрос HTTP GET + токен Negotiate SPNEGO в заголовке авторизации: Negotiate base64 (token).
- Проверка веб-аутентификации SPNEGO на сервере Weblogic видит заголовок HTTP с токеном SPNEGO. SPNEGO проверяет токен SPNEGO и получает информацию о пользователе.
- После того, как Weblogic получит информацию о пользователе, он проверяет пользователя в Microsoft Active Directory / KDC. Когда процесс идентификации выполняется, Weblogic выполняет соответствующий Java-код (сервлеты, JSP, EJB и т.д.) И проверяет авторизацию.
- Код обработчика Token Handler сервера Oracle WebLogic Server принимает и обрабатывает токен через API GSS, аутентифицирует пользователя и отвечает запрошенным URL-адресом.
Теперь перейдем к практике
- Создаем пользователя в Active Directory (срок действия пароля должен быть не ограничен)
- Устанавливаем соответствующий SPN для имени сервера WLS
верхнем регистре
- В данном случае не рассматриваем настройку авторизации WLS в AD считаем, что она работает, если нужно расписать этот пункт пишите в комментариях.
- Настраиваем SPNEGO в WLS
Для этого необходимо перейти в WebLogic Server Administration Console
Переходим в раздел Security Realms >myrealm >Providers и нажимаем кнопку Add
Выбираем тип “WebLogic Negotiate Identity Assertion provider”
Проверяем, что бы было выбрано оба параметра.
Нажимаем кнопку Reorder и управляя стрелками выставляем последовательности типов авторизации. На первом месте должно быть установлено WebLogic Negotiate Identity Assertion provider на втором месте Provider that performs LDAP authentication (доменная авторизация)
- Перезагружаем сервер, для применения изменений в конфигурации.
- Деплоим приложение с измененным способом авторизации (новым web.xml)
- Чтобы отключить данный вид авторизации для административной консоли необходимо внести следующие изменения %Ora_Home%\wlserver\server\lib\consoleapp\webapp\WEB-INF\web.xml.
Меняем строку
Create a keytab file
Note:
To use the instructions and examples on this page, you need access to a Kerberos client, on either your personal workstation or an IU research supercomputer. When following the examples on this page, enter the commands exactly as they are shown. You may need to modify your path to include the location of (for example, or
).
You can create keytab files on any computer that has a Kerberos client installed. Keytab files are not bound to the systems on which they were created; you can create a keytab file on one computer and copy it for use on other computers.
Following is an example of the keytab file creation process using MIT Kerberos:
> ktutil ktutil: addent -password -p username@ADS.IU.EDU -k 1 -e aes256-cts Password for username@ADS.IU.EDU: ktutil: wkt username.keytab ktutil: quit
Following is an example using Heimdal Kerberos:
> ktutil -k username.keytab add -p username@ADS.IU.EDU -e arcfour-hmac-md5 -V 1
If the keytab created in Heimdal does not work, it is possible you will need an entry. In that case, you will need to find a computer with MIT Kerberos, and use that method instead.
Note:
For more about the ADS.IU.EDU Kerberos realm, see Current Kerberos realm at IU.
Синхронизация времени
Протокол Kerberos требует соответствия показаний часов всех клиентов и серверов, и при рассинхронизации часов аутентификация становится невозможной.Простой и стандартный путь обеспечения синхронизации — использование сервиса Network Time Protocol (NTP).
Установка пакета (сервер)
Пакеты сервиса Kerberos входят в стандартные дистрибутивы Astra Linux, и могут быть установлены с помощью графического менеджера пакетов, или из командной строки командой
apt install krb5-kdc krb5-admin-server krb5-user
При установке выдаётся предупреждение о том, что пакет не настроен, которое пока можно проигнорировать.
После установки сервис автоматически не запускается, и должен быть настроен для запуска.
Настройка пакета (сервер Kerberos)
При установке пакета будет создан файл конфигурации сервиса /etc/krb5kdc/kdc.conf со стандартным содержимым, в котором автоматически будет указано имя области Kerberos, полученное из FQDN сервера, на котором выполняется установка:
Kerberos использует для контроля доступа к администрированию сервиса Списки Управления Доступом (Access Control List, ACL) .По умолчанию, список располагается в файле /etc/krb5kdc/kadm5.acl.
Для примера, создадим файл /etc/krb5kdc/kadm5.acl, дающий неограниченные права любому принципалу, чьё имя заканчивается на /admin:
И создадим новую область Kerberos командой:
krb5_newrealm
При выполнении команды нужно будет ввести и подтвердить пароль администратора, после чего будут автоматически созданы нужные базы данных.
Далее, для выполнения задач по администрированию сервиса Kerberos нужно создать принципала с правами администратора.Для этого используем инструмент командной строки kadmin.local, предназначенный для администрировния Kerberos на локальном компьютере.
Инструмент вызывается из командной строки командой
После вызова инструмента можно ввести симовл «вопросительный знак», в ответ на это будет выдана подсказка по списку команд.
Добавим нового принципала admin/admin командой addprinc:
После ввода команды будет запрошен пароль для создаваемого принципала.
Выход из инструмента kadmin.local осуществляется командой quit.
![Подключение debian gnu/linux 10 (buster) к домену active directory с помощью sssd/realmd и настройка pam для аутентификации и авторизации sshd/apache [вики it-kb]](https://smartshop124.ru/wp-content/uploads/c/d/c/cdc1caef8b9af92efe998f5a9a7c246d.jpeg)
![Centos linux 6.6 (shmz) - подключение к домену active directory с помощью adcli и настройка аутентификации и авторизации через sssd [вики it-kb]](https://smartshop124.ru/wp-content/uploads/f/a/b/fabd0f243715564cced198dc04113dd6.jpeg)
![Centos linux 6.6 (shmz) - подключение к домену active directory с помощью adcli и настройка аутентификации и авторизации через sssd [вики it-kb]](https://smartshop124.ru/wp-content/uploads/f/6/a/f6a51eb1d11f659f6ca0860c36ea0cd0.jpeg)
После создания принципала admin/admin его можно использовать для администрирования сервера Kerberos с удалённых компьютеров с помощью инструмента командной строки kadmin.Этот инструмент аналогичен инстрменту kadmin.local, однако рассчитан на удалённое подключение, и требует авторизации пользователя через указание принципала и ввод пароля:
kadmin -p admin/admin
Настройка DNS для автоматизации подключения клиентов
Для автоматического получения клиентами адреса сервера Kerberos можно использовать специальные настройки сервера DNS: служебные записи (SRV-записи).Пример таких записей для службы Kerberos см. в статье про сервер DNS
Установка пакетов (клиент)
Клиентский пакет Kerberos krb5-user входит в дистрибутивы Astra Linux, но по умолчанию не устанавливается. Пакет может быть установлен с помощью графического менеджера пакетов, или из командной строки командой
apt install krb5-user
При установке пакета krb5-user, кроме самого пакета, автоматически будет установлен пакет krb5-config для настройки клиента
Настройка клиентов
Настройка клиента Kerberos выполняется командой
dpkg-reconfigure krb5-config
При этом команда
- Попросит указать имя домена (в нашем примере — ASTRADOMAIN.RU);
- Задаст вопрос о необходимости указать сервер(ы) Kerberos в файле конфигурации клиента /etc/krb5.conf.Если ответить «да», то программа попросит ввести имена сервера (серверов) Kerberos Если DNS уже настроен (см «Настройка DNS для автоматизации подключения клиентов»), можно просто ответить «нет».
После завершения работы программы настройки результат настройки можно проверить получением принципала.Команда kinit должна выполняться без ошибок:
kinit admin/admin
Проверить содержимое полученного принципала можно командой
klist
Настройка авторизации клиентов через Kerberos
Для обеспечения возможности авторизации пользователей через Kerberos требуется дополнительно установить пакет libpam-krb5:
apt install libpam-krb5
После установки пакета необходимые модули авторизации будут автоматически добавлены в стек авторизации PAM.
Kerberos (MIT)
FILE Main Kerberos config file
libdefaults default_realm = EXAMPLE.CO.UK forwardable = true proxiable = true default_keytab_name = FILE:/etc/krb5.keytab
Do not create the file /etc/krb5.keytab — Samba may give an error if it can’t create the keytab file.
The following command will grab a Kerberos ticket for the currently logged in user. <user> can actually be any valid Kerberized user account, if omitted then the current Unix username is used. If the default realm is already specified in krb5.conf then it can be also be omitted.
If the realm is already set and the ticket is for a username that matches the Unix user then simply run kinit and enter a password.
It is not always possible to use supplementary groups with some daemons eg Squid. The following will add additional ACLs to the Kerberos keytab file file to allow the processes to read the keytab. This assumes that you have ACL support on the system. If not then you will need some other method of allowing the daemons to access the single keytab. Failing that you will have to create separate keytabs for each application and get them set up manually — web search for that. Only do this bit after getting Samba to create the file, otherwise you may get errors.
file: etc/krb5.keytab owner: root group: root user::rwx user:squid:r-- user:apache:r-- group::r-- mask::r-- other::---
Проверка keytab-файла[править]
Для проверки keytab-файла необходима настроенная Kerberos-аутентификация.
Это можно проверить командой:
# kinit Administrator@DOMG.TESTG
Она должна запрашивать пароль и получать билет:
# klist Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@DOMG.TESTG Valid starting Expires Service principal 14.03.2017 16:45:58 15.03.2017 02:45:58 krbtgt/DOMG.TESTG@DOMG.TESTG renew until 21.03.2017 16:44:36
Попробуем зарегистрироваться с помощью keytab-файла:
# kinit -V -k HTTP/sqserver.domg.testg -t /home/test/squid.keytab Using existing cache: persistent:0:krb_ccache_95Lkl2t Using principal: HTTP/sqserver.domg.testg@DOMG.TESTG Using keytab: /home/test/squid.keytab Authenticated to Kerberos v5
Проверить версию ключей на сервере можно, предварительно получив билет, с помощью команды:
# kvno HTTP/sqserver.domg.testg HTTP/sqserver.domg.testg@DOMG.TESTG: kvno = 6
Проверить версию kvno и список ключей в keytab-файле можно с помощью команды:
# klist -ket /home/test/squid.keytab Keytab name: FILE:/home/test/squid.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 6 01.01.1970 03:00:00 HTTP/sqserver.domg.testg@DOMG.TESTG (arcfour-hmac)
После всех проверок желательно удалить полученные билеты командой:
Обзор Kerberos¶
Жесткая аутентификация и установление личности пользователя – основа безопасного доступа в Hadoop. Пользователи должны
иметь возможность надежно “идентифицировать” себя, а затем использовать эту идентификацию во всем кластере Hadoop. Как
только это будет сделано, данные пользователи могут получить доступ к ресурсам (например, к файлам или каталогам) или
взаимодействовать с кластером (например, выполнять задания MapReduce). Помимо пользователей, сами ресурсы кластера Hadoop
(такие как хосты и сервисы) должны проходить аутентификацию друг с другом, чтобы избежать потенциально опасных вредоносных
систем или систем, “позиционирующих себя” как надежные компоненты кластера с целью получения доступа к данным.
![Подключение debian gnu/linux 10 (buster) к домену active directory с помощью sssd/realmd и настройка pam для аутентификации и авторизации sshd/apache [вики it-kb]](https://smartshop124.ru/wp-content/uploads/2/8/c/28c0c9d233630fe92f38feeda76441d7.jpeg)
Hadoop использует Kerberos в качестве основы для строгой аутентификации и обеспечения идентичности пользователям и
сервисам. Kerberos является сторонним механизмом аутентификации, на который полагаются пользователи и сервисы для
удостоверения подлинности друг друга. Сам сервер Kerberos известен как Key Distribution Center (Центр распределения ключей)
или KDC. Он состоит из трех частей:
- База данных пользователей и сервисов (известных как принципалы), о которых он знает, и соответствующие пароли Kerberos;
- Сервер аутентификации (AS), который выполняет первоначальную проверку подлинности и выдает Ticket Granting Ticket (TGT);
- Ticket Granting Server (TGS) – сервер, который оформляет последующие билеты на основе начального TGT.
Пользователь-принципал запрашивает аутентификацию от AS. AS отправляет в ответ TGT, который зашифрован с
использованием пароля пользователя-принципала Kerberos, известный только пользователю и AS. Пользователь-принципал
расшифровывает TGT локально, используя свой пароль Kerberos, и с этого момента до истечения срока действия билета
пользователь-принципал может использовать TGT для получения билетов от TGS. Данные билеты позволяют принципалу получить
доступ к различным сервисам.
Поскольку ресурсы кластера (хосты или сервисы) не могут каждый раз предоставлять пароль для расшифровки TGT, они
используют специальный файл keytab, который содержит учетные данные аутентификации ресурса. Набор хостов, пользователей и
сервисов, над которыми сервер Kerberos имеет контроль, называется сферой.
Host Names
Each server in a Kerberos authentication realm must be assigned a Fully Qualified Domain Name (FQDN) that is forward-resolvable.
Kerberos also expects the server’s FQDN to be reverse-resolvable. If reverse domain name resolution is not available, set the rdns variable to false in clients’ krb5.conf
Note: Active Directory depends heavily on DNS, so it is likely that the Active Directory Domain Controller is also running the Microsoft DNS server package. If this is the case, verify that each server has a FQDN assigned to it before performing the tests outlined in this section.
If the server already has an FQDN assigned to it, test forward and reverse look-up with the following commands:
$ nslookup server.example.com $ nslookup <server ip address>
The output of the first command should contain the IP address of the server. The output of the second command should contain the FQDN of the server.
If the server does not already have a FQDN assigned to it and DNS services are not available, name resolution can be implemented by editing the local hosts file (typically this is located in /etc) on each server and client, adding the following line:
127.0.0.1 linuxwork.example.com localhost linuxwork
Test the local DNS name resolution using the nslookup technique described at the beginning of the section.
Установка и настройка KDC¶
Ambari может настроить Kerberos в кластере для работы с существующим MIT KDC или с существующей Active Directory.
В данном разделе описываются шаги, необходимые для подготовки к интеграции.
Если у вас нет существующего KDC (MIT или Active Directory), необходимо установить новый MIT KDC.
Important
Установка KDC на узле кластера уже после установки клиента Kerberos может перезаписать созданный Ambari файл krb5.conf
При выборе автоматической настройки Kerberos Ambari самостоятельно подключается к KDC, создает необходимых принципалов,
генерирует и распространяет keytabs. При выборе ручной настройки Kerberos необходимо вручную создавать принципалов,
генерировать и распространять keytabs.
- Использование существующего MIT KDC;
- Использование существующей Active Directory;
- Ручная настройка Kerberos;
- Установка нового MIT KDC.
Использование существующего MIT KDC
Для использования существующего MIT KDC для кластера необходимо подготовить:
- Серверы Ambari и кластеры, имеющие сетевой доступ как к административным узлам KDC, так и к самому KDC;
- Учетные данные администратора KDC.
Дальнейшие действия описаны в разделе .
Использование существующей Active Directory
Для использования существующей Active Directory для кластера с автоматической установкой Kerberos необходимо подготовить:
- Серверы Ambari и кластеры, имеющие доступ к сети и DNS-именам Domain Controllers;
- Настроить конфигурацию LDAP (LDAPS) Active Directory;
- Пользовательскую Active Directory для принципалов. Например, “OU = Hadoop, OU = People, dc = apache, dc = org”;
- Учетные данные администратора Active Directory с с настроенным правом “Создание, удаление и управление учетными записями пользователей”.
Дальнейшие действия описаны в разделе .
Ручная настройка Kerberos
Для ручной настройки Kerberos необходимо подготовить:
- Сетевой доступ узлов кластера к KDC;
- Установить утилиты клиента Kerberos (например, kinit) на каждом узле кластера;
- Установить расширения Java Cryptography (JCE) на хосте сервера Ambari Server и на всех узлах кластера;
- Вручную создать сервисные и Ambari принципалы в KDC перед выполнением мастера;
- Создать вручную и распространить ключи для принципалов сервисов и Ambari на узлы кластера перед выполнением мастера.
Дальнейшие действия описаны в разделе .
Настройка Linux для интеграции с AD
Для интеграции Linux с нашим LDAP (в данном примере, на основе Active Directory) установим необходимые пакеты и настроим Kerberos.
Установка пакетов
Необходимые пакеты ставим из репозиториев.
а) на Ubuntu/Debian:
apt-get install heimdal-clients
б) на Centos:
yum install krb5-workstation
Проверка файла
Переходим в каталог с файлом keytab и выполняем команду:
kinit -kt spnego.keytab HTTP/nginx.domain.local@DOMAIN.LOCAL
* напомним, что spnego.keytab — имя нашего файла; HTTP/nginx.domain.local@DOMAIN.LOCAL — принципал, для которого сгенерирован файл.
Команда нам ничего не должна вернуть. Это значит, что она выполнена корректно.
Теперь выполним:
klist
Мы должны увидеть что-то на подобие:
Credentials cache: FILE:/tmp/krb5cc_0
Principal: HTTP/nginx.domain.local@DOMAIN.LOCAL
Issued Expires Principal
Apr 28 15:04:47 2021 Apr 29 01:04:47 2021 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
В данном ответе мы видим, что нам выдан билет для принципала HTTP/nginx.domain.local@DOMAIN.LOCAL. Идем дальше.
Настройка kerberos
Открываем на редактирование файл:
vi /etc/krb5.conf
Приводим его к виду (остальные строки не трогаем):
…
default_realm = DOMAIN.LOCAL
..
DOMAIN.LOCAL = {
kdc = 192.168.0.15
kdc = 192.168.0.16
kdc = 192.168.0.17
admin_server = domain.local
}
* DOMAIN.LOCAL — наш домен; kdc — перечень контроллеров домена; admin_server — первичный контроллер (в данном примере будет использоваться случайный).
На компьютере — web-сервере Apache2 (Часть 2)
Скопировать keytab (файл /tmp/http.keytab) с контроллера домена на web-сервер в каталог /etc/apache2/.
Выставить права на keytab:
sudo chown www-data /etc/apache2/http.keytabsudo chmod 644 /etc/apache2/http.keytab
В конфигурацию виртуального хоста virtualhost в файле /etc/apache2/sites-available/000-default.conf внести настройки:
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
<Directory /var/www>
AuthType Kerberos
# Имя реалма Керберос - имя домена ЗАГЛАВНЫМИ буквами
KrbAuthRealms ASTRA.DOMAIN
# Полное доменное имя сервиса (имя ранее созданной службы HTTP):
KrbServiceName HTTP/client.astra.domain@ASTRA.DOMAIN
# Имя файла, в котором сохранены ключи
Krb5Keytab /etc/apache2/http.keytab
KrbMethodNegotiate on
KrbMethodK5Passwd off
require valid-user
KrbSaveCredentials on
</Directory>
</VirtualHost>
Создать каталог для виртуального сервера:
На компьютере — web-сервере назначить мандатные атрибуты каталогу с виртуальным сервером:
sudo pdpl-file 3:0:0xffffffffffffffff:ccnr /var/www/sudo pdpl-file 3:0:0xffffffffffffffff:ccnr /var/www/html/
Перезапустить web-сервер:
sudo systemctl restart apache2
Проверка работы мандатных ограничений
На компьютере — контроллере домена создать доменного пользователя, и выставить ему ненулевой «максимальный уровень конфиденциальности» (например, 1).
На компьютере — web-сервере в папке виртуального сервера /var/www/html/ создать 2 файла и установить ненулевую мандатную метку на файл 1.html:
echo «Hello world! 0» | sudo tee /var/www/html/0.htmlecho «Hello world! 1» | sudo tee /var/www/html/1.htmlsudo pdpl-file 1:0:0 /var/www/html/1.html
Должно получиться так:
На любом компьютере, который должен выступать в роли клиента, в web-браузере negotiate авторизацию (для чего открыть страницу about:config и добавить http:// в параметры network.negotiate-auth.delegation-uris и network.negotiate-auth.trusted-uris):
После чего зайти на клиентский компьютер под пользовательской доменной учетной записью с нулевым уровнем конфиденциальности и попытаться получить доступ к странице с ненулевым уровнем конфиденциальности http://client.astra.domain/html/1.html. Результатом должен стать отказ в доступе:
![Squid и kerberos-авторизация через active directory [rtzra's hive]](https://smartshop124.ru/wp-content/uploads/a/3/4/a34516e9f59d7bb5563bd8aa82c72866.jpeg)
При этом доступ к странице с нулевым уровнем конфиденциальности http://client.astra.domain/html/0.html должен предоставляться:
При входе на клиентский компьютер под пользовательской доменной учетной записью с ненулевым уровнем конфиденциальности должны быть доступны обе страницы.
Настройка squid на проверку подлинности через Kerberos в домене Windows 2008 R2.
Для того чтобы сквид знал, какой кейтаб использовать, ему нужно указать, где он лежит. Для этого нужно создать и заполнить файл /etc/default/squid3 следующим содержимым (задать переменную, хранящую путь к кейтаб файлу, которую читает сквид):
squid ~ # cat /etc/default/squid3 KRB5_KTNAME=/etc/squid3/squid.keytab export KRB5_KTNAME
Так же, необходимо в squid.conf настроить схему аутентификации, для этого нужно добавить следующие строки:
# указание, какой хелпер использовать с каким SPN auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/squid.domain.local@DOMAIN.LOCAL # сколько параллельных потоков запускать для обслуживания аутентификации клиентов auth_param negotiate children 10 # указывает поддерживать связь, а не обрывать, когда браузер опрашивает схемы аутентификации auth_param negotiate keep_alive on
В некоторых конфигурациях в «сети» приводятся примеры без указания параметра -s и SPN, но у меня такая конфигурация не заработала. Так же, не забываем о наличии строк, разрешающим доступ для авторизованных пользователей:
acl lan proxy_auth REQUIRED http_access allow lan
Примечание: вместо SPN можно использовать значение GSS_C_NO_NAME, в данном случае, squid будет использовать любой (какой? в какой последовательности?) SPN из keytab файла. Строка будет выглядеть так: <…>ate program /usr/lib/squid3/squid_kerb_auth -s GSS_C_NO_NAME(спасибо за дополнение комментатору selivan)
На этом можно считать настойку сквида законченной (не забудте сделать рестарт сквида). Если необходимо пускать не в всех пользователей в интернет, а только избранных, то в acl необходимо указать имя пользователя в том формате, в котором squid распознает пользователя. Этот формат можно посмотреть в логе access.log. Например для нашего случая имя пользователя имеет следующий вид:
1330858897.314 86 10.0.1.48 TCP_MISS/200 491 GET http://www.google-analytics.com/__utm.gif? test2@DOMAIN.LOCAL DIRECT/173.194.69.113 image/gif 1330858898.296 94 10.0.1.48 TCP_MISS/204 192 GET http://support.google.com/accounts/bin/stats? test2@DOMAIN.LOCAL DIRECT/173.194.69.100 -
то есть имя пользователя имеет формат имя_пользователя@ОБЛАСТЬ_ДОМЕНА. При этом, как показала практика, регистр букв имеет значение, то есть если в acl указать имя пользователя tEst2@DOMAIN.LOCAL или test2@DOMAIN.local, а в AD он заведен как test2 и область домена в верхнем регистре, то доступ пользователю предоставлен не будет. То есть нужно быть внимательным при указании пользователя в acl. Так же, можно задать список пользователей, перечислив их в отдельном файле и указав этот файл как значение для acl, например:
squid ~ # cat /etc/squid3/usersallow ultest@DOMAIN.LOCAL test2@DOMAIN.LOCAL ... testn@DOMAIN.LOCAL squid ~ # grep allow /etc/squid3/squid.conf acl allowinet proxy_auth "/etc/squid3/usersallow" http_access allow allowinet
Кроме данного способа, есть возможность предоставить доступ пользователей к интернету на основе членства в доменных группах. Но для данной задачи используется отдельный хелпер и список доступа в формате external_acl и хелпер /usr/lib/squid3/squid_ldap_group. В сети можно найти много примеров. Конфигурацию на основе доменных групп я постараюсь рассмотреть в следующих статьях.
Apache
- Add to /etc/conf.d/apache2
Edit the module config or add it into your vhost configuration
FILE Example Apache Kerberos config
<IfDefine AUTH_KERB>
LoadModule auth_kerb_module modules/mod_auth_kerb.so
#LogLevel Debug
<Location "/">
AuthType Kerberos
AuthName "Kerberos Login"
Krb5Keytab /etc/krb5.keytab
KrbAuthRealms EXAMPLE.CO.UK
KrbMethodNegotiate On
KrbMethodK5Passwd Off
Require valid-user
</Location>
</IfDefine>
Set on to get prompted for authentication. I suggest you only use this over SSL/TLS (https) for obvious reasons.
Use Samba to set the service principle(s) for Apache (HTTP):
Note the format in the second command. This will get non default Service Principle Names into the keytab, eg for externally facing vhosts. Remember to set the section in krb5.conf if you need an external domain to map to an internal realm (or AD domain as MS call them!) The second command also seems to need the SPN added to AD using setspn.exe (on a Windows machine with Domain Admin rights and probably an elevated command prompt on server 2008+):
c:\>setspn.exe -A HTTP/<another SPN> <computer account>
Test it with this index.php in the web server’s htdocs somewhere (assuming you have PHP installed and configured):
FILE Test PHP script
<?php echo "You have logged in as <b>" . $_SERVER'REMOTE_USER' . "</b>;"; ?>
Errors like this in errors_log means that the keytab can’t be read — check the permissions on it for the apache user:
gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Permission denied)
# Типы шифрования
Выбранный тип шифрования зависит от участников взаимодействия — версии ПО домена (Windows Server), настроек домена, настроек пользователя, настроек ПО клиента.
В ранних версиях (Windows 2000, 2003) настраивали DES, в поздних (Windows 2008, 2012) рекомендуют использованием AES.
Настройки пользователя, оказывающие влияние на поведение Kerberos:
This account supports Kerberos AES 128/256 bit encryption — разрешение использования соответствущего типа шифрования для пользователя
(TODO — при невключённых чекбоксах всё равно использовался AES128)
Use Kerberos DES encryption for this acount — включает шифрование DES для пользователя, после установки чекбокса требуется смена пароля
# krb5.ini
Файл не является обязательным, но может влиять на поведение процесса аутентификации.
На сервере и клиентских машинах Windows он может быть расположен в ${windir}/krb5.ini.
Пример файла krb5.ini
.test.com = TEST.COM
test.com = TEST.COM
default_realm = TEST.COM
kdc_timesync = 1
ccache_type = 4
ticket_lifetime = 600
default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
kdc = CONSOLE
TEST.COM = {
kdc = 192.168.0.1
kdc = 192.168.1.1
default_domain = test.com
}
autologin = true
forward = true
forwardable = true
encrypt = true
Настройка сервера
Данная инструкция сделана в окружении Windows Server2008R2 (контроллер домена), Windows Server2012R2 (RunaWFE Server), Windows7 (RunaWFE client).
В данном разделе регистр может иметь значение, хотя опытным путём было выяснено что логин пользователя, название компьютера сервера и SPN не являются регистрозависимыми.
Realm Administration: kadmin
The Kerberos realm is administered using the kadmin utility. The kadmin utility is an interactive interface that allows the administrator to create, retrieve, update, and delete realm principals. kadmin can be run on any computer that is part of the Kerberos realm, provided the user has the proper credentials. However, for security reasons, it is best to run kadmin on a KDC.
An alternative program, kadmin.local, is available as well. Running kadmin.local as the root user on the KDC allows the administrator to authenticate without having an existing principal. This is generally not necessary in a properly configured environment.
To start the kadmin utility, issue the following command:
$ kadmin -p <principal>
Replace <principal> with a valid principal name. By default, the principal admin/admin has administrative rights to the realm, so to launch kadmin as the realm administrator, use:
$ kadmin -p admin/admin
Type ? and press Enter at the kadmin prompt to see a list of valid commands.
Common tasks
Add a user:
kadmin: addprinc user
The default realm name is appended to the principal’s name by default
Delete a user:
kadmin: delprinc user
List principals:
kadmin: listprincs
Add a service:
kadmin: addprinc service/server.fqdn
The default realm name is appended to the principal’s name by default
Delete a user:
kadmin: delprinc service/server.fqdn
Delete a key from a keytab file
If you no longer need a keytab file, delete it immediately. If the keytab contains multiple keys, you can delete specific keys with the
command. You can also use this procedure to remove old versions of a key. An example using MIT Kerberos follows:
> ktutil ktutil: read_kt mykeytab ktutil: list ... slot# version# username@ADS.IU.EDU version# ... ktutil: delent slot#
Replace with the name of your keytab file,
with your username, and with the appropriate version number.
Verify that the version is gone, and then in , enter:
quit
To do the same thing using Heimdal Kerberos, use:
> ktutil -k mykeytab list ... version# type username@ADS.IU.EDU ... > ktutil -k mykeytab remove -V version# -e type username@ADS.IU.EDU
Настройка NFSv4 без Kerberos
1.1., 1.2. Настройка NFSv4 сервера и клиента
Я решил объединить эти 2 пункта, т.к. они содержат очень похожие шаги. Поэтому начнем настройку с общих этапов для клиента и сервера. Итак, и на клиенте и на сервере необходимо настроить сеть в Debian. (Так же можно почитать статью основные понятия сетей). На сервере и клиенте необходим с необходимыми зависимостями (portmap). Для того чтобы протокол Kerberos работал корректно, необходимо обязательно правильно настроить файлы , , , ну и конечно /etc/network/interfaces. Для того чтобы избавиться от возможных ошибок при работе к Kerberos, необходимо учесть некоторые нюансы (хотя и без этих нюансов скорей всего заработает), которые я отмечу комментариями:
root@nfsc:~# cat /etc/hosts 10.0.0.51 nfsc.DOMAIN.local nfsc 127.0.0.1 localhost # для Kerberos советуют указывать именно такой порядок # то есть первой строкой именно 10.0.0.51 (внешний IP, не loopback) root@nfsc:~# cat /etc/hostname nfsc root@nfsc:~# cat /etc/resolv.conf domain DOMAIN.local search DOMAIN.local nameserver 10.0.0.4 root@nfsc:~# cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.0.0.51 netmask 255.255.0.0 gateway 10.0.0.254 ================================== root@nfsd:~# cat /etc/hosts 10.0.0.50 nfsd.DOMAIN.local nfsd 127.0.0.1 localhost root@nfsd:~# cat /etc/hostname nfsd root@nfsd:~# cat /etc/resolv.conf domain DOMAIN.local search DOMAIN.local nameserver 10.0.0.4 root@nfsd:~# cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.0.0.50 netmask 255.255.0.0 gateway 10.0.0.254
Думаю видно, где тут сервер, где тут клиент? Если все же — нет, то как я уже говорил выше nfsd — это сервер и имеет строку root@nfsd:~#, а nfsс — это клиент и имеет строку root@nfsc:~#. На клиенте и на сервере необходимо иметь установленный пакет nfs-common, как он устанавливается и из чего он состоит я писал в прошлой статье. В конфигурационном файле NFS клиента (/etc/default/nfs-common) необходимо добавить «yes» в параметр NEED_IDMAPD=yes и NEED_GSSD=yes. Это разрешить запуск демонов rpc.idmapd и rpc.gssd, которые необходимы для работы интерфейса GSS-API для взаимодействия с Kerberos. После этого, необходимо перезапустить nfs-common на обеих машинах.
root@nfsс:~# service nfs-common restart Stopping NFS common utilities: gssd idmapd statd. Starting NFS common utilities: statd idmapd gssd.
Далее, настройка производится на cервере. На сервере NFS необходимо установить . И задать экспортируемые каталоги в , перезапустить сервер и проверить сделанное :
root@nfsd:~# mkdir /nfs root@nfsd:~# vim /etc/exports root@nfsd:~# cat /etc/exports /nfs 10.0.0.51(rw,sync,no_subtree_check) 10.0.0.50(rw,sync,no_subtree_check) root@nfsd:~# service nfs-kernel-server restart Stopping NFS kernel daemon: mountd nfsd. Unexporting directories for NFS kernel daemon.... Exporting directories for NFS kernel daemon.... Starting NFS kernel daemon: nfsd mountd. root@nfsd:~# showmount -e Export list for nfsd: /nfs 10.0.0.50,10.0.0.51
На этом настройка сервера и клиента завершена. Давайте проверим наши настройки. Сначал необходимо попробовать смонтировать экспортированный каталог локально на сервере по протоколу NFSv4:
root@nfsd:~# mount -v -t nfs4 10.0.0.50:/nfs /mnt mount.nfs4: timeout set for Fri Nov 18 12:20:52 2011 mount.nfs4: trying text-based options 'addr=10.0.0.50,clientaddr=10.0.0.50' 10.0.0.50:/nfs on /mnt type nfs4 (rw) root@nfsd:~# mount | grep nfs4 10.0.0.50:/nfs on /mnt type nfs4 (rw,addr=10.0.0.50,clientaddr=10.0.0.50)
Как видно, монтирование произошло удачно. Более подробно о а еще подробней — в . Теперь проверим возможность удаленного монтирования с клиентской машины:
root@nfsc:~# mount -v -t nfs4 10.0.0.50:/nfs /mnt mount.nfs4: timeout set for Fri Nov 18 11:01:16 2011 mount.nfs4: trying text-based options 'addr=10.0.0.50,clientaddr=10.0.0.51' 10.0.0.50:/nfs on /mnt type nfs4 (rw) root@nfsc:~# mount | grep nfs4 10.0.0.50:/nfs on /mnt type nfs4 (rw,addr=10.0.0.50,clientaddr=10.0.0.51)
Как видно, опять все удачно. На этом можно считать, что NFS корректно работает по протоколу NFSv4. Теперь можно приступить к настройке протокола Kerberos на Debian.
