Авторизация kerberos в linux

Kerberos

Kerberos is an authentication protocol using a combination of secret-key cryptography and trusted third parties to allow secure authentication to network services over untrusted networks. More information about the Kerberos protocol is available from MIT’s Kerberos site. Designing an Authentication System is an accessible introduction to the principals of Kerberos’ authentication scheme.

Intended Audience

This guide aims to supplement the documentation available in the official Ubuntu documentation by re-iterating certain key concepts in more detail and providing information on network service configuration. It is directed at system administrators that need to supplement their understanding of Kerberos and its advanced configuration.

Several Kerberos implementations exist. Two common open-source implementation of the Kerberos protocol are the original MIT implementation, and Heimdal, an implementation that was created to avoid United States export regulations. These regulations are no longer a concern, and for sake of brevity, this guide will provide instructions for the MIT version. The same concepts apply to Heimdal, although the syntax of various commands is different.

Microsoft’s Active Directory is a common closed-source implementation of a Kerberos authentication realm. The following guide contains several notes that give specific configuration information for Active Directory. In an Active Directory environment, the KDC is typically one of the services provided by the Domain Controller (DC). Readers wishing to integrate with an Active Directory Domain can skip directly to the Client Configuration section.

Pre-installation Decisions

A central part of Kerberos’ trusted third party authentication scheme is the Key Distribution Center (KDC), which is a centralized repository for users’ password information. Before deploying Kerberos, a server must be selected to take on the role of KDC. Physical and network security will be critical for this server, since a compromised KDC compromises the security of the entire realm.

Selecting a descriptive name for the Kerberos authentication realm is also important. Conventionally, the realm names is the site’s domain name fully capitalized. For instance, the site example.com would conventionally use EXAMPLE.COM for its realm name.

Prerequisites

All servers and clients that participate in a Kerberos realm must be able to communicate with each other and have accurate system clocks. The following section describes how to meet these requirements.

Host Names

Each server in a Kerberos authentication realm must be assigned a Fully Qualified Domain Name (FQDN) that is forward-resolvable.

Kerberos also expects the server’s FQDN to be reverse-resolvable. If reverse domain name resolution is not available, set the rdns variable to false in clients’ krb5.conf

Note: Active Directory depends heavily on DNS, so it is likely that the Active Directory Domain Controller is also running the Microsoft DNS server package. If this is the case, verify that each server has a FQDN assigned to it before performing the tests outlined in this section.

If the server already has an FQDN assigned to it, test forward and reverse look-up with the following commands:

$ nslookup server.example.com $ nslookup

The output of the first command should contain the IP address of the server. The output of the second command should contain the FQDN of the server.

If the server does not already have a FQDN assigned to it and DNS services are not available, name resolution can be implemented by editing the local hosts file (typically this is located in /etc) on each server and client, adding the following line:

127.0.0.1 linuxwork.example.com localhost linuxwork

Test the local DNS name resolution using the nslookup technique described at the beginning of the section.

Connectivity

To verify connectivity between hosts, ping each host’s FQDN:

$ ping kerberos.example.com PING kerberos.example.com (10.0.0.1) 56(84) bytes of data. 64 bytes from kerberos.example.com (10.0.0.1): icmp_seq=1 ttl=128 time=0.176ms

The output of the ping command shows successful resolution of the FQDN to an IP Address, and a sample reply from the server. A reply from the server serves as confirmation that the host and the server can communicate.

Connectivity failures while pinging the KDC’s FQDN usually point to DNS server or client configuration errors. See the Network Configuration for information on correct network settings.

Time Synchronization

The Kerberos protocol requires the time of the client and server to match: if the system clocks of the client does not match that of the server, authentication will fail. The simplest way to synchronize the system clocks is to use a Network Time Protocol (NTP) server. See UbuntuTime for details.

Note: Active Directory Domain Controllers are typically also NTP servers.

Firewalls

As with all network services, Kerberos must be allowed to pass through any firewalls between hosts. The Kerberos System Administration Manual has a detailed section on this topic.

KDC Setup

$ sudo apt-get install krb5-kdc krb5-admin-server $ sudo dpkg-reconfigure krb5-kdc

These packages are available from the Main repository. See InstallingSoftware for details on software installation, repositories and package management.

• disable Kerberos 4 compatibility mode
• do not run krb524d (daemon to convert Kerberos tickets between versions)
• defaults for the other settings are acceptable

The default location of the KDC’s configuration file is /etc/krb5kdc/kdc.conf. Important settings are the locations of the KDC’s data files, and the default settings for the durations that tickets are valid. The realm name must be configured; other configuration options should only be changed by knowledgable users.

Here is an example configuration file:

[kdcdefaults] kdc_ports = 750,88 default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = database_name = /var/lib/krb5kdc/principal admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab acl_file = /etc/krb5kdc/kadm5.acl key_stash_file = /etc/krb5kdc/stash kdc_ports = 750,88 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = des3-hmac-sha1 supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm default_principal_flags = +preauth >

Kerberos uses an Access Control List (ACL) to specify the per-principal access rights to the Kerberos admin daemon. This file’s default location is /etc/krb5kdc/kadm5.acl. The default as shown below is sufficient for most realms, but additional ACLs may be necessary depending on the network configuration.

# This file is the access control list for krb5 administration. # When this file is edited run /etc/init.d/krb5-admin-server restart to activate # One common way to set up Kerberos administration is to allow any principal # ending in /admin is given full administrative rights. # To enable this, uncomment the following line: */admin@EXAMPLE.COM *

Create the Kerberos database with the following command:

Principals

Principals are entries in the Kerberos database that represent users or services on the network. Each user or service that is participates in a Kerberos authentication realm must have a principal defined in the Kerberos database.

User principals take the form principal@REALM.NAME. For instance, user tom on the EXAMPLE.COM realm should have a principal tom@EXAMPLE.COM in the Kerberos database.

Service principals take the form service/server.fqdn@REALM.NAME. For example, the FTP service on lab.example.com in the EXAMPLE.COM realm would have the principal ftp/lab.example.com@EXAMPLE.COM in the Kerberos database.

Principal names are case sensitive.

Realm Administration: kadmin

The Kerberos realm is administered using the kadmin utility. The kadmin utility is an interactive interface that allows the administrator to create, retrieve, update, and delete realm principals. kadmin can be run on any computer that is part of the Kerberos realm, provided the user has the proper credentials. However, for security reasons, it is best to run kadmin on a KDC.

An alternative program, kadmin.local, is available as well. Running kadmin.local as the root user on the KDC allows the administrator to authenticate without having an existing principal. This is generally not necessary in a properly configured environment.

To start the kadmin utility, issue the following command:

Replace with a valid principal name. By default, the principal admin/admin has administrative rights to the realm, so to launch kadmin as the realm administrator, use:

Type ? and press Enter at the kadmin prompt to see a list of valid commands.

Common tasks

Источник

Настройка 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»:

1. В секции [libdefaults] укажите:
   • allow_weak_crypto = true
   • default_ccache_name = FILE:/home/%/krb5cc
   • default_tgs_enctypes = rc4-hmac
   • default_tkt_enctypes = rc4-hmac
   • permitted_enctypes = rc4-hmac
   • default_realm = название_домена_в_котором_находится_сервер_Kerberos_в_верхнем_регистре (например, default_realm = V2016.TESTINFOMAXIMUM.COM )

   Примечания:

   1. Если на сервере Kerberos включено другое шифрование, тогда его нужно указать вместо rc4-hmac.
   2. Если это шифрование относится к стойким, то параметр allow_weak_crypto можно поставить в false.
   • имя_домена = имя_домена_в_верхнем_регистре
   • имя_домена_с_сточкой_впереди = имя_домена_в_верхнем_регистре
   • [domain_realm]
   • v2016.testinfomaximum.com = V2016.TESTINFOMAXIMUM.COM
   • .v2016.testinfomaximum.com = V2016.TESTINFOMAXIMUM.COM
   • kinit пользователь_под_которым_будем_входить_в_систему@домен_в_верхнем_регистре
   • kinit SuperUser@V2016.TESTINFOMAXIMUM.COM

   После ввода пароля создается билет Kerberos, по которому можно будет входить в систему. Билет имеет время жизни, которое можно установить в «krb5.conf» в секции [libdefaults] (например, ticket_lifetime = 24h) или при вызове kinit (добавив перед именем пользователя ключ -l от времени жизни). После истечения времени жизни билет необходимо пересоздавать командой kinit.

   При использовании стойких шифров сервер Kerberos (KDC) добавляет к паролю дополнительные символы («соль»). В качестве «соли» Kerberos использует имя домена, объединённое с именем сервера. Клиент Kerberos под Linux в качестве «соли» по умолчанию использует имя домена, объединённое с именем сотрудника, под которым необходимо залогиниться. Таким образом, при использовании стойкого шифрования не удаётся наладить связь между KDC и клиентом, так как пароли оказываются разными. Чтобы избежать данной проблемы, мы советуем задать в клиенте Kerberos шифрование rca4-hmac.

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

   Firefox

   Чтобы настроить браузер Firefox:

   1. На вкладке about:config найдите все параметры со словом negotiate.
   2. Установите в true:
      • network.negotiate-auth.allow-non-fqdn ;
      • network.negotiate-auth.allow-proxies ;
      • network.negotiate-auth.using-native-gsslib .
   3. В параметрах network.negotiate-auth.delegation-uris и network.negotiate-auth.trusted-uris введите имя компьютера, на котором запущен сервер, с точкой вначале. Например:
      • .base2016.v2016.testinfomaximum.com

   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).

   Источник