Google-группы по kerberos и Freeswitch

Я создал две новых google-группы для обсуждения вопросов, связанных с kerberos и freeswitch. Просьба все свои вопросы задавать там - формат комментариев к блогу не очень хорошо подходит для подобных обсуждений.


1. ru-kerberos
2. freswitch-ru

Subversion 1.5 и SASL

Если кто-то пропустил, то обращаю внимание, что теперь Subversion поддерживает GSSAPI, так как они перешли на стороннюю библиотеку для реализации SASL.

Поддержка есть как в svnserve, так и в клиенте. Настройки абсолютно стандартные - принципиал svn/`hostname -f` в keytab, и указать имя keytab в переменной окружения KRB5_KTNAME для svnserve. Ну и надо прописать в списке методов gssapi (документация рулит).

Инфраструктура Kerberos, Squid

LDAP мы уже настраивали, перейдем к одной из самых популярных серверных компонент - прокси серверу, в нашем случае это Squid.
Достаточное время существует механизм аутентификации для HTTP протокола - Negotiate. В среде windows используется SSPI, в linux GSSAPI. Поддерживается механизм в Firefox, WebKit (Safari), Konqueror, IE7, Squid, ISA server. Про Opera не подскажу, не использую.

Здесь я сделаю отступление, и дам ссылку на статью, прочитав которую, я решил не описывать настройку Apache - прекрасная статья, мне практически нечего к ней добавить.

Собрать Squid надо с ключами --enable-auth="negotiate" --enable-negotiate-auth-helpers="squid_kerb_auth" (это не означает, что других ключей не надо). Надо сказать, что из коробки такой метод сборки хелпера аутентификации squid_kerb_auth работает только для MIT библиотек и для Heimdal надо лезть в helpers/negotiate_auth/squid_kerb_auth/Makefile и править руками (сами найдете где).

Ну и если squid у вас в дистрибутиве уже собраный, то скорее всего хелпера там нет. Сильно рекомендую собирать не из исходников с сайта, а взять исходник из своего дистрибутива и поправить сборочные скрипты. Для debian based надо зайти на packages.*.*, найти squid, скачать исходник и diff к нему, распаковать исходники и пропатчить. Затем vim debian/rules, chmod 755 debian/rules, fakeroot debian/rules binary. Примерно так : ) Заодно разберетесь как пакеты собирать, кто не в курсе.

Еще есть возможность скачать squid_kerb_auth из cvs с sourceforge, но я не думаю, что в дистрибутивном squid вообще включен механизм negotiate, так что пересобирать все равно придется (к слову у меня он как раз из cvs).

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

Настройка заключается, как и всегда, в выгрузке билета и настройке сервера.

/etc/krb5.conf настраиваете по аналогии с предыдущими статьями (копируете просто).

В squid.conf:

auth_param negotiate program /usr/local/squid/libexec/squid_kerb_auth -d -s HTTP/squid_host.realm.tld@REALM.TLD
auth_param negotiate children 10
auth_param negotiate keep_alive on


Выгружаем ключи:

kinit admin/admin
ktutil -k /etc/squid/HTTP.keytab HTTP/`hostname -f` >>> DNS конечно же уже настроен в обе стороны?
chown squid-user /etc/squid/HTTP.keytab >>> пользователя смотрим в своем конфиге
kdestroy


В стартовый скрипт squid (/etc/rc.d/rc.squid, /etc/init.d/squid):

export KRB5_KTNAME=/etc/squid/HTTP.keytab <<< перед стартом демона


Перезапускаем, радуемся жизни пишем баг репорты (можно поднять тему на opennet.ru и дать мне ссылку в комментарии) - всем помогу : )

Инфраструктура Kerberos, рабочая станция

Рабочая станция, при включении в инфраструктуру должна осуществлять аутентификацию, через PAM, брать авторизационную информацию из источников, настроенных в /etc/nsswitch.conf, и, заодно, быть включенной в какую либо систему управления.

Самое первое, это на каждой машине установить поддержку kerberos:
aptitude install heimdal-clients
и настроить /etc/krb5.conf также, как и на KDC в первой заметке из серии (проверяем пытаясь получить билет и тп).

Для начала аутентификация. В нашем случае это, конечно же, kerberos, что как мы помним, дает нам множество неоспоримых преимуществ. Для этого ставим модули pam:
aptitude install libpam-heimdal libpam-ccreds
Модуль ccreds нам понадобится для локального кеширования пароля, на случай отсутствия связи с сервером (особенно актуально для ноутбучников). Пароль конечно не хранится в чистом виде - это хеш, что исключает его подбор в обозримом будущем, в случае кражи файла с парольным кешем.

Настройки PAM.
/etc/pam.d/common-auth

auth [success=done default=ignore] pam_unix.so nullok_secure try_first_pass
auth [authinfo_unavail=ignore success=1 default=2] pam_krb5.so use_first_pass minimum_uid=1000 forwardable debug
auth [default=done] pam_ccreds.so action=validate use_first_pass
auth [default=done] pam_ccreds.so action=store
auth [default=bad] pam_ccreds.so action=update

/etc/pam.d/common-account

account sufficient pam_krb5.so forwardable minimum_uid=1000
account required pam_unix.so use_first_pass

/etc/pam.d/common-session

session required pam_unix.so
session optional pam_foreground.so
session optional pam_krb5.so
session required pam_mkhomedir.so umask=0022 skel=/etc/skel


Теперь при входе получается билет, пароль кешируется, все замечательно. Вот только не будет работать. Вся информация о наших пользователях хранится в ldap, надо ее доставить на рабочие станции:
aptitude install libnss-ldapd libnss-db nss-updatedb
Здесь у нас опять таки помимо необходимой библиотеки идет кеширующий комплект - nss-updatedb забирает информацию из ldap и дублирует ее в локальные базы - на случай отсутствия связи с сервером. Запускать через cron или через cfengine (советую почитать - интересная вещь).

Редактируем /etc/nss-ldapd.conf:

uri ldap://kdc.realm.tld
base dc=realm,dc=tld
ldap_version 3
scope sub
use_sasl on
krb5_ccname FILE:/tmp/krb5cc_0


В /etc/nsswitch.conf, правим только эти две строки:

passwd: files ldap [NOTFOUND=return] db
group: files ldap [NOTFOUND=return] db


А так как для libnss-ldapd демона мы указали, что ему нужно получать доступ к каталогу с помощью ключа Kerberos, то надо ему этот ключ предоставить. Здесь мы возращаемся к настройке сервера.
В /etc/inetd.conf должна присутствовать строка:
kerberos-adm stream tcp nowait root /usr/lib/heimdal-servers/kadmind kadmind

В /etc/heimdal-kdc/kadmind.acl:

deepwalker/admin all

Это немного другой пользователь, добавьте его в базу kerberos. Также, я думаю, вы уже сами настроили bind и прямую и обратную зоны и время у вас на машинах сильно не различается, потому что описываться это будет несколько позже. Вернемся к рабочей станции, получаем билет:

sudo su >>> root
kinit deepwalker >>> получаем билет
ktutil get host/`hostname -f` >>> загружаем с сервера ключи для машины
kdestroy >>> теперь ключ администратора не нужен - убираем его
kinit -k host/`hostname -f` >>> получаем билет для машины
/etc/init.d/nslcd restart >>> Рестартуем демона ldapd
/etc/init.d/nscd restart >>> рестартуем nscd
exit >>> больше нам root не нужен

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

dn: dc=kdc.realm.tld,ou=hosts,dc=realm,dc=tld
uid: host/kdc.realm.tld
krb5PrincipalName: host/kdc.realm.tld@REALM.TLD
objectClass: top
objectClass: krb5KDCEntry
objectClass: krb5Principal
objectClass: domainRelatedObject
objectClass: dcObject
objectClass: dNSDomain
objectClass: posixAccount
associatedDomain: kdc.realm.tld
uidNumber: 5002
krb5KDCFlags: 126
dc: kdc.realm.tld
gidNumber: 5000
homeDirectory: /home/cfengine
cn: kdc.realm.tld
krb5KeyVersionNumber: 0

dn: uid=nfs,dc=kdc.realm.tld,ou=hosts,dc=realm,dc=tld
objectClass: krb5KDCEntry
objectClass: krb5Principal
objectClass: account
uid: nfs
krb5KDCFlags: 126
krb5PrincipalName: nfs/kdc.realm.tld@REALM.TLD
krb5KeyVersionNumber: 0

>>> Ну следующая запись требуется только для сервера, если конечно вы не хотите поднять LDAP для каких либо иных нужд
dn: uid=ldap,dc=kdc.realm.tld,ou=hosts,dc=realm,dc=tld
objectClass: krb5KDCEntry
objectClass: krb5Principal
objectClass: account
uid: ldap
krb5KDCFlags: 126
krb5PrincipalName: ldap/kdc.realm.tld@REALM.TLD
krb5KeyVersionNumber: 0


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

Инфраструктура Kerberos, сервисы

Теперь, когда у нас есть KDC, можно настраивать доступ к службам с использованием Kerberos.
Первым делом пример доступа к LDAP, так как этот сервис уже настроен. OpenLDAP поддерживает SASL(Simple Authentication and Security Layer). Почитать: http://bog.pp.ru/work/SASL.html или в Википедии.

Одним из механизмов SASL выступает GSSAPI - как раз наш случай, Kerberos (на самом деле не только). Остается настроить этот механизм (фрагмент /etc/ldap/slapd.conf):

sasl-realm REALM.TLD
sasl-host kdc.realm.tld

Далее надо чтобы был настроен /etc/krb5.conf, установлен пакет libsasl2-modules-gssapi-heimdal (или mit, но если вы читали статью про heimdal-kcm, то выбрать вам будет проще).

Если это все готово, то переходим к следующему этапу - надо сделать keytab файл для slapd. Тут стоит остановиться подробнее - keytab файл хранит ключи для сервисов (вы же не будете настукивать пароль при каждом обращении пользователя :) ). Чтение этого файла, всем кроме root, противопоказано, а slapd у нас работает от пользователя openldap. Значит делаем финт ушами:
в /etc/default/slapd добавим строчку - export KRB5_KTNAME="FILE:/etc/ldap/slapd.keytab". Это укажет slapd где искать ключи. Далее надо собствено выгрузить ключи:

kadmin -l ext --keytab=/etc/ldap/slapd.keytab ldap/kdc.realm.tld
chown openldap.openldap /etc/ldap/slapd.keytab


Надеюсь вы помните, что мы пока находимся все на том же сервере, а поэтому мы используем kadmin с ключом "-l", что позволяет пользователю root делать что угодно с базой kerberos. Для доступа с другой машины надо будет настроить kadmind

Ключи выгружены, slapd настроен, рестартуем демон: /etc/init.d/slapd restart
Проверка:

root@kdc:~# kinit deepwalker <<< надо будет ввести пароль
root@kdc:~# ldapsearch -H ldap://127.0.0.1 -Y GSSAPI
>>> тут должно быть выведено все дерево каталога <<<


Примерно таким же образом настраивается все остальное. Например для apache надо будет подгрузить модуль с поддержкой kerberos, выгрузить ключи вида HTTP/wwwhost.realm.tld. Для NFSv4 ключи надо выгружать в стандартный /etc/krb5.keytab для каждой машины. Впрочем по отдельным сервисам статьи можно написать будет отдельно. Главную мысль вы, я надеюсь, уловили.

Проблемы:
главная проблема это DNS (расхождения времени мы пока получить не можем, так как машина одна). В /etc/hosts вбейте нечто вроде:

127.0.0.1 localhost
192.168.0.1 kdc.realm.tld kdc


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

Инфраструктура Kerberos, начало

Как и обещал, попробую написать, как это делается. Приветствуются замечания, предложения, улучшения. Если есть что добавить к документу - я всеми руками за. Указывайте на ошибки, ругайте и тп : )

Вообще автор ждет Samba4, а пока спасается как может.

Итак, мы строим следующую структуру:
1. Heimdal KDC - центр распределения ключей;
2. OpenLDAP 2.4 - каталог, здесь будет храниться вся сетевая конфигурация. Такая как ключи kerberos, DNS, конфигурация (в предыдущих постах я описывал SCFL, только вот пока не выложил).

Я использую ubuntu 8.04, поэтому, как обычно, правит каждый сам под себя. Да и вообще - не надо всему, что вы прочли в интернете, слепо верить - стоит почитать документацию.

Ставим минимальный набор:

aptitude install heimdal-kdc slapd heimdal-clients pdns-server pdns-backend-ldap


Правим /etc/heimdal-kdc/kdc.conf:

[kdc]
logging = FILE:/var/log/heimdal-kdc.log
database = {
realm = REALM.TLD
dbname = ldap:dc=realm,dc=tld
mkey_file = /var/lib/heimdal-kdc/m-key
acl_file = /etc/heimdal-kdc/kadmind.acl
}


Правим /etc/ldap/slapd.conf:

include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
include         /etc/ldap/schema/hdb.schema
include         /etc/ldap/schema/dnsdomain2.schema #PowerDNS схема расширяющая стандартную

pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args
loglevel        0

modulepath      /usr/lib/ldap
moduleload      back_bdb
moduleload      syncprov #Для синхронизации

sizelimit 500
tool-threads 1
backend         bdb
sasl-realm              REALM.TLD
sasl-host               kdc.realm.tld

# Следующая строчка преобразует пользователя, подключающегося через sasl механизм 
# GSSAPI(kerberos) к его реальному DN в дереве. 
# В данном случае поиском, так как у меня они не лежат в одной папке.
authz-regexp uid=([^,]*),cn=realm.tld,cn=gssapi,cn=auth
        ldap:///dc=realm,dc=tld??sub?(uid=$1)


database        bdb #Мне тут сказали, что лучше использовать hdb. Попробую, почитаю.
suffix          "dc=realm,dc=tld"
checkpoint 512 30
directory       "/var/lib/ldap"

# Далее настройки хранилища bdb какие были по умолчанию. Надо бы разобраться и докрутить.
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500

# Настройки индекса. В общем то надо расширить их значительно.
index           objectClass,uid eq
lastmod         on

access to attrs=userPassword,shadowLastChange
        # Везде рекомендуют вначале привести к нормальному имени.
        # Пометим как TODO
        by dn="gidnumber=0+uidnumber=0,cn=peercred,cn=external,cn=auth" write
        by * none

access to attrs=krb5Key
        by dn="gidnumber=0+uidnumber=0,cn=peercred,cn=external,cn=auth" write
        by * none

access to dn.base="" by * read
access to dn.subtree="ou=config,dc=realm,dc=tld"
        # Мне можно править : )
        by dn.base="uid=deepwalker,ou=users,dc=realm,dc=tld" manage
        # Остальным читать
        by users read
        by anonymous auth
        by * none

access to *
        by dn="gidnumber=0+uidnumber=0,cn=peercred,cn=external,cn=auth" write
        by users read
        by anonymous auth
        by * none
# Последняя строчка для синхронизации
overlay syncprov

Теперь надо инициализировать LDAP, но для начала в /etc/default/slapd вставляем строчку:

SLAPD_SERVICES="ldap:/// ldapi:///"

Это заставит демон слушать на локальном сокете. Перезапускаем, и создаем файлик base.ldif с содержимым:

# realm.tld
dn: dc=realm,dc=tld
objectClass: dcObject
objectClass: organization
o: realm
dc: realm

# users, realm.tld
dn: ou=users,dc=realm,dc=tld
ou: users
objectClass: top
objectClass: organizationalUnit

# hosts, realm.tld
dn: ou=hosts,dc=realm,dc=tld
ou: hosts
objectClass: top
objectClass: organizationalUnit

# groups, realm.tld
dn: ou=groups,dc=realm,dc=tld
ou: groups
objectClass: top
objectClass: organizationalUnit

Теперь загрузим его в базу:

cat base.ldif | ldapadd -H ldapi:/// -Y EXTERNAL

Здесь это делается от root, мы подключаемся к локальному сокету и аутентифицируемся по специальному sasl механизму external - просто локальные пользователи.

Ну и инициализация KDC:

# /etc/init.d/heimdal-kdc restart
# kadmin -l
> init REALM.TLD

Далее надо по идее создать пользователя. Если вы в kadmin сделаете "add deepwalker", то создаст он вам пользователя немного не так, как хотелось бы, а по сему делаем tmpuser.ldif:

dn: uid=TMPUSER,ou=users,dc=realm,dc=tld
uid: TMPUSER
krb5PrincipalName: TMPUSER@REALM.TLD
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: userSecurityInformation
objectClass: krb5KDCEntry
objectClass: krb5Principal
loginShell: /bin/bash
uidNumber: TMPUIDNUM
krb5KDCFlags: 126
gidNumber: 2000
sn: TMPUSER
homeDirectory: /home/TMPUSER
krb5KeyVersionNumber: 1

И используем:

root@kdc:~# a=`ldapsearch -H ldapi:/// -Y external uidNumber | grep ^uidNumber | cut -c 12- | sort |tail -n 1`; let last_uid=$a+1
root@kdc:~# cat tmpuser.ldif | sed s/TMPUSER/deepwalker/g | sed s/TMPUIDNUM/$last_uid/g | ldapadd -H ldapi:/// -Y external
root@kdc:~# kadmin -l cpw deepwalker

Можно посмотреть содержимое каталога LDAP:

slapcat
# или
ldapsearch -Y external -H ldapi:///

Теперь надо настроить /etc/krb5.conf:

[libdefaults]
        default_realm = REALM.TLD
        default_tgs_enctypes = des-cbc-crc
        default_tkt_enctypes = des-cbc-crc
        default_etypes = des-cbc-crc
        default_etypes_des = des-cbc-crc

        fcc-mit-ticketflags = true


[realms]
        REALM.TLD = {
                kdc = kdc.realm.tld
                admin_server = kdc.realm.tld
        }

[domain_realm]
        realm.tld = REALM.TLD
        .realm.tld = REALM.TLD

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

kinit deepwalker

Далее пишем гневные комментарии и ждем следующей части.