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.

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 флаг для тестирования только. Не определяйте свой пароль на командной строке. Выполнение так является дырой в системе безопасности, так как атакующий мог обнаружить Ваш пароль, перечисляя все рабочие процессы в системе, например.

Аутентификация файловых серверов GNU/Linux в домене Windows на базе AD. Часть 2

Мы будем настраивать только доступ к серверу GNU/Linux с использованием Samba. Авторизация пользователей останется локальной, с использованием /etc/passwd.
Мы присвоим нашему новому серверу статический IP-адрес. Пусть им будет 192.168.7.9.
Для начала нужно проверить, какой сервер у нас используется в качестве DNS. Им в нашей сети должен быть контроллер домена. У нас адрес сервера определен как 192.168.7.2. Правим файл /etc/resolv.conf. Он должен выглядеть следующим образом:

search lab.local nameserver 192.168.7.2

Проверим, все ли работает:

#host 192.168.7.2 2.7.168.192.in-addr.arpa domain name pointer lab-dc1.lab.local. #

Естественно, в Вашем случае имена будут другими. Обязательно сделайте в домене lab.local запись в DNS, ссылающуюся на наш новый сервер. Запись в DNS не означает того, что наш GNU/Linux сервер включен в домен. Проверим:

linux-test:~ # host 192.168.7.9 9.7.168.192.in-addr.arpa domain name pointer test-linux.lab.local. linux-test:~ # host test-linux test-linux.lab.local has address 192.168.7.9 linux-test:~ #

Для корректной работы в домене Windows требуется несколько служб: Kerberos, LDAP и Samba. В общем случае требуется только настройка Samba, настройка других служб не является обязательной. Но будет лучше, если мы их настроим – они могут пригодиться в будущем.
Kerberos настраивается просто – через один файл /etc/krb5.conf. Основными параметрами является REALM, указывающий на наш домен и адрес сервера Kerberos – это адрес контроллера домена. Файл /etc/krb5.conf выглядит примерно так:

linux-test:~ # more /etc/krb5.conf [libdefaults] default_realm = LAB.LOCAL clockskew = 300 # default_realm = EXAMPLE.COM [realms] LAB.LOCAL = < kdc = 192.168.7.2 default_domain = lab.local admin_server = 192.168.7.2 ># EXAMPLE.COM = < # kdc = kerberos.example.com # admin_server = kerberos.example.com # >[logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON [domain_realm] .lab.local = LAB.LOCAL [appdefaults] pam =

Секция [libdefaults] указывает на домен по умолчанию. У нас это LAB.LOCAL. Далее, в секции [realms] указываются параметры для LAB.LOCAL – имя домена и адрес сервера Kerberos. В нашем случае, в качестве сервера Kerbeors выступает контроллер домена. В секции [logging] указывается местоположение лог-файлов. Эти файлы пригодятся для процедуры поиска неисправности, если что-то пойдет не так.
Проверим работу Kerberos:

linux-test:~ # kinit Administrator@LAB.LOCAL Password for Administrator@LAB.LOCAL: linux-test:~ # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: Administrator@LAB.LOCAL Valid starting Expires Service principal 04/05/12 11:22:23 04/05/12 21:22:35 krbtgt/LAB.LOCAL@LAB.LOCAL renew until 04/06/12 11:22:23 linux-test:~ #

Команда kinit получает от сервера тикет, а klist показывает полученные тикеты от сервера. Выполнение kinit не является обязательным, но ведь нужно как-то проверить работу Kerberos?
Настройка LDAP тоже не является обязательной – Samba сама построит необходимые файлы и сделает нужные запросы. Но LDAP может пригодиться в дальнейшем. Конфигурация OpenLDAP хранится в файле /etc/openldap/ldap.conf. Обратите внимание – в системе может быть два файла ldap.conf. У них разные предназначения и даже немного разный синтаксис. В каталоге /etc/openldap лежит файл ldap.conf для OpenLDAP (и для Samba), а в файле /etc/ldap.conf хранится конфигурация для разрешения имен через LDAP (для nss_ldap). К файлу /etc/ldap.conf мы вернемся в других статьях, сейчас настроим /etc/openldap/ldap.conf

linux-test:~ # cat /etc/openldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never uri ldap://192.168.7.2 base DC=lab,DC=local linux-test:~ #

Как видите, все очень просто – нужно указать URI сервера LDAP (это наш контроллер домена) и базу для поиска.
Теперь переходим к самому сложному – настройке Samba.
В состав Samba входят 3 демона – smbd, nmbd и winbind. Все они берут настройки из файла /etc/samba/smb.conf.
Smbd отвечает за доступ клиентов к службе SMB/CIFS (собственно это и есть сервер Samba). Nmbd – это служба разрешения имен для Netbios. Winbind – служба разрешения имен (и компьютеров и пользователей) через доменные службы Windows.
Во многих руководствах можно встретить упоминание того, что кроме Samba требуется настраивать и winbind – службу, отвечающую за отношения между GNU/Linux и контроллером домена Windows. В частном случае, когда нужно настроить только Samba, настройки winbind можно опустить. Winbind обеспечивает авторизацию в домене Windows самых различных служб, обеспечивая интерфейс между модулями PAM и контроллером домена Windows. При неработающем winbind Samba остается работоспособной. Но настроив winbind мы делаем возможным дальнейшее расширение нашего сервера за счет добавления различных служб, авторизующихся через контроллер домена.
Мы сделаем самый простой сервер, открыв всем пользователям доступ к некоторому общему каталогу файлов и к домашнему каталогу пользователей. Более подробно о настройке доступа к серверу Samba мы будем говорить в других статьях.
В файле /etc/samba/smb.conf мы должны указать следующие строки:

[global] workgroup = LAB passdb backend = ldapsam:ldap://192.168.7.2 printing = cups printcap name = cups printcap cache time = 750 cups options = raw map to guest = Bad User logon path = \\%L\profiles\.msprofile logon home = \\%L\%U\.9xprofile logon drive = P: usershare allow guests = Yes

Здесь мы указываем сокращенное наименование нашего домена (LAB) и место, где хранятся пароли – параметр passdb backend, указывающий на то, что пароли находятся на сервере LDAP, в качестве которого выступает контроллер домена. Кстати, можно указать и несколько серверов, перечислив их через пробел. Это пригодится в том случае, если у нас несколько контроллеров домена. Строка usershare allow guests = Yes разрешает пользователям управлять доступом к своим папкам, открывая их для гостей. Остальные строки относятся к управлению печатью и процессу регистрации. В нашем случае они не являются обязательными и перекочевали из конфигурационного файла дистрибутива Samba.
Продолжим редактирование секции [global] файла smb.conf.

 domain logons = No domain master = No security = ADS encrypt passwords = yes

Строки domain logons и domain master разрешают использовать Samba в качестве контроллера домена. Это не наш случай и поэтому для них установлено No.
Строка security = ADS имеет ключевое значение. Тем самым мы указываем Samba, что сервер является членом домена Windows и за авторизацию отвечает AD. Строка encrypt passwords = yes означает, что используются зашифрованные пароли.
Продолжим редактировать все ту же секцию [global].

 ldap admin dn = Administrator@lab.local ldap delete dn = No ldap group suffix = ou=Groups ldap idmap suffix = ou=Idmap ldap machine suffix = ou=Computers ldap passwd sync = Yes ldap ssl = No ldap suffix = DC=lab,DC=local ldap timeout = 5 ldap user suffix = ou=Users

Эти строки относятся к управлению соединением с LDAP сервером. Заметьте, что форма записи DN администратора имеет форму user@domain – она должна совпадать с тем, что мы указывали при тестировании Kerberos. Остальные строки указывают суффиксы различных местоположений в AD.
Следующие строки относятся уже к Kerberos:

 realm = LAB.LOCAL template homedir = /home/%D/%U winbind refresh tickets = yes kerberos method = system keytab

Здесь мы указываем REALM и метод аутентификации в Kerberos.
Теперь строки, которые относятся к настройке winbind:

 winbind separator = / winbind enum users = yes winbind enum groups = yes winbind nested groups = yes winbind use default domain = No winbind nss info = rfc2307 winbind offline logon = yes

Здесь указаны различные параметры работы Winbind – форма разделитя имен домена и пользователя, разрешение для winbind перечислять имена пользователей и групп, разрешение оффлайновой аутентификации и т.п. Эти настройки рекомендованы разработчиками Samba.
Секция глобальных настроек закончена. Обратите внимание, что у нас нет строк password server и idmap backend, которые можно встретить в других руководствах. Samba должна сама разобраться, откуда берутся пароли.
Переходим к настройке каталогов. Здесь все просто:

[homes] comment = Home Directories valid users = %S, %D%w%S browseable = No read only = No inherit acls = Yes available = Yes [profiles] comment = Network Profiles Service path = %H read only = No store dos attributes = Yes create mask = 0600 directory mask = 0700 [users] comment = All users path = /home read only = No inherit acls = Yes veto files = /aquota.user/groups/shares/ [groups] comment = All groups path = /home/groups read only = No inherit acls = Yes [SRV] comment = Common files path = /local write list = Administrator guest ok = Yes hosts allow = 192.168.7.

К стандартному списку разделяемых каталогов, распространяемому вместе с дистрибутивом Samba мы добавили только секцию [SRV] – общедоступный каталог.
Конфигурирование всех необходимых файлов закончено, и мы приступаем к проверке работоспособности нашего сервера.

2. Проверка работоспособности.

Здесь мы проверим корректность наших настроек и включим наш новый сервер в домен Windows. Сначала проверим корректность настройки Samba:
l

inux-test:~ # testparm Load smb config files from /etc/samba/smb.conf rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) Processing section "[homes]" Processing section "[profiles]" Processing section "[users]" Processing section "[groups]" Processing section "[SRV]" Loaded services file OK. Server role: ROLE_DOMAIN_MEMBER Press enter to see a dump of your service definitions

Как видно, каких либо серьезных предупреждений и ошибок конфигурации у нас нет.
Теперь запустим по очереди демоны smbd, nmbd и winbindd. Сделаем это через файлы /etc/init.d/smb, /etc/init.d/nmb и /etc/init.d/winbind. Можно выполнить это и вручную, что может оказаться полезным для получения различной дополнительной информации. О том, как это сделать можно прочесть во встроенных руководствах (man) по smbd, nmbd и winbindd.
Проверим состояние нашего домена и нашего сервера в домене. Состояние домена можно получить командой net ads info

linux-test:~ # net ads info LDAP server: 192.168.7.2 LDAP server name: LAB-DC1.lab.local Realm: LAB.LOCAL Bind Path: dc=LAB,dc=LOCAL LDAP port: 389 Server time: Thu, 05 Apr 2012 13:03:47 MSK KDC server: 192.168.7.2 Server time offset: 4 linux-test:~ #

Как видно, все в порядке. Если какие-то параметры, выводимые командой не совпадают с нашим планом – надо искать причину. Теперь проверим состояние нашего сервера в домене:
l

inux-test:~ # net ads status -U Administrator Enter Administrator's password: No machine account for 'LINUX-TEST' found linux-test:~ #

Отсюда следует, что наш сервер не включен в домен. Запрос к контроллеру домена делается от имени администратора, и пароль нужно указывать от учетной записи администратора домена Windows.
Теперь мы должны включить наш сервер в домен:
l

inux-test:~ # net ads join -U Administrator Enter Administrator's password: Using short domain name -- LAB Joined 'LINUX-TEST' to realm 'lab.local' DNS Update for linux-test.lab.local failed: ERROR_DNS_UPDATE_FAILED DNS update failed! linux-test:~ #

Итак, наш новый сервер включен в домен, о чем свидетельствуют строки:

Using short domain name -- LAB Joined 'LINUX-TEST' to realm 'lab.local'

Динамическое изменение DNS у нас не прошло. Это не страшно, поскольку оно и не планировалось. Теперь рекомендуется перезапустить все наши процессы – smbd, nmbd и winbindd. Заметим, что после перезапуска до дальнейших проверок должно пройти несколько минут.
Проверим статус нашего сервера в домене:

linux-test:~ # net ads status -U Administrator Enter Administrator's password:

В ответ мы получим распечатку состояния нашего нового сервера в домене. Там будут указаны различные поля AD, относящиеся к нашему серверу. Так же наш сервер GNU/Linux мы увидим на вкладке Computers, запустив средство администратора AD на контроллере домена.

Можно проверить список пользователей домена:
l

inux-test:~ # net ads user -U Administrator Enter Administrator's password: Administrator Guest krbtgt usertest linux-test:~ #

И проверим работу winbind:

linux-test:~ # wbinfo -t checking the trust secret for domain LAB via RPC calls succeeded linux-test:~ #

И получим список пользователей в домене:
l

inux-test:~ # wbinfo -u LAB/administrator LAB/guest LAB/krbtgt LAB/usertest linux-test:~ #

Можно проверить состояние домена через wbinfo:
l

inux-test:~ # wbinfo -D LAB Name : LAB Alt_Name : lab.local SID : S-1-5-21-3914562201-450990341-53424453 Active Directory : Yes Native : Yes Primary : Yes linux-test:~ # wbinfo -P checking the NETLOGON dc connection succeeded linux-test:~ #

Все в порядке. Теперь самая главная проверка – попробуем открыть каталоги на нашем новом сервере, используя рабочую станцию под управлением Windows 7. Наша рабочая станция включена в домен. Мы должны увидеть наш новый сервер на вкладке Network обозревателя Windows, либо указав имя или IP адрес:

Теперь можно переходить к дальнейшим процедурам настройки нашего сервера. В дальнейшем мы рассмотрим некоторые нюансы описанного процесса в зависимости от дистрибутива GNU/Linux и подробнее рассмотрим настройку прав доступа к серверу Samba.
Работа выполнена на базе Информационно-вычислительного центра МЭИ.

Пример настройки 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 команда что делает