Настройка Kerberos-аутентификации для Linux
Настройки kerberos-аутентификации под Linux отличаются в зависимости от дистрибутива. В таблице представлены пакеты, которые необходимо установить для настройки аутентификации.
| RHEL/ CentOS/ Fedora | Debian/ Ubuntu/ Astra | Alt |
|---|---|---|
| krb5-workstation krb5-libs krb5-pkinit pam_krb5 sssd-krb5 sssd-krb5-common gssntlmssp | krb5-user krb5-config krb5-pkinit sssd-krb5 sssd-krb5-common gss-ntlmssp | krb5-kinit pam_krb5 sssd-krb5 sssd-krb5-common gssntlmssp |
Настройка подключения к серверу Kerberos
Чтобы настроить подключение к серверу Kerberos, внесите изменения в файл «/etc/krb5.conf»:
- В секции [libdefaults] укажите:
default_ccache_name = FILE:/home/%/krb5cc
default_tgs_enctypes = rc4-hmac
default_tkt_enctypes = rc4-hmac
permitted_enctypes = rc4-hmac
default_realm = название_домена_в_котором_находится_сервер_Kerberos_в_верхнем_регистре
- Если на сервере Kerberos включено другое шифрование, тогда его нужно указать вместо rc4-hmac.
- Если это шифрование относится к стойким, то параметр allow_weak_crypto можно поставить в false.
- имя_домена = имя_домена_в_верхнем_регистре
- имя_домена_с_сточкой_впереди = имя_домена_в_верхнем_регистре
- [domain_realm]
- v2016.testinfomaximum.com = V2016.TESTINFOMAXIMUM.COM
- .v2016.testinfomaximum.com = V2016.TESTINFOMAXIMUM.COM
kinit пользователь_под_которым_будем_входить_в_систему@домен_в_верхнем_регистре
После ввода пароля создается билет Kerberos, по которому можно будет входить в систему. Билет имеет время жизни, которое можно установить в «krb5.conf» в секции [libdefaults] (например, ticket_lifetime = 24h) или при вызове kinit (добавив перед именем пользователя ключ -l от времени жизни). После истечения времени жизни билет необходимо пересоздавать командой kinit.
При использовании стойких шифров сервер Kerberos (KDC) добавляет к паролю дополнительные символы («соль»). В качестве «соли» Kerberos использует имя домена, объединённое с именем сервера. Клиент Kerberos под Linux в качестве «соли» по умолчанию использует имя домена, объединённое с именем пользователя, под которым необходимо залогиниться. Таким образом, при использовании стойкого шифрования не удаётся наладить связь между KDC и клиентом, так как пароли оказываются разными. Чтобы избежать данной проблемы, мы советуем задать в клиенте Kerberos шифрование rca4-hmac.
Настройки браузеров
Firefox
Чтобы настроить браузер Firefox:
- На вкладке about:config найдите все параметры со словом negotiate.
- Установите в true:
network.negotiate-auth.allow-non-fqdn
network.negotiate-auth.allow-proxies
network.negotiate-auth.using-native-gsslib
Active Directory в браузере FireFox не работает со встроенной библиотекой обработки GSS-API. Инструкция по решению данной проблемы представлена на странице Настройка Kerberos-аутентификации для Firefox.
Chrome/Chromium
Чтобы настроить браузеры Chrome/Chromium, в директории /etc/chromium/policies/managed (или /etc/chromium-browser/policies/managed) создайте json-файл с произвольным именем (например, kerberos.json):
Этот файл настроен на принятие любых адресов для использования Kerberos. Можно заменить «*» на конкретное доменное имя сервера.
Вход в систему
После создания билета и настройки браузера вход в систему осуществляется через нажатие кнопки Войти с помощью Active Directory. При этом ни имя, ни пароль дополнительно не запрашиваются (запрос пароля происходит в процессе создания билета Kerberos).
Создаем keytab-файл для Kerberos аутентификации в Active Directory
31.08.2020
itpro
Active Directory, PowerShell, Windows Server 2016
комментариев 5
Многие сервисы 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 «[email protected]» -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 файл используется следующая команда:
ktpass -princ HTTP/[email protected] -mapuser web -crypto ALL -ptype KRB5_NT_PRINCIPAL -pass Bergam0ttapoK -target dc01.test.com -out c:\ps\web_host.keytab
Successfully mapped HTTP/www.test.com to web. Password successfully set! Key created. Key created. Key created. Key created. Key created. Output keytab to c:\ps\web_host.keytab: Keytab version: 0x502 keysize 53 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x1 (DES-CBC-CRC) keylength 8 (0x73f868856e046449) keysize 53 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x3 (DES-CBC-MD5) keylength 8 (0x73f868856e046449) keysize 61 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x17 (RC4-HMAC) keylength 16 (0x9365b81e20c6137186d956c06ade2e77) keysize 77 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x12 (AES256-SHA1) keylength 32 (0x16b6c95e8047e7e70b1dc3cd502353df 5eeab2c24d4097c41165b0ca65b9b31f) keysize 61 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x11 (AES128-SHA1) keylength 16 (0x72c8b1cde771e59b6f1bc6501d614e32)
Данная команда создала keytab файл (c:\ps\web_host.keytab) для SPN записи сервиса HTTP/[email protected]. При этом SPN запись привязывается к учетной записи web с указанным паролем.
Проверьте, что для SPN записи службы была создана успешно (если вы не создавали ее вручную):
setspn -Q */[email protected]
Видно, что 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: c:\PS\web_host.keytab, 5 entries found.
Посмотрим на содержимое 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 смогут воспользоваться любыми ключами из него).
Предыдущая статья Следующая статья 
Owen Rumney
I’m assuming for anyone who is doing this that you have your /etc/krb5.conf in order and that isn’t going to get in your way.
One thing you’re going to want to know is what your permitted and default enctypes and the realm are from this file. In my case I’m going to use aes128-cts-hmac-sha1-96 and my realm is DPE.INTERNAL .
Creating the keytab file
To create the keytab file you’re going to need ktutil (and a number of other kxxxxxx commands)
sudo yum install krb5-workstation sudo apt-get install krb5-user Now you have the required programs installed, you can create your keytab file using ktutil .
This will present you with a prompt for you to add the entries in the keytab file
add_entry -password -p user@DPE.INTERNAL -k 1 -e aes256-cts-hmac-sha1-96 Password for user@DPE.INTERNAL: write_kt user.keytab quit Breaking this down, we are saying that we want to add an entry to the keytab using a password for authentication.
The -p is the principal that we will be logging in as using the end file.
The -k refers to the Key Version Number which in some situations isn’t really needed and is ignored (in Windows environment for example). You can get the current Key version number (kvno) by using the kvno command
kvno user@DPE.INTERNAL user@DPE.INTERNAL: kvno = 1 The -e refers to the enctype mentioned earlier. This needs to be one of those that are permitted in your krb5.conf file so you’re using an accepted and appropriate encryption.
Testing the Key
We can now test the keytab for successfully login
kinit -kt user.keytab user@DPE.INTERNAL This should exit normally, then we can check we’ve got a ticket using klist
klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: user@DPE.INTERNAL Valid Starting Expires Service principal 01/23/2019 14:27:28 01/24/2019 00:27:28 user@DPE.INTERNAL To clear out the ticket, you can use kdestroy . This will remove all current authentications.