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

Здесь стоит отметить один момент: у нас служба контроллера домена построена на базе Samba и базируется на ветке '3.0.х' этого продукта. Связка Samba+OpenLDAP на основном сервере была настроена в 2007-м году и с тех пор пор претерпевала лишь минорные обновления версий, которые закрывали найденные уязвимости в безопасности протокола. Иначе говоря, несмотря на установленные последние версии Samba, базовый функционал продукта соответствовал состоянию примерно на 2007 год. Попытки решить проблему «в лоб» (ставить машины с «семеркой» в домен Samba 3.0, аналогично XP) не увенчались успехом, а чтение документации и поиск по форумам выявил проблему принципиальной несовместимости «старых» (в кавычках) версий Samba и последних операционных систем от Microsoft.

Необходимость обновления вызывала вполне понятные опасения насчёт совместимости с уже работающими клиентами; не очень-то хотелось прерывать работу предприятия на несколько часов, пытаясь разобраться, что же пошло не так, или из-за изменившихся параметров доменной авторизации повторно ставить в домен почти сотню машин основного филиала. Положение упрощал тот факт, что база учётных записей пользователей находилась в LDAP и при неблагоприятном развитии событий, по крайней мере, можно было не беспокоиться насчёт пользовательских данных. Поэтому, для экспериментов была настроена тестовая машина с параметрами, аналогичными рабочему контроллеру домена, скачаны последние стабильные версии (я выбрал ветку '3.5') и всё сначала проверялось на ней…

В основном, мои опасения не оправдались и обновление на тестовом (а в последующем, и на действующем) контроллере домена с '3.0.36' до '3.5.3' сборки команды SerNet не вызвали особых проблем. Обновление производилось стандартным способом (установка бинарных пакетов через «rpm -Uvh …»). Имеющиеся клиенты «прозрачно» подхватили новый домен и продолжили работу, как обычно. Машины с Windows 7 теперь нормально авторизуются и работают в домене.

Вот основные подводные камни, с которыми мне пришлось столкнуться при обновлении:

На каком-то этапе развития Samba от ветки '3.0' до '3.4' сменился формат TDB-файлов и у меня создалось впечатление, что заявленная автоматическая конвертация срабатывает не всегда корректно. Я сохранил SID-ы («net getlocalsid», «net getdomainsid») и удалил все TDB-файлы из /etc/samba. После обновления я восстановил значения («net setlocalsid», «net setdomainsid») и задал права доступа к LDAP-базе через 'smbpasswd';

В новых версиях по умолчанию включен доступ к LDAP по SSL. В моём случае, используется незашифрованное соединение к базе на localhost, поэтому пришлось отключить шифрование («ldap ssl = off» в '/etc/samba/smb.conf');

На RHEL4 не удалось обновить пакет 'samba3-cifsmount' из-за отсутствующей в дистрибутиве (по умолчанию) библиотеки 'libkeyutils'. По этой же причине, при проверке сигнатур RPM-пакетов выдаются предупреждения, которые можно проигнорировать. В версии для RHEL5/CentOS5 всё нормально. Для меня монтирование SMB-каталогов с RHEL4-машины не является критичным, поэтому я не стал разбираться с этим вопросом;

Для нормальной работы Windows 98 в '/etc/samba/smb.conf' нужно включить опцию «lanman auth = yes» (теперь она по умолчанию отключена). Это сработало только с основным контроллером домена, но lanman-аутентификация на другом Samba-сервере, который является членом домена и проверяет авторизацию на контроллере домена через winbind, не работает. У меня в сети всего одна машина с Windows 98, поэтому для меня это также не критично;

Для успешной авторизации машины с Windows 7 перед включением в домен я использовал REG-файл, идущий в поставке Samba ('Win7-Samba3DomainMember.reg'). Подробности смотрите здесь и здесь;

В '3.5.3' перестал работать «UsrMgr», в последующей версии обещали починить; я ещё не успел проверить недавно выпущенную '3.5.4', возможно, там эта ошибка уже исправлена.

linux, network