LDAP-репликация и Samba
Материал из Xgu.ru
ОС и ПО: Debian GNU/Linux, OpenLDAP, Samba
- Автор: Игорь Чубин
- Короткий URL: ldap/replication
На этой странице рассматриваются процедура подготовки slave-сервера LDAP и вопросы использования файлового сервера Samba совместно с slave-сервером LDAP.
[править] Samba и LDAP
Файловый сервер Samba хранит служебную информацию, в частности, информацию об учётных записях пользователей, в специальной базе данных, passdb backend. Сейчас Samba поддерживает большое количество разнообразных видов хранилищ, начиная от простого текстового файла (smbpasswd) и заканчивая MySQL-сервером.
Одним из распространённых в последнее время типов хранилищ, используемых вместе с Samba, является LDAP-хранилище, то есть фактически, сервер каталога, доступный по протоколу LDAP.
Наиболее важными преимуществами этого хранилища в сравнении с остальными является:
- Простота интеграции с другими системами;
- Возможность масштабирования.
Простота интеграции с другими системами позволяет добиться того чтобы все (или большинство) систем, используемых в сети, имели доступ и использовали в своей работе одну и ту же учётную информацию. Это позволяет упростить процесс администрирования и избежать создания внутренних противоречий.
Грубо говоря, если почтовый сервер и файловый сервер пользуются одними и теми же учётными записями, не нужно создавать одну и ту же запись два раза, и не может возникнуть ситуация, когда для почты поменяли пользователю пароль, а для файлового сервера — нет.
Чаще всего причиной, заставляющей перейти на использование LDAP-каталога для хранения учётной информации является первая, то есть простота интеграции. Масштабируемость нужна гораздо реже: традиционное файловое хранилище используемое в Samba легко справляется с несколькими сотнями учётных записей. На LDAP переходят и при значительно меньшем количестве пользователей. Тем не менее, возможность распределения является тоже очень важной, и рано или поздно при росте системы она приобретает большое значение.
Возможность масштабирования даёт возможность роста системы в нескольких направлениях:
- размер системы (другими словами, количество учётных записей и интенсивность обращений);
- территориальная распределённость (географическая удалённость систем, использующих базу данных учётных записей);
- административная распределённость (за разные учётные записи отвечают разные люди).
В первом и втором случае создаётся несколько LDAP-серверов, один из которых является master-сервером, в него заносятся все изменения, которые делаются в каталоге; остальные же — slave-серверами, они хранят копию данных master-сервера. Передача данных с master-сервера на slave выполняется с помощью репликации.
Для решения третьей задачи, как правило, используются распределённые подкаталоги (поддомены).
На этой странице рассматриваются процедура подготовки slave-сервера LDAP и вопросы использования файлового сервера Samba совместно с slave-сервером LDAP. Вопросы распределения каталога (создания поддоменов) здесь не рассматриваются.
[править] Сценарий
Есть центральный офис и есть отделение. Есть файловые серверы Samba, работающие в сети центрального офиса и в сети отделения.
В настоящий момент Samba-сервер отделения использует LDAP-сервер центрального офиса.
Это плохо по нескольким причинам:
- Данные между LDAP-сервером и Samba постоянно должны передаваться между центральным офисом и удалённым отделением;
- Когда центральный офис не работает, Samba-сервер использовать не удаётся.
Нужно сделать так чтобы файловый сервер Samba в сети отделения (и прочие службы тоже) использовали при чтении локальную реплику LDAP-каталога. Запись же (которая происходит значительно реже, чем чтение) должна выполняться в сервер центрального офиса.
[править] Использование Samba с репликой LDAP
Samba-сервер использует локальную реплику LDAP. При чтении данных всё очевидно — данные просто читаются из локального LDAP-сервера.
С записью возникает несколько вопросов:
- Куда Samba-сервер должен записывать данные?
- Если в локальный LDAP-сервер, то как они попадут в центр?
- Если в центральный LDAP-сервер, то как сообщить Samba-серверу, что читать данные он должен на одном сервере, а записывать на другой.
Samba-сервер, в зависимости от того какую операцию он выполняет, может записывать данные в LDAP двумя способами:
- Посредством внешних скриптов (чаще всего smbldap-tools), которые используются при выполнении ряда операций (управление учётными записями пользователей и машин);
- Напрямую, непосредственно обращаясь к серверу, адрес которого указан в конфигурации Samba.
Рассмотрим каждый процесс более детально.
[править] Модификация каталога через smbldap-tools
На схеме показан типичный процесс изменения данных в каталоге по отправленному Samba запросу клиента, выполняющийся посредством внешних скриптов (например, добавление пользователя в каталог).
Шаги:
- Обращение к локальному samba-серверу;
- Samba не выполняет запись в LDAP-сервер напрямую; она использует для этого скрипты smbldap-tools;
- Прямое обращение;
- Репликация изменений в каталоге через slurpd;
- Чтение информации из локального ldap;
- Ответ локального samba-сервера.
[править] Модификация каталога без smbldap-tools
На схеме показан типичный процесс изменения в каталоге по отправленному Samba запросу клиента, выполняющийся самим файловым сервером Samba (например, изменение пароля пользователя).
Шаги:
- Обращение к локальному samba-серверу;
- Samba пытается записать информацию в локальный LDAP-сервер напрямую, с помощью протокола LDAP;
- LDAP-сервер возвращает Samba ответ-ссылку (referral);
- Samba пытается записать информацию в центральный LDAP-сервер, адрес которого получен на предыдущем этапе;
- Репликация изменений в каталоге через slurpd;
- Чтение информации из локального ldap;
- Ответ локального samba-сервера.
[править] Переход на использование реплицированного LDAP-сервера
Процесс подготовки отделения к использованию локального (реплицированного) LDAP-сервера состоит из нескольких шагов:
- Создание в каталоге специальной учётной записи для выполнения репликаций (репликатора);
- Настройка центрального LDAP-сервера на отправку реплик на LDAP-сервер отделения;
- Инсталляция локального LDAP-сервера;
- Первичное копирование данных с центрального LDAP-сервера;
- Перевод Samba и других LDAP-клиентов на использование локального LDAP-сервера.
[править] Создание replicatora
Создайте файл, который будет содержать LDIF-запись, добавляемую в каталог:
%# cat > /tmp/replicator.ldif <<REPLICATOR dn: cn=replicator,dc=example,dc=com cn: replicator objectclass: top objectclass: organizationalRole objectclass: simpleSecurityObject userPassword: {SSHA}GYlNLdJctxRtLcqiMA5XsJvCVMtFjkeN REPLICATOR
Хэш пароля можно определить с помощью команды slappasswd:
%# slappasswd New password: Re-enter new password: {SSHA}GYlNLdJctxRtLcqiMA5XsJvCVMtFjkeN
После этого вы можете добавить запись в каталог:
%# ldapadd -D cn=manager,dc=example,dc=com -x -W -f /tmp/replicator.ldif
Есть искушение не создавать учётную запись репликатора, а проводить репликацию пользуясь учётной записью менеджера (cn=manager,dc=example,dc=com). Так делать нельзя! Поскольку в этом случае локальный LDAP-сервер при обращении к нему с запросами на запись не возвращает ссылку на центральный сервер, а отрабатывает запросы самостоятельно. |
[править] Изменение конфигурации master-сервера
В конфигурационный файл master-сервера OpenLDAP slapd.conf необходимо добавить следующие строки (директивы replica нужно добавлять по одной для каждого slave-сервера, если их несколько):
replogfile /var/lib/ldap/replog replica uri=ldap://slave.example.com:389 binddn="cn=replicator,dc=example,dc=com" bindmethod=simple credentials=replicator-pass
Здесь вместо replicator-pass необходимо указать пароль, который был введён в slappasswd на предыдущем шаге.
Убедитесь, что каталог (в данном случае /var/lib/ldap), предназначенный для хранении журнала репликации LDAP, существует.
[править] Изменение конфигурации slave-сервера
Убедитесь, что в конфигурационном файле slave-сервера есть следующие директивы:
Здесь важна строка replicator, которая разрешает выполнять запись от имени пользователя-репликатора. Запись будет выполняться master-сервером (а точнее, его процессом slurpd), когда в каталоге будут появляться изменения, которые нужно отреплицировать.
access to * by dn="cn=admin,dc=example,dc=com" write by dn="cn=replicator,dc=example,dc=com" write by * read
Директива updatedn указывает учётную запись, обращения от имени которой должны отрабатываться непосредственно самим сервером. При обращении от имени любой другой учётной записи сервер не будет выполнять запись, а будет перенаправлять клиента на master-сервер.
updatedn cn=replicator,dc=example,dc=com
Директива updateref указывает куда должны перенаправляться клиенты, которые хотели выполнить запись на этот LDAP-сервер. Здесь необходимо указать адрес мастер-сервера LDAP.
updateref ldap://10.0.3.11:389
Пример. Конфигурационный файл slave-сервера OpenLDAP.
root@slave:~# grep -v ^# /etc/ldap/slapd.conf | grep -xv '' 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/samba.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 256 modulepath /usr/lib/ldap moduleload back_bdb sizelimit 500 tool-threads 1 backend bdb checkpoint 512 30 database bdb suffix "dc=example,dc=com" rootdn "cn=manager,dc=example,dc=com" rootpw {SSHA}4AJKTEFYkaJz/2fmYcKJIt85StohXBs updatedn cn=replicator,dc=example,dc=com updateref ldap://10.0.3.11:389 directory "/var/lib/ldap" 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 eq lastmod on access to attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword,sambaPwdLastSet,sambaPwdMustChange by dn="cn=admin,dc=example,dc=com" write by dn="cn=replicator,dc=example,dc=com" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=example,dc=com" write by dn="cn=replicator,dc=example,dc=com" write by * read
[править] Копирование базы данных с master-сервера на slave-сервер
Копирование базы данных выполняется очень просто: нужно просто синхронизировать каталоги.
Убедиться что master- и slave-серверы остановлены:
master%# /etc/init.d/slapd stop slave%# /etc/init.d/slapd stop
На slave-сервере выполнить синхронизацию:
slave%# rsync -auvz master:/var/lib/ldap/ /var/lib/ldap/
Запустить master-сервер и slave-сервер вновь.
master%# /etc/init.d/slapd start slave%# /etc/init.d/slapd start
[править] Конфигурация Samba
В конфигурации Samba-сервера отделения необходимо сделать следующие изменения.
Во-первых, нужно указать новый LDAP-сервер в качестве backend-сервера, в котором хранится учётная информация Samba.
passdb backend = ldapsam:ldap://10.0.103.11
Здесь — 10.0.103.11 адрес LDAP-сервера отделения.
Во-вторых, нужно сказать Samba-серверу, что изменения в локальном сервере LDAP (в том, которым он пользуется), могут быть доступны не мгновенно, а спустя небольшое время. Это время определяется директивой ldap replication sleep в конфигурационном файле Samba. Например, в случае, когда в файле smb.conf присутствует строка:
ldap replication sleep = 5000
репликация должна успеть завершиться за 5 секунд.
[править] Другие клиенты LDAP
Необходимо нацелить на новый LDAP-сервер не только Samba, но и другие клиенты LDAP.
[править] libnss-ldap
Необходимо отредактировать конфигурационный файл библиотеки libnss_ldap, который расположен в /etc/libnss-ldap.conf или другом месте, которое можно определить с помощью команды:
%# strings /usr/lib/libnss_ldap.so | grep /etc /etc/libnss-ldap.conf /etc/libnss-ldap.secret
[править] pam_ldap
Необходимо отредактировать конфигурационный файл библиотеки pam_ldap, который расположен в /etc/pam_ldap.conf или другом месте, которое можно определить с помощью команды:
# strings /lib/security/pam_ldap.so | grep /etc /etc/pam_ldap.conf /etc/pam_ldap.secret
[править] smbldap-tools
Скрипты smbldap-tools могут оставаться нацеленными на master-сервер как и раньше. В большинстве своём работа скриптов требует модификации данных в каталоге, поэтому работа в любом случае будет выполняться с центральным сервером (либо сразу, либо после получения referral).
[править] Как проверить
Изменить пароль пользователем в сети отделения. Проверить, изменился ли пароль в центре.
[править] Ошибки при настройке
[править] Использование unix password sync
Может возникнуть мысль вместо того чтобы воспользоваться механизмом ссылок (referral) в LDAP, переложить все задачи по обновлению на скрипты smbldap-tools, которые работают с центральным LDAP-сервером.
Несостоятельность этой мысли выяснится сразу же при попытке поменять пароль пользователем в сети отделения.
Если не указывать директиву updateref в конфигурационном файле slave-сервера LDAP, пароль меняется, но только на локальном сервер отделения и изменения не попадают в центральный каталог.
Попытка воспользоваться механизмом unix password sync в Samba и менять пароль с помощью smbldap-passwd тоже ни к чему не приводит.
В лог-файлах при этом появляются сообщения вида:
[2007/09/05 14:08:50, 0] libsmb/smbencrypt.c:decode_pw_buffer(552) decode_pw_buffer: incorrect password length (1174457325). [2007/09/05 14:08:50, 0] libsmb/smbencrypt.c:decode_pw_buffer(553) decode_pw_buffer: check that 'encrypt passwords = yes'
Этот путь неправильный и по нему идти не следует.
[править] Использование rootdn вместо updatedn
Если в записи updatedn указать идентификатор пользователя rootdn, и, который для записи использует Samba, перенаправление в центр выполняться не будет. Запись будет выполняться непосредственно на LDAP-сервере отделения, что является ошибкой.
[править] Что дальше?
Рассмотреть переход с традиционной репликации с помощью slurpd, которая используется в описанной процедуре, на более прогрессивный механизм LDAP Sync Replication.
[править] Важные замечания по безопасности
Внимательно прочитайте этот раздел прежде чем рассматривать возможность внедрения описанной выше схемы у себя в сети! |
> Все пока работает в лабораторных условиях. > У нас 42 удаленных района (на картинке только 4), в каждом стоит ldap + samba-сервер, и > у каждого района есть администратор, который имеет полный доступ к своей ветке ldap. > Центр на картинке dc=OPFR. > в центре устанавливаю некий linux-сервер (файловый или ftp) и включаю > аутентификацию через ldap, и даю ограниченный доступ районным пользователям. >- > И тут я наткнулся на то, что любой районный админ может его взломать > следующим образом: > в своей ветке ldap у легальной учетки (на картинке user1) сменить uid на 0, > и зайти на центральный сервер этой учеткой, но для сервера этот пользователь > во всем тождественнен root !!! > Если отобрать у админов права на атрибут uid, то они не смогут > создавать своих пользователей. так и есть! Но это не взлом! Это нормальное поведение системы. Они и не должны иметь право создавать пользователей,- юзеры должны создаваться только центральным админом. Обычный админ может подать запрос (через web-интерфейс, через команду или каким-угодно другим способом) на создание учётной записи пользователя. Центральный админ разрешает операцию или отменяет. Пользователь создаётся в центре. Фактически, создание пользователя может выполняться на любой реплике (как и прочая модификация каталога). Автоматически происходит репликация наверх и данные верхнего каталога модифицируются.- Естественно, что можно создать, например, запись с- идентификатором uid = 0 и она разойдётся по всем репликам. Тем самым получить права адмнистратора на всех репликах системы. На локальных репликах ни у кого не должен быть доступ к каталогу с правами администратора, а если он неизбежен, то нужно 1) Или запрещать обновление каталога снизу (с реплик в центр) 2) Или делать поддомены (то есть, отдельные каталоги, которые просто интегрируются в общее дерево) В этой фразе- « > у каждого района есть администратор, который имеет полный доступ к > своей ветке ldap. > Центр на картинке dc=OPFR. » что именно понимается по своей веткой?
[править] Дополнительная информация
- Replication with slurpd (англ.) — глава из руководства по OpenLDAP
[править] Материалы по LDAP на xgu.ru
- LDAP
- Схема LDAP
- LDAP-репликация и Samba
- Squid и LDAP
- Sudo и LDAP
- Jabber и LDAP
- Apache и LDAP
- RADIUS и LDAP
- Asterisk и LDAP
- man-страницы:
- man:ldapadd — добавление записей
- man:ldapdelete — удаление записей
- man:ldapmodify — модификация записей
- man:ldapmodrdn — переименование записей
- man/ldapsearch — поиск записей
Серверы LDAP:
[править] Материалы по Samba на xgu.ru
- Samba
- Samba 4
- Антивирусная защита Samba с помощью ClamAV
- LDAP-репликация и Samba
- Автоматическая смена пароля в Samba