На время начала работ по установке PDC Samba+OpenLDAP мой опыт работы с LINUX-системами был относительно невелик. Одна из причин, вызвавших затруднения в дальнейшем освоении – особенности источников сведений по этой тематике. Пишут их настоящие знатоки, поэтому некоторые аспекты, предельно простые для гуру и неясные для новичка в литературе найти не всегда легко. По многим причинам начальный этап в освоении POSIX-серверов нужно каким-то образом преодолевать. Так или иначе это удалось, мой не самый маленький домен работает, и теперь могу предположить, что полученный опыт поможет кому-то еще.

Исходный рубеж – знания и практика работы с сетевыми службами в различных операционных средах, так же как и знания, позволяющие начать работать с POSIX-системами. Так как развертывать сервер в среде LINUX полностью из командной строки первый раз нелегко (и отпугивает многих – эта статья как раз для них), выбирается дистрибутив, имеющий графические инструменты основных настроек. В моем случае это OpenSUSE 10.3. С учетом возможностей оборудования использовал версию i386. Поскольку в дальнейшем нам нужно будет развертывать резервный контроллер, а также службы, требующие защищенного соединения, в том числе и за пределами локальной сети, предусмотрим возможность шифрования клиентских подключений на основе сертификатов, подписанных собственным СА. Варианты с максимальным упрощением настроек не рассматриваем, чтобы избежать в дальнейшем существенных переделок и остановок сетевых служб в действующем домене. Возможности Samba по использованию перемещаемых профилей, логон-скриптов и т.п. пока не задействуем. Впрочем, можно эти опции настраивать заданным группам пользователей позднее. Следует отметить, что отказаться от перемещаемого профиля получается пока только правкой настроек на Windows-клиенте.

Подготовка рабочей станции к подключению в домен

В этом поможет оснастка MMC «Политика «Локальный компьютер» - Административные шаблоны – система – профили пользователей».

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

Выражаю благодарность авторам использованных программных пакетов, а также авторам публикаций по рассматриваемому вопросу.

По тексту далее. Группы и пользователей, создаваемых нами в linux, будем называть «Posix-группы или пользователи», встроенные бюджеты (учетные записи служб и т.д.) определим как «системные», учетные записи, создаваемые в samba (в форме базы данных OpenLDAP) – samba-пользователи (группы).

Шаг1. Развертывание серверной платформы.

Сервер назовем asles.bgiki.local. Начальный метод регистрации пользователя – локальный, и кроме root никаких учетных записей не создаем. При установке выбираем KDE, файловый сервер, DNS, DHCP, LDAP, в разделе «разработка – базовая разработка» - Perl. Необходимо установить пакеты из состава дистрибутива: openldap2-devel, openssl-certs, pam_cifs, pam_smb, pam-config, pam-modules, pam_ldap, perl-Authen-SASL, Perl-BerkeleyDB, perl-OpenCA-CRL, OpenCA-REQ, perl-OpenCA-X509, perl-Unicode-String, все perl-Crypt, perl-IO-String, perl-ldap, perl-ldap-ssl, Perl-IO-Socket-SSL, perl-Net_SSLeay, perl-Unicode-Map8, libgcrypt, libxcrypt, libnscd, libacl, libmsrpc, libsmbsharemodes, libmspack, компоненты cyrus-sasl, tls, и по желанию - mc, kdeaddons3-kate, gvim. Дополнительные пакеты из репозитория SUSE: openldap2-back-perl, ldapsmb, samba-doc. Вероятно, этот перечень может быть скорректирован путем проб и ошибок.

Примечание: Учитывая README к пакету smbldap-tools версии 0.9.2, а именно фразу: «In the future, some other function may come (like … compliance to RFC2307...)…» нам предстоит сделать выбор схемы каталога – nis.shema – либо более прогрессивная rfc2703bis.schema, но без использования smbldap-tools. Для простоты был выбран вариант с использованием smbldap-tools.

При установленном samba-doc элементы пакета smbldap-tools находим в папке /usr/share/doc/packages/samba/examples/LDAP/smbldap-tools-0.9.2, вероятно, их можно использовать, но по ряду причин мне показалось целесообразным использовать свежую версию пакета, которую можно найти на http://opensuse.org.

Версии smbldap-tools могут несколько отличаться, в том числе по порядку установки. В варианте 0.9.4-3.2 имеются зависимости - 3 компоненты Perl, это rpm-пакет perl-Jcode-2.06-5.1.noarch.rpm и пакеты в исходных текстах Unicode-Map-0.112.tar.gz и Unicode-MapUTF8-1.11.tar.gz.

RPM-пакет найден поиском в Google, тарболы нашлись с помощью http://search.cpan.org.

Конфигурируем сетевую карту для внутренней зоны, IP-адрес статический. Открываем в брэндмауэре серверы LDAP, samba, dns, а также те порты, что могут быть необходимы в нашей конфигурации. Настроим сервер DNS.

Шаг2. Установка smbldap-tools.

Устанавливаем perl-Jcode:

#rpm -Uvh perl-Jcode-2.06-5.1.noarch.rpm

Распаковываем вышеуказанные пакеты Unicode-*.tar.gz в /usr/src/packages/sources, в раздельные каталоги и далее поступаем согласно документу INSTALL, где указано, что сборка и установка заключается в последовательном выполнении четырех команд:

#perl Makefile.PL
#make
#make test ;-соответственно проследим, нет ли ошибок,
#make install

При установке из исходных текстов в базе RPM сведений о пакетах не будет, поэтому при

#rpm -Uvi smbldap-tools-0.9.4-3.2.noarch.rpm

получим ответ:

error: Failed dependencies:
perl(Unicode::Map) is needed by smbldap-tools
perl(Unicode::MapUTF8) is needed by smbldap-tools

Важно убедиться, что RPM не затребовал еще каких-нибудь зависимостей. Если нет, то повторяем установку с опцией --nodeps:

#rpm -Uvi --nodeps smbldap-tools-0.9.4-3.2.noarch.rpm

Чистим каталог …/sources/… по завершении установки пакетов.

Шаг3. Настройка SSL.

Корректируем /etc/ssl/openssl.conf – сведения о организации – чтобы меньше заполнять впоследствии при формировании подчиненных сертификатов. Правда, при создании корневого сертификата (СА) придется их все же один раз набрать. В YaST «пользователи и безопасность - управление СА» создадим корневой сертификат. Указываем необходимые опции - страну, город, срок действия сертификата. В том числе нужно определить общее имя (common name) как имя машины, на которой и в дальнейшем будет запускаться Центр сертификации. В закладке «дополнительные параметры – Key Usage» отметим опцию «digital Signature»:

Готовим сертификат для сети учебного учреждения

Указываем пароль, и отрабатываем «далее» - до закрытия вкладки. Корневой сертификат будет сформирован. При повторном открытии того же инструмента требуется выделить CA в дереве CA tree, и нажать клавишу «Enter CA», после чего будет предложено набрать пароль корневого сертификата. В открывшейся форме, перейдя во вкладку «Сертификаты» формируем сертификат для компьютера, на котором развернем PDC («добавить – добавить сертификат сервера»). Общее имя сертификата должно соответствовать полному имени сервера, переименовывать потом машину – обладатель сертификата будет нежелательно. Сертификат сохраняем в файл, выбрав клавишу «Экспорт» например, /root/docs/security/asles.p12, причем в формате «как PKCS12 и включая СА цепочку» (и закрыт паролем). На будущем PDC используя вкладку YaST «пользователи и безопасность - общий сертификат сервера» импортируем asles.p12 из файла.

Примечания:

Шаг4 . Запуск LDAP.

Открываем вкладку YaST «сетевые службы - сервер LDAP - настройка - общие настройки - файлы схем». Установим опцию автозапуска сервера при загрузке. Добавляем или проверяем наличие схем - core.schema, cosine.schema, nis.schema, inetorgperson.schema, misc.schema, samba3.schema, yast.schema, ppolicy.schema. Последняя – только по причине того, что она есть в данном дистрибутиве, - отчего бы не использовать.

Перейдем на вкладку «базы данных - добавить базу данных», создаем базу, dn базы, например, dc=bgiki,dc=edu, dc=ru, далее dn корневого объекта - cn=Administrator,dc=bgiki,dc=edu,dc=ru, строкой ниже задаем ему пароль. Выбрав клавишу «Принять» сохраним созданную корневую конфигурацию LDAP. Снова включаем YaST «сетевые службы- сервер LDAP - конфигурирование – общие настройки - TLS настройки - TLS Активация» - выбираем «Да» в ее настройках. Для TLS-шифрования нужен ключ и сертификат к нему, поэтому выбираем в той же вкладке опцию «Выбрать сертификат» - настраиваем на использование общего сертификата сервера. YaST сформирует эти файлы и поместит их:

Запустим демон LDAP:

#rcldap start

и по выводу сообщения «done» убедимся, что он запущен.

Открываем вкладкуYaST «сетевые службы - клиент LDAP» и устанавливаем подключение к нашему серверу:

Настройка клиента LDAP в графической форме

В закладке «дополнительная настройка - настройки администратора» впишем (или проверим наличие) DN администратора LDAP. В этой же закладке указываем опцию «Создать конфигурационные объекты по умолчанию», в результате будет создан контейнер LDAP «ou=ldapconfig,dc=…». В закладке «настройки клиента» проверим контекст именования:

Клавишей «принять» сохраняем конфигурацию клиента. При открытии инструмента «сервер LDAP» настраиваем политику паролей (добавить политику – место хранения – в контейнере ou=ldapconfig…) и определяем срок действия пароля в днях, таймаут блокировки при заданном количестве ошибок набора пароля и другие. Скажу сразу, что объект политики в каталоге не виден, но соответствующая строка в slapd.conf появится.

Открываем вкладкуYaST «сетевые серверы - Обозреватель LDAP», проверяем открытие каталога.

Создаем файл /etc/ldap.secret, и вносим в него пароль корневой учетной записи базы cn=Administrator,dc=bgiki,dc=edu,dc=ru:

#echo "пароль" > /etc/ldap.secret

Тестируем созданное:

#rcldap restart ;-перезапуск ldap
#ps aux | grep slapd ;-вернет сведения о запущенном демоне
#netstat -nap | grep slapd ;-вернет информацию о готовности к соединению демона slapd, нас интересует факт открытия tcp-порта 389 из источников 0.0.0.0 и 127.0.0.1 с докладом «LISTEN».

Наличие графических инструментов не отменяет необходимости чтения системных руководств, например:

#man slapd.conf

Вышеуказанные конфигурации текстуально отображены в скриптах /etc/openldap/slapd.conf – сервера LDAP и /etc/ldap.conf – клиента LDAP. Приведем наиболее существенные строки из их содержания.

slapd.conf:

pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
# ссылка на динамические модули:
modulepath /usr/lib/openldap/modules
#Начальные настройки доступа к каталогу
access to attrs=SambaLMPassword,SambaNTPassword
by dn="cn=Administrator,dc=bgiki,dc=edu,dc=ru" write
#; by dn="cn=root,ou=People,dc=bgiki,dc=edu,dc=ru" write
#; by dn="cn=proxyuser,ou=People,dc=bgiki,dc=edu,dc=ru" read
by * none
## Yast2 samba hack ACL done
access to dn.base=""
by * read

access to dn.base="cn=Subschema"
by * read

access to attrs=userPassword,userPKCS12
by self write
by * auth

access to attrs=shadowLastChange
by self write
by * read

access to *
by * read
###########################################################
# BDB database definitions – определения базы данных
###########################################################
loglevel 0 #может быть до 10, если нужно
TLSCipherSuite :SSLv3
#переименовал YaST-CA.pem, это необязательное действие
TLSCACertificateFile /etc/ssl/certs/CA.pem
TLSCertificateFile /etc/ssl/servercerts/servercert.pem
TLSCertificateKeyFile /etc/ssl/servercerts/serverkey.pem
database bdb
suffix "dc=bgiki,dc=edu,dc=ru"
rootdn "cn=Administrator,dc=bgiki,dc=edu,dc=ru"
#;rootdn "cn=root,ou=People,dc=bgiki,dc=edu,dc=ru"
rootpw "{ssha}хеш сгенерируется автоматически при настройке сервера"
directory /var/lib/ldap/
checkpoint 1024 5
cachesize 10000
#параметры поиска объектов в какталоге
index objectClass,uidNumber,gidNumber eq
index member,mail eq,pres
index cn,displayname,uid,sn,givenname sub,eq,pres
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
#
overlay ppolicy
ppolicy_default "cn=Default Policy,ou=ldapconfig,dc=bgiki,dc=edu,dc=ru"

ldap.conf:
#URL хоста,-не IP-адрес, потому что работает с сертификатом
host asles.bgiki.local
base dc=bgiki,dc=edu,dc=ru
uri ldap://127.0.0.1/
#uri ldaps://127.0.0.1/ #сможем включить позднее
#uri ldapi://%2fvar%2frun%2fldapi_sock/
ldap_version 3
#;binddn cn=proxyuser,ou=People,dc=bgiki,dc=edu,dc=ru
#;bindpw пароль проксиюзера открытым текстом наберем позднее

# Password is stored in /etc/ldap.secret
rootbinddn cn=Administrator,dc=bgiki,dc=edu,dc=ru
#;rootbinddn cn=root,ou=People,dc=bgiki,dc=edu,dc=ru
port 389
#без этих таймлимитов возникают ошибки nss_ldap, с ними тоже, но реже
timelimit 30
bind_timelimit 30

# Reconnect policy и прочие policy,
bind_policy soft
nss_connect_policy persist
idle_timelimit 3600
nss_paged_results yes
pagesize 1000

# Filter to AND with uid=%s
pam_filter objectclass=account
pam_login_attribute uid

# диапазон разрешенных UID
pam_min_uid 1000
pam_max_uid 60000

pam_password exop

nss_initgroups_ignoreusers root,ldap

# Enable support for RFC2307bis (distinguished . . .
#nss_schema rfc2307bis – и все же когда-нибудь мы это включим...

# NDS mappings
nss_map_attribute uniqueMember member

# OpenLDAP SSL mechanism – пока это главное
ssl start_tls
pam_filter objectclass=posixAccount
#следующие три строки сгенерируются при соответствующей настройке
#клиента LDAP, а в конечном варианте ?one ограничивает глубину запроса:
nss_base_passwd ou=People,dc=bgiki,dc=edu,dc=ru?one
nss_base_shadow ou=People,dc=bgiki,dc=edu,dc=ru?one
nss_base_group ou=Group,dc=bgiki,dc=edu,dc=ru?one
#позволяет работать с самоподписанным сертификатом:
tls_checkpeer no
#ssl on
# OpenLDAP SSL options
# Пока нас устраивает только start_tls, SSL в чистом виде не включаем,
# следовательно ниже закомментировано
#tls_checkpeer yes
# CA certificates for server certificate verification
# At least one of these are required if tls_checkpeer is "yes"
#tls_cacertfile /etc/ssl/CA.pem
#tls_cacertdir /etc/ssl/certs

# Seed the PRNG if /dev/urandom is not provided
#tls_randfile /var/run/egd-pool

# Client certificate and key. Пока задействуем уже созданную
# ключевую пару, скопировав ее в папку /etc/ssl/ldap/:
tls_cert /etc/ssl/ldap/servercert.pem
tls_key /etc/ssl/ldap/serverkey.pem

Конфигурационный файл, где указан порядок поиска учетных записей - nsswitch.conf:

passwd: compat #в соответствии с определением passwd_compat
shadow: files #теневые пароли – см. [4]
group: files ldap
hosts: files mdns4_minimal [NOTFOUND=return] dns
networks: files dns
services: files ldap
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files ldap
publickey: files
bootparams: files
automount: files nis
aliases: files ldap
passwd_compat: ldap

Шаг5. Запуск Samba - сервера.

Открываем вкладку YaST «сетевые службы - сервер Samba», во вкладке «загрузка» установим опцию автозапуска сервера, во вкладке «общие ресурсы» проверим наличие netlogon, во вкладке «идентификация» установим имя домена и роль контроллера – PDC. Там же перейдем в «дополнительные настройки-способ идентификации пользователя» и выставим параметр LDAP и значение – ldap://127.0.0.1. Настройки сохранятся при закрытии инструмента, при этом будет предложено набрать пароль администратора samba-сервера.

После завершения работы в графической утилите используем текстовый редактор для правки секции глобальных настроек файла smb.conf:

[global]
workgroup = BGIKI
server string = BGIKI_PDC
map to guest = Bad User
security = user
domain logons = Yes
domain master = Yes
logon path = ""
logon home = ""
os level = 255
preferred master = Yes
# пока разрешаем заходить только из нашей сетки
hosts allow = 10.31.99. 127.0.0.
# так как нет другого wins, включим свой:
wins support = yes
log level = 1
log file = /var/log/samba/log.%m
max log size = 100000
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

# опции для LDAP
passdb backend = ldapsam:ldap://127.0.0.1/
ldap admin dn = cn=Administrator,dc=bgiki,dc=edu,dc=ru
#;ldap admin dn = cn=root,ou=People,dc=bgiki,dc=edu,dc=ru
ldap suffix = dc=bgiki,dc=edu,dc=ru
ldap group suffix = ou=Group
ldap idmap suffix = ou=Idmap
ldap machine suffix = ou=Computers
ldap user suffix = ou=People
ldap passwd sync = Yes
ldap ssl = Start_tls
ldap timeout = 15
ldap delete dn = No
#manage users from Win tools
add machine script = /usr/sbin/smbldap-useradd -a -w "%u"
add user script = /usr/sbin/smbldap-useradd -a -m "%u"
delete user script = /usr/sbin/smbldap-userdel "%u"
add group script = /usr/sbin/smbldap-groupadd -p "%g"
delete group script = /usr/sbin/smbldap-groupdel "%g"
add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g"
delete user from group script = /usr/sbin/smbldap-groupmod -x "%u" "%g"
set primary group script = /usr/sbin/smbldap-usermod -g %g %u

Добавим пароль корневой записи администратора ldap в samba:

#smbpasswd -wЕгоПароль

Проверяем конфигурационный файл smb.conf с помощью команды testparm и перезапустим демон:

#rcsmb restart

проверим, какие порты прослушивает smbd:

#netstat -nap | grep smbd

проверим доступность ресурсов samba:

#smbclient -L localhost –U administrator

вернет информацию о доступных ресурсах samba (если ошибка – ставим log level = 2 и читаем сообщения из /var/logs/).

Шаг 6. Подготовка конфигурационных файлов smbldap-tools.

Сертификаты, сформированные для LDAP-TLS временно используем и для smbldap-tools. Для этого из папки /etc/ssl/servercerts файлы servercert.pem и serverkey.pem копируем в /etc/smbldap-tools. Попытки использовать указанные server*.pem из общего каталога совместно smbldap-tools и slapd к успеху не привели, поэтому и используются те же сертификаты, но для smbldap-tools они будут использоваться из отдельного каталога.

Получим SID домена:

#net getlocalsid – вернет SID домена

Используем файл configure.pl. Для этого его из /usr/share/doc/packages/smbldap-tools копируем в /usr/sbin - и запускаем. На консоль будут выводиться вопросы и в большинстве пунктов значение параметра по умолчанию - если мы согласны с этим значением, то просто нажимаем "Enter". В результате сформируются конфигурационные файлы в каталоге /etc/smbldap-tools. Проверяем текст smbldap.conf и smbldap_bind.conf, при этом:

ldapTLS="1" -потому что мы TLS уже включили,
cafile="/etc/ssl/certs/CA.pem",
clientcert="/etc/smbldap-tools/servercert.pem"
clientkey="/etc/smbldap-tools/serverkey.pem"
suffix="dc=bgiki,dc=edu,dc=ru"
#dn, где мы собираемся учитывать компьютеры, группы, пользователей:
usersdn="ou=People,${suffix}"
computersdn="ou=Computers,${suffix}"
groupsdn="ou=Group,${suffix}"
idmapdn="ou=Idmap,${suffix}",
#Размещение счетчика UID/GID:
sambaUnixIdPooldn="sambaDomainName=BGIKI,${suffix}"
# Алгоритм шифрования:
hash_encrypt="SSHA"
#Опция, повышающая криптостойкость хеша – в просторечии «соль»
crypt_salt_format="%s"

#Настройки шаблонов – например, простейшие:
userSmbHome="".""
userProfile="".""
userHomeDrive=""
userScript=""

И последнее – в файле smbldap-bind.conf будет текущий пароль администратора каталога для ведомого и ведущего сервера, и так как у нас это один и тот же сервер – то и повторится он дважды, в формате plain-text.

Теперь используя YaST нужно создать Posix-группы для домена, с корректировкой GID - ntadmins gid=512, mashines gid=515, ntguests gid=514, ntusers gid=513.

Примечание: posix-группы «nt*» и «mashines» будут «привязываться» (mapping) к созданным в каталоге LDAP объектам домена. Известно, что у Windows – группы имеется SID (идентификатор Microsoft), этот SID в целях эмуляции контроллера Windows “привязывается” к posix-группе командой net groupmap add. При определении gid posix-группам со значением по умолчанию у меня как раз и не получалось исполнить этот mapping – пока не вписал posix gid равным последним трем цифрам windows- классификатора, как и указано выше, в результате привязка упростилась.

Шаг7. Заполнение каталога openldap.

Выполняем команду из комплекта smbldap-tools:

#smbldap-populate

Далее увидим список созданных объектов, в завершение утилита предложит сформировать пароль нового администратора домена (его dn: cn=root,ou=People.. и т.д.).

Примечание: Если что-либо не выходит, чаще всего ошибка заключается в настройках TLS.

Проверив привязку групп, убедимся, что mapping получился автоматически:

#net groupmap list
Domain Admins (S-1-5-21-. . .111-512) -> ntadmins

и т.д.

Даём группе Domain Admins необходимые права:

#net rpc rights grant
"Domain Admins"
SeMachineAccountPrivilege
SeTakeOwnershipPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeRemoteShutdownPrivilege
SePrintOperatorPrivilege
SeAddUsersPrivilege
SeDiskOperatorPrivilege -Uroot

Используя YaST, создаем posix-пользователя с именем - для примера - adminchik, проверяем, что ему присвоен uidNumber 1000 , включаем его в posix-группу ntadmins и в командной строке создаем для него учетную запись samba:

#smbldap-useradd -m "adminchik"

С этой учетной записью сможем выполнять административный вход на клиентские машины. Cоздадим posix – запись контроллера домена, имя заканчивается знаком $.

#adduser -n -g machines -d /dev/null -s /bin/false asles$

Добавим контроллер в домен:

#net join

запросит пароль администратора.

Производим конфигурирование модулей pam последовательно двумя вызовами команды pam-config:

#pam-config -a --unix2
#pam-config -a --ldap

после чего утилитой YaST "система - управление службами" включим pamsmbd. Перезапустим ldap и smbd, проверим:

#getent passwd

вернет список пользователей.

Сформируем хеш для пользователя proxyuser:

# slappasswd -v -s ParolProxyUzera -h {SSHA} –c %s

используем его для параметра userPassword при создании файла proxy.ldif, вот его текст:

dn: cn=proxyuser,ou=people,dc=bgiki,dc=edu,dc=ru
cn: proxyuser
sn: proxyuser
objectclass: top
objectclass: person
userPassword: {SSHA}U0k4II20PybууUwAlDxRееhGW4diAI5+

Модифицируем каталог:

#ldapmodify -a –v -f proxy.ldif -D "cn=administrator,dc=bgiki,dc=edu,dc=ru" -x –W

В соответствующей ветке каталога появится запись, с помощью которой схема авторизации будет читать пароли. У нас появится возможность не указывать пароль администратора каталога простым текстом в файле ldap.secret при повседневной работе сервера. К сожалению, эта уязвимость еще остается в smbldap_bind.conf.

Произведем смену администратора LDAP в конфигурации, для этого:

а) Используя YaST «сетевые службы - сервер LDAP - настройка – база данных –…», изменим dn администратора на имя cn=root,ou=People…и введем новый пароль.

б) Правим файл slapd.conf, текстовым редактором в подразделе # Yast2 samba hack ACL — изменим на dn нового администратора, и добавим права proxyuser:

access to attrs=SambaLMPassword,SambaNTPassword
by dn="cn=root,ou=people,dc=bgiki,dc=ru" write
by dn="cn=proxyuser,ou=people,dc=bgiki,dc=ru" read
by * none

Примечание: после вышеуказанных правок нужно с осторожностью пользоваться графической утилитой YaST-samba, поскольку в ней есть свой шаблон, отличающийся от приведенных настроек.

в) Правим файл ldap.conf:

г) Правим файл smb.conf, где изменим значение ldap admin dn.

Бюджет нового администратора нужно учесть в базе учетных записей samba:

#smbpasswd –wЕго_Пароль

после чего перезапустим smbd и slapd.

д) Правим файл smbldap_bind.conf путем редактирования dn администратора и его пароля.

Создадим posix- учетную запись клиентского компьютера, подключаем его в домен – если операционная система Windows, то так же, как в домене Microsoft, с учетной записью «root». И для компьютеров и для пользователей требуется создавать posix-учетные записи, после чего можно заполнять данные в samba. С клиентской машины посредством утилиты Usrmgr.exe производства Microsoft (из дистрибутива NT4.0 –сервера – на сайте производителя тоже есть) администрируем учетные записи samba.

Создадим группу для последующего допуска к некоторому ограниченному ресурсу. Для этого сначала создадим posix-группу:

#groupadd konsplususers

Или выполним ту же процедуру инструментом YaST.

Создадим группу в samba:

#smbldap-groupadd -p konsplususers

используя YaST убедимся, что gid в перечне ldap и posix совпадают, если нужно, поправим.

Другой способ – создадим группу в каталоге ldap, запросит пароль администратора

#net rpc group add konsplususers
Password:

и свяжем ее с заранее созданной posix-группой

#net groupmap add rid=1003 ntgroup="konsplususers" unixgroup=konsplususers
Unix group konsplususers already mapped
to SID S-1-5-21-147838798-37688190-2313965735-1097

Добавим posix-пользователя в созданную posix-группу, создадим его бюджет в сервере samba, и уже в файл-сервере он получит права на предоставленный группе ресурс – чего и добивались.

Если это получилось, значит, еще один боец IT-фронта готов к выходу из под пресса монополистов проприетарного ПО.

Теперь самым насущным делом становится укрепление защищенности сервера, резервное копирование, развертывание на POSIX-платформе файл-сервера и почтового сервера, конечная цель - система управления учреждением на базе Open Source.

Литература:

1. Григорьев Михаил Настраиваем OpenLDAP сервер и клиент с поддержкой SSL.
Date: Tue, 19 Apr 2005 http://www.unixdoc.ru/print.php?print_id=123

2. Vsevolod Stakhov <cebka[at]jet[dot]msk[dot]su>
Настройка OpenLDAP и его взаимодействиия с сетевыми сервисами. Date: Mon, 5 Dec 2005 Оригинал: http://cebka.pp.ru/my/openldap.txt. Статья впервые опубликована в журнале "Системный Администратор".

3. From: CoderInside <coder@linuxportal.vrn.ru.>Date: Mon, 24 Apr 2007 Subject: SAMBA PDC - установка, настройка, управление (Slackware) Оригинал: Воронежский Linux портал.

4. Алексей Барабанов <alekseybb at mail dot ru>. Размещение пользовательских бюджетов в LDAP. Москва, октябрь-декабрь 2006.

5. Настройка OpenLDAP и его клиентов. http://www.freesource.info/wiki/ALTLinux/Dokumentacija/OpenLDAP

6. Настройка Samba 3 (PDC) с пользователями в LDAP каталоге.
From: Crux Date: Mon, 20 Sep 2004 Оригинал: http://www.unix.nordcomp.ru/articles.html?page=2&id=17

7. OpenLDAP и TLS/SSL, http://www.freesource.info/wiki/ALTLinux/Dokumentacija/OpenLDAP/TLS

8. Иван Максимов. Организуем сетевой календарь в корпоративной среде. Журнал "Системный Администратор" №2- 2008 год.