Проверить keytab kinit linux

Создание SPN и Keytab файла

Содержание

Введение [ править ]

SPN (Service Principal Name) — уникальный идентификатор экземпляра сервиса. SPN используется аутентификацией Kerberos для сопоставления экземпляра сервиса с учетной записью сервиса (service logon account). Это позволяет клиентским приложением аутентифицироваться в роли сервиса даже не зная имени пользователя.
До того как аутентификация Kerberos сможет использовать SPN для аутентификации сервиса, SPN должен быть привязан к учетной записи, которая будет использоваться для входа. SPN может быть привязан только к одной учетной записи. Если учетная запись, привязанная к SPN, изменяется, то необходимо заново выполнить привязку.
Когда клиент хочет воспользоваться сервисом, он находит экземпляр сервиса и составляет SPN для этого экземпляра, далее использует этот SPN для аутентификации.

Keytab-файл — это файл содержащий пары Kerberos принципалов и их ключей (полученных с использованием Kerberos пароля). Эти файлы используются для аутентификации в системах, использующих Kerberos, без ввода пароля. Если пароль принципала изменится, то 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 [ править ]

Необходимо выполнить следующую команду:

Рассмотрим параметры команды подробнее:

• -princ — имя принципала содержащее SPN и Kerberos-область (realm)
• -mapuser — пользователь к которому привязывается SPN
• -pass — пароль пользователя
• -ptype — указывает тип принципала (рекомендуется KRB5_NT_PRINCIPAL)
• -out — путь и имя генерируемого файла

На машине с 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-файла используется команда:

• dc.ipa.server.ru — FreeIPA сервер
• HTTP/httpserver.ipa.server.ru — SPN
• /etc/http.keytab — куда запишется keytab

Проверка keytab-файла [ править ]

Для проверки keytab-файла необходима настроенная Kerberos-аутентификация.
Это можно проверить командой:

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

Попробуем зарегистрироваться с помощью keytab-файла:

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

Проверить версию kvno и список ключей в keytab-файле можно с помощью команды:

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

Источник

Создаем 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):

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:

setspn -A HTTP/www.test.com@test.com web

Выведите список SPN записей, привязанных к пользователю:

Чтобы создать keytab файл используется следующая команда:

ktpass -princ HTTP/www.test.com@TEST.COM -mapuser web -crypto ALL -ptype KRB5_NT_PRINCIPAL -pass Bergam0ttapoK -target dc01.test.com -out c:\ps\web_host.keytab

Данная команда создала keytab файл (c:\ps\web_host.keytab) для SPN записи сервиса HTTP/www@test.com. При этом SPN запись привязывается к учетной записи web с указанным паролем.

Проверьте, что для SPN записи службы была создана успешно (если вы не создавали ее вручную):

setspn -Q */www.test.com@test.com
Видно, что SPN запись найдена (Existing SPN found!). Она привязана к учетной записи web,

В 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 смогут воспользоваться любыми ключами из него).

Источник

Настройка Kerberos-аутентификации с использованием смарт-карт

В продолжение давней темы про использование двухфакторной аутентификации в ОС GNU/Linux позвольте рассказать про схему работы и настройку аутентификации с помощью Kerberos. В этой статье мы рассмотрим процесс настройки MIT Kerberos для аутентификации пользователей по сертификатам и ключевым парам, находящимся на USB-токене. Также материалы, изложенные в статье, можно использовать для настройки аутентификации в домене Windows.

Краткое введение

Kerberos – сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован, в первую очередь, на клиент-серверную модель и обеспечивает взаимную аутентификацию – оба пользователя через сервер подтверждают личности друг друга.

Стоит отметить, что Kerberos в первую очередь является протоколом, а не конкретной системой аутентификации. Его реализации используются в различных операционных системах, в том числе и в Windows, как метод аутентификации пользователей в домене. Существует несколько open source реализаций протокола Kerberos, например оригинальная MIT Kerberos и Heimdal. Такой зоопарк возник из-за ограничений США на экспорт криптографических средств защиты информации, на сегодня эта ситуация вокруг MIT Kerberos уже улеглась. В статье мы рассмотрим процесс настройки для MIT Kerberos V5.

Терминология Kerberos

• Билет (ticket) – временные данные, выдаваемые клиенту для аутентификации на сервере, на котором располагается необходимая служба.
• Клиент (client) – некая сущность в сети (пользователь, хост или сервис), которая может получить билет от Kerberos.
• Центр выдачи ключей (key distribution center, KDC) – сервис, выдающий билеты Kerberos.
• Область (realm) – сеть, используемая Kerberos, состоящая из серверов KDC и множества клиентов. Имя realm регистрозависимо, обычно пишется в верхнем регистре и совпадает с именем домена.
• Принципал (principal) – уникальное имя для клиента, для которого разрешается аутентификация в Kerberos. Записывается в виде root[/instance]@REALM.

Файлы настроек Kerberos

На сервере:

• /etc/krb5kdc/kdc.conf — настройки KDC

На клиенте и сервере:

• /etc/kbr5.conf — настройки сервера аутентификации (описание realms, доменных имен и других настроек)

Настройка рабочего окружения

Для начала необходимо развернуть среду, в которой будет производиться аутентификация. Наиболее просто это сделать, взяв две виртуальные машины, находящиеся в одной подсети. Достаточно установить на одну виртуальную машину какую-нибудь Ubuntu (это будет наш сервер), а затем клонировать ее и получить клиента. При написании статьи я воспользовался свежей Ubuntu 12.10 (x86) и виртуальной машиной от VMWare. Чтобы виртуальным машинам было удобнее видеть друг друга по сети, стоит переключить сетевые карты в Bridged-режим.
Важно! Следите за тем, чтобы время на клиенте и сервере было синхронизировано, это необходимо для корректной работы Kerberos.

Настройка сети

Клиенты Kerberos ищут свои сервера по доменным именам, поэтому необходимо настроить DNS и убедиться, что имена серверов успешно разрешаются. В нашем примере достаточно занести доменное имя сервера в /etc/hosts, что я и сделал. Схема «сети» изображена ниже.

Установка необходимых пакетов

На сервере нам потребуются:

• krb5-kdc – сервис KDC
• krb5-admin-server – административный сервер Kerberos (он ведет контроль учетных записей пользователей)
• krb5-pkinit – модуль расширения Kerberos для аутентификации по сертификатам

На клиент надо поставить следующие пакеты:

• krb5-user – базовый набор утилит для работы клиентской аутентификации
• krb5-config – файлы настроек Kerberos
• krb5-pkinit
• libpam-krb5 – модуль PAM для использования Kerberos-аутентификации
• pcscd, opensc, libengine-pkcs11-openssl – пакеты, необходимые для работы с токенами

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

• Default realm: AKTIV-TEST.RU
• Имена серверов (admin server и KDC): aktiv-test.ru (он же прописан в /etc/hosts на клиенте)
• Пользователь: testuser@AKTIV-TEST.RU

Настройка Kerberos

Базовые настройки

Настройка аутентификации по открытому ключу

На сервере:

Создадим ключевую пару и сертификат нашего «УЦ». Здесь мы сгененируем ключ УЦ и создадим самоподписанный сертификат с помощью openssl. В реальном мире ключ естественно надо надежно защитить от попадания в чужие руки.
Создадим ключевую пару для KDC, заявку на сертификат и выпишем его сами себе.
Здесь нам потребуется специальный файл расширений OpenSSL (pkinit_extensions), в котором будут указаны дополнительные поля сертификатов, используемых в Kerberos. В частности, мы зададим:

• Extended Key Usage (EKU) – идентификатор (OID), говорящий о том, как планируется использовать сертификат
• otherName – поле, задающее нашего принципала, для которого выписывается сертификат

После этого перенесем следующие файлы в /var/lib/krb5kdc/:

• kdc.pem
• kdckey.pem
• cacert.pem

На сервере отредактируем настройки Kerberos (файл /etc/krb5kdc/kdc.conf) для использования ключей и сертификатов сервера и УЦ:
Далее на сервере необходимо включить предварительную аутентификацию для нашего пользователя.

Дальнейшие действия будем выполнять на клиенте

Настройка PAM-аутентификации с использованием Kerberos

Ранее при настройке клиентской машины мы поставили пакет libpam-krb5. Он поможет нам выполнить аутентификацию в Kerberos при входе в систему, а также в приложениях, использующих системную аутентификацию (например login, lightdm и проч.). Для подключения модуля PAM достаточно выполнить команду
и выбрать в диалоге необходимые модули аутентификации. Для более тонкой настройки можно заглянуть в файл /etc/pam.d/common-auth и отредактировать его по желанию. Структуру файла я описывал в предыдущей статье.

Заключение

Применение протокола Kerberos для централизованной аутентификации в связке с централизованным созданием хранением и раздачей учетных записей (например, посредством каталога на базе OpenLDAP) позволяет создать «домен UNIX», полностью состоящий из машин под управлением свободного программного обеспечения. Такое решение может применяться в корпоративном секторе, а аутентификация по смарт-картам будет приятным бонусом как для администраторов, так и для пользователей сети компании.

Источник