как проверить keytab пользователя в linux
Создаем 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 смогут воспользоваться любыми ключами из него).
Создание 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-файле можно с помощью команды:
После всех проверок желательно удалить полученные билеты командой:
Создание 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-файлами:
Дополнительные источники информации:
Use a keytab
Introduction
A keytab is a file containing pairs of Kerberos principals and encrypted keys (which are derived from the Kerberos password). You can use a keytab file to authenticate to various remote systems using Kerberos without entering a password. However, when you change your Kerberos password, you will need to recreate all your keytabs.
Keytab files are commonly used to allow scripts to automatically authenticate using Kerberos, without requiring human interaction or access to password stored in a plain-text file. The script is then able to use the acquired credentials to access files stored on a remote system.
Create a keytab file
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:
Following is an example using Heimdal Kerberos:
If the keytab created in Heimdal does not work, it is possible you will need an aes256-cts entry. In that case, you will need to find a computer with MIT Kerberos, and use that method instead.
Use a keytab to authenticate scripts
To execute a script so it has valid Kerberos credentials, use:
Replace username with your username, mykeytab with the name of your keytab file, and myscript with the name of your script.
List the keys in a keytab file
With MIT Kerberos, to list the contents of a keytab file, use klist (replace mykeytab with the name of your keytab file):
The output contains two columns listing version numbers and principal names. If multiple keys for a principal exist, the one with the highest version number will be used.
With Heimdal Kerberos, use ktutil instead:
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 ktutil command. You can also use this procedure to remove old versions of a key. An example using MIT Kerberos follows:
Replace mykeytab with the name of your keytab file, username with your username, and version# with the appropriate version number.
To do the same thing using Heimdal Kerberos, use:
Merge keytab files
If you have multiple keytab files that need to be in one place, you can merge the keys with the ktutil command.
To merge keytab files using MIT Kerberos, use:
To verify the merge, use:
To do the same thing using Heimdal Kerberos, use:
Then, to verify the merge, use:
Copy a keytab file to another computer
If possible, use SCP or another secure method to transfer the keytab between computers. If you have to use FTP, be sure to issue the bin command from your FTP client before transferring the file. This will set the transfer type to binary so the keytab file will not be corrupted.
Авторизация на SQUID через Active Directory
Инструкция подразумевает, что у нас уже есть рабочий Squid-сервер. В противном случае, настраиваем, используя инструкцию Установка и настройка Squid на CentOS.
Наш сервер будет принимать как наиболее безопасную Kerberos-авторизацию, так и NTLM. Для компьютеров в домене будет поддерживаться прозрачная LDAP-аутентификация. Все команды выполняются на примере системы Linux CentOS 7.
Подготовка
Настройка времени
Интеграция с Active Directory требует минимального расхождения времени с контроллером домена. Устанавливаем утилиту chrony:
yum install chrony
Запускаем службу для синхронизации времени:
Имя сервера
Задаем имя сервера следующей командой:
hostnamectl set-hostname proxy.domain.local
* где proxy — имя сервера; domain.local — доменное имя, используемое в сети.
Настройка на контроллере домена
Создание учетной записи
Открываем консоль управления пользователями и добавляем нового со стандартными правами. От этой учетной записи будут выполняться запросы к AD DS.
В своем примере мы создаем пользователя squid.
Учетная запись должна быть размещена по пути, в котором присутствуют названия только на латинице. Подразделения и контейнеры не должны быть на русском.
Создание keytab-файла
В двух словах, данный файл позволяет установить легитимность нашего Linux-сервера. Создается он на контроллере домена и копируется на последний.
Для создания файла переходим на контроллер домена и от имени администратора запускаем Powershell или обычную командную строку. Вводим:
ktpass /princ HTTP/proxy.domain.local@DOMAIN.LOCAL /mapuser squid@DOMAIN.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass «password» /out C:\proxy.keytab
* где proxy.domain.local — полное имя нашего squid-сервера; DOMAIN.LOCAL — наш домен; squid@DOMAIN.LOCAL — учетная запись в AD для выполнения запросов (создана на шаге выше); password — пароль, который будет задан пользователю (должен соответствовать требованию AD).
* регистр важен.
В нашем примере, после выполнения команды на контроллере домена в корне диска С появится файл proxy.keytab. Его копируем на Linux-сервер, например, при помощи WinSCP.
Настройка CentOS
Kerberos
Устанавливаем следующие пакеты:
yum install cyrus-sasl-gssapi krb5-workstation krb5-devel
Открываем конфигурационный файл Kerberos:
Редактируем следующие строки:
[libdefaults]
.
default_realm = DOMAIN.LOCAL
..
[realms]
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 — первичный контроллер (в данном примере будет использоваться случайный).
Проверяем настройки krb, запросив тикет:
При правильных настройках мы увидим на подобие:
Ticket cache: KEYRING:persistent:0:0
Default principal: domainuser@DOMAIN.LOCAL
Valid starting Expires Service principal
15.05.2018 10:08:33 15.05.2018 20:08:33 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
renew until 22.05.2018 10:08:30
Проверяем keytab-файл, который мы перенесли на сервер с контроллера домена:
* где /etc/squid/proxy.keytab — путь до keytab-файла; HTTP/proxy.domain.local@DOMAIN.LOCAL — принципал, который был задан при создании файла.
Картина, примерно, следующая:
Ticket cache: KEYRING:persistent:0:krb_ccache_9MN6pt8
Default principal: HTTP/proxy.domain.local@DOMAIN.LOCAL
Valid starting Expires Service principal
16.05.2018 09:35:20 16.05.2018 19:35:20 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
renew until 23.05.2018 09:35:20
Зададим файлу следующие права:
chown squid:squid /etc/squid/proxy.keytab
chmod u+rwx,g+rx /etc/squid/proxy.keytab
Устанавливаем следующие пакеты:
yum install samba-winbind samba-winbind-clients pam_krb5 krb5-workstation
Добавляем сервер в домен:
* где administrator — учетная запись в AD с правами на ввод компьютеров в домен.
Разрешаем автозапуск winbind и запускаем его:
systemctl enable winbind
systemctl start winbind
Проверяем, что наш сервер умеет обращаться к службе каталогов:
* первая команда проверяет возможность отправлять запросы на контроллер домена; вторая — выводит список групп, находящихся в каталоге.
Настройка SQUID
Для скрипта запуска squid добавим следующее:
KRB5_KTNAME=/etc/squid/proxy.keytab
export KRB5_KTNAME
* в данном случае, мы задаем переменную KRB5_KTNAME, в которой указан путь до кейтаб файла.
Открываем конфигурационный файл squid:
* где /usr/lib64/squid/negotiate_kerberos_auth — путь до библиотеки аутентификации по kerberos, ее путь может отличаться — это зависит от версии системы; HTTP/proxy.domain.local@DOMAIN.LOCAL — учетная запись в keytab.
Также настраиваем, чтобы squid требовал аутентификацию. Для этого в секции acl добавим:
acl auth proxy_auth REQUIRED
http_access allow localnet
http_access allow auth
* в нашем случае acl localnet использовалась для предоставления доступа.
Проверяем настройки конфигурационного файла:
Проверка
Для проверки на сервере открываем лог:
* dmosk — учетная запись в AD, от которой будем проверять работу squid.
Теперь на клиентском компьютере заходим в систему под нашей учетной записью (в данном примере, dmosk) и грузим любой сайт.
На сервер в логах должны появиться записи, примерно, такого вида:
Авторизация на основе групп AD
Ранее, мы предоставили доступ к сети Интернет любому пользователю Active Directory. Теперь ограничим доступ с помощью групп AD DS.
Для начала, создаем 2 группы пользователей, например:
Теперь на прокси-сервере открываем конфигурационный файл squid:
Добавляем после настройки аутентификации:
#acl auth proxy_auth REQUIRED
acl squid_users_acl_krb external squid_users_from_ad_krb
acl squid_superusers_acl_krb external squid_superusers_from_ad_krb
acl squid_users_acl_ntlm external squid_users_from_ad_ntlm squidusers
acl squid_superusers_acl_ntlm external squid_superusers_from_ad_ntlm squidsuperusers
* предыдущую acl для общей аутентификации комментируем.
#http_access allow auth
http_access allow squid_superusers_acl_krb
http_access allow squid_superusers_acl_ntlm
http_access allow squid_users_acl_krb
http_access allow squid_users_acl_ntlm
* разрешаем доступ для созданных ранее acl; предыдущее разрешение для всех пользователей AD запрещаем. На данном этапе разницы между пользователями групп squidusers и squidsuperusers нет — позже мы настроим ограничение доступа к сайтам, где будем применять разные группы для предоставления различных прав.
Перечитываем конфигурацию прокси-сервера:
Ограничение доступа к сайтам
Мы рассмотрим простой пример блокировки двух сайтов. Доступ к ним будет ограничен в рабочее и ночное время для пользователей группы squidusers. Пользователи группы squidsuperusers будут иметь полный доступ ко всем сайтам.
Открываем конфигурационный файл squid:
В разделе с ACL добавим 2 строки:
* в данном примере мы создаем acl BLOCKED для сайтов, доступ к которым будем блокировать; список сайтов будем хранить в файле /etc/squid/denysite. Второй acl BLOCKED_ACCESS будем использовать для предоставления доступа к заблокированным сайтам, но с промежуток с 18:00 до 23:59.
Теперь преобразовываем к следующему виду, ранее созданные правила для доступа:
http_access allow squid_superusers_acl_krb
http_access allow squid_superusers_acl_ntlm
http_access allow BLOCKED BLOCKED_ACCESS
http_access deny BLOCKED
http_access allow squid_users_acl_krb
http_access allow squid_users_acl_ntlm
* как видим, мы добавили правила блокировки после пользователей группы squidsuperusers — таким образом, на последних они не будут распространяться. Данные правила разрешают заблокированные сайты в указанный ранее промежуток времени и блокируют доступ к сайтам, перечисленным в файле /etc/squid/denysite.
Создаем файл /etc/squid/denysite:
* в данном примере мы блокируем доступ к социальным сетям facebook и ВКонтакте.
Перечитываем конфигурацию squid:
Возможные ошибки
1. Password set failed! 0x00000020
Возникает при попытке создать keytab на контроллере домена.
Причина: учетная запись, которая используется в ключе /mapuser находится в одном из подразделений, названных с применением кириллицы.
Решение: перенесите учетную запись для связывания в подразделение, названное на латинице, например, CN=Users,dc=domain,dc=local.
Читайте также
Другие инструкции по SQUID, которые могут показаться интересными: