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

Контроллер домена на SAMBA за семь шагов

Нашел тут весьма интересную статью Сергея Воронцова о настройке контроллера домена под линуксом с помощью пакета samba.

На время начала работ по установке 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 из файла.


Примечания:



  1. Те же результаты могут быть достигнуты средствами командной строки.

  2. Возможности получения 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 корневого объекта - dn=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 "система - управление службами" включим amsmbd.
Перезапустим 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.


Литература:


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 год.

Комментариев нет: