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

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

py-configurator, scfl - добавки к Cfengine

Для нужд рабочих я написал несколько скриптов:
1. py-configurator - уже описывал и выкладывал;
2. scfl - Sync Config From LDAP - скоро выложу;
3. apt-control - ставит или удаляет пакеты руководствуясь списком из файла.

Это все добавки к Cfengine, хотя если будет время создать py-facter (для выуживания данных из окружения) и py-controller (контроль поцессов, запуск команд шелла и тп), то это будет полностью самостоятельной группой программ. По идее py-configurator и scfl уже связаны в тандем - один выгружает, второй рендерит шаблоны и кладет на место, - но они достаточно легко могут быть использованы по отдельности (достаточно конфигурацию поменять, так как py-configurator по умолчанию лезет в папку, в которую scfl по умолчанию выгружает).

Собственно сайт проекта на Google Code - py-configurator. Со временем туда выложу SCFL и apt-control (надо очистить их от рабочих данных).

Ключевая фишка всего набора - ориентирован он по умолчанию на Kerberos+LDAP окружение, чего, к сожалению, нет ни в одной альтернативе. Иначе я бы не стал изобретать велосипед.

LDAP vs Kerberos

Часто, когда люди узнают, что я использую Kerberos они говорят, что у них чистый LDAP (pam_ldap) и все прекрасно работает, папки монтируются, сервер проверяется на истинность сертификатами. Но главное, что у них не работает это SSO - Single Sign On. То есть пароль придется вводить на доступ к каждой службе отдельно, отдельно на прокси, отдельно на почту. И это мой главный аргумент за использование Kerberos. О том, что в случае использования Kerberos, пароли по сети не передаются в любом виде, я и вовсе молчу. К хорошей сети сложно подключить машину, которой там быть не должно - EAP существует достаточно давно, а потому украсть передаваемый трафик это очень сложная задача.

Тут можно привести еще один аргумент - в среде Kerberos сервер также не получает ваш пароль, и подстановка фальшивого сервера практически невозможна. Ну а если некто и взломает сервер, то пароль он все равно получить не сможет и все что ему достанется это информация на этом самом сервере.

Для меня выбор Kerberos очевиден еще и потому, что установив дружеские отношения с доменом Active Directory, я фактически решил проблему взаимодействия Linux и Windows сред.

OpenLDAP, syncrepl

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

Филиал у нас лицо не довереное, значит пароли ему знать ни к чему. Не доверяем потому что физически не контролируем.

Что требуется:
1. На нашем центральном сервере/серверах добавляем:

database bdb
...
overlay syncprov

2. Реплика в филиале:

database bdb
...
syncrepl rid=1
    provider=ldap://kdc.realm.tld
    bindmethod=sasl
    saslmech=GSSAPI
    searchbase="dc=realm,dc=tld"
    filter="(objectClass=*)"
    attrs="*"
    schemachecking=off
    scope=sub
    type=refreshOnly
    retry="5 5 300 5"

updateref       ldap://kdc.realm.tld

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

nss-ldapd, реинкарнация детища padl

У оригинального libnss-ldap есть серьезный недостаток при работе с gssapi - любому пользователю, желающему ознакомиться со списком пользователей, требуется предоставить билет kerberos. Второй вариант - дать всем читать билет, которым будет пользоваться libnss-ldap. Первое это нереально - ну откуда у dbus свой билет? Второе просто уже тупо как то - зачем вообще тогда весь этот лес?

nss-ldapd решает эту проблему. Возможно, ее автор хотел решить какие то другие проблемы, но меня волновала эта. Эта версия состоит из двух частей - демона, который собственно имеет билет и общается с ldap, и клиента, который просто обащается с демоном в пределах одной машины. Разом снимает головную боль с билетами.

Приведу элементарную настройку на работу с kerberos:

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

Кстати в kinit (Heimdal последних версий) есть возможность обновлять билет, до тех пор пока работает программа, переданная в качестве параметра.
То есть можно поправить стартовый скрипт nslcd, и билет будет обновляться автоматически.

ldapvi

Предыдущий пост описывает прием работы, который подходит для скриптования. Но есть в репозиториях совершенно дикая вещь - ldapvi.
Что это? Это метод скрестить крокодила с бегемотом - ldap и текстовый редактор. Описывать смысла особого нет - дает возможность быстренько что либо поправить в свойствах записи, удалить записи и тп. Данный пост просто повод обратить внимание.

nfs4 и samba - дружим доменами

При мигрировании, грамотно не ломать что либо сразу, а произвести плавный переход. Сначало плавно учимся привыкать к толстому OOo, а потом некоторую часть пользователей переводим на linux. Но перевод на linux не должен прерывать обмен данными с оставшимися пользователями. А у нас большое количество данных проходит через сетевые папки (некую файлопомойку с элементами упорядоченной структуры). Как знают грамотные люди, электронный документооборот требует не только покупки софта, а потому наша фирма пока еще пользуется таким способом работы.
Но вернемся к теме - linux, с некоторых пор, имеет поддержку nfs4, поддержку cifs он имеет с времен незапамятных. В свою очередь, nfs4 имеет поддержку протокола kerberos, ну а современные windows сети без kerberos не живут. Протокол kerberos пятой версии характеризуется хорошим механизмом отношений, или иначе "дружбой" сфер kerberos.
Я решил сделать как раз по этой схеме - у linux машин своя сфера kerberos, у windows - AD.
В общем я придумал три варианта:
1. Файловый сервер на машине с windows. Тут как раз нужно настроить дружбу доменов (сфер), а потом создавать пользователей два раза. Почему? Потому что это самый простой путь для подобной схемы - вы просто настраиваете отображение пользователей сферы linux в пользователей домена windows.
2. Файловый сервер на Samba и nfs4. В этом случае вы вводите машину с samba в домен windows, что, однако никак не отражается на самой системе сервера, просто теперь машины из AD смогут получить доступ к вашему серверу аутентифицируясь в AD. В то же время пользователи из сферы linux смогут получить доступ к файлам по протоколу nfs4, аутентифицируясь в linux сфере kerberos. Ключевым моментом схемы является отображение пользователей windows при помощи winbind - uid'ы пользователей AD не должны пересекаться с linux пользователями.
3. А можно не делать отдельную сферу kerberos для linux пользователей, можно аутентификацию и получение kerberos билетов организовать через домен AD. Тогда и проблем нет - делайте хоть на samba, хоть на windows сервере. Но мне не нравится это тем, что тогда отказаться от AD в дальнейшем не выйдет, и ничего то мы не сэкономим на подобном переходе. В общем я этот вариант не реализовывал.

При использовании второго варианта, доступ через nfs4 для linux машин более удобен и прост, так как монтирование по протоколу cifs(так называется протокол, используемый в windows среде) сетевой папки имеет некоторые недостатки:
1. ядро не имеет поддержки монтирования cifs шар с kerberos;
2. основанный на smbclient, smbfs имеет наприятные особенности;
3. если пользоваться, например, kde, то программы из этой среды смогут работать с сетевой папкой через kio-slaves, а вот OOo нет;
Таким образом, просматривать и скачивать файлы можно при помощи различных slaves (kde, да и гном что то такое имел в своем составе), а вот нормально работать только при использовании smbfs.

А вот конкретные настройки будут в следущей серии...

OpenLDAP+GSSAPI начало

Буду описывать краткими кусочками : )
Если хочется полного описания, хотя, на мой взгляд, довольно таки дурацкого, то вам сюда -> http://www.bayour.com/LDAPv3-HOWTO.html
У меня же тут будет все попроще для понимания, я надеюсь. В любом случае на родном оно сподручнее читать.

Нам надо сделать аутентификацию, при обращении к каталогу ldap, по GSSAPI. Можно конечно и по сертификатам, но мне нравится kerberos. Ключевое при получении авторизационной информации машинами клиентами, это аутентификация сервера. Это важно - если вашим машинам подставят другой сервер, и на нем скажут, что вот Вася Пупкин админ, то, согласитесь, радости это нам доставит мало.

На примере ubuntu (мне думается, что debian в этом плане сильно не отличается), мы просто делаем любимое aptitude install slapd.

Далее изменения в конфиг:

backend         bdb

#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend                
+sasl-realm              REALM.TLD # Ваша сфера kerberos
+sasl-host               ldap.realm.tld # Имя машины, на которой это все присходит
+authz-regexp uid=([^,]*),cn=realm.tld,cn=gssapi,cn=auth # А вот тут нужно почитать
+        ldap:///dc=realm,dc=tld??sub?(uid=$1) # справку, что бы понять

Суть такова - вы указываете сферу, имя, и настраиваете отображение имен. Это довольно важный момент - когда пользователь аутентифицируется, его имя выглядит как uid=anyuser,cn=realm.tld,cn=gssapi,cn=auth, но системе надо знать его dn, те uid=anyuser,ou=users,dc=town,dc=realm,dc=tld. По идее, конечно, и в таком виде сойдет, но тогда в ваших списках доступа не будут иметь смысла записи self, и пользователь не сможет сменить себе /bin/bash на любимый zsh, ну и пароль.

По идее далее идут настройки acl, которые довольно хорошо выполнены по ссылке выше. Но о чем стоит вспомнить, так это о том, что slapd запускается под пользователем openldap и доступа к /etc/krb5.keytab не имеет. Ну это не большая проблема, просто ключ надо сохранить в, например, /etc/ldap/slapd.keytab, поправить права, а демону перед стартом пояснить где его искать. Это можно сделать например редактированием стартового скрипта /etc/init.d/slapd. Вносим вначале файла export KRB5_KTNAME="FILE:/etc/ldap/slapd.keytab" и всех делов.

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

linux в торговле

Уже много лет активно обсуждается применение linux на корпоративном десктопе. Ну что же, это вполне возможно и ни капли не смертельно. Уж я то точно могу об этом сказать, так как проэкспериментировал на собственной фирме.

Не так давно наша фирма решила немного расширить свое розничное направление (а торгует наша компания мебелью), и запустила новый бренд розничной сети. Ну и под этим брендом открываются у нас несколько магазинов. Вообще магазины у нас были довольно таки обкатаной единицей к тому времени - контроллер домена + файлосвалка, офисная АТС, около 4 рабочих станций, около 5 тонких клиентов (Thinstation linux).

Как у любых администраторов, linux был конечно же у всех на слуху (а у кого то и на рабочем месте). Я вообще довольно давно разбирался в вопросах как сделать интегрированую сеть на linux, и наработки были. И решили все таки попробовать.

Стандартную схему переработали, контроллер домена сменили на linux сервер, АТС на него же. Так же linux установили на все рабочие места. Единственной рабочее место с windows, это место "Моделирование кухонь". Многие производители кухонь делают что то на коленке для этих целей, а коленка у них это access, ms jet и иже с ними. В общем wine я под это заточить не сумел, да и с возможными косяками возится не очень то и хотелось - я же все таки ленивый админ или как?

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

Ну а самое важное для корпоратива, это конечно же логины, пароли, сетевые папки. Ну это просто достаточно - ldap как хранилище авторизационной информации, kerberos как служба аутентификации, nfs4 как сетевая фс, samba для общения с офисом, который еще не так продвинут (тяжело его продвинуть все таки, магазин он маленький, а офис...).

Вот это то наверное и буду описывать в дальнейшем, для этого и завел себе блог. Но сразу стоит оговориться, что коробочного толкового решения я еще не видел, чтоб хоп, как в windows, пару раз мышкой щелкнули, и машина в домене. Сейчас активно разрабатываются FreeIPA, Mandriva DS, но первый минус этой кухни - работает в одном каком то конкретном дистрибутиве (fedora и mandriva, конечно же), а второе - еще не допилено до конца. Можно сказать , что у меня есть предвзятое отношение, но mandriva у меня всегда вызывала опасения. Возможно я не прав, и руки у них за столько лет стали прямее, но ранний опыт использования не впечатлил. Fedora же довольно последовательно строит свой каталог, и уважение корпоративщиков к ее старшему брату, существует видимо неспроста.

А пока я строю свой каталог на коленке из openldap и heimdal kerberos, но об этом в следующих сериях.