Создание SPN и Keytab файла
Содержание
Введение [ править ]
Создание SPN [ править ]
DC Windows [ править ]
Для начала необходимо создать на контроллере домена (DC) пользователя к которому впоследствии мы привяжем SPN.
Например создадим пользователя squid: 
Далее необходимо запретить пользователю смену пароля и не ограничивать срок действия пароля. Последнее важно, так как иначе при истечении срока действия пароля придется не только менять пароль, но и заново генерировать keytab-файлы привязанные к этому пользователю: 
В целях безопасности рекомендуется исключить сервисного пользователя из доменных групп.
Создадим SPN для прокси-сервера squid HTTP/sqserver.domg.testg и привяжем его к пользователю squid.
Для этого в командной строке на контроллере домена выполним следующую команду:
Проверить привязанные SPN у пользователя можно командой:
DC FreeIPA [ править ]
Для добавления SPN зайдите в web-интерфейс сервера FreeIPA->Identity->Services->Add: 
В открывшемся окне необходимо выбрать имя сервиса и имя хоста, к которому будет привязан сервис: 
Чтобы добавить SPN с коротким именем хоста (например это необходимо для samba), выполните команду:
Генерирование keytab-файла [ править ]
Создать keytab-файл можно разными способами.
Рассмотрим некоторые из них.
На контроллере домена Windows 2008 R2 [ править ]
Необходимо выполнить следующую команду:
Рассмотрим параметры команды подробнее:
На машине с ALT [ править ]
С помощью ktutil [ править ]
Этот способ работает если SPN предварительно были созданы и привязаны.
Установим необходимый пакет:
Запустим ktutil и создадим keytab-файл:
С помощью Samba [ править ]
Для создания keytab-файла с помощью samba, необходима работающая kerberos-аутентификация.
При использовании этого метода нет необходимости генерировать и привязывать SPN на контроллере домена.
Приведите файл настроек /etc/samba/smb.conf к следующему виду:
Введите машину в домен:
Проверить ввод в домен можно командой:
После этого в домене будет создан аккаунт компьютера к которому можно будет привязать SPN.
Создадим keytab-файл для компьютера:
Добавим в keytab-файл принципала сервиса «HTTP»:
Далее можно поменять права на keytab и отредактировать его утилитой kutil.
С помощью Samba DC [ править ]
При использовании этого метода kerberos ни при чём, а все действия выполняются на машине с домен-контроллером.
Создадим пользователя, с которым будем связывать создаваемые SPN:
Привяжем к нему SPN:
(возможно несколько раз для разных сервисов)
(выполняем несколько раз для всех spn, которые хотим поместить в keytab)
С помощью FreeIPA Client [ править ]
Для этого способа необходимо ввести машину в домен FreeIPA [[1]]
Для генерации keytab-файла используется команда:
Проверка keytab-файла [ править ]
Для проверки keytab-файла необходима настроенная Kerberos-аутентификация.
Это можно проверить командой:
Она должна запрашивать пароль и получать билет:
Попробуем зарегистрироваться с помощью keytab-файла:
Проверить версию ключей на сервере можно, предварительно получив билет, с помощью команды:
Проверить версию kvno и список ключей в keytab-файле можно с помощью команды:
После всех проверок желательно удалить полученные билеты командой:
Прозрачная авторизация для приложения на Oracle Weblogic Server
В данной статье расскажу, как мы перешли с NTLM на Kerberos авторизацию для приложений на Oracle Weblogic Server, тем самым упростив пользователям вход, убрав необходимость вводить пароль. Все пользователи, а также сервер приложения находятся в одном домене, так же ранее была настроена доменная авторизация для приложений Weblogic сервера. Все конфигурации были проверены на WLS 12.1.2.
Для начала немного теории, очень кратко для дальнейшего понимания процесса взаимодействия.
Что такое Single Sign-On?
Единый вход (SSO) — это механизм, посредством которого одно действие аутентификации пользователя, позволяет пользователю получить доступ ко всем компьютерам и системам, где у него есть разрешение на доступ, без необходимости вводить несколько паролей. Ранее введенные учетные данные будут прозрачно повторно использоваться различными компонентами.
Что такое Kerberos?
Kerberos — это протокол сетевой аутентификации, который был впервые разработан Технологическим институтом Массачусетса. Kerberos является безопасным методом аутентификации запроса на услугу в сети и предназначен для обеспечения надежной аутентификации для клиент-серверных приложений с использованием криптографии с секретным ключом.
Что такое SPNEGO?
SPNEGO — это простой и защищенный механизм переговоров GSSAPI. Это стандартизованный интерфейс для аутентификации (например, JNDI для поиска в каталогах), реализация по умолчанию для SPNEGO под Windows — это Kerberos (например, LDAP для JNDI). В терминологии Microsoft в качестве синонима SPNEGO используется «Интегрированная аутентификация Windows». В Windows Integrated Authentication могут быть согласованы протоколы Kerberos или NTLM.
Когда сервер получает запрос от браузера Internet Explorer (IE 6.1 или выше), он может запросить, чтобы браузер использовал протокол SPNEGO для аутентификации. Этот протокол выполняет аутентификацию Kerberos через HTTP и позволяет Internet Explorer передавать делегированные полномочия, чтобы веб-приложение могло выполнять вход в последующие Kerberized службы от имени пользователя.
Когда HTTP-сервер хочет выполнить SPNEGO, он возвращает ответ «401 Unauthorized» на HTTP-запрос с заголовком «WWW-Authorization: Negotiate». Затем Internet Explorer связывается с службой выдачи билетов (TGS) для получения билета. Он выбирает специальное имя участника услуги для запроса билета, например:
Возвращенный билет затем завернут в токен SPNEGO, который закодирован и отправляется обратно на сервер с использованием HTTP-запроса. Маркер разворачивается, и билет аутентифицируется.
Преимущества Kerberos
Использование керберос дает возможность администраторам отключить проверку подлинности NTLM, как только все сетевые клиенты смогут аутентифицировать Kerberos. Протокол Kerberos более гибкий и эффективный, чем NTLM, и более безопасный.
Настройка SSO на основе Kerberos в среде сервера приложений Weblogic
Теперь перейдем к практике
1. Выполняем настройки на стороне сервера домен контролера, на котором настроены службы TGS / KDC.
должно вернуть две записи
Сгенерировать Keytab файл
Скопировать данный файл на сервер WLS
2. Настройка сервера WLS
Обратите внимание, что имя домена должно быть указано в верхнем регистре. Для более ранних версий, используйте com.sun.security.jgss.initiate в предыдущем конфиге вместо com.sun.security.jgss.krb5.initiate.
Нажимаем кнопку Reorder и управляя стрелками выставляем последовательности типов авторизации. На первом месте должно быть установлено WebLogic Negotiate Identity Assertion provider на втором месте Provider that performs LDAP authentication (доменная авторизация)
Роль должна быть предустановлена в системе. В нашем случае используется встроенная роль для ADF (valid-users), а уже далее на основании доменных групп раздаются полномочия.
Для включения и отключения дебага, перезагрузка не требуется.
Логинимся на доменную машину, переходим по ссылке приложения и авторизуемся без ввода пароля. Стоит отметить, что кнопка Выход, в приложении работать не будет в данной конфигурации.
Создаем keytab-файл для Kerberos аутентификации в Active Directory
Многие сервисы Linux (apache, nginx и др.) могут использовать keytab файлы для Kerberos аутентификации в Active Directory без ввода пароля. В keytab файле хранятся имена принципалов Kerberos и соответствующие им зашифрованные ключи (ключи получаются из паролей Kerberos). В этой статье мы покажем, как создать keytab файл для SPN связанной учетной записи Active Directory с помощью утилит ktpass.
Чаще всего для службы, которая требует использование keytab файла создается отдельная учетная запись пользователя ActiveDirectory (но можно использовать и объект компьютера), затем к ней привязывается имя сервиса (ServicePrincipalName — SPN). SPN используется аутентификацией Kerberos для сопоставления экземпляра сервиса с учетной записью в AD (благодаря этому приложения могут аутентифицироваться в качестве сервиса даже не зная имени пользователя).
Сначала создайте сервисную учетную запись в AD и задайте ей известный пароль. Можно создать учетную запись из графической консоли ADUC или с помощью PowerShell командлета New-ADUser (из модуля PowerShell для Active Directory):
Включите для сервисной учетной записи опции “User cannot change password” и “Password never expires“ через графическую консоль или PowerShell:
Следующий шаг – привязка имени сервиса (SPN) к учетной записи пользователя. Этот шаг делать отдельно не обязательно, т.к. его автоматически выполняет утилита ktpass при создании keytab файла (я оставлю этот шаг здесь для общего понимания процесса).
Привяжите следующую SPN запись к учетной записи web:
Выведите список SPN записей, привязанных к пользователю:
Чтобы создать keytab файл используется следующая команда:
Данная команда создала keytab файл (c:\ps\web_host.keytab) для SPN записи сервиса HTTP/www@test.com. При этом SPN запись привязывается к учетной записи web с указанным паролем.
Проверьте, что для SPN записи службы была создана успешно (если вы не создавали ее вручную):
В Windows нет встроенных средств для просмотра содержимого keytab файла. Но если, у вас а компьютере установлена версия Java JRE, вы можете воспользоваться утилитой klist.exe, которая входит в комплект java.
Посмотрим на содержимое key-tab файла. Здесь хранятся имена SPN, ключи, временные метки, алгоритм шифрование и версия ключа (KVNO — key version number).
При создании keytab файла утилита ktpass увеличивает значение атрибута msDS-KeyVersionNumber учетной записи (можно посмотреть в редакторе атрибутов AD) и использует это значение в качестве номера KVNO в keytab таблице.
При смене пароля учетной записи значение этого атрибута увеличивается на единицу, при этом все keytab записи с предыдущим номером KVNO становятся невалидными (даже если старый и новый пароли совпадают). Если пароль пользователя в AD изменится, то keytab-файл придется сгенерировать заново.
В одном keytab файле могут хранится ключи нескольких SPN. Дополнительные имена SPN и ключи добавляются в keytab файл с помощью отдельных параметров утилиты ktpass (-in, -setupn, -setpass).
Дальнейшее использование полученного keytab файла зависит от конкретного сервиса, где он применяется. Например, здесь можно посмотреть особенности использования keytab-файла для прозрачной SSO аутентификации пользователей в системе мониторинга Zabbix. Также не забывайте о необходимости обеспечения безопасности keytab файлов (все, кто могут прочитать содержимое keytab смогут воспользоваться любыми ключами из него).
Создание keytab-файла, содержащего несколько разных Kerberos Principal
Разные службы и приложения, работающие в Linux и использующие аутентификацию Kerberos, например в связке с контроллерами домена Active Directory (AD), используют для механизмов этой самой аутентификации специальный keytab-файл, который содержит хеши пароля доменной учётной записи пользователя, с которым ассоциирована та или иная служба в Linux-системе (как с Kerberos Principal). И вполне типичной и распространённой практикой является создание отдельного keytab-файла для каждого принципала Kerberos. То есть, как правило, прослеживается такая логика: отдельная учётная запись служебного пользователя в AD, для которого зарегистрировано конкретное имя службы ServicePrincipalName (SPN) => отдельный keytab-файл, сопоставимый с записью SPN в AD.
В логе при этом будут регистрироваться события типа:
Подготовка учётной записи пользователя в AD
Теперь можно переходить с манипуляциями с keytab-файлом.
Генерация и обновление keytab-файла на контроллере домена AD
Для начала, напомню о том, как мы создавали исходный keytab-файл, уже имеющийся на нашем веб-сервере Apache.
Для настроенной учетной записи был сгенерирован keytab-файл на контроллере домена AD (в нашем случае на базе Windows Server 2012 R2) с помощью утилиты ktpass в следующем порядке:
В нашем примере команда выглядела так:
В результате выполнения команды мы увидим исчерпывающую информацию о том, что попало в keytab-файл:
При выполнении утилиты ktpass в указанном порядке значение номера Key Version Number (KVNO) будет обновлено в свойствах учётной записи в AD (атрибут msDS-KeyVersionNumber), с последующей записью номера в keytab-файл. 
А все keytab-файлы, которые генерировались ранее для этой учётной записи (где номер KVNO меньше текущего) станут недействительными.
Здесь хочу немного отвлечься и сделать небольшую ремарку о том, как посмотреть содержимое keytab-файла на Windows. Стандартных инструментов в составе Windows для этой задачи я найти не смог (возможно плохо искал). Однако если в вашей Windows-системе установлен стандартный клиент Java (JRE), то в его составе есть утилита klist.exe, которая работает с опциями, схожими с теми, что используются в утилите klist под Linux. Например, чтобы получить полную информацию о содержимом нашего keytab-файла нужно будет вызвать эту утилиту следующим образом:
Из вывода утилиты будет понятно, что номер keytab-файла, и KVNO остались неизменными:
Ещё раз заглянем для убедительности в новый keytab-файл web_refreshed.keytab с помощью утилиты klist:
И действительно, мы видим, что в файле появилось 5 новых записей, а номер KVNO при этом у всех записей остался прежним (в нашем примере это 4 ). Заменим keytab-файл на веб-сервере Apache и убедимся в том, что теперь с Kerberos аутентификацией успешно работает и основное имя и альтернативное. Таким образом мы можем добавить в keytab-файл столько имён принципалов сколько необходимо, при условии, что все эти имена в виде SPN-записей есть в свойствах учётной записи соответствующего доменного пользователя в атрибуте servicePrincipalName. При проверках с Windows-клиентов перед проверкой не забываем очищать локальный клиентский кэш билетов Kerberos командой (выполнять в контексте того пользователя, от имени которого делается проверка доступности веб-сайтов на Windows-системе):
Обновление keytab-файла на Linux-сервере
Есть ещё одна хитрость, которая позволит нам менять содержимое keytab-файла непосредственно на Linux-сервере без манипуляций по обновлению файла на контроллере домена и копированию его туда-сюда по сети. Если нам известен пароль от учётной записи сервисного пользователя (а он нам конечно известен:)) и текущий номер KVNO (подсмотреть его можно как в keytab-файле, так и в AD), то с помощью утилиты ktutil, мы сможем добавить в существующий keytab-файл нужную нам дополнительную запись с новым именем принципала Kerberos. Для этого войдём в режим интерактивного взаимодействия утилиты ktutil:
Выполним команду list, которая покажет, какими данными оперирует утилита (пока там пусто):
Выполним команду чтения содержимого из нашего keytab-файла (read_kt), который мы хотим использовать, как исходный, затем команду list:
Следующей командой add_entry добавим в массив данных, с которыми оперирует утилита, нужную нам дополнительную запись принципала Kerberos. При этом нужно будет указать имя принципала Kerberos (ключ -p), текущий номер KVNO (ключ -k) и тип шифрования (ключ -e). Правильный формат типов шифрования можно посмотреть в самом keytab-файле утилитой klist с ключом -e, как было показано ранее. После ввода команды будет запрошен пароль пользователя, с которым связан данный принципал Kerberos (у нас это DOM\web-srv-user ).
Таким образом мы можем добавить аналогичные записи для всех необходимых типов шифрования:
По завершению добавления записей командой write_kt сохраняем получившийся массив данных в новый keytab-файл и выходим из интерактивного режима работы утилиты:
Разумеется, для того, чтобы обновлённый на Linux-системе keytab-файл работал, нужно обеспечить наличие соответствующей дополнительной SPN-записей в свойствах учётной записи в домене AD. Осталось подключить обновлённый keytab-файл к конфигурации Apache и проверить результат.
В качестве заключения хочется напомнить о паре простых правил безопасности, про которые всегда стоит помнить при работе с keytab-файлами:
Дополнительные источники информации:
Как правильно сформировать keytab-файл с несколькими принципалами сервисов в среде Active Directory
Предпосылки и исходные данные
Имеется настроенный домен Active Directory windom.net. Требуется настроить веб-сервер араche2 на сервере с Ubuntu так, чтобы он обслуживал два виртуальных хоста, — windom.net (он же www.windom.net) и sandbox.windom.net, — в которых пользователи проходили бы Kerberos-аутентификацию в Active Directory. Примерная DNS-зона:
С одной стороны, подобная конфигурация уже много раз хорошо документирована в Интернет и нет смысла повторяться. С другой стороны, для работы mod_auth_kerb требуется keytab-файл с принципалами сервисов apache2. Сначала мне казалось, что там должны быть такие принципалы:
Но на самом деле, как выяснилось опытным путём, оказалось достаточно двух (что, в общем-то, логично, учитывая работу протокола HTTP):
Кстати, это даёт некоторый бонус: виртуальные хосты, сколько бы их ни было, имена которых организуются CNAME-записями DNS, указывающими на основной веб-сервер, не нуждаются в дополнительных именах сервисных принципалов.
Итак, задача: сформировать в среде Active Directory рабочий keytab-файл с несколькими принципалами сервисов для его использования в apache2.
Совсем чуть-чуть теории
Что мы знаем о keytab-файлах? В Kerberos keytab (от «key table», «таблица ключей») — способ хранения долговременных ключей для одного или нескольких принципалов. Чаще всего таблицы ключей хранятся в виде файлов стандартизированного формата (те самые keytab-файлы). Таблица ключей может включать в себя одну или несколько записей, каждая из которых состоит из отметки времени (когда запись была добавлена в keytab), имени принципала, номера версии ключа (key version number или KVNO), типа шифрования и собственно зашифрованного ключа. Кроме всего прочего, этот ключ будет использоваться для аутентификации принципала в базе данных безопасности KDC. KVNO — целое положительное число, дополнительный критерий защиты: если в keytab несколько записей для одного и того же принципала с разным KVNO, валидной будет считаться та запись, KVNO которой совпадает с текущим KVNO этого принципала в базе данных безопасности KDC (обычно запись с наибольшим KVNO).
Следовательно, нам нужно создать учётную запись в LDAP-каталоге Active Directory, установить ей пароль (известный нам), привязать к этой учётной записи необходимые имена принципалов сервисов и сформировать keytab-файл с этими принципалами и ключами, основанными на известном нам пароле учётной записи.
Остальная теория — по мере выполнения.
Как сделать
Шаг 1. Создание учётной записи
Первая дилемма, с которой сталкиваются администраторы — какую учётную запись заводить: пользователя или компьютера. Обычно заводят учётную запись пользователя на том основании, что там легко задаётся пароль. Мне это кажется не совсем верным, поскольку сервисы работают на компьютерах и логичнее завести для этих целей учётку компьютера. Тем более учётки компьютеров не устаревают никогда. Но если вы всё же решили использовать учётку пользователя, принципиального значения это не имеет, просто скорректируйте команду создания учётной записи под себя.
Второй вопрос при создании учётки компьютера — стоит ли использовать уже имеющуюся учётку, если Ваш сервер является членом домена? В моём случае на том же Ubuntu-сервере работает samba и учётная запись компьютера webserver создалась в Active Directory автоматически при вводе сервера в домен. Я считаю — не стоит, на том основании, что члены домена периодически (по умолчанию раз в 30 дней) меняют пароль своей учётной записи, поэтому keytab-файл (если он не связан с keytab-файлом samba) придётся переделывать. В общем, я решил завести новую учётную запись компьютера и назвать её www.
Наконец, как лучше создавать учётную запись компьютера: графическими средствами (ADUC) или из командной строки? Это дело вкуса. Единственный момент: при создании учётки из командной строки пароль ей не назначается и KVNO будет равен 1, а при создании из оснастки ADUC учётной записи сразу назначается некий «стандартный» пароль, и KVNO у неё будет 2. Это необходимо будет учитывать при выполнении последующих шагов.
Итак, создадим учётную запись компьютера www:
Проверим интересующие нас атрибуты учётной записи:
Наша учётная запись создана без пароля (KVNO=1), имена принципалов пользователя и сервиса не назначены.
Шаг 2. Назначение учётной записи имён принципалов сервисов.
Если честно, этот шаг необязательный, поскольку применяемая на следующих двух шагах утилита ktpass так или иначе «привязывает» имя принципала сервиса к учётной записи. Но раз уж мы решили сделать всё правильно, то выполним привязку явно. Это делается с помощью утилиты setspn. Первые две команды назначают учётной записи компьютера требуемые нам имена принципалов сервиса, третья — выводит список назначенных учётной записи принципалов:
Проверим интересующие нас атрибуты учётной записи:
Пароля всё ещё нет (KVNO=1), имя принципала пользователя не назначено, но есть два имени принципалов сервиса.
Шаг 3. Задание пароля учётной записи, задание имени принципала пользователя и формирование keytab-файла для первого принципала сервиса.
Здесь в игру вступает супер-инструмент Microsoft: утилита ktpass. Она делает всё и сразу, поэтому пользоваться ей необходимо осторожно, иначе есть шанс всё испортить и придётся удалять учётку и начинать заново. Если Вы ещё не сталкивались с этой утилитой, лучше сразу посмотреть официальное руководство, чтобы представлять, о чём пойдёт речь далее.
Основной функционал ktpass:
Как видите, функционал богатый и чёткого описания как всё это должно работать, нет. Поэтому ещё раз предупреждаю: будьте внимательны и осторожны, перед выполнением команды Вы должны чётко понимать, что собираетесь сделать.
Итак, нам нужно задать пароль учётной записи компьютера и сформировать keytab-файл для первого принципала сервиса. При этом (по умолчанию) имя принципала сервиса будет привязано к учётной записи, а также задано в качестве имени принципала пользователя этой учётной записи. Выполним команду:
Проверим интересующие нас атрибуты учётной записи:
Пароль установлен (KVNO=2), имя принципала пользователя назначено, добавлено ещё одно имя принципала сервиса.
Шаг 4. Формирование keytab-файла для двух принципалов сервиса.
На этом этапе нам нужно создать keytab-запись для второго принципала сервиса с ключом на основе того же пароля, импортировать keytab-запись первого принципала сервиса из промежуточного keytab-файла, созданного на предыдущем шаге, и записать обе keytab-записи в итоговый keytab-файл. При этом нам нельзя менять пароль самой учётной записи компьютера, поскольку KVNO этой учётки повысится и keytab-запись, созданная на предыдущем этапе, перестанет быть валидной. Выполним команду:
Теперь рассмотрим вывод команды. Первым делом ktpass показал нам содержимое импортированной из промежуточного файла keytab-записи. Затем сообщил об успешной привязке принципала сервиса к учётной записи. Затем он сформировал ключ принципала сервиса и вывел две keytab-записи в указанный keytab-файл. Обратите внимание, что KVNO двух keytab-записей совпадает ( vno 2 ).
Проверим интересующие нас атрибуты учётной записи:
Пароль учётной записи не изменился (KVNO=2), имя принципала пользователя не изменилось, добавлено ещё одно имя принципала сервиса.
Собственно всё, задача решена: правильный keytab-файл для двух принципалов сервиса сформирован. Осталось передать его в нужное место, ограничить права доступа и тестировать работу аутентификации apache2.
И ещё один небольшой бонус напоследок, пока мы не покинули Windows-сервер: утилита ktpass — это единственный известный мне инструмент, с помощью которого можно легально (не прибегая к ухищрениям c LDAP-каталогом) сменить пароль учётной записи компьютера. Для этого нужно просто «попытаться» привязать к ней неверно сформированное имя принципала сервиса. ktpass выдаст ошибку, но пароль всё равно сменит. Пример:
Ссылки
Материалы, которые помогли мне разобраться в теме:
Последнее изменение страницы — 20 апреля 2016 года.
