Mit kerberos for windows krb5 ini

• 1 # Термины и определения
• 2 # Инструменты
• 3 # Описание
  • 3.1 # Типы шифрования
  • 3.2 # krb5.ini
• 4 # Настройка сервера
  • 4.1 # Создание пользователя для сервера
  • 4.2 # Создание SPN
  • 4.3 # Привязка SPN к пользователю сервера
  • 4.4 # Создание keytab для SPN
  • 4.5 # Настройка kerberos.properties
  • 4.6 # Команды для выполнения по вышеперечисленным пунктам
• 5 # Настройка браузера
• 6 # Настройка оповещателя
  • 6.1 # Настройка для получения заданий
  • 6.2 # Настройка для браузера
• 7 # Типичные проблемы

# Термины и определения

# Инструменты

# Описание

Более строгое описание можно найти в интернете, например https://blogs.technet.microsoft.com/askds/2008/03/06/kerberos-for-the-busy-admin/.

# Типы шифрования

Выбранный тип шифрования зависит от участников взаимодействия — версии ПО домена (Windows Server), настроек домена, настроек пользователя, настроек ПО клиента.

В ранних версиях (Windows 2000, 2003) настраивали DES, в поздних (Windows 2008, 2012) рекомендуют использованием AES.

Настройки пользователя, оказывающие влияние на поведение Kerberos:

• This account supports Kerberos AES 128/256 bit encryption — разрешение использования соответствущего типа шифрования для пользователя

(TODO — при невключённых чекбоксах всё равно использовался AES128)

• Use Kerberos DES encryption for this acount — включает шифрование DES для пользователя, после установки чекбокса требуется смена пароля

# krb5.ini

Файл не является обязательным, но может влиять на поведение процесса аутентификации.

Детальное описание файла конфигурации Kerberos

На сервере и клиентских машинах Windows он может быть расположен в ${windir}/krb5.ini.

Пример файла krb5.ini

[domain_realm]
 .test.com = TEST.COM
 test.com = TEST.COM
[libdefaults]
 default_realm = TEST.COM
 kdc_timesync = 1
 ccache_type = 4
 ticket_lifetime = 600
 default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
 default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
 permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
[logging]
 kdc = CONSOLE
[realms]
 TEST.COM = {
  kdc = 192.168.0.1
  kdc = 192.168.1.1
  default_domain = test.com
 }
[appdefaults]
 autologin = true
 forward = true
 forwardable = true
 encrypt = true

# Настройка сервера

Данная инструкция сделана в окружении Windows Server2008R2 (контроллер домена), Windows Server2012R2 (RunaWFE Server), Windows7 (RunaWFE client).

В данном разделе регистр может иметь значение, хотя опытным путём было выяснено что логин пользователя, название компьютера сервера и SPN не являются регистрозависимыми.

# Создание пользователя для сервера

На контроллере домена нужно создать пользователя {SERVER_USER} с настройками по умолчанию.

Проверка: kinit {SERVER_USER} должен успешно получить тикет.

# Создание SPN

На контроллере домена нужно выполнить команды:

setspn -A {SERVER_SPN} {SERVER_USER}

Проверка: через ADSIEdit можно увидеть что свойство пользователя servicePrincipalName установлено либо посмотреть св-во servicePrincipalName с помощью команды Get-ADUser {SERVER_USER} -Properties *.

Если планируется использовать SPN на основании NetBIOS имени — то нужно зарегистрировать и его (https://msdn.microsoft.com/en-us/library/ms677949.aspx)

setspn -A HTTP/{SERVER_NAME} {SERVER_USER}

# Привязка SPN к пользователю сервера

На контроллере домена нужно выполнить команду:

ktpass /princ {SERVER_SPN} /mapuser {SERVER_USER} +setupn /pass *

Можно игнорировать предупреждение «WARNING: pType and account type do not match. This might cause problems».

Для обхода бага со сбросом пароля https://support.microsoft.com/en-us/kb/939980 рекомендуют вписать пароль вместо звёздочки. А если выполнить данную команду без пароля — то почему-мо возникает ошибка 24 с некорректным salt.

Проверка: в свойствах пользователя User logon name стал равен SPN либо посмотреть св-во UserPrincipalName с помощью команды Get-ADUser {SERVER_USER} -Properties *.

Проверка: kinit {SERVER_SPN} должен успешно получить тикет.

# Создание keytab для SPN

Выполнить команду из {JAVA_HOME}/bin:

ktab -a {SERVER_SPN} -n 0 -k {KEYTAB_PATH}

Проверка: kinit -k -t {KEYTAB_PATH} {SERVER_SPN} должен успешно получить тикет без запроса пароля.

Этот файл также можно получить в результате вызова команды ktpass на контроллере домена.

# Настройка kerberos.properties

Создайте файл kerberos.properties в директории {RUNAWFE_JBOSS}/standalone/wfe.custom. Замените в нем имена на настоящие.

# задействовать аутентификацию используя RunaWFE API
api.auth.enabled=true
appName=com.sun.security.jgss.krb5.accept
moduleClassName=com.sun.security.auth.module.Krb5LoginModule
principal={SERVER_SPN}
storeKey=true
useKeyTab=true
keyTab={KEYTAB_PATH}
doNotPrompt=true
# режим отладки аутентификации
debug=true
# задействовать аутентификацию по протоколу HTTP (из веб-интерфейса)
http.auth.enabled=true
jcifs.http.enableNegotiate=true
# режим отладки аутентификации
sun.security.krb5.debug=true
jcifs.spnego.servicePrincipal={SERVER_SPN}
http.auth.preference=Kerberos

# Команды для выполнения по вышеперечисленным пунктам

На контроллере домена:

setspn -A HTTP/runaserver.test.com runauser

ktpass -princ HTTP/runaserver.test.com -pass * -mapuser runauser

На сервере:

ktab -a HTTP/runaserver.test.com -n 0 -k C:/runawfe/krb5.keytab

# Настройка браузера

Для того чтобы браузер пытался использовать Kerberos для аутентификации:

• в нём должна быть включена настройка Enable Integrated Windows Authentication (в некоторых версиях IE её нет)
• настройки зоны безопасности должны позволять её использование, по умолчанию это настроено для LocalIntranet
• настройка {SERVER_SPN} должна быть корректно произведена

Во время запроса на сервере формируется в логе Request Authorization:

• Negotiate YIIV… — правильно
• Negotiate TlRMT… — неправильно (попытка использовать NTLM)

Если по нажатию на ссылке Сквозная аутентификация (kerberos) будет выведено окно с вводом логина/пароля — то это значит что браузер не получил сервисный тикет в контроллере домена или даже не пытался это сделать. При возникновении такой ситуации самым действенным оказывается использование WireShark для прослушивания траффика по порту 88 с контроллером домена.

# Настройка оповещателя

На сервере должна быть корректно настроена аутентификация.

# Настройка для получения заданий

Настроить kerberos.properties если authentication.type установлено в kerberos (для sspiKerberos это не требуется):

appName=com.sun.security.jgss.initiate
moduleClassName=com.sun.security.auth.module.Krb5LoginModule
useTicketCache=true
doNotPrompt=true
debug=true
serverPrincipal=HTTP/runaserver.test.com

# Настройка для браузера

Настройку login.relative.url установить в /krblogin.do.

# Типичные проблемы

https://technet.microsoft.com/en-us/library/bb463167.aspx

Включение аудита на контроллере домена иногда помогает понять проблему (логирование происходит в журнале событий, категория Безопасность.

In Greek mythology, Kerberos, also called Cerberus, guards the gates of the Underworld to prevent the dead from leaving. He is commonly described as a three-headed dog, a serpent’s tail, mane of snakes and a lion’s claws. In computer, Kerberos is an authentication protocol based on the exchange of tickets. Windows 2000 and later versions use Kerberos as its default authentication method. It is often used as a Single Sign On (SSO) solution or to authenticate not only users but also computer nodes and services. It is frequently used in complex systems such as Hadoop based Big Data platforms.

When a user wish to gain access to a Kerberos secured service, he must first authenticate and, once successful, he will receive a master ticket called TGT stored on his local host. This ticket can later be used to create a service ticket (TS) which is used to access a remote service using an RPC connection or over HTTP. When the ticket is transmitted over HTTP, the communication make use of the SPNEGO protocol which store the ticket information into the HTTP header request.

The client installation procedure is very easy on Linux and OSX. Most of the time, Kerberos comes pre-installed or, if not, a simple command with your favourite package manager will install the client library. Safari will work right away while Firefox and Chrome will require some adjustments easily found on the Internet. While being easy on Linux and OSX, it is a little bit more complicated on Windows. If your host is integrated with an Active Directory, a ticket is already present. However, you cannot always use it to contact a remote service secured with Kerberos, for example because it exposes a domain which is not trusted by the Active Directory. Moreover, Windows has its own way to manage the Kerberos ticket.

The article explain how create a ticket with the MIT Kerberos client for Windows, how to store a ticket into its own file path and how to configure Firefox to make use of it.

Credential cache

Kerberos ticket are stored inside the credentials cache. There are multiple credentials cache supported on Windows:

• FILE caches
  Simple and most portable. A simple flat file format is used to store one credential after another. This is the default on Linux and OSX.
• API cache
  Only implemented on Windows, it communicates with a server process that holds the credentials in memory. This seems to be the default on Windows.

The default credential cache name is determined by…

• The KRB5CCNAME environment variable
• The default_ccache_name profile variable in [libdefaults] of the configuration file
• The hardcoded default, DEFCCNAME, default to FILE:/tmp/krb5cc_%{uid} on Unix

Note about the credential cache path

In the procedures below, whether you choose to declare the credential cache with an environment variable or through the configuration file, don’t forget to replace {username} with your windows username. You can declare any path you wish. The path must correspond to the file where your Kerberos Ticket will be written. Its parent directory must exists with writable permissions by the user issuing the ticket.

Environment variable

Using the windows search, look for “environment variables” and select “Edit the system environment variables”. In the new window, click on the “Environment variables” button. From there, add a new user variable named “KRB5CCNAME” with the value C:Users{username}AppDataLocalTempkrb5cache.

From the PowerShell console, you can print the value of the credential cache with the command $Env:KRB5CCNAME. You do not need to restart your host to activate the environment variable but you must reload your PowerShell session if it was already opened.

Configuration file

The path to the Kerberos client configuration is C:ProgramDataMITKerberos5krb5.ini. We will get back to its full configuration later but for now, to set the credential cache, you only need to the set the default_ccache_name profile variable.

Navigate to the C:ProgramDataMITKerberos5 and change the permission to allow the current user to edit the file.

Now edit the file with your favorite code editor such as Sublime Text or Notepad++ and make it look like:

[libdefaults]
 default_ccache_name = C:Users{username}AppDataLocalTempkrb5cache

Kerberos

MIT Kerberos client installation

Download and install the Kerberos MIT client for Windows. The current version at the time of this writing is 4.1 and the download link is located in the section called “MIT Kerberos for Windows 4.1”.

This installation procedure is straightforward. Just accept all the default settings and move forward. Once the installation is complete, the installer will ask to restart the computer. It is probably not necessary but I didn’t had the time to check.

Automatic client discovery

Depending on your setup, you do not always need to modify the Kerberos client configuration. In the absence of entries in the configuration file, the KDC adress can be obtained from the DNS records. This feature can be desactivated if dns_lookup_kdc is false. The FreeIPA DNS service expose the following domain records:

• _kerberos of type “TXT”, eg “AU.ADALTAS.CLOUD”
• _kerberos-master._tcp of type “SRV”
• _kerberos-master._udp of type “SRV”
• _kerberos._tcp of type “SRV”
• _kerberos._udp of type “SRV”
• _kpasswd._tcp of type “SRV”
• _kpasswd._udp of type “SRV”

Users of our Adaltas clusters with access to the cluster through a VPN tunnel transparently use our FreeIPA DNS server. It provides them with the auto discovery of the Kerberos server. You can check this on Linux with dig:

dig srv _kerberos._udp.au.adaltas.cloud +short
0 100 88 ipa-2.au.adaltas.cloud.
0 100 88 ipa1.au.adaltas.cloud.

As well as on Windows with nslookup:

nslookup -type=SRV _kerberos._udp.au.adaltas.cloud
Server:  ipa1.au.adaltas.cloud
Address:  10.0.0.5

_kerberos._udp.au.adaltas.cloud SRV service location:
         priority       = 0
         weight         = 100
         port           = 88
         svr hostname   = ipa1.au.adaltas.cloud
_kerberos._udp.au.adaltas.cloud SRV service location:
         priority       = 0
         weight         = 100
         port           = 88
         svr hostname   = ipa-2.au.adaltas.cloud
au.adaltas.cloud        nameserver = ipa1.au.adaltas.cloud
ipa1.au.adaltas.cloud   internet address = 10.0.0.5
ipa-2.au.adaltas.cloud  internet address = 10.0.0.9

Client configuration

Alternatively, you may need to create or import your own kerberos configuration file. The path to the file is C:ProgramDataMITKerberos5krb5.ini.

If you have access to an environment with Kerberos enabled, such as a Linux box through SSH, then you already have access to the Kerberos configuration. On Linux, the file is readable by every users and it is located at “/etc/krb.conf”. You can simply import the file into your Windows host and rename it “krb5.ini” instead than “krb5.conf”. Here is an example which you could adjust with your own settings.

[libdefaults]
 default_realm = AU.ADALTAS.CLOUD
 dns_lookup_realm = false
 dns_lookup_kdc = true
 rdns = false
 ticket_lifetime = 24h
 forwardable = true
 udp_preference_limit = 0

[realms]
 AU.ADALTAS.CLOUD = {
  kdc = ipa1.au.adaltas.cloud:88
  master_kdc = ipa1.au.adaltas.cloud:88
  admin_server = ipa1.au.adaltas.cloud:749
  default_domain = au.adaltas.cloud
 }

[domain_realm]
 .au.adaltas.cloud = AU.ADALTAS.CLOUD
 au.adaltas.cloud = AU.ADALTAS.CLOUD
 ipa1.au.adaltas.cloud = AU.ADALTAS.CLOUD

Ticket creation

The ticket can now be created from the Kerberos client window by entering your provided principal and password.

If successful, you shall view your ticket as well as some complimentary information such as the validation date as well as the credential cache location.

Note, opening the Kerberos client window to enter your Kerberos credential is not mandatory. Once Firefox is configured (see the next section), you can directly enter your destination URL and a new window will pop up asking for your principal and username.

Firefox

Configuration

We have created a Kerberos ticket and we now need to configure Firefox to use it. Before going to your destination URL, you must edit the configuration window by writing “about:config” in the adress bar.

Accept the risk and modify the following properties:

• network.negotiate-auth.trusted-uris: .au.adaltas.cloud
  Lists the sites that are permitted to engage in SPNEGO authentication with the browser.
• network.auth.use-sspi: false
  Determines whether to use SSPI or GSSAPI for Kerberos authentication. SSPI is a proprietary variant of GSSAPI with extensions and Windows-specific data types. It is the default API on Windows. GGSAPI is an IETF standard and it is used by the MIT Kerberos client we just installed and used.

Also, while not being mandatory, you can change the following variables:

• network.negotiate-auth.delegation-uris: .au.adaltas.cloud
  Lists the sites for which the browser may delegate user authorization to the server.
• network.negotiate-auth.using-native-gsslib: false
  Use the default GSSAPI library.
• network.negotiate-auth.gsslib: C:Program FilesMITKerberosbingssapi64.dll
  Specifies a alternate GSSAPI shared library. Modify the path to the appropriate dll depending on your host architecture (32 or 64 bits).
• network.negotiate-auth.allow-non-fqdn: true
  Accepts service domain names instead of fully qualified domain names.

Ticket creation

If you try to access a service URL secured with Kerberos but without a valid ticket, you will see such a page:

The 401 HTTP error code indicates that your browser failed to negotiate the authentication. As part of the SPNEGO protocol, the server has requested to negotiate the authentication by returning the WWW-Authenticate: Negotiate response header. However your browser couldn’t propose any suitable method. You can see this exchange with the curl command:

curl --negotiate -u: --head http://yarn-rm-1.au.adaltas.cloud:8088/cluster
HTTP/1.1 401 Authentication required
Date: Thu, 24 Oct 2019 09:57:48 GMT
Date: Thu, 24 Oct 2019 09:57:48 GMT
Pragma: no-cache
WWW-Authenticate: Negotiate
Set-Cookie: hadoop.auth=; Path=/; HttpOnly
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 267

The --negotiate argument tell to curl to negotiate the authentication with the remote service. The --user argument provide the required username and password which are empty in the case of Kerberos since the credential information is stored inside the local ticket.

With a valid ticket, the negotiation will succeed and you ticket will be encrypted as base64 in the second WWW-Authenticate header:

curl --negotiate -u: --head http://yarn-rm-1.au.adaltas.cloud:8088/cluster
HTTP/1.1 401 Authentication required
Date: Thu, 24 Oct 2019 09:58:17 GMT
Date: Thu, 24 Oct 2019 09:58:17 GMT
Pragma: no-cache
WWW-Authenticate: Negotiate
Set-Cookie: hadoop.auth=; Path=/; HttpOnly
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 267

HTTP/1.1 405 HTTP method GET is not supported by this URL
Date: Thu, 24 Oct 2019 09:58:17 GMT
Date: Thu, 24 Oct 2019 09:58:17 GMT
Pragma: no-cache
WWW-Authenticate: Negotiate oYH1MIHyoAMKAQChCwYJKoZIhvcSAQICom4EbGBqBgkqhkiG9xIBAgICAG9bMFmgAwIBBaEDAgEPok0wS6ADAgESokQEQhnlSj8cuKVGz6eBMJNi9R8ImTtdpJU4zV8N4s4EwJxpnmU0ZohrBtavGQxoXFSuuxScHcpiNVL51qEJzsoAA6x6iqNuBGxgagYJKoZIhvcSAQICAgBvWuBZoAMCAQWhAwIBD6JNMEugAwIBEqJEBEIZ5Uo/HLilRs+ngTCTYvUfCJk7XaSVOM1fDeLOBMCcaZ5lNGaIawbWrxkMaFxUrrsUnB3KYjVS+dahCc7KAAOseoo=
Set-Cookie: hadoop.auth="u=david&p=david@AU.ADALTAS.CLOUD&t=kerberos&e=1571947097972&s=Df9/vrrj4xHASRxHPdBJHOCap4Gdmvst1QCnjFXuceI="; Path=/; HttpOnly
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 309

And you can finally access all your Kerberos secured service without having to renter your login credentials:

I want to use Kerberos to do auth to an IIS kerberos protected web site from a Java application. The goal is to be able to use a keytab file to authenticate with a service account without specifying a username and password.

This describes how to use http client to auth using kerberos. But it requires a couple special configuration files login.conf and krb5.ini.

The format is the login conf is described here: https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/LoginConfigFile.html

The format of the krb5.ini file is described here: https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html

I also found some related sof articles (listed below).

But none of them seem to describe the process of actually creating the login.conf file and the krb5.conf/krb5.ini file for use against Active Directory.

What are steps to generating these files for use with a Windows Active Directory kerberos situation?

Here’s what I have so far, but I’m completely going off of examples I’ve found from friends and random links around the web.

login.conf

KrbLogin {
  com.sun.security.auth.module.Krb5LoginModule required
  useKeyTab=true
  storeKey=true
  keyTab="file:///C:/kerb/kerberos500.keytab"
  useTicketCache=true
  principal="kerberos500@FUSIONIS.LIFE"
  debug=true;
};

com.sun.security.jgss.initiate {
  com.sun.security.auth.module.Krb5LoginModule required
  useKeyTab=true
  storeKey=true
  keyTab="/home/ndipiazza/lucidworks/httpclient-tester/kb.keytab"
  useTicketCache=true
  principal="kerberos500@FUSIONIS.LIFE"
  debug=true;
};

krb5.ini

[libdefaults]
    default_realm = FUSIONIS.LIFE
    default_tkt_enctypes = aes128-cts-hmac-sha1-96 rc4-hmac
    default_tgs_enctypes = aes128-cts-hmac-sha1-96  rc4-hmac
    permitted_enctypes = aes128-cts-hmac-sha1-96 rc4-hmac
    dns_lookup_realm = false
    dns_lookup_kdc = false
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
    udp_preference_limit = 1

[realms]
FUSIONIS.LIFE = {
   kdc = 192.168.1.71
   admin_server = 192.168.1.71
}

[domain_realm]
.fusionis.life = FUSIONIS.LIFE
fusionis.life = FUSIONIS.LIFE

Create the keytab on Windows

ktpass /princ kerberos500@FUSIONIS.LIFE /pass password /ptype KRB5_NT_PRINCIPAL /out kerberos500.keytab

Creating the KeyTab on Ubuntu Linux

ktutil
addent -password -p kerberos500@FUSIONIS.LIFE -k 1 -e RC4-HMAC
- it will ask you for password of kerberos500 -
wkt kerberos500.keytab
q

Related sofs:

HttpClient set credentials for Kerberos authentication

Simple Kerberos client in Java?

Where is the krb5.ini file in alter Windows file gone?