На время начала работ по установке 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 из файла.
Примечания:
- Те же результаты могут быть достигнуты средствами командной строки.
- Возможности получения CA, подписанного авторитетным центром сертификации
рассмотрены в работе Ивана Максимова [8].
Шаг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 сформирует эти файлы и поместит
их:
- корневой сертификат: /etc/ssl/certs/YaST-CA.pem
- сертификат сервера LDAP: /etc/ssl/servercerts/servercert.pem
- ключ сервера LDAP: /etc/ssl/servercerts/serverkey.pem
Запустим демон LDAP:
#rcldap start
и по выводу сообщения «done» убедимся, что он запущен.
Открываем вкладкуYaST «сетевые службы - клиент LDAP» и устанавливаем
подключение к нашему серверу:
Настройка клиента LDAP в графической форме
В закладке «дополнительная настройка - настройки администратора» впишем (или
проверим наличие) DN администратора LDAP. В этой же закладке указываем опцию
«Создать конфигурационные объекты по умолчанию», в результате будет создан
контейнер LDAP «ou=ldapconfig,dc=…». В закладке «настройки клиента» проверим
контекст именования:
- отражение пользователя(user map) ou=people,…
- отражение пароля (password map) ou=people,…
- отражение группы (group map) ou=group,…
Клавишей «принять» сохраняем конфигурацию клиента. При открытии инструмента
«сервер 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, при этом:
- SID домена должен соответствовать выводу команды net getlocalsid
- Slave и Master LDAP server - это один и тот же наш сервер, его IP- адрес
127.0.0.1
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:
- изменим запись rootbinddn
- раскомментируем строку binddn, где указан proxyuser, не забываем указать
его пароль строкой ниже.
г) Правим файл 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.
| 
