Настройки авторизации

Настройка SSO на основе Kerberos в среде сервера приложений Weblogic

1. Когда зарегистрированный пользователь (РС) запрашивает ресурс из Oracle WebLogic Server (WLS), он отправляет исходный HTTP GET-запрос.
2. Сервер Oracle WebLogic Server (WLS), выполняющий код обработчика токенов SPNEGO, требует аутентификации и выдает ответ 401 Access Denied, WWWAuthenticate: Negotiate.
3. Клиент (Браузер на PC) запрашивает билет сессии из TGS / KDC (AD).
4. TGS / KDC (AD) предоставляет клиенту необходимый билет Kerberos (при условии, что клиент авторизован), завернутый в токен SPNEGO.
5. Клиент повторно отправляет запрос HTTP GET + токен Negotiate SPNEGO в заголовке авторизации: Negotiate base64 (token).
6. Проверка веб-аутентификации SPNEGO на сервере Weblogic видит заголовок HTTP с токеном SPNEGO. SPNEGO проверяет токен SPNEGO и получает информацию о пользователе.
7. После того, как Weblogic получит информацию о пользователе, он проверяет пользователя в Microsoft Active Directory / KDC. Когда процесс идентификации выполняется, Weblogic выполняет соответствующий Java-код (сервлеты, JSP, EJB и т.д.) И проверяет авторизацию.
8. Код обработчика 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 [email protected] -k 1 -e aes256-cts
  Password for [email protected]: 
  ktutil:  wkt username.keytab
  ktutil:  quit

Following is an example using Heimdal Kerberos:

  > ktutil -k username.keytab add -p [email protected] -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.

После создания принципала 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 [email protected]

Она должна запрашивать пароль и получать билет:

# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: [email protected]
Valid starting       Expires              Service principal
14.03.2017 16:45:58  15.03.2017 02:45:58  krbtgt/[email protected]
	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/[email protected]
Using keytab: /home/test/squid.keytab
Authenticated to Kerberos v5

Проверить версию ключей на сервере можно, предварительно получив билет, с помощью команды:

# kvno HTTP/sqserver.domg.testg
HTTP/[email protected]: 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/[email protected] (arcfour-hmac)

После всех проверок желательно удалить полученные билеты командой:

Обзор Kerberos¶

Жесткая аутентификация и установление личности пользователя – основа безопасного доступа в Hadoop. Пользователи должны
иметь возможность надежно “идентифицировать” себя, а затем использовать эту идентификацию во всем кластере Hadoop. Как
только это будет сделано, данные пользователи могут получить доступ к ресурсам (например, к файлам или каталогам) или
взаимодействовать с кластером (например, выполнять задания MapReduce). Помимо пользователей, сами ресурсы кластера Hadoop
(такие как хосты и сервисы) должны проходить аутентификацию друг с другом, чтобы избежать потенциально опасных вредоносных
систем или систем, “позиционирующих себя” как надежные компоненты кластера с целью получения доступа к данным.

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/[email protected]

* напомним, что spnego.keytab — имя нашего файла; HTTP/[email protected] — принципал, для которого сгенерирован файл.

Команда нам ничего не должна вернуть. Это значит, что она выполнена корректно.

Теперь выполним:

klist

Мы должны увидеть что-то на подобие:

Credentials cache: FILE:/tmp/krb5cc_0
        Principal: HTTP/[email protected]
  Issued                Expires               Principal
Apr 28 15:04:47 2021  Apr 29 01:04:47 2021  krbtgt/[email protected]

В данном ответе мы видим, что нам выдан билет для принципала HTTP/[email protected]. Идем дальше.

Настройка 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/[email protected]

		# Имя файла, в котором сохранены ключи
		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. Результатом должен стать отказ в доступе:

При этом доступ к странице с нулевым уровнем конфиденциальности  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/[email protected]
# сколько параллельных потоков запускать для обслуживания аутентификации клиентов
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? [email protected] 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? [email protected] DIRECT/173.194.69.100 -

то есть имя пользователя имеет формат имя_пользователя@ОБЛАСТЬ_ДОМЕНА. При этом, как показала практика, регистр букв имеет значение, то есть если в acl указать имя пользователя [email protected] или [email protected], а в AD он заведен как test2 и область домена в верхнем регистре, то доступ пользователю предоставлен не будет. То есть нужно быть внимательным при указании пользователя в acl. Так же, можно задать список пользователей, перечислив их в отдельном файле и указав этот файл как значение для acl, например:

squid ~ # cat /etc/squid3/usersallow
[email protected]
[email protected]
...
[email protected]
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# [email protected]        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 [email protected]
  ...

  > ktutil -k mykeytab remove -V version# -e type [email protected]

Настройка 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.