Kinit linux что это

Обновлено: 03.07.2024

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

Аутентификация через Kerberos является фактическим стандартом аутентификации доменных пользователей, и применяется в Windows Active Directiry, Samba AD DC, FreeI PA, Astra Linux Directory (ALD) .

В Linux-системах существуют две основные реализаций Kerberos - MIT и Heimdal. В ОС Astra Linux (и далее в примерах этой статьи) используется MIT Kerberos.

При описании работы Kerberos применяются некоторые специфические термины:

Область (realm) - о бласть (области), обслуживаемые сервисом. П римерно соответствует термину "домен";
Принципал - учетная запись Kerberos, с соответствующим набором прав. Примерно соответствет термину "пользователь". Но, при этом, пользователь может получать разные наборы прав от Керберос (разные принципалы).

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

Далее в примере используются

Имена и доступность компьютеров

Сервис Kerberos следует устанавливать в сети, в которой уже настроена служба DNS. Каждому серверу, входящему в область Kerberos, должно быть присвоено Полное Квалифицированное Доменное Имя (Fully Qualified Domain Name, FQDN).
Настроенный DNS-сервис должен обеспечивать прямое и обратное (реверсивное) разрешение FQDN (для отключения реверсивного разрешения можно в файле конфигурации клиента krb5.conf установить переменной rdns начение false)

Проверить настройку прямого и обратного разрешения имён можно командами:

nslookup <FQDN_имя_сервера>
nslookup <IP_адрес_сервера>

(для использования команды nslookup следует установить пакет dnsutils: apt install dnsutils)

Для проверки доступности компьютеров можно использовать команду ping:

Синхронизация времени

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

Пакеты сервиса Kerberos входят в стандартные дистрибутивы Astra Linux, и могут быть установлены с помощью графического менеджера пакетов,
или из командной строки командой

При установке выдаётся предупреждение о том, что пакет не настроен, которое пока можно проигнорировать.

После установки сервис автоматически не запускается, и должен быть настроен для запуска.

При установке пакета будет создан файл конфигурации сервиса /etc/krb5kdc/kdc.conf со стандартным содержимым, в котором автоматически будет указано имя области Kerberos, полученное из FQDN сервера, на котором выполняется установка:

Kerberos использует для контроля доступа к администрированию сервиса Списки Управления Доступом (Access Control List, ACL) .
По умолчанию, список располагается в файле /etc/krb5kdc/kadm5.acl.

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

И создадим новую область Kerberos командой:

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

Далее, для выполнения задач по администрированию сервиса Kerberos нужно создать принципала с правами администратора.
Для этого используем инструмент командной строки kadmin.local, предназначенный для администрировния Kerberos на локальном компьютере.

При использовании инструмента kadmin.local подразумевается, что этот инструмент вызывается с защищенного сервера Kerberos,
поэтому инструмент не требует логинов и паролей, и автоматически получает все полномочия для администрирования сервиса Kerberos.

Инструмент вызывается из командной строки командой

После вызова инструмента можно ввести симовл "вопросительный знак", в ответ на это будет выдана подсказка по списку команд.

Добавим нового принципала admin/admin командой addprinc:

После ввода команды будет запрошен пароль для создаваемого принципала.

Выход из инструмента kadmin.local осуществляется командой quit.

После создания принципала admin/admin его можно использовать для администрирования сервера Kerberos с удалённых компьютеров с помощью инструмента командной строки kadmin.
Этот инструмент аналогичен инстрменту kadmin.local, однако рассчитан на удалённое подключение, и требует авторизации пользователя через указание принципала и ввод пароля:

Для автоматического получения клиентами адреса сервера Kerberos можно использовать специальные настройки сервера DNS: служебные записи (SRV-записи).
Пример таких записей для службы Kerberos см. в статье про сервер DNS

Клиентский пакет Kerberos krb5-user входит в дистрибутивы Astra Linux, но по умолчанию не устанавливается. Пакет может быть установлен с помощью графического менеджера пакетов, или из командной строки командой

При установке пакета krb5-user, кроме самого пакета, автоматически будет установлен пакет krb5-config для настройки клиента

Если Kerberos предполагается использовать с контроллером домена Samba AD DC,
для настройки клиентов следует использовать копию конфигурационного файла /var/lib/samba/krb5.conf,
автоматически создаваемого при процедуре назначения Samba
Кроме того, в сети должны быть правильно настроены и работать службы DNS и DHCP.

Настройка клиента Kerberos выполняется командой

При этом команда

После завершения работы программы настройки результат настройки можно проверить получением принципала.
Команда kinit должна выполняться без ошибок:

Проверить содержимое полученного принципала можно командой

Для обеспечения возможности авторизации пользователей через Kerberos требуется дополнительно установить пакет libpam-krb5:

apt install libpam-krb5

После установки пакета необходимые модули авторизации будут автоматически добавлены в стек авторизации PAM.

В данной статье мы рассмотрим настройку сервера «1С:Предприятие» для использования Microsoft AD в качестве системы авторизации клиентов 1С. Статья представляет собой описание успешно внедрённого решения, за основу брались различные статьи из открытых источников, в частности официальная документация разработчика 1С.

Преамбула.
У нас имеется работающий на ОС Linux (CentOS7) сервер «1С:Предприятие». Сервер работает на хосте srv-app01, входящем в домен local.domain.name.

1. Настройка кластера сервера 1С:Предприятие

Настройка и управление кластером сервера «1С:Предприятие» происходит с компьютера с ОС Windows, так что для управления сервером нужно использовать традиционную оснастку mmc для Windows «Администрирование серверов 1С:Предприятие», которую следует установить из дистрибутива технологической платформы для Windows (ссылка).

Обязательно нужно настроить «Параметры рабочего сервера», как показано ниже:

Свойства кластера 'Критический объем памяти процессов', 'Режим распределения нагрузки' или свойства рабочего сервера 'Критический объем памяти процессов', 'Временно допустимый объем памяти процессов', 'Интервал превышения допустимого объема памяти процессов', 'Безопасный расход памяти за один вызов', 'Количество ИБ на процесс' содержат значения, отличные от значений по умолчанию.

Использование этих функций возможно только для лицензий на платформу уровня КОРП.

Это связано с тем, что «..начиная с версий платформы «1С:Предприятие» 8.3.12.1852, 8.3.13.1791 и 8.3.14.1592, вводятся ограничения на техническом уровне, не позволяющие использовать функциональность КОРП». Подробнее можно посмотреть здесь.

2. Настройка Kerberos-аутентификации

Для решения поставленной задачи настроим Kerberos-аутентификацию сервера «1С:Предприятие».

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

Имя сервера srv-app01 обязательно должно разрешаться DNS-сервером (если его ввели в домен, то соответствующая запись в DNS-сервере есть).

Создать в домене учетную запись пользователя, с которой будут ассоциироваться запросы авторизации к серверу 1С:Предприятие. Имя может быть произвольное. В нашем случае это будет пользователь usr1cv8x с паролем XxXxXx. В свойствах этой уч`тной записи на вкладке «Учётная запись» в секции «Параметры учётной записи:» следует сбросить флажок «Use DES encryption types with this account»:

Для пользователя usr1cv8x следует сгенерировать файл с секретным ключом на компьютере с ОС Windows. Для этого используется утилита ktpass, входящая в состав в пакета Windows Support Tools (его можно найти в подкаталоге SUPPORT установочного диска Windows).

В командной строке запустим утилиту ktpass, которая «свяжет» доменного пользователя с пользователем, от имени которого работает сервер «1С:Предприятие»:

usr1cv8x, указываемое в параметре mapuser, — это имя доменного пользователя, которого мы создали.

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

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

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

Убедимся, что все в порядке:

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

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

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

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

Мы видим, что файл с секретным ключом содержит именно то, что нам нужно — в колонке Principal указано то самое имя службы, которое мы задавали при создании файла с секретным ключом, и правильный алгоритм шифрования (arcfour-hmac для RC4-HMAC).

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

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

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

в) Настройка пользователей в информационных БД «1С:Предприятие»

Для настройки аутентификации пользователей в информационной БД «1С:Предприятие» с помощью доменной учетной записи нужно запустить БД под Администратором.

Перейти в «Администрирование», слева в списке выбрать «Пользователи».

В появившемся окне «Пользователи» выбрать нужного пользователя.

В свойствах пользователя выбрать «Аутентификация операционной системы» и в поле «Пользователь» нажать на кнопку «. ».

В списке «Пользователи» выбрать нужного пользователя и нажать на кнопку «Выбрать». Должно получиться как на скриншоте:

Эти действия нужно повторить для всех пользователей БД.

В результате мы получаем решение, при котором пользователю не требуется совершать дополнительных действий по вводу логина и пароля для запуска приложения. Система определяет пользователя операционной системы, запускающего приложение, и соотносит с имеющейся ролью в конфигурации «1С». Использование единой системы авторизации в прикладных приложениях удобно как для пользователя, так и для администратора конфигурации «1С» — не нужно обслуживать дополнительную локальную базу пользователей приложения.

В продолжение давней темы про использование двухфакторной аутентификации в ОС GNU/Linux позвольте рассказать про схему работы и настройку аутентификации с помощью Kerberos. В этой статье мы рассмотрим процесс настройки MIT Kerberos для аутентификации пользователей по сертификатам и ключевым парам, находящимся на USB-токене. Также материалы, изложенные в статье, можно использовать для настройки аутентификации в домене Windows.

Для начала проведем небольшой ликбез по терминологии Kerberos и рассмотрим доступные реализации этого протокола в ОС на базе GNU/Linux. Сразу оговорюсь, что мне не удалось найти однозначного перевода терминов, использующихся в Kerberos, поэтому для избежания путаницы основные термины я буду дублировать на английском.
Итак, начнем. Если процитировать Википедию, то

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

Стоит отметить, что Kerberos в первую очередь является протоколом, а не конкретной системой аутентификации. Его реализации используются в различных операционных системах, в том числе и в Windows, как метод аутентификации пользователей в домене. Существует несколько open source реализаций протокола Kerberos, например оригинальная MIT Kerberos и Heimdal. Такой зоопарк возник из-за ограничений США на экспорт криптографических средств защиты информации, на сегодня эта ситуация вокруг MIT Kerberos уже улеглась. В статье мы рассмотрим процесс настройки для MIT Kerberos V5.

Билет (ticket) – временные данные, выдаваемые клиенту для аутентификации на сервере, на котором располагается необходимая служба.
Клиент (client) – некая сущность в сети (пользователь, хост или сервис), которая может получить билет от Kerberos.
Центр выдачи ключей (key distribution center, KDC) – сервис, выдающий билеты Kerberos.
Область (realm) – сеть, используемая Kerberos, состоящая из серверов KDC и множества клиентов. Имя realm регистрозависимо, обычно пишется в верхнем регистре и совпадает с именем домена.
Принципал (principal) – уникальное имя для клиента, для которого разрешается аутентификация в Kerberos. Записывается в виде root[/instance]@REALM.

Файлы настроек Kerberos

На сервере:

На клиенте и сервере:

/etc/kbr5.conf — настройки сервера аутентификации (описание realms, доменных имен и других настроек)

Для начала необходимо развернуть среду, в которой будет производиться аутентификация. Наиболее просто это сделать, взяв две виртуальные машины, находящиеся в одной подсети. Достаточно установить на одну виртуальную машину какую-нибудь Ubuntu (это будет наш сервер), а затем клонировать ее и получить клиента. При написании статьи я воспользовался свежей Ubuntu 12.10 (x86) и виртуальной машиной от VMWare. Чтобы виртуальным машинам было удобнее видеть друг друга по сети, стоит переключить сетевые карты в Bridged-режим.
Важно! Следите за тем, чтобы время на клиенте и сервере было синхронизировано, это необходимо для корректной работы Kerberos.

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

Клиенты Kerberos ищут свои сервера по доменным именам, поэтому необходимо настроить DNS и убедиться, что имена серверов успешно разрешаются. В нашем примере достаточно занести доменное имя сервера в /etc/hosts, что я и сделал. Схема «сети» изображена ниже.

Установка необходимых пакетов

На сервере нам потребуются:

krb5-kdc – сервис KDC
krb5-admin-server – административный сервер Kerberos (он ведет контроль учетных записей пользователей)
krb5-pkinit – модуль расширения Kerberos для аутентификации по сертификатам

На клиент надо поставить следующие пакеты:

Базовые настройки

После установки пакетов на сервере нужно инициализировать realm командой
А на клиенте – обновить файлы конфигурации:
Также на клиенте и сервере надо добавить следующие строки в /etc/krb5.conf:
Теперь создадим на сервере нового пользователя c именем testuser
На клиенте теперь можно проверить, правильно ли мы настроили сеть и Kerberos:

Настройка аутентификации по открытому ключу

Для работы модуля pkinit нам придется воспользоваться openssl в качестве мини-УЦ, чтобы создать ключевые пары и сертификаты клиента и сервера.

На сервере:

Extended Key Usage (EKU) – идентификатор (OID), говорящий о том, как планируется использовать сертификат
otherName – поле, задающее нашего принципала, для которого выписывается сертификат

kdc.pem
kdckey.pem
cacert.pem

Дальнейшие действия будем выполнять на клиенте

Ранее при настройке клиентской машины мы поставили пакет libpam-krb5. Он поможет нам выполнить аутентификацию в Kerberos при входе в систему, а также в приложениях, использующих системную аутентификацию (например login, lightdm и проч.). Для подключения модуля PAM достаточно выполнить команду
и выбрать в диалоге необходимые модули аутентификации. Для более тонкой настройки можно заглянуть в файл /etc/pam.d/common-auth и отредактировать его по желанию. Структуру файла я описывал в предыдущей статье.

Применение протокола Kerberos для централизованной аутентификации в связке с централизованным созданием хранением и раздачей учетных записей (например, посредством каталога на базе OpenLDAP) позволяет создать «домен UNIX», полностью состоящий из машин под управлением свободного программного обеспечения. Такое решение может применяться в корпоративном секторе, а аутентификация по смарт-картам будет приятным бонусом как для администраторов, так и для пользователей сети компании.

Kerberos это система сетевой аутентифиации, основанная на принципах доверия третьей стороне. Другие две стороны - это пользователь и сервис, на котором он хочет авторизоваться. Не все сервисы и приложения могут использовать Kerberos, но те, которые могут, приближают сетевое окружение на один шаг к технологии единого входа (Single Sign On - SSO).

Этот раздел раскрывает установку и настройку сервера Kerberos, а также некоторые примеры клиентских настроек.

Обзор

Если вы новичок в Kerberos, есть несколько терминов, которые хорошо понять до установки сервера Kerberos. Большинство терминов связаны с вещами, которые могут быть вам знакомы по другим окружениям:

Учетная запись (Principal): любые пользователи, компьютеры или сервисы, предоставляемые серверами, должны быть определены как учетные записи Kerberos .

Требования (Instances): используются для сервисных и специальных административных учетных записей.

Центр распространения ключей (KDC): состоит из трех частей: базы данных всех учетных записей, сервера аутентификации и сервера предоставления билетов. Для каждой области должен быть хотя бы один KDC.

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

Сервер распространения билетов (TGS): выпускает сервисные билеты для клиентов по запросу.

Билеты (Tickets): подтверждение идентичности двух учетных записей. Одна учетная запись - пользователь, а другая - сервис, запрашиваемый этим пользователем. Билеты устанавливают секретный ключ, используемый для защищенного соединения во время авторизованной сессии.

Файлы ключей (Keytab Files): файлы, извлеченные из базы учетных записей KDC и содержащие ключ шифрования для сервиса или компьютера.

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

Читайте также: