Домен/Использование Kerberos: различия между версиями
(→IE) |
Нет описания правки |
||
Строка 21: | Строка 21: | ||
Получить билет: | Получить билет: | ||
$ kinit [USER][@ | $ kinit [USER][@REALM] | ||
В настроенной системе достаточно просто kinit, а указание полной формы типа kinit user@EXAMPLE.COM позволяет получить тикет в системе сразу после установки epmi /usr/bin/kinit. | В настроенной системе достаточно просто kinit, а указание полной формы типа kinit user@EXAMPLE.COM позволяет получить тикет в системе сразу после установки epmi /usr/bin/kinit. | ||
Строка 36: | Строка 36: | ||
https://web.mit.edu/kerberos/krb5-devel/doc/admin/env_variables.html | https://web.mit.edu/kerberos/krb5-devel/doc/admin/env_variables.html | ||
Если машина находится в другой сети, то потребуется ручное указание REALM и соответствия его | Если машина находится в другой сети, то потребуется ручное указание REALM и соответствия его домену в /etc/krb5.conf: | ||
<pre> | <pre> | ||
default_realm = | default_realm = EXAMPLE.COM | ||
... | ... | ||
[realms] | [realms] | ||
EXAMPLE.COM = { | |||
default_domain = | default_domain = example.com | ||
} | } | ||
</pre> | </pre> |
Версия от 03:18, 14 декабря 2018
Журнал ALT-review
Title::Использование Kerberos- Раздел: Section::практика Тег: Tag::kerberos,домен,приложения
|
На этой странице приводится пример использование билетов Kerberos в различных программах для подключения к сервисам. При правильной настройке пользователю выдаётся билет (TGT) при логине в систему.
kinit / klist / kdestroy
Отдельное управление билетами для отладки осуществляется следующими командами:
Получить билет:
$ kinit [USER][@REALM]
В настроенной системе достаточно просто kinit, а указание полной формы типа kinit user@EXAMPLE.COM позволяет получить тикет в системе сразу после установки epmi /usr/bin/kinit.
Удалить полученные билеты из кэша:
$ kdestroy
Просмотреть полученные билеты:
$ klist
Для отладки получения билета удобно использовать
$ export KRB5_TRACE=/dev/stdout
https://web.mit.edu/kerberos/krb5-devel/doc/admin/env_variables.html
Если машина находится в другой сети, то потребуется ручное указание REALM и соответствия его домену в /etc/krb5.conf:
default_realm = EXAMPLE.COM ... [realms] EXAMPLE.COM = { default_domain = example.com }
Браузеры
Chromium
$ chromium --auth-server-whitelist="*.example.com,*.etersoft.ru"
Для того, чтобы настройки применялись общесистемно:
/etc/chromium/default @@ -5,6 +5,8 @@ # Default: CHROMIUM_FLAGS="--enable-seccomp-sandbox" +CHROMIUM_FLAGS="$CHROMIUM_FLAGS --auth-server-whitelist=*.etersoft.ru,*.eterhost.ru" +
Должен быть ещё способ задания настроек по умолчанию на уровне пользователя.
curl
$ kinit $ curl --negotiate -u : "http://example.com"
(если не работает, проверяйте $ epmqf curl — он может оказаться от CryptoPro, где он старый и не поддерживает GSSAPI)
wget
Судя по всему, поддержка GSSAPI так и не включена апстримом.
Firefox
Добавить в about:config в firefox
network.negotiate-auth.delegation-uris .etersoft.ru network.negotiate-auth.trusted-uris .etersoft.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
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
Windows
Список полученных билетов:
> klist
Очистить:
> klist purge
Серверная сторона
nginx
Apache
- epmi apache2-mod_auth_kerb
- a2enmod auth_krb5 && serv httpd2 reload
положил тикет с SPN
добавил такие настройки:
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
другой вариант:
- epmi apache2-mod_auth_gssapi
- a2enmod auth_gssapi && serv httpd2 reload
AuthType GSSAPI AuthName "WebDAV Login" GssapiBasicAuth On GssapiCredStore keytab:/etc/apache2/http.keytab
require valid-user RequestHeader set REMOTE-USER %{REMOTE_USER}s
https://github.com/haiwen/seafdav/issues/8
sshd
Для разрешения подключаться, используя билет Kerberos, нужно раскомментировать в /etc/openssh/sshd_config:
GSSAPIAuthentication yes
nodejs
RunaWFE