Keytab файл что это
SPN (Service Principal Name) - уникальный идентификатор экземпляра сервиса. SPN используется аутентификацией Kerberos для сопоставления экземпляра сервиса с учетной записью сервиса (service logon account). Это позволяет клиентским приложением аутентифицироваться в роли сервиса даже не зная имени пользователя.
До того как аутентификация Kerberos сможет использовать SPN для аутентификации сервиса, SPN должен быть привязан к учетной записи, которая будет использоваться для входа. SPN может быть привязан только к одной учетной записи. Если учетная запись, привязанная к SPN, изменяется, то необходимо заново выполнить привязку.
Когда клиент хочет воспользоваться сервисом, он находит экземпляр сервиса и составляет SPN для этого экземпляра, далее использует этот SPN для аутентификации.
Keytab-файл - это файл содержащий пары Kerberos принципалов и их ключей (полученных с использованием Kerberos пароля). Эти файлы используются для аутентификации в системах, использующих Kerberos, без ввода пароля. Если пароль принципала изменится, то keytab-файл необходимо будет сгенерировать заново.
Внимание! Каждый кто имеет разрешения на чтения keytab-файла может воспользоваться любыми ключами в нем. Чтобы предотвратить нежелательное использование, ограничивайте права доступа при создании keytab-файла
Проверить привязанные SPN у пользователя можно командой:
Для добавления SPN зайдите в web-интерфейс сервера FreeIPA->Identity->Services->Add:
В открывшемся окне необходимо выбрать имя сервиса и имя хоста, к которому будет привязан сервис:
Чтобы добавить SPN с коротким именем хоста (например это необходимо для samba), выполните команду:
Создать keytab-файл можно разными способами.
Рассмотрим некоторые из них.
Необходимо выполнить следующую команду:
Рассмотрим параметры команды подробнее:
- -princ - имя принципала содержащее SPN и Kerberos-область (realm)
- -mapuser - пользователь к которому привязывается SPN
- -pass - пароль пользователя
- -ptype - указывает тип принципала (рекомендуется KRB5_NT_PRINCIPAL)
- -out - путь и имя генерируемого файла
Этот способ работает если SPN предварительно были созданы и привязаны.
Установим необходимый пакет:
Запустим ktutil и создадим keytab-файл:
Для создания keytab-файла с помощью samba, необходима работающая kerberos-аутентификация.
При использовании этого метода нет необходимости генерировать и привязывать SPN на контроллере домена.
Приведите файл настроек /etc/samba/smb.conf к следующему виду:
Введите машину в домен:
Проверить ввод в домен можно командой:
После этого в домене будет создан аккаунт компьютера к которому можно будет привязать SPN.
Создадим keytab-файл для компьютера:
Добавим в keytab-файл принципала сервиса "HTTP":
Далее можно поменять права на keytab и отредактировать его утилитой kutil.
При использовании этого метода kerberos ни при чём, а все действия выполняются на машине с домен-контроллером.
Создадим пользователя, с которым будем связывать создаваемые SPN:
Привяжем к нему SPN:
(возможно несколько раз для разных сервисов)
(выполняем несколько раз для всех spn, которые хотим поместить в keytab)
проверка (sudo klist -ke, работает):
Для этого способа необходимо ввести машину в домен FreeIPA [[1]]
Для генерации keytab-файла используется команда:
Для проверки keytab-файла необходима настроенная Kerberos-аутентификация.
Это можно проверить командой:
Она должна запрашивать пароль и получать билет:
Попробуем зарегистрироваться с помощью keytab-файла:
Проверить версию ключей на сервере можно, предварительно получив билет, с помощью команды:
Проверить версию kvno и список ключей в keytab-файле можно с помощью команды:
31.08.2020
itpro
Active Directory, PowerShell, Windows Server 2016
Комментариев пока нет
Многие сервисы 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):
New-ADUser -Name "web" -GivenName "nginx web app" -SamAccountName "web" -UserPrincipalName "web@test.com" -Path "OU=Services,OU=SPB,DC=test,DC=com" –AccountPassword (ConvertTo-SecureString “Bergam0ttapoK” -AsPlainText -force) -Enabled $true
Включите для сервисной учетной записи опции “User cannot change password” и “Password never expires“ через графическую консоль или PowerShell:
Get-ADUser web | Set-ADUser -PasswordNeverExpires:$True -CannotChangePassword:$true
Следующий шаг – привязка имени сервиса (SPN) к учетной записи пользователя. Этот шаг делать отдельно не обязательно, т.к. его автоматически выполняет утилита ktpass при создании keytab файла (я оставлю этот шаг здесь для общего понимания процесса).
Привяжите следующую SPN запись к учетной записи web:
Выведите список SPN записей, привязанных к пользователю:
Чтобы создать keytab файл используется следующая команда:
Проверьте, что для SPN записи службы была создана успешно (если вы не создавали ее вручную):
В Windows нет встроенных средств для просмотра содержимого keytab файла. Но если, у вас а компьютере установлена версия Java JRE, вы можете воспользоваться утилитой klist.exe, которая входит в комплект java.
cd "c:\Program Files\Java\jre1.8.0_181\bin"
klist.exe -K -e -t -k c:\PS\web_host.keytab
Посмотрим на содержимое 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, сопряжённых с записями ServicePrincipalName в свойствах одной конкретной учётной записи служебного пользователя в 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-файла нужно будет вызвать эту утилиту следующим образом:
Теперь мы подошли к самому интересному. Второе и последующие имена нужные нам имена принципалов Kerberos добавляем в уже имеющийся keytab-файл с применением дополнительных параметров ( -in, - setupn, -setpass ) утилиты ktpass, которые позволят сохранить текущий номер KVNO в файле и AD:
Из вывода утилиты будет понятно, что номер 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-файлами:
Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 10. Аутентификация и авторизация пользователей Active Directory в Icinga Web 2 (Kerberos и SSO)
В этой части нашего цикла заметок об Icinga будет рассмотрен пример того, как можно организовать доменную аутентификацию пользователей Active Directory (AD) с поддержкой Kerberos и Single sign-on (SSO) при подключении к веб-консоли Icinga Web 2.
Если мы заглянем в опорный документ Icinga Web 2 Authentication , то узнаем, что веб-консоль Icinga Web 2 способна работать с аутентификаций, основанной на каталоге Active Directory, других реализациях LDAP-каталогов, базах данных MySQL или PostgreSQL, а также делегировать процесс аутентификации непосредственно веб-серверу. Так, как в рассматриваемом нами примере будут использоваться такие вещи, как аутентификация с помощью Kerberos и дополнительная авторизация с помощью PAM, выбран вариант с делегированием процесса аутентификации веб-серверу. При этом процедуры внутренней проверки прав доступа к объектам веб-консоли Icinga Web 2 будут выполняться через специально созданное подключение к AD, как к LDAP-каталогу.
Создание keytab-файла, содержащего несколько разных Kerberos Principal
Подключение Debian GNU/Linux 8.6 к домену Active Directory с помощью SSSD и realmd
На большом количестве разных интернет-ресурсов можно встретить описание процедуры присоединения серверов на базе ОС Linux к домену Active Directory, и практически везде в таких описаниях в виде неотъемлемой части присутствует установка Samba с последующим использованием Winbind. Мы тоже не стали в этом плане исключением. В этой заметке я хочу рассмотреть пример использования альтернативного средства расширения функционала аутентификации и авторизации в Linux – службы SSSD (System Security Services Daemon), которая будет автоматически настроена с помощью пакета realmd (Realm Discovery). В этом примере нами будет настроена аутентификация и авторизация на сервере Debian GNU/Linux 8.6 (Jessie) с подключением к домену Active Directory (на базе Windows Server 2012 R2). Читать далее.
Развёртывание и настройка oVirt 4.0. Часть 10. Настройка Single sign-on (SSO) на базе Kerberos для упрощения аутентификации на веб-порталах oVirt
В этом части описания мы продолжим тему интеграции oVirt 4.0 с внешним LDAP-каталогом на базе домена Microsoft Active Directory (AD) и поговорим о настройке механизма Single sign-on (SSO) средствами протокола Kerberos для веб-сервера Apache с целью облегчения процедуры аутентификации пользователей при входе на веб-порталы oVirt. Читать далее.
SSO-подключение к серверу Ubuntu Server 14.04 LTS по протоколу SSH с помощью PuTTY с компьютера на базе Windows в домене Active Directory
Продолжая тему интеграции систем на базе Linux в доменную инфраструктуру Active Directory (AD), в этой заметке мы рассмотрим вопрос настройки Single sign-on (SSO) при подключении к Linux-серверу на базе Ubuntu Server 14.04 LTS по протоколу SSH с клиентских компьютеров под управлением Windows. Начнём с настроек на стороне Linux-сервера, который будет выступать в качестве сервера SSH на базе пакета OpenSSH (описание установки и базовой настройки рассмотрено ранее ).
Настройка прокси сервера Squid 3.3 на Ubuntu Server 14.04 LTS. Часть 4. Конфигурация Kerberos и NTLM
В этой части мы рассмотрим порядок настройки Ubuntu Server 14.04 LTS для обеспечения возможности работы с механизмами аутентификации пользователей прокси-сервера Squid 3 по протоколам Kerberos и NTLM в среде домена Active Directory (AD). Для поддержки NTLM наш Linux-сервер будет присоединён к домену AD, а для поддержки Kerberos для сервера в домене будет создана специальная служебная учетная запись пользователя. В дальнейшем при конфигурации Squid, протокол Kerberos будет использоваться как приоритетный, а протокол NTLM будет применяться в случаях когда клиент прокси-сервера по какой-то причине не может использовать Kerberos. Читать далее.
Онлайн-курсы Евгения Лейтана
Внедрение Microsoft System Center Operations (SCOM) 2016/2019
13 уроков (6 часов видео), лабораторные работы и вручение именного сертификата.
Промокод "IT-KB_60" со скидкой 60%!
В этой части мы рассмотрим порядок настройки Ubuntu Server 14.04 LTS для обеспечения возможности работы с механизмами аутентификации пользователей прокси-сервера Squid 3 по протоколам Kerberos и NTLM в среде домена Active Directory (AD). Для поддержки NTLM наш Linux-сервер будет присоединён к домену AD, а для поддержки Kerberos для сервера в домене будет создана специальная служебная учетная запись пользователя. В дальнейшем при конфигурации Squid, протокол Kerberos будет использоваться как приоритетный, а протокол NTLM будет применяться в случаях когда клиент прокси-сервера по какой-то причине не может использовать Kerberos.
Добавляем поддержку Kerberos
Сначала проверим список установленных пакетов
Можно встретить упоминания о том что нужно установить пакеты krb5-user и libkrb53. Однако в нашем случае установка пакета libkrb53 будет безуспешна и, как я понял, в системе уже присутствует заменяющий пакет libkrb5-3, поэтому мы выполним установку только пакета krb5-user
Сохраним на всякий случай появившийся в системе после установки пакета krb5-user конфигурационный файл krb5.conf в krb5.conf.default и откроем исходный файл в текстовом редакторе (с подсветкой синтаксиса):
Очистим содержимое файла (или закомментируем все открытые строки) и впишем туда следующие строки:
Настраиваем Kerberos
В интернете можно найти разные описания настройки Kerberos на Linux, где зачастую предполагается использование утилиты MSKTUTIL для создания в домене отдельной учетной записи компьютера, которая будет использоваться для аутентификации пользователей домена, а также для периодического изменения пароля этой учетной записи и регенерации keytab файла. В нашем описании мы пойдём по несколько иному пути, чтобы немного упростить схему получения и использования keytab-файла. Далее мы создадим в домене AD служебную учетную запись пользователя, отключим в свойствах учетной записи устаревание пароля и необходимость смены пароля, сгенерируем на контроллере домена для этой учетной записи keytab-файл, который затем скопируем на наш прокси сервер и будем использовать его для аутентификации Kerberos на постоянной основе.
Создаем в домене учетную запись пользователя для службы SQUID. В нашем примере это будет учетная запись KOM\s-KOM-SquidKerb
Отключим для учетной записи требование периодической смены пароля (Password never expires):
Для созданной учетной записи нам нужно сгенерировать keytab-файл на контроллере домена AD (в нашем случае на базе Windows Server 2012 R2) с помощью утилиты ktpass
В процессе генерации keytab-файла в домене в свойствах учетной записи пользователя изменится имя для входа а также будет изменён атрибут servicePrincipalName (будет добавлено значение из параметра -princ )
Теперь нам нужно безопасным способом передать получившийся файл PROXY.keytab с компьютера под управлением Windows на Linux-сервер KOM-AD01-GW10 в каталог /etc/squid3/ . Сделать это можно например по протоколу SSH ( ранее мы уже запустили службу сервера OpenSSH на KOM-AD01-GW10 ) с помощью утилиты WinSCP или PSCP .
Передадим файл сначала в каталог /home/user/ (или ~ для краткости):
Теперь из каталога /home/user/ нам нужно будет переместить файл в в каталог /etc/squid3/
Далее выставляем разрешения на keytab-файл таким образом, чтобы в дальнейшем служба Squid могла получить к нему доступ:
Проверяем возможность аутентификации в AD с помощью Kerberos. Сначала выполняем команду, которая должна отработать без ошибок:
Затем проверим наличие полученного билета Kerberos командой klist
Как видим, билет успешно получен. Теперь можем удалить его командой kdestroy
Для того чтобы SQUID однозначно знал где искать keytab-файл, создадим файл настроек по умолчанию и откроем его на редактирование:
Впишем в файл следующие сроки:
На этом базовую поддержку Kerberos в рамках нашей задачи можно считать законченной, переходим к NTLM.
Настраиваем поддержку NTLM
Устанавливаем пакеты Samba и Winbind, которые потребуются нам для того, чтобы сделать наш Linux-сервер членом домена AD и задействовать механизмы NTLM-аутентификации:
Останавливаем только что установленные и запущенные службы:
Как таковая, файловая служба samba в нашем случае на Linux-сервере не нужна, поэтому отключим её автозапуск (по сути нам нужна только служба winbind, т.к. она отвечает за резолвинг юзеров и групп и авторизацию в домене)
Сохраняем на всякий случай исходный конфигурационный файл Samba, после чего открываем его на редактирование:
Новое содержимое файла:
Проверяем утилитой testparm. Утилита должна распарсить конфигурационный файл без явных ошибок
Чтобы увидеть содержимое текущего конфигурационного файла smb.conf и все параметры Samba по умолчанию применяемые вместе с этим файлом можно выполнить:
Создаём в домене учетную запись компьютера для нашего Linux-сервера в том OU, где нам удобно. Эта учетная запись будет использована для ввода сервера в домен AD. После этого выполняем команду ввода сервера в домен:
Вводим пароль доменного пользователя с правами на присоединение к домену (как правило это администратор домена, хотя может быть и другой непривилегированный в домене пользователь)
Проверяем запуск службы winbind (должно отработать без ошибок)
Теперь нужно перезагрузить сервер и убедиться в том, что службы запустились автоматически. При перезапуске я обнаружил запись в /var/log/boot.log :
Как я понял, это проблема запуска Samba как ADS-сервера, которая в нашем случае не нужна. Поэтому я отключил выполнение соответствующего конфига в /etc/init/ , создав файл переопределений, который объясняет системе Upstart, что данная служба может запускаться только вручную по мере необходимости.
Проверяем статус доверительных отношений с доменом:
Проверяем аутентификацию пользователя в домене:
Включим пользователя от имени которого будет работать Squid ( proxy ) в группу доступа для чтения каталога /var/run/samba/winbindd_privileged
Забегая вперёд могу сказать, что проделанной настройки Samba4 оказалось недостаточно. Когда дело дошло до тестирования хелперов Squid, хелпер NTLM аутентификации из состава Samba4 ( /usr/bin/ntlm_auth ) при вызове Squid-ом для любой попытки аутентификации пользователей приводил к одной и той же ошибке:
Для решения проблемы неработающей NTLM аутентификации в Squid пришлось настроить разрешения на каталог /var/lib/samba/winbindd_privileged аналогично тому, как они настроены для каталога /var/run/samba/winbindd_privileged …
…а также слинковать подкаталог ../pipe из старого месторасположения в новое…
После этих изменений можно перезапустить сервер чтобы “взбодрить” Squid3 и Samba4.
Теперь относительно того, что для учетной записи компьютера (не путать с сервисной учетной записью пользователя для поддержки Kerberos) нашего Linux-сервера в домене AD рекомендуется выполнять периодическую смену пароля. Судя по документу Samba manpages - smb.conf.5 параметр machine password timeout отвечает за то, насколько часто процесс smbd будет пытаться выполнить смену пароля учетной записи компьютера в домене. По умолчанию это значение равно 604800 секунд, то есть 7 дней. Таким образом добавлять в планировщик заданий CRON в крон отдельную задачу смены пароля командой “net rpc changetrustpw” мы не станем.
На этом минимальную настройку поддержки Kerberos и NTLM в Ubuntu Server 14.04 LTS для использования механизмов аутентификации пользователей домена Active Directory в Squid 3 будем считать законченной. В следующей части рассмотрим базовую настройку самого прокси-сервера Squid.
Читайте также: