Создание SPN и Keytab файла: различия между версиями
Нет описания правки |
|||
Строка 45: | Строка 45: | ||
*'''-out''' - путь и имя генерируемого файла | *'''-out''' - путь и имя генерируемого файла | ||
=== На машине с ALT === | === На машине с ALT === | ||
==== С помощью ktutil ==== | |||
Этот способ работает если SPN предварительно были созданы и привязаны.<br> | |||
Установим необходимый пакет: | Установим необходимый пакет: | ||
<pre># apt-get install krb5-kadmin</pre> | <pre># apt-get install krb5-kadmin</pre> | ||
Строка 53: | Строка 55: | ||
ktutil: wkt squid.keytab | ktutil: wkt squid.keytab | ||
ktutil: q</pre> | ktutil: q</pre> | ||
==== С помощью Samba ==== | |||
== Проверка keytab-файла == | == Проверка keytab-файла == |
Версия от 11:50, 15 марта 2017
Введение
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.
Для этого в командной строке на контроллере домена выполним следующую команду:
C:\>setspn -A HTTP/sqserver.domg.testg squid Регистрация ServicePrincipalNames для CN=squid,CN=Users,DC=domg,DC=testg HTTP/sqserver.domg.testg Обновленный объект
Проверить привязанные SPN у пользователя можно командой:
C:\>setspn -L squid Зарегистрирован ServicePrincipalNames для CN=squid3,CN=Users,DC=domg,DC=testg: HTTP/sqserver.domg.testg
Генерирование keytab-файла
Создать keytab-файл можно разными способами.
Рассмотрим некоторые из них.
На контроллере домена Windows 2008 R2
Необходимо выполнить следующую команду:
C:\>ktpass -princ HTTP/sqserver.domg.testg@DOMG.TESTG -mapuser squid -pass Pa$$word -ptype KRB5_NT_PRINCIPAL -out C:\squid.keytab Targeting domain controller: dcd.domg.testg Using legacy password setting method Successfully mapped HTTP/sqserver.domg.testg to squid3. Key created. Output keytab to C:\squid.keytab: Keytab version: 0x502 keysize 70 HTTP/sqserver.domg.testg@DOMG.TESTG ptype 1 (KRB5_NT_PRINCIPAL) vno 6 etype 0x17 (RC4-HMAC) keylength 16 (0x1a4b1757588cab6298e29e91c06df58d)
Рассмотрим параметры команды подробнее:
- -princ - имя принципала содержащее SPN и Kerberos-область (realm)
- -mapuser - пользователь к которому привязывается SPN
- -pass - пароль пользователя
- -ptype - указывает тип принципала (рекомендуется KRB5_NT_PRINCIPAL)
- -out - путь и имя генерируемого файла
На машине с ALT
С помощью ktutil
Этот способ работает если SPN предварительно были созданы и привязаны.
Установим необходимый пакет:
# apt-get install krb5-kadmin
Запустим ktutil и создадим keytab-файл:
# ktutil ktutil: addent -password -p HTTP/sqserver.domg.testg@DOMG.TESTG -k 6 -e RC4-HMAC Password for HTTP/sqserver.domg.testg@DOMG.TESTG: ktutil: wkt squid.keytab ktutil: q
С помощью Samba
Проверка keytab-файла
Для проверки keytab-файла необходима настроенная Kerberos-аутентификация.
Это можно проверить командой:
# kinit Administrator@DOMG.TESTG
Она должна запрашивать пароль и получать билет:
# klist Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator@DOMG.TESTG Valid starting Expires Service principal 14.03.2017 16:45:58 15.03.2017 02:45:58 krbtgt/DOMG.TESTG@DOMG.TESTG 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/sqserver.domg.testg@DOMG.TESTG Using keytab: /home/test/squid.keytab Authenticated to Kerberos v5
Проверить версию ключей на сервере можно, предварительно получив билет, с помощью команды:
# kvno HTTP/sqserver.domg.testg HTTP/sqserver.domg.testg@DOMG.TESTG: 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/sqserver.domg.testg@DOMG.TESTG (arcfour-hmac)
После всех проверок желательно удалить полученные билеты командой:
# kdestroy