Kinit команда что делает

kinit [- 4 | —524init ] [- 9 | —524convert ] [- -afslog ] [- c cachename — -cache= cachename ] [- f | —forwardable ] [- t keytabname — -keytab= keytabname ] [- l time — -lifetime= time ] [- p | —proxiable ] [- R | —renew ] [- -renewable ] [- r time — -renewable-life= time ] [- S principal — -server= principal ] [- s time — -start-time= time ] [- k | —use-keytab ] [- v | —validate ] [- e enctypes — -enctypes= enctypes ] [- a addresses — -extra-addresses= addresses ] [- -fcache-version= integer ] [- -no-addresses ] [- -anonymous ] [- -version ] [- -help ] [ principal [ command ] ]

DESCRIPTION

kinit is used to authenticate to the Kerberos server as principal or if none is given, a system generated default (typically your login name at the default realm), and acquire a ticket granting ticket that can later be used to obtain tickets for other services.

If you have compiled kinit with Kerberos 4 support and you have a Kerberos 4 server, kinit will detect this and get you Kerberos 4 tickets.

— c cachename — -cache= cachename The credentials cache to put the acquired ticket in, if other than default. — f — -forwardable Get ticket that can be forwarded to another host. — t keytabname — -keytab= keytabname Don’t ask for a password, but instead get the key from the specified keytab. — l time — -lifetime= time Specifies the lifetime of the ticket. The argument can either be in seconds, or a more human readable string like `1h’ — p — -proxiable Request tickets with the proxiable flag set. — R — -renew Try to renew ticket. The ticket must have the `renewable’ flag set, and must not be expired. —renewable The same as — -renewable-life with an infinite time. — r time — -renewable-life= time The max renewable ticket life. — S principal — -server= principal Get a ticket for a service other than krbtgt/LOCAL.REALM. — s time — -start-time= time Obtain a ticket that starts to be valid time (which can really be a generic time specification, like `1h’ seconds into the future. — k — -use-keytab The same as — -keytab but with the default keytab name (normally FILE:/etc/krb5.keytab ) — v — -validate Try to validate an invalid ticket. — e — -enctypes= enctypes Request tickets with this particular enctype. — -fcache-version= version Create a credentials cache of version version — a — -extra-addresses= enctypes Adds a set of addresses that will, in addition to the systems local addresses, be put in the ticket. This can be useful if all addresses a client can use can’t be automatically figured out. One such example is if the client is behind a firewall. Also settable via libdefaults/extra_addresses in krb5.conf5. — -no-addresses Request a ticket with no addresses. — -anonymous Request an anonymous ticket (which means that the ticket will be issued to an anonymous principal, typically «anonymous@REALM )»

The following options are only available if kinit has been compiled with support for Kerberos 4.

— 4 — -524init Try to convert the obtained Kerberos 5 krbtgt to a version 4 compatible ticket. It will store this ticket in the default Kerberos 4 ticket file. — 9 — -524convert only convert ticket to version 4 —afslog Gets AFS tickets, converts them to version 4 format, and stores them in the kernel. Only useful if you have AFS.

The forwardable proxiable ticket_life and renewable_life options can be set to a default value from the appdefaults section in krb5.conf, see krb5_appdefault3.

If a command is given, kinit will setup new credentials caches, and AFS PAG, and then run the given command. When it finishes the credentials will be removed.

ENVIRONMENT

KRB5CCNAME Specifies the default credentials cache. KRB5_CONFIG The file name of krb5.conf , the default being /etc/krb5.conf KRBTKFILE Specifies the Kerberos 4 ticket file to store version 4 tickets in.

Домен/Использование Kerberos

На этой странице приводится пример использование билетов Kerberos в различных программах для подключения к сервисам. При правильной настройке пользователю выдаётся билет (TGT) при логине в систему.

1 kinit / klist / kdestroy

2 Браузеры

2.1 Chromium
2.2 Brave
2.3 curl
2.4 wget
2.5 Firefox
2.6 IE

3.1 Монтирование CIFS-ресурса

4.1 ssh
4.2 Подключение к LDAP
4.3 Windows

5.1 nginx

5.2 Apache

5.2.1 mod_auth_kerb
5.2.2 mod_auth_gssapi

kinit / klist / kdestroy

Отдельное управление билетами для отладки осуществляется следующими командами:

$ kinit [USER][@REALM]

В настроенной системе достаточно просто kinit, а указание полной формы типа kinit user@EXAMPLE.COM позволяет получить тикет в системе сразу после установки epmi /usr/bin/kinit.

Удалить полученные билеты из кэша:

$ kdestroy

Просмотреть полученные билеты:

$ klist

Для отладки получения билета удобно использовать

$ export KRB5_TRACE=/dev/stdout

Если машина находится в другой сети, то потребуется ручное указание REALM и соответствия его домену в /etc/krb5.conf:

default_realm = EXAMPLE.COM . [realms] EXAMPLE.COM =

Браузеры

Chromium

$ chromium --auth-server-whitelist="*.example.com,*.etersoft.ru"

Для того, чтобы установить настройки для всех пользователей машины, создайте /etc/chromium/policies/recommended/kerberos.json со следующим содержимым (например):

Должен быть ещё способ задания настроек по умолчанию на уровне пользователя.

https://dev.chromium.org/administrators/linux-quick-start
https://dev.chromium.org/administrators/policy-list-3#AuthServerWhitelist

Brave

Способ аналогичен chromium, но файл в другом каталоге:

/etc/brave/policies/recommended/kerberos.json

curl

(если не работает, проверяйте $ epmqf curl — он может оказаться от CryptoPro, где он старый и не поддерживает GSSAPI)

wget

Судя по всему, поддержка GSSAPI так и не включена апстримом.

Firefox

Открыть about:config в firefox и добавить через запятую нужные узлы:

network.negotiate-auth.trusted-uris .etersoft.ru,.eterhost.ru

Либо добавить в prefs.js в профиле браузера (в каталоге ~/.mozilla/firefox) при закрытом браузере:

user_pref("network.negotiate-auth.trusted-uris", ".etersoft.ru,.eterhost.ru");

Способ общесистемных настроек пока не найден.

https://insinuator.net/2016/02/how-to-test-kerberos-authenticated-web-applications/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/sso-config-firefox.html
https://forum.altlinux.org/index.php?topic=15876.msg165572#msg165572
https://people.redhat.com/mikeb/negotiate/

IE

Добавить в доверенные сайты

Свойства браузера -> Безопасность -> Надёжные сайты
Нажать на кнопку «Сайты» и добавить адрес нужного сайта
Нажать на кнопку «Другое» и найти раздел » Проверка подлинности пользователя» в окошке «Параметры»
Выбрать пункт «Автоматический вход в сеть с текущим именем пользователя и паролем»

Файловые системы

Монтирование CIFS-ресурса

# kinit # smbclient -k -L //SERVER # mount -o sec=krb5 //SERVER/share /mnt/share

Не ясным остаётся вопрос с

$ kinit $ sudo mount .

(тикет перестаёт быть доступен после повышения привилегий)

Прочее

ssh

Просто подключаемся к ssh-серверу, настроив его (см. ниже настройку sshd)

Чтобы подключаться к пользователю с другим логином (ssh otheruser@host) нужно на удалённой машине создать файл ~/.k5login и в него вписать разрешённые адреса, например:

guest@ETERSOFT.RU pv@ETERSOFT.RU

Так как содержимое файла .k5login перекрывает правила по умолчанию, нужно явно вписывать туда всех пользователей, которым разрешено подключение.

Подключение к LDAP

Домен/GSSAPI

Также можно посмотреть на test на python для подключения к LDAP.

Windows

Список полученных билетов:

> klist

> klist purge

Серверная сторона

nginx

Создание SPN и Keytab файла
Nginx/AD-auth

Apache

mod_auth_kerb

Не используйте mod_auth_kerb, он давно устарел и удалён, см. 39063. Перейдите к mod_auth_gssapi.

epmi apache2-mod_auth_kerb
a2enmod auth_krb5 && serv httpd2 reload

положил тикет с SPN в /etc/krb5.time.office.keytab

добавил такие настройки:

AuthType Kerberos AuthName "Please enter your login and password for ETERSOFT.RU" KrbMethodNegotiate on KrbMethodK5Passwd on KrbServiceName HTTP/time.office.etersoft.ru@ETERSOFT.RU KrbAuthRealms ETERSOFT.RU Krb5Keytab /etc/krb5.time.office.keytab #KrbLocalUserMapping On

mod_auth_gssapi

epmi apache2-mod_auth_gssapi
a2enmod auth_gssapi && serv httpd2 reload

AuthType GSSAPI AuthName "GSSAPI Login" GssapiBasicAuth On GssapiCredStore keytab:/etc/apache2/http.keytab

require valid-user RequestHeader set REMOTE-USER %s

См. также полную статью Apache2/AD-auth.

sshd

Для разрешения подключаться, используя билет Kerberos, нужно раскомментировать в /etc/openssh/sshd_config:

GSSAPIAuthentication yes

nodejs

RunaWFE

kinit — Получают и кэш билет выдачи билетов Kerberos

kinit используется, чтобы получить и кэшировать билеты выдачи билетов Kerberos. Этот инструмент подобен в функциональности kinit инструменту, которые обычно находятся в других реализациях Kerberos, таких как ШОВ и Ссылочные реализации MIT.

Пользователь должен быть зарегистрирован как принципал с Центром распределения ключей (KDC) до выполнения kinit.

РЕЗЮМЕ

ОПИСАНИЕ

По умолчанию на платформе Windows файл кэша называют \krb5cc_ будет сгенерирован. число идентификатора пользователя пользователя, зарегистрированного в систему.

получается из java.lang.System свойство user.home . получается из java.lang.System свойство user.name . Если нуль, файл кэша хранился бы в текущем каталоге, от которого работает программа. имя пользователя входа в систему операционной системы. Это имя пользователя могло отличаться чем основное имя пользователя. Например на Windows NT, это могло быть c:\winnt\profiles\duke\krb5cc_duke , в котором duke и c:\winnt\profiles\duke .

По умолчанию имя keytab получается от конфигурационного файла Kerberos. Если имя keytab не является specifed в конфигурационном файле Kerberos, имя берется, чтобы быть \krb5.keytab

Если Вы не определяете пароль, используя password опция на командной строке, kinit запросит Вас пароль.

Отметьте: password обеспечивается только для тестирования. Не помещайте свой пароль в сценарий или обеспечивайте Ваш пароль на командной строке. Выполнение так поставит под угрозу Ваш пароль.

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

КОМАНДЫ

Использование: kinit [-fp] [-c cache_name>] [-k] [-t keytab_filename>] [principal>] [password>] [-help]

Опция команды	Описание
-A	Не включайте адреса.
-f	Выпустите forwardable билет.
-p	Выпустите proxiable билет.
-c cache_name>	Имя кэша (то есть, FILE:d:\temp\mykrb5cc ).
-k	Используйте keytab
-t keytab_filename>	Имя keytab (то есть, d:\winnt\profiles\duke\krb5.keytab ).
principal>	Основное имя (то есть, duke@java.sun.com ).
password>	Пароль Kerberos принципала. (DO НЕ ОПРЕДЕЛЯЕТ НА КОМАНДНОЙ СТРОКЕ ИЛИ В СЦЕНАРИИ.)
-help	Инструкции дисплеев.

ПРИМЕРЫ

Запрос учетных данных, допустимых для аутентификации от текущего хоста клиента, для служб значения по умолчанию, хранение кэша учетных данных в расположении значения по умолчанию ( c:\winnt\profiles\duke\krb5cc_duke ):

kinit duke@JAVA.SUN.COM

Запрос proxiable учетные данные для различного принципала и хранение этих учетных данных в указанном кэше файла:

kinit -p -c FILE:c:\winnt\profiles\duke\credentials\krb5cc_cafebeef cafebeef@JAVA.SUN.COM

Запрос proxiable и forwardable учетные данные для различного принципала и хранение этих учетных данных в указанном кэше файла:

kinit -f -p -c FILE:c:\winnt\profiles\duke\credentials\krb5cc_cafebeef cafebeef@JAVA.SUN.COM

Отображение меню помощи для kinit:

kinit -help

ПРЕДУПРЕЖДЕНИЕ БЕЗОПАСНОСТИ

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

Пример настройки 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
имя компьютера (hostname) — main
IP-адрес — 192.168.29.150
имя домена — krb.local
Центральный сервер кластера 1С:Предприятия
Операционная система Fedora 6
Имя компьютера (hostname) — srv1c
IP-адрес — 192.168.29.151
Установлена реализация Kerberos от MIT, поддерживающая алгоритм RC4-HMAC (пакет krb5-workstation).
Рабочая станция

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

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

В DNS-сервере следует «вручную» зарегистрировать все Linux-компьютеры. Регистрация Windows-компьютеров происходит автоматически при включении их в домен. В нашем случае, «вручную» необходимо зарегистрировать центральный сервер кластера 1С:Предприятия (т.к. на нем исполняется Linux-версия сервера), а рабочую станцию включить в домен (зарегистрирована она будет автоматически).

После этого следует создать учетную запись пользователя, с которой будут ассоциироваться запросы авторизации к серверу 1С:Предприятия . В нашем примере это будет пользователь usr1cv8 с паролем pass1cv8 . В свойствах этой учетной записи следует сбросить флажок «Use DES encryption types with this account» . Если ваша реализация Kerberos не поддерживает алгоритм шифрования RC4-HMAC, то флажок обязательно нужно выставить.

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

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

Копировать в буфер обмена

C:\>ktpass -princ usr1cv81/srv1c.krb.local@KRB.LOCAL -mapuser usr1cv8 -pass pass1cv8 -out usr1cv81.keytab C:\>

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

Копировать в буфер обмена

C:\>ktpass -crypto DES-CBC-CRC -princ usr1cv81/srv1c.krb.local@KRB.LOCAL -mapuser usr1cv8 -pass pass1cv8 -out usr1cv81.keytab C:\>

В результате будет создан файл 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 адрес контроллера домена. В результате файл должен содержать следующие строки:

srv1c:~# cat /etc/resolv.conf nameserver 192.168.29.150 search krb.local srv1c:~#

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

srv1c:~# ping main -c 1 PING main.krb.local (192.168.29.150) 56(84) bytes of data. 64 bytes from 192.168.29.150: icmp_seq=1 ttl=128 time=0.177 ms --- main.krb.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.177/0.177/0.177/0.000 ms srv1c:~#

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

srv1c:~# ntpdate main 4 Jun 11:51:53 ntpdate[2527]: step time server 192.168.29.150 offset -56.766439 sec srv1c:~#

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

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

srv1c:~# cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = KRB.LOCAL dns_lookup_realm = false dns_lookup_kdc = false default_tkt_enctypes = rc4-hmac default_tgs_enctypes = rc4-hmac [realms] KRB.LOCAL = < kdc = main.krb.local:88 default_domain = krb.local >[domain_realm] krb.local = KRB.LOCAL .krb.local = KRB.LOCAL KRB.LOCAL = KRB.LOCAL .KRB.LOCAL = KRB.LOCAL [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [appdefaults] pam = < debug = true ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = false krb4_convert = false >srv1c:~#

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

. . . default_tkt_enctypes = des-cbc-crc des-cbc-md5 default_tgs_enctypes = des-cbc-crc des-cbc-md5 . . .

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

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

srv1c:~# kinit user Password for user@KRB.LOCAL: srv1c:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: user@KRB.LOCAL Valid starting Expires Service principal 06/04/08 11:29:21 06/04/08 21:28:28 krbtgt/KRB.LOCAL@KRB.LOCAL renew until 06/05/08 11:29:21 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached srv1c:~# kdestroy srv1c:~#

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

srv1c:~# cd /opt/1C/v8.1/i386 srv1c:i386# chown usr1cv81:grp1cv81 usr1cv81.keytab srv1c:i386# chmod 600 usr1cv81.keytab srv1c:i386#

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

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

srv1c:~# klist -e -k -t /opt/1C/v8.1/i386/usr1cv81.keytab

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

Keytab name: FILE:/opt/1C/v8.1/i386/usr1cv81.keytab KVNO Principal ---- --------------------------------------------------------------------- 13 usr1cv81/srv1c.krb.local@KRB.LOCAL (ArcFour with HMAC/md5)

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

Keytab name: FILE:/opt/1C/v8.1/i386/usr1cv81.keytab KVNO Principal ---- --------------------------------------------------------------------- 13 usr1cv81/srv1c.krb.local@KRB.LOCAL (DES cbc mode with RSA-MD5)

Мы видим, что файл с секретным ключом содержит именно то, что нам нужно (в колонке 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 должна отработать без каких-либо сообщений, не спрашивать никаких паролей и вернуть управление обратно в командную строку:

srv1c:~# kinit -k -t /opt/1C/v8.1/i386/usr1cv81.keytab usr1cv81/srv1c.krb.local@KRB.LOCAL srv1c:~#

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

srv1c:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: usr1cv81/srv1c.krb.local@KRB.LOCAL Valid starting Expires Service principal 06/04/08 11:44:54 06/04/08 21:43:58 krbtgt/KRB.LOCAL@KRB.LOCAL renew until 06/05/08 11:44:54 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached srv1c:~#

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

srv1c:~# klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000) Kerberos 4 ticket cache: /tmp/tkt1000 klist: You have no tickets cached srv1c:~#

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

Kinit команда что делает