Linux kerberos authentication

Пример настройки Kerberos-аутентификации для Linux-версии сервера 1С:Предприятия 8

Статья предназначена для версий 1С:Предприятия, начиная с 8.1.12 и 8.2.8.

В данном примере описывается настройка Kerberos-аутентификации сервера 1С:Предприятия 8.1 для некоторой базовой системы, состоящей из трех компьютеров: контроллера домена, центрального сервера кластера 1С:Предприятия и рабочей станции.

Настройка сервера 1С:Предприятия версии 8.2 выполняется аналогично с учетом следующего:

• Вместо usr1cv81 следует использовать usr1cv82
• Вместо grp1cv81 — grp1cv82
• Вместо /opt/1C/v8.1 — /opt/1C/v8.2

Описание базовой системы

В базовой системе присутствуют следующие компьютеры:

Настройка контроллера домена

В нашем примере мы полагаем, что контроллер домена Active Directory настроен и работает. Исходя из этого, для настройки Kerberos-аутентификации нужно выполнить следующие шаги:

В командной строке запустим утилиту ktpass. В нашем примере командная строка должна выглядеть следующим образом:

Если алгоритм RC4-HMAC не поддерживается, командная строка должна выглядеть так:

В результате будет создан файл usr1cv81.keytab в текущей директории (в нашем случае — это корень диска C:), а c пользователем usr1cv8 будет ассоциировано имя участника службы usr1cv81/srv1c.krb.local.

Обратите внимание на различие между именем usr1cv81 и usr1cv8. В нашем примере usr1cv81/srv1c.krb.local@KRB.LOCAL — это стандартное имя службы. Оно включает в себя имя локального пользователя, от имени которого на центральном сервере кластера запускается сервер 1С:Предприятия (usr1cv81). А usr1cv8, указываемое в параметре mapuser, — это имя доменного пользователя, которое мы создали в пункте 2.

В параметре pass передается пароль учетной записи usr1cv8 — pass1cv8.

В параметре out указывается имя файла с ключом. В нашем случае это usr1cv81.keytab.

Настройка центрального сервера кластера 1С:Предприятия

В нашем примере мы полагаем, что кластер серверов 1С:Предприятия уже установлен и работает на центральном сервере кластера.

Прежде всего следует указать DNS-сервер для центрального сервера кластера. Это должен быть DNS контроллер домена. Процесс настройки зависит от конкретного дистрибутива Linux, в нашем случае отредактируем «вручную» файл /etc/resolv.conf, указав в нем IP адрес контроллера домена. В результате файл должен содержать следующие строки:

Теперь проверим работу DNS. Для этого выполним команду ping:

Для компьютеров, участвующих в процессе аутентификации, не допускается большого расхождения системных часов, так как аутентификационные пакеты (тикеты) имеют ограниченное время действия. Соответственно, нужно синхронизировать время центрального сервера кластера с контроллером домена. Используем для этого команду ntpdate:

Теперь настроим Kerberos. Для этого отредактируем файл /etc/krb5.conf. При этом, нам понадобится NETBIOS-имя контроллера домена. Оно, как правило, представляет собой имя домена в верхнем регистре. Поэтому в нашем случае NETBIOS-имя будет KRB.LOCAL.

В результате файл /etc/krb5.conf должен выглядеть следующим образом:

Если алгоритм RC4-HMAC не поддерживается, то значения параметров default_tkt_enctypes и default_tgs_enctypes должны быть следующими:

Теперь проверим работу системы аутентификации. Для этого выполним команду kinit , где имя — это имя произвольного пользователя, зарегистрированного в домене krb.local. В следующем примере это имя user. Далее введем пароль этого пользователя и нажмем Enter. Если после этого программа не выдаст никаких сообщений — значит все хорошо.

Убедиться в этом можно с помощью команды klist. Как видно на рисунке, мы получили от KDC (Key Distribution Center — центр распределения ключей. Эту функцию выполняет контроллер домена) так называемый ticket-granting ticket. После этого следует с помощью команды kdestroy очистить локальный кэш тикетов, чтобы вернуться в исходное состояние.

Далее, любым способом следует передать файл с секретным ключом usr1cv81.keytab, полученный во время настройки контроллера домена, на центральный сервер кластера 1С:Предприятия. Этот файл следует скопировать в директорию, где установлен сервер 1С:Предприятия (по умолчанию это /opt/1C/v8.1/i386), и установить права и владельца файла, как показано ниже:

При желании файл можно разместить в любом другом месте, нужно только изменить переменную SRV1CV8_KEYTAB в конфигурационном файле, чтобы она указывала на новое местоположение файла с секретным ключом.

После этого, с помощью команды klist проверяем, все ли мы сделали правильно. Для этого выполним команду:

В нашем случае результат выполнения команды должен выглядеть следующим образом:

Если алгоритм RC4-HMAC не поддерживается, результат выполнения команды будет выглядеть следующим образом:

Мы видим, что файл с секретным ключом содержит именно то, что нам нужно (в колонке Principal указано то самое имя службы, которое мы задавали при создании файла с секретным ключом (п. 3), и правильный алгоритм шифрования (ArcFour with HMAC/md5 для RC4-HMAC или DES cbc mode with RSA-MD5 для DES).

Далее проверим возможность работы Kerberos без пароля с использованием секретного ключа. С помощью команды kinit укажем, что надо использовать аутентификационную информацию из файла (в нашем случае /opt/1C/v8.1/i386/usr1cv81.keytab) и прочитать оттуда ключ для сервиса usr1cv81/srv1c.krb.local@KRB.LOCAL. В результате программа kinit должна отработать без каких-либо сообщений, не спрашивать никаких паролей и вернуть управление обратно в командную строку:

Теперь посмотрим на результаты работы с помощью команды klist. В случае успеха мы увидим примерно следующее:

Если что-то настроено не так, то эта команда выведет следующее:

Если проверка работоспособности прошла успешно, это значит, что с данного момента сервер кластера 1С:Предприятия способен обрабатывать запросы на аутентификацию. При этом перезапуск сервера не требуется, кроме того случая, когда в конфигурационном файле было изменено место расположения файла с секретным ключом.

RootUsers

Guides, tutorials, reviews and news for System Administrators.

How To Configure Linux To Authenticate Using Kerberos

Kerberos is an authentication protocol that can provide secure network login or SSO for various services over a non-secure network. Kerberos works with the concept of tickets which are encrypted and can help reduce the amount of times passwords need to be sent over the network.

These tickets are issued throughout the Kerberos realm by a centralised key distribution center (KDC). Here we will cover how to setup a KDC and obtain a Kerberos ticket from a client system in CentOS Linux.

Note that for the RHCE exam you will not have to actually create the KDC, you will only need to setup a client to connect to an existing KDC. We have covered both parts so that you can create your own KDC in order have something to connect to while learning.

Studying for your RHCE certification? Checkout our RHCE video course over at Udemy which is 20% off when you use the code ROOTUSER.

Example Environment

Here is a list of our servers that we will be testing with, both are running CentOS 7.

• Kerberos Server (KDC): 192.168.1.13 – This Linux server will act as our KDC and serve out Kerberos tickets.
• Kerberos Client: 192.168.1.14 – This Linux client will request Kerberos tickets from the KDC.

Prerequisites

In order for Kerberos to function correctly, the following must first be configured on both servers.

• NTP: Time synchronization is required, if the time difference is more than 5 minutes authentication will fail. See our guide on synchronizing time with NTP for further details regarding setting this up.
• DNS: The FQDN’s should ideally resolve in a proper environment, however here we do get by with only using IP addresses. Modifying /etc/hosts would also work for testing, however using DNS properly is recommended.

Setup a KDC

As mentioned previously, setting up a KDC is not an RHCE objective, however you will need one in order to perform other objectives that use Kerberos, such as setting up NFS to use Kerberos.

The following commands are run on our KDC server.

Once these packages have been installed the /etc/krb5.conf file needs to be modified. By default a few things are commented out that need to be configured. Below is a copy of the default configuration.

Remove the comments from default_realm, and the entire [realms] section and set these appropriately for your environment, for this example I’ll stick with using example.com, with my kdc being kdc.example.com

Next edit the /var/kerberos/krb5kdc/kdc.conf file and again replace the instances of example.com to your particular domain, again I will be leaving this as default as I am using the example.com domain here for testing.

Create a Kerberos Database

Now we’re ready to create a Kerberos database with the kdb5_util command as shown below. You will be prompted to enter a password which will act as the master key, this is used by the KDC to encrypt the database so it is very important to store this securely.

This command took about a minute to complete as it took a while to load random data, you can move your mouse around in the GUI or press keys to speed up the process. The -s flag is specified so that a stash file is created, allowing for the Kerberos service to automatically start up without requiring the master key to be provided manually.

Service Management

Speaking of starting automatically, we want to enable and start both kadmin and krb5kdc so that our Kerberos KDC services will be automatically available after system reboot.

For further information on basic service management with systemctl, see our guide here.

Firewall Configuration

In order for other systems to communicate with the services of the KDC, correct firewall rules need to be set. This can be done as shown below with firewalld.

The predefined Kerberos service allows both TCP/UDP port 88 traffic in. We can check and confirm that the krb5kdc service is indeed listening on these ports for connections.

We have only allowed Kerberos through, note that traffic to kadmin requires TCP 749 so if you want to access that remotely you’ll need to consider opening that too, however for our purposes and to increase security we’ll leave that as local access only.

Kerberos Administration

The KDC can be administered by running the kadmin.local command. To view available commands within the kadmin.local context, simply run ‘?’. From this helpful information we can see that ‘addprinc’ can be used to add a Kerberos principal, which we’ll do for our ‘user’ account.

Our KDC is now ready to accept client connections and provide tickets to the ‘user’ principal.

Setup The Client

Now it’s time to configure our client system to use the KDC. There are a few different methods that you can use to complete this, personally I find using the GUI to actually be very quick and easy here. In order to use the GUI, first install the authconfig-gtk package.

Once complete simply run ‘authconfig-gtk’ from a terminal window within the GUI. This will open up the Authentication Configuration window. From the Identity & Authentication tab, select LDAP from the User Account Configuration drop down in order to get access to the Authentication Configuration which is where we will select Kerberos password and provide our realm and KDC information.

In this example, as shown previously the realm on the KDC is EXAMPLE.COM, the IP address of our KDC is 192.168.1.13 as I do not have DNS setup I am not able to use the FQDN, and the admin server is also the same as the KDC as this is where kadmin is running.

Once you have defined your realm and KDC, click the Apply button.

If you’re not a fan of the GUI or simply don’t have one installed, you can also use the text user interface instead by running ‘authconfig-tui’. Both of these will configure our /etc/sssd/sssd.conf file automatically, however you can manually edit this if you know what you’re doing. Personally I’ve always had a terrible experience when trying to set sssd.conf manually, so I definitely recommend using either of these authconfig tools.

Create the user

On our KDC we have created a principal for ‘user’, we’ll now create a local user account on the client system. This is not technically required, we should be able to kinit from another user however for consistency we’ll use this account.

Now we’re ready to try and get a ticket from the KDC, first we become the new user and run the ‘kinit’ command which is used to obtain and cache our Kerberos ticket.

From ‘klist’ we can see that we have been issued with a ticket which is valid for 24 hours.

Summary

We have successfully configured a key distribution center (KDC) which is capable of providing Kerberos tickets to clients.

This post is part of our Red Hat Certified Engineer (RHCE) exam study guide series. For more RHCE related posts and information check out our full RHCE study guide.

Information Security Squad

stay tune stay secure

Как установить Kerberos KDC Server и клиент на Ubuntu 18.04

Здесь и сейчас рассматривается постепенное руководство по настройке Kerberos Server (KDC) и Kerberos Enabled Client, а затем тестирование установки путем получения тикета Kerberos с сервера KDC.

В этом уроке вы узнаете:

• Что такое Kerberos и как он работает
• Настройте сервер Kerberos (KDC)
• Настройте клиента
• Проверьте аутентификацию Kerberos
• Создание Keytab

Что такое Kerberos и как он работает

Kerberos — это протокол сетевой аутентификации.

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

Клиент аутентифицирует себя на сервере аутентификации (AS), который перенаправляет имя пользователя в центр распространения ключей (KDC).

KDC выдает тикет (билет) для выдачи (TGT), который имеет метку времени и шифрует его с использованием секретного ключа службы выдачи билетов (TGS), и возвращает зашифрованный результат на рабочую станцию ​​пользователя.

Это делается нечасто, обычно при входе пользователя в систему; TGT истекает в какой-то момент, хотя он может быть прозрачно обновлен менеджером сеанса пользователя, когда пользователи вошли в систему.

Когда клиенту необходимо связаться с другим узлом («приципал» на языке Kerberos) какой-то службе на этом узле, клиент отправляет TGT в TGS, который обычно использует тот же хост, что и KDC.

Служба должна быть зарегистрирована в TGT с именем участника службы (SPN).

Клиент использует SPN для запроса доступа к этой услуге.

После проверки того, что TGT действителен и что пользователю разрешен доступ к запрошенной услуге, TGS выдает клиенту ключи билета и сеанса.

Затем клиент отправляет билет на сервисный сервер (SS) вместе со своим сервисным запросом.

Настройте сервер Kerberos (KDC)

Синхронизация времени и DNS играет важную роль для правильной работы KDC.

Если разница во времени превышает 5 минут, аутентификация не удастся.

Полные доменные имена в идеале должны разрешаться в правильной среде, здесь мы можем изменить /etc/hosts, но рекомендуется правильно использовать DNS.

Выполните приведенную ниже команду, чтобы установить сервер администрирования Kerberos и KDE (центр распространения ключей):

Система спросит следующие три вещи по одному:

• Kerberos Realm. (здесь я использовал UBUNTUBOX.COM)
• Имя хоста сервера Kerberos — kdc.ubuntubox.com
• Имя хоста админа (смена пароля) сервера для Kerberos Realm UBUNTUBOX.COM — kdc.ubuntubox.com

Теперь выполните приведенную ниже команду для настройки realm.

Система попросит ввести пароль для создания базы данных и после этого запустит процессы администрирования Kerberos KDC krb5kdc и Kerberos kadmind.

Откройте файл /etc/krb5kdc/kadm5.acl в любом текстовом редакторе и раскомментируйте последнюю строку, чтобы файл выглядел следующим образом.

Теперь процесс установки сервера Kerberos завершен успешно.

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

Выполните приведенную ниже команду для установки и настройки клиента Kerberos.

Опять же, он спросит 3 вещи, один за другим, как и в настройке сервера KDC.

• Kerberos Realm — UBUNTUBOX.COM
• Имя хоста для сервера KDC — kdc.ubuntubox.com
• Имя хоста сервера администратора — kdc.ubuntubox.com

Проверьте аутентификацию Kerberos

Принципал Kebs — это уникальная составляющая, которой Kerberos может назначать билеты, поэтому мы создадим принципал в KDC Server, как показано ниже.

Чтобы удалить участника из KDC, выполните следующую команду.

Теперь для аутентификации в Kerberos и получения билета с сервера KDC выполните следующую команду на клиентском узле.

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

Чтобы проверить детали принципала, выполните приведенную ниже команду в KDC Server.

Создание Keytab

keytab — это файл, содержащий пары принципалов Kerberos и зашифрованные ключи (которые получены из пароля Kerberos).

Вы можете использовать файл keytab для аутентификации на различных удаленных системах с использованием Kerberos без ввода пароля.

Однако, когда вы измените свой пароль Kerberos, вам нужно будет воссоздать все ваши keytabs.

Заключение

Аутентификация имеет решающее значение для безопасности компьютерных систем, традиционные методы аутентификации не подходят для использования.

Система аутентификации Kerberos хорошо подходит для аутентификации пользователей в таких средах.

Создание keytab-файла, содержащего несколько разных Kerberos Principal

Разные службы и приложения, работающие в Linux и использующие аутентификацию Kerberos, например в связке с контроллерами домена Active Directory (AD), используют для механизмов этой самой аутентификации специальный keytab-файл, который содержит хеши пароля доменной учётной записи пользователя, с которым ассоциирована та или иная служба в Linux-системе (как с Kerberos Principal). И вполне типичной и распространённой практикой является создание отдельного keytab-файла для каждого принципала Kerberos. То есть, как правило, прослеживается такая логика: отдельная учётная запись служебного пользователя в AD, для которого зарегистрировано конкретное имя службы ServicePrincipalName (SPN) => отдельный keytab-файл, сопоставимый с записью SPN в AD.

А теперь представьте ситуацию, когда, например, на веб-сервере Apache настроена и успешно работает Kerberos-аутентификация с помощью keytab-файла, содержащего имя принципала Kerberos, равное HTTP/web.holding.com@HOLDING.COM , сопоставимое с SPN HTTP/web.holding.com в свойствах некоторой учётной записи служебного пользователя в домене AD (примеры такой настройки мы рассматривали ранее: здесь , здесь и здесь ). В таком случае аутентификация Kerberos будет успешно работать только при обращении к веб-сайту Apache по имени http://web.holding.com . Однако, в один прекрасный момент возникает необходимость использовать другое имя FQDN сервера в URL, так как в Apache создан дополнительный виртуальный хост, а в DNS создана A-запись, имеющая имя этого виртуального хоста и ведущая к IP адресу этого же веб-сервера. Например, пусть это будет имя web2.holding.com .
В этом случае, если мы попытаемся использовать старый keytab-файл файл для настройки конфигурации нового виртуального хоста Apache, то при попытке обращения к URL http://web2.holding.com , клиенты получат от веб-сервера ошибку 500 Internal Server Error .

В логе при этом будут регистрироваться события типа:

И это справедливо, ведь имеющийся у нас на веб-сервер keytab-файл содержит записи только для принципала HTTP/web.holding.com , и никакого HTTP/web2.holding.com там нет и в помине.

Как же быть в таком случае? Можно по классической схеме сделать в домене AD новую учётную запись служебного пользователя, зарегистрировать для неё SPN HTTP/web2.holding.com и сгенерировать отдельный keytab-файл.
С точки зрения информационной безопасности — это более правильный подход, то есть отдельное веб-приложение = отдельный служебный пользователь в домене.
Но как быть, если на сервере много небольших однотипных веб-сайтов, которым нужны разные имена, а плодить в домене AD под каждый такой сайт учётную запись не очень хочется.
В этом случае нам на помощь придут небольшие советы, которые я подсмотрел в статье Ricky’s Hodgepodge — Two Tips about Kerberos .

Итак, имеем задачу — получить комплексный keytab-файл, содержащий в себе некоторое множество разных имён Kerberos Principal, сопряжённых с записями ServicePrincipalName в свойствах одной конкретной учётной записи служебного пользователя в AD. Приступим.

Подготовка учётной записи пользователя в AD

Для начала, необходимо обеспечить наличие всех нужных SPN-записей в свойствах учётной записи служебного пользователя в домене AD. В нашем примере это будет пользователь DOMweb-srv-user , для которого ранее на нашем веб-сервере Apache уже была настроена аутентификация Kerberos по имени сайта web.holding.com . Посмотрим текущее состояние SPN-записей для этого пользователя на Windows-системе (для просмотра SPN достаточно прав рядового пользователя домена):

Зарегистрируем для пользователя новую SPN-запись, которая будут содержать имя нужных нам дополнительной службы, например HTTP/web2.holding.com , следующим образом (для изменения SPN требуются права администратора домена):

Теперь можно переходить с манипуляциями с keytab-файлом.

Генерация и обновление keytab-файла на контроллере домена AD

Для начала, напомню о том, как мы создавали исходный keytab-файл, уже имеющийся на нашем веб-сервере Apache.
Для настроенной учетной записи был сгенерирован keytab-файл на контроллере домена AD (в нашем случае на базе Windows Server 2012 R2) с помощью утилиты ktpass в следующем порядке:

В нашем примере команда выглядела так:

В результате выполнения команды мы увидим исчерпывающую информацию о том, что попало в keytab-файл:

При выполнении утилиты ktpass в указанном порядке значение номера Key Version Number (KVNO) будет обновлено в свойствах учётной записи в AD (атрибут msDS-KeyVersionNumber), с последующей записью номера в keytab-файл.

А все keytab-файлы, которые генерировались ранее для этой учётной записи (где номер KVNO меньше текущего) станут недействительными.

Здесь хочу немного отвлечься и сделать небольшую ремарку о том, как посмотреть содержимое keytab-файла на Windows. Стандартных инструментов в составе Windows для этой задачи я найти не смог (возможно плохо искал). Однако если в вашей Windows-системе установлен стандартный клиент Java (JRE), то в его составе есть утилита klist.exe, которая работает с опциями, схожими с теми, что используются в утилите klist под Linux. Например, чтобы получить полную информацию о содержимом нашего keytab-файла нужно будет вызвать эту утилиту следующим образом:

Теперь мы подошли к самому интересному. Второе и последующие имена нужные нам имена принципалов Kerberos добавляем в уже имеющийся keytab-файл с применением дополнительных параметров ( —in, — setupn, —setpass ) утилиты ktpass, которые позволят сохранить текущий номер KVNO в файле и AD:

Из вывода утилиты будет понятно, что номер keytab-файла, и KVNO остались неизменными:

Ещё раз заглянем для убедительности в новый keytab-файл web_refreshed.keytab с помощью утилиты klist:

И действительно, мы видим, что в файле появилось 5 новых записей, а номер KVNO при этом у всех записей остался прежним (в нашем примере это 4 ). Заменим keytab-файл на веб-сервере Apache и убедимся в том, что теперь с Kerberos аутентификацией успешно работает и основное имя и альтернативное. Таким образом мы можем добавить в keytab-файл столько имён принципалов сколько необходимо, при условии, что все эти имена в виде SPN-записей есть в свойствах учётной записи соответствующего доменного пользователя в атрибуте servicePrincipalName. При проверках с Windows-клиентов перед проверкой не забываем очищать локальный клиентский кэш билетов Kerberos командой (выполнять в контексте того пользователя, от имени которого делается проверка доступности веб-сайтов на Windows-системе):

Обновление keytab-файла на Linux-сервере

Есть ещё одна хитрость, которая позволит нам менять содержимое keytab-файла непосредственно на Linux-сервере без манипуляций по обновлению файла на контроллере домена и копированию его туда-сюда по сети. Если нам известен пароль от учётной записи сервисного пользователя (а он нам конечно известен:)) и текущий номер KVNO (подсмотреть его можно как в keytab-файле, так и в AD), то с помощью утилиты ktutil, мы сможем добавить в существующий keytab-файл нужную нам дополнительную запись с новым именем принципала Kerberos. Для этого войдём в режим интерактивного взаимодействия утилиты ktutil:

Выполним команду list, которая покажет, какими данными оперирует утилита (пока там пусто):

Выполним команду чтения содержимого из нашего keytab-файла (read_kt), который мы хотим использовать, как исходный, затем команду list:

Следующей командой add_entry добавим в массив данных, с которыми оперирует утилита, нужную нам дополнительную запись принципала Kerberos. При этом нужно будет указать имя принципала Kerberos (ключ -p), текущий номер KVNO (ключ -k) и тип шифрования (ключ -e). Правильный формат типов шифрования можно посмотреть в самом keytab-файле утилитой klist с ключом -e, как было показано ранее. После ввода команды будет запрошен пароль пользователя, с которым связан данный принципал Kerberos (у нас это DOMweb-srv-user ).

Таким образом мы можем добавить аналогичные записи для всех необходимых типов шифрования:

По завершению добавления записей командой write_kt сохраняем получившийся массив данных в новый keytab-файл и выходим из интерактивного режима работы утилиты:

Разумеется, для того, чтобы обновлённый на Linux-системе keytab-файл работал, нужно обеспечить наличие соответствующей дополнительной SPN-записей в свойствах учётной записи в домене AD. Осталось подключить обновлённый keytab-файл к конфигурации Apache и проверить результат.

В качестве заключения хочется напомнить о паре простых правил безопасности, про которые всегда стоит помнить при работе с keytab-файлами:

• Не оставлять keytab-файлы во всяких временных каталогах после операций над этими файлами и всевозможных тестов. Keytab-файл должен лежать только в том месте, где он реально используется.
• Жёстко ограничивать на Linux-системе доступ к keytab-файлу, оставляя право на чтение лишь тем Linux-пользователям, от имени которых работает служба использующая для Kerberos-аутентификации данный keytab-файл.

Дополнительные источники информации:

Linuxoid

OpenSource forever

Установка Kerberos в Ubuntu

Для администраторов небольших сетей проблем в организации доступа пользователей к немногочисленным сетевым ресурсам, в общем, то и нет. Но как только сеть начинает расти, требуется уже синхронизировать учетные записи пользователей на всех сервисах и управлении доступом к различным сервисам. Здесь уже требуется централизованный подход, к решению этой проблемы. Сейчас разберем, как установить и настроить сетевую систему аутентификации пользователей Kerberos на примере Linux Ubuntu.

История Kerberos

В 1983 году две компании DEC, IBM и MIT (Massachusetts Institute of Technology) начали работу над проектом Athena. Суть работ продолжавшихся 8 лет, заключалась в создании единой вычислительной среды, количество пользователей и сервисов в которой можно было бы легко расширить вплоть до 10 тысяч. Пользователь в такой среде мог бы спокойно выходить в сеть с любого компьютера, получать доступ к требуемым файлам и приложениям, не замечая различий в работе и интерфейсе. Было разработано множество передовых на тот момент технологий, из которых сегодня самыми известными являются графическая подсистема X-Window, которая применяется во всех Unix и Kerberos. Разработкой протокола защиты сетевых сервисов используемых в Athena занимались в MIT, в недрах которой и использовались версии 1-3. В 1987 году общественности был представлен протокол Kerberos 4, который имел ряд недостатков и ограничений. Если кто забыл греческую мифологию, так называли трехгодового пса охранявшего выход из царства мертвых Аида (он всего 5 раз не справился со своими обязанностями). В 1993 вышла пятая версия протокола, используемая и по сей день, хотя современные реализации могут работать и с 4 версией. В пятой версии использовалась весьма стойкая по тем временам криптография (DES с 56-битным ключом), и по американским законам попадала под категорию военных технологий, экспорт которых за территорию США запрещен. Поэтому была разработана версия MIT Bones в основу, которой была положена версия 4 и убрана вся сильная криптография. Экспорту Bones уже ни что не препятствовало, но такая “функциональность” никого естественно не устраивала. В 1997 году группа программистов KTH-KRB из Стокгольмского Королевского университета (Royal Institute of Technology in Sweden) выпустила вариант eBones, в котором недостающее было восстановлено. Но в современном мире больше известна реализация Kerberos 5 от KTH-KRB получившая название Heimdal (существо в скандинавской мифологии защищавшее богов, кстати, это еще и город в Trondheim, местность, исхоженная в Wolfenshtein вдоль и поперек). Сейчас версия от MIT распространяется уже безо всяких ограничений.

Принцип работы Kerberos

Кратко опишу принцип работы системы, чтобы было понятно, чем мы будем заниматься. Протокол описан в RFC 1510 (tools.ietf.org/html/rfc1510) и RFC 4120 (tools.ietf.org/html/rfc4120) . В настоящее время клиентские компоненты для работы с Kerberos имеются в большинстве современных операционных систем. Для подтверждения подлинности используется доверенная третья сторона, которая владеет секретными ключами всех субъектов и участвующая в по парной проверке подлинности. Когда клиент пытается получить доступ к ресурсу, он посылает запрос, содержащий сведения о себе и о запрашиваемой услуге. Весь процесс происходит в три этапа, в ответ контролер Kerberos (Key Distribution Center, KDC) выдает билет, удостоверяющий пользователя TGT (ticket granting ticket). Каждый билет имеет ограниченный срок жизни, что снижает интерес к его перехвату. Поэтому одним из требований к системе Kerberos синхронизация времени между всеми участниками. При последующем обращении к другим сервисам вводить пароль уже не нужно. Каждый участник системы Kerberos как служба, так и пользователь именуются принципал (principial). Каждый принципал имеет имя и пароль. Типичное имя принципала выглядит так root/admin@GRINDER.COM, что означает имя (primary name) root, характеристику (instance), который принадлежит сектору GRINDER.COM. Такой подход позволяет различать несколько служб работающих на одном компьютере, и среди однотипных служб выбирать нужную. Вся схема работы от пользователя скрыта. При обращении к ресурсу, по прежнему вводит только свой логин и пароль. Для удобства компьютеры могут быть объединены в сектора (realms), кстати в некоторой литературе realms переводят как домен. Все принципиалы сохраняются в базе данных сервера Kerberos. В сети может быть использовано несколько KDC, один из которых является основным (master). На master KDC устанавливается административный сервер kadmind управляющий политиками. Все конечно не так просто, и на порядок или два сложнее, но этого достаточно для понимания, того чего мы будем настраивать дальше.

Устанавливаем NTP

Прежде чем установить Kerberos, необходимо настроить службу синхронизации времени (NTP — Network Time Protocol), без которой не возможна нормальная работа Kerberos.

$ sudo apt-get install ntp

Все настройки производятся в одном единственном файле.

$ sudo mcedit /etc/ntp.conf

statistics loopstats peerstats clockstats

filegen loopstats file loopstats type day enable

filegen peerstats file peerstats type day enable

filegen clockstats file clockstats type day enable

# серверы с которыми будем синхронизировать время

# используем локальное время в случае неудачи

fudge 127.127.1.0 stratum 13

restrict default kod notrap nomodify nopeer noquery

# локальные пользователи могут запрашивать время

restrict 127.0.0.1 nomodify

# прослушивание времени в сети

$ sudo /etc/init.d/ntp restart

* Stopping NTP server ntpd [ OK ]

* Starting NTP server ntpd [ OK ]

Теперь синхронизируем время.

$ ntpq -p -c as && echo && ntptrace

Устанавливаем Kerberos

В репозитариях пакетов дистрибутивов Linux уже все необходимое есть. Хотя при желании можно установить систему из исходных текстов. Дистрибутив Heimdal найдете на FTP сервере Стокгольмского университета ftp://ftp.pdc.kth.se/pub/heimdal/src, последняя версия на момент написания этих строк 1.0.2 от декабря 2007 года, там же можно найти готовые пакеты для некоторых дистрибутивов. Версия от MIT лежит по адресу http://web.mit.edu/kerberos/.

Команда “sudo apt-cache search kerberos” в Ubuntu выдаст большой список пакетов в котором можно найти решения от MIT и Hemdail.

Основные настройки их практически идентичны, эти системы также понимают билеты выданные друг другом, хотя есть и проблемы совместимости, но о них говорить не будем. Для примера, выберем версию от MIT.

$ sudo apt-get install krb5-admin-server krb5-kdc krb5-config krb5-user krb5-clients

Основные настройки Kerberos производятся в файле /etc/krb5.conf. Набивать его полностью не надо, можно использовать готовый шаблон:

$ sudo cp /usr/share/kerberos-configs/krb5.conf.template /etc/krb5.conf

Теперь открываем файл и начинаем подгонять под свои условия.

$ sudo mcedit /etc/krb5.conf

# kdc и admin сервер для GRINDER.COM

# сообщаем kdc, какие узлы входят в облать GRINDER.COM

# если область и домен совпадает эту секцию можно опустить

# отключаем совместимость с 4 версией Kerberos

Этот файл используется как сервером, так и приложениями, поэтому его можно практически без изменений распространить на остальные системы входящие в один realms (если их много можно использовать службу DNS). Все настройки KDC производятся в /etc/krb5kdc/kdc.conf. В принципе большую часть параметров можно оставить как есть, заменив только realms:

$ sudo mcedit /etc/krb5kdc/kdc.conf

max_life = 10h 0m 0s

max_renewable_life = 7d 0h 0m 0s

supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3

Перезапускаем KDC и сервер администрирования.

$ sudo /etc/init.d/krb5-kdc restart

$ sudo /etc/init.d/krb5-admin-server restart

Создаем принципиалы и ключи

Для начала следует создать новую базу данных и наполнить ее принципиалами. Здесь возможно несколько вариантов, один из них вызов kadmin с ключом –l. Можно использовать специальные утилиты.

$ sudo kdb5_util create -s

Loading random data

Initializing database ‘/var/lib/krb5kdc/principal’ for realm ‘GRINDER.COM’,

master key name ‘K/M@GRINDER.COM’

You will be prompted for the database Master Password.

It is important that you NOT FORGET this password.

Enter KDC database master key:

Re-enter KDC database master key to verify:

Новая база создана. Утилита попросит ввести пароль, не забудьте его. Создадим принципиал, который потребуется для административных целей:

$ sudo kadmin.local -q «addprinc admin/admin»

Authenticating as principal root/admin@GRINDER.COM with password.

Enter password for principal «admin/admin@GRINDER.COM»:

Re-enter password for principal «admin/admin@GRINDER.COM»:

Principal «admin/admin@GRINDER.COM» created.

Authenticating as principal root/admin@GRINDER.COM with password.

Enter password for principal «admin/admin@GRINDER.COM»:

Re-enter password for principal «admin/admin@GRINDER.COM»:

Principal «admin/admin@GRINDER.COM» created.

Для добавления принципиалов для KDC, admin сервера, своего компьютера , пользователей воспользуемся интерактивным режимом работы:

$ sudo kadmin.local -p admin/admin

Authenticating as principal admin/admin with password.

# зарегистрировались использовав принципиал администратора

# создаем принципиал компьютера, так как компьютер не будет вводить пароль, используем случайный пароль

kadmin.local: addprinc -randkey host/grinder.com

Principal «host/grinder.com@GRINDER.COM» created.

kadmin.local: addprinc grinder

Enter password for principal «grinder@GRINDER.COM»:

Re-enter password for principal «grinder@GRINDER.COM»:

Principal «grinder@GRINDER.COM» created.

# добавим принципиал компьютера в файл keytab в котором хранятся собственные принципиалы

kadmin.local: ktadd host/grinder.com

Entry for principal host/grinder.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.

Entry for principal host/grinder.com with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.

И так далее. Чтобы иметь возможность заходить удаленно на сервер с использованием Kerberos необхдимо создать файл .k5login (с точкой) в который вписать имя принципиал.

Настраиваем рабочую станцию

В состав обоих вариантов Kerberos входят утилиты, предназначенные для замены стандартных системых утилит вроде /bin/login. Настройки керберизации в разных дистрибутивах будут отличаться. Хотя бы потому что в большинтсве систем используется /sbin/init и достаточно в /etc/inittab заменить /bin/login на керберизированый /usr/bin/login, после чего при регистрации пользователя сначала будет идти обращение к Kerberos, а в случае неудаче к локальной базе /etc/passwd. В Ubuntu с 6.10 вместо /sbin/init используется новая система загрузки upstart, потому здесь немножечко все по-другому.

Для настройки нам понадобятся пакеты krb5-clients, krb5-user и libpam-krb5. Файл /etc/krb5.conf берем с KDC. Затем приступаем к настройкам PAM. В каталоге /etc/pam.d необходимо создать файл common-krb5 такого содержания:

auth sufficient /lib/security/pam_krb5.so use_first_pass

В самом конце файла /etc/pam.d/login есть строки описывающие методы аутентифкации.

# Standard Un*x account and session

Перед этими строчками добавляем еще одну:

И если регистрация в системе происходим в графическом менеджере: GDM в Ubuntu, KDM в KUbuntu, в файлах gdm и/или kdm поступаем аналогично. Кстати в репозитарии имеется пакет kredentials, после установки, которого в панели задач появится аплет с помощью которого можно управлять личными билетами. Установить его можно командой.

$ sudo apt-get install kredentials

После чего ярлык для запуска найдете в меню K.

Нам удалось создать систему, которая будет надежно аутентифицировать пользователей. Регистрация пользователей и сервисов управляется с одного места. Пользователь успешно зарегистрировшийся в системе сможет без проблем попасть на любой разрешенный сетевой ресурс. Настройка поддержки Kerberos в различных сервисах это предмет отдельного разговора.

3 комментария

хороший материал.
смутил один момент:
server 127.127.1.0
imho, новички могут не понять, что это за адрес такой.

Это адрес локального источника времени — local clock