вторник, 24 июня 2008 г.

Subversion 1.5 и SASL

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

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

понедельник, 23 июня 2008 г.

Как мне установить программу, распространяемую в исходных кодах?

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


Вступление


Существует несколько способов. Практически у всех есть общая часть - распаковать исходники:
tar xvfj mega_app.tar.bz2
or
tar xvfz mega_app.tar.gz
Выполнить комманду ./configure, затем make. Эти комманды служат для сборки из исходных кодов исполняемых файлов, библиотек и тп.

Отдельно стоит отметить первую комманду - ./configure
Если выполнить ./configure --help, то вы получите список параметров, которые можно передать ./configure
Например часто возможна такая комманда:
./configure --prefix=/opt/mega_app

Или указать путь к библиотеке, которая по каким либо причинам не нашлась сама:
./configure --kerberos-lib=/opt/kerberos/lib

Классический.


Итак делаем последовательность:
./configure
make
и команда которая собственно установит все составляющие программы в систему:
make install
WARNING!!! Используя этот способ легко получить очень серьезные проблемы в дальнейшем. Во первых, скорее всего,
вы не сможете удалить программу (make uninstall).

Checkinstall.


Правильный путь. После выполнения общей части запускаете:
checkinstall
Программа сама спросит вас обо всем, а можете просто везде нажать ENTER.
man checkinstall тоже очень хороший путь : ))

Сборка пакета для Debian.


Это отдельный и сложный путь - вам нужно разобраться со многими аспектами создания deb-пакетов (или любых других).
Здесь этот путь не будет описан в полной мере, только пример как собрать пакет из уже подготовленных материалов. Я,
например, пользовался им чтобы сделать бекпортинг пакетов из Feisty в Dapper.
Итак, пример. Идем на packages.ubuntu.com, находим нужный пакет (diff например) и качаем два файла - исходник (http://archive.ubuntu.com/ubuntu/pool/main/d/diffutils/diffutils_2.8.1.orig.tar.gz) и патч к нему, который поправит исходники и создаст папку debian с магическим файлом rules внутри (http://archive.ubuntu.com/ubuntu/pool/main/d/diffutils/diffutils_2.8.1-11ubuntu4.diff.gz).
Я скопировал их в папку ~/test и для начала распаковал исходник:
tar xvfz diffutils_2.8.1.orig.tar.gz
А затем наложил патч:
cd diffutils-2.8.1/
gzip -cd ../diffutils_2.8.1-11ubuntu4.diff.gz | patch -p1
Теперь надо сделать debian/rules исполняемым:
chmod 750 debian/rules
И собрать пакет:
fakeroot debian/rules binary
Fakeroot нужна для сборки пакета обычным пользователем (обычно многие операции требуемые не позволили бы вам сделать пакет).
ls ../
diff_2.8.1-11ubuntu4_i386.deb diffutils-2.8.1 diffutils_2.8.1-11ubuntu4.diff.gz diffutils_2.8.1.orig.tar.gz
Как видите, пакет готов.

Заключение


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

Ну и конечно автор ответственности не несет ни за что и никогда : ))

среда, 18 июня 2008 г.

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

Включение Windows машины в сферу Kerberos


В этой статье прекрасно описана процедура включения машины под управлением Windows в сферу Kerberos и настройки Samba. Если нет сервера с AD, то это прекрасный метод, только пользователей вручную создавать придется (возможно еще при помощи cfengine или сделать скрипт для синхронизации с LDAP).

Доверительные отношения сферы Kerberos и домена Active Directory



Первым делом ссылка на документацию от Heimdal.

Для настройки доверия нам потребуется утилита ksetup (вы же прочитали статью по ссылке?), с ее помощью мы настроим в Windows адреса KDC сферы на каждом контроллере AD:

$ ksetup.exe /addkdc REALM.TLD kdc1.realm.tld
$ ksetup.exe /addkdc REALM.TLD kdc2.realm.tld

Возможно потребуется перегрузить контроллер. Настройка доверия на контроллере AD:

$ netdom trust AD-REALM.TLD /Domain:SOUZT.TLD /add /realm /passwordt:пароль_доверия

Теперь надо добавить доверительную запись в базу нашего KDC:

# kadmin -l
> add krbtgt/AD-REALM.TLD@REALM.TLD <<< ввести пароль_доверия
> add krbtgt/REALM.TLD@AD-REALM.TLD <<< ввести пароль_доверия


Важно - надо удалить типы кодирования ключей, которые не поддерживаются AD, то есть все кроме des-cbc-md5(pw-salt), des-cbc-md4(pw-salt), des-cbc-crc(pw-salt), arcfour-hmac-md5(pw-salt). Точный список сейчас не скажу, например в W2003R2 была какая то проблема, связанная со сменой типа ключа используемого по умолчанию. Если кто то имеет более актуальную информацию - поделитесь.

Я использую это доверие в работе для доступа к ресурсам AD - к сетевым папкам и каталогу LDAP. Для этого надо настроить отображение - mapping. Отличная ссылка из первых рук, но попробую описать на родном.

Нам понадобится оснастка MMC для управления учетками, меню <Вид>, галочку на <Дополнительные функции>. Теперь находим пользователя deepwalker, в контекстном меню выбираем <Отображение имен>. Выбираем вкладку Kerberos и добавляем в список deepwalker@REALM.TLD. На этом все, попробуйте сделать нечто вроде:

ldapsearch -H ldap://pdc.ad-realm.tld/ -Y gssapi -b dc=ad-realm,dc=tld
klist

Весь домен должен промелькнуть у вас перед глазами, а в выводе klist должна появится строка:

Jun 18 11:19:24 Jun 18 19:08:22 ldap/pdc.ad-realm.tld@AD-REALM.TLD

Это будет означать, что билет вы получили и доверие работает. Далее можете попробовать зайти в сетевые папки через konqueror или через подобную программу.

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

На сегодня все, а про гневные комментарии вы и так помните : ) Надеюсь, что если я что то здесь не доосветил, то приведенные ссылки и google.ru вам помогут.

вторник, 17 июня 2008 г.

Инфраструктура 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 и дать мне ссылку в комментарии) - всем помогу : )

четверг, 12 июня 2008 г.

Инфраструктура 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


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