Итак на моем рабочем компе навернулась Windows 7 и я решил заменить ее на Ubuntu 14.04.
Установил Ubuntu 14.04 Server x64, затем установил KDE desktop:
sudo apt-get update && sudo apt-get install kubuntu-dekstop
Введение в домен AD
Сначала нужно сделать несколько подготовительных вещей.
1. Убедиться что имя локального пользователя Ubuntu не совпадает с именем доменного админа.
2. Прописать DNS и DNS-суффикс в настройках сетевого соединения. В новых версиях Ubuntu эти параметры задаются для сетевых интерфейсов и прописываются в /etc/network/interfaces.
# The primary network interface auto eth0 iface eth0 inet static address _IP_ADDRESS_ netmask _NETMASK_ gateway _GW_IP_ADDRESS_ dns-nameservers IP_DNS1_ _IP_DNS2_ dns-domain domain.name dns-search domain.name
Теперь можно установить необходимое ПО и ввести Ubuntu в домен.
Я использовал Power Broker Open Edition - http://download1.beyondtrust.com/Technical-Support/Downloads/PowerBroker-Identity-Services-Open-Edition/?Pass=True.
Этот пакет - коммерческий аналог likewise-open. Я ставлю бесплатную версию, которая несколько менее функциональна, чем платная - частности она не поддерживает GPO.
Скачал и установил:
wget http://download1.beyondtrust.com/Technical-Support/Downloads/PowerBroker-Identity-Services-Open-Edition/pbiso/850/pbis-open-8.5.0.153.linux.x86_64.deb.sh chmod a+x pbis-open-8.5.0.153.linux.x86_64.deb.sh sudo ./pbis-open-8.5.0.153.linux.x86_64.deb.sh
При установке на вопрос о “legacy links” я ответил No.
После установки сразу можно вводить машину в домен AD:
sudo /opt/pbis/bin/domainjoin-cli join --disable ssh domainName ADjoinAccount
Тут domainName - имя домена (должно нормально резолвиться), а ADjoinAccount - имя доменной учетной записи, имеющей права на ввод машины в домен.
Теперь нужно немного отредактировать файлик /etc/pam.d/common-session. Там находим строчку session sufficient pam_lsass.so, комментируем ее и в самый конец файла дописываем:
session [success=ok default=ignore] pam_lsass.so
В конец файла эту строку нужно помещать для того, чтобы нормально отрабатывали опциональные модули, а без success=ok default=ignore пользователя будет пускать в систему, но KDE можно будет запустить только после логина вручную.
После этого можно входить в систему с учетной записью, но по умолчанию KDE не предлагает вводить имя пользователя, а предлагает выбрать пользователя машкой и вводить пароль.
Отключить такое безобразие можно:
“Пуск” → Computer → System Settings → Login Screen (Light GDM).
Там выбираем тему Classic.
Все.
Теперь можно перезагрузиться и логиниться с доменной учетной записью.
ВВодить имя можно как в виде DOMAIN\username, так и в виде Username@domain.local
Все. Дальше можно работать в домене. :) Логиниться с учетной записью вида: DOMAIN\user как локально, так и по SSH.
Некоторые дополнительные настройки
Список настраиваемых параметров PBIS можно получить командой:
/opt/pbis/bin/config --list [Eventlog] AllowDeleteTo AllowReadTo AllowWriteTo MaxDiskUsage MaxEventLifespan MaxNumEvents [Lsass] DomainSeparator SpaceReplacement EnableEventlog LogInvalidPasswords Providers [Lsass - PAM] DisplayMotd PAMLogLevel UserNotAllowedError [Lsass - Active Directory provider] AssumeDefaultDomain CreateHomeDir CreateK5Login SyncSystemTime TrimUserMembership LdapSignAndSeal LogADNetworkConnectionEvents NssEnumerationEnabled NssGroupMembersQueryCacheOnly NssUserMembershipQueryCacheOnly RefreshUserCredentials CacheEntryExpiry DomainManagerCheckDomainOnlineInterval DomainManagerUnknownDomainCacheTimeout MachinePasswordLifespan MemoryCacheSizeCap HomeDirPrefix HomeDirTemplate RemoteHomeDirTemplate HomeDirUmask LoginShellTemplate SkeletonDirs UserDomainPrefix DomainManagerIgnoreAllTrusts DomainManagerIncludeTrustsList DomainManagerExcludeTrustsList RequireMembershipOf SmartcardEnabled SmartcardRequiredForLogin [Lsass - Local provider] Local_AcceptNTLMv1 Local_HomeDirTemplate Local_HomeDirUmask Local_LoginShellTemplate Local_SkeletonDirs [User Monitor] UserMonitorCheckInterval [System Initialization] LsassAutostart EventlogAutostart GpagentAutostart
Чтобы не добавлять название домена к имени учетной записи при регистрации достаточно активировать “AssumeDefaultDomain”.
sudo /opt/pbis/bin/config AssumeDefaultDomain true
Проверить текущую установку можно так:
$ sudo /opt/pbis/bin/config --detail AssumeDefaultDomain $ sudo /opt/pbis/bin/config --show AssumeDefaultDomain
При использовании этой опции в /etc/sudoers и в /etc/passwd - с именем домена (pre-Windows200) в формате DOMAIN_NAME\username с одним слешем. В обоих файлах должно быть одинаково. Если добавлять только в sudoers, то надо добавлять без имени домена.^
Также можно добавить доменного пользователя в файлик /etc/sudoers, для того, чтобы работал sudo.
Открываем /etc/sudoers и добавляем туда:
DOMAIN\\username ALL=(ALL:ALL) ALL
Тут нужно обратить внимание на двойной слеш в качестве разделителя \\. Без него не работает.
Например, для добавления доменных админов нужно добавить строку:
%DOMAIN\\domain^admins ALL=(ALL:ALL) ALL
Обращаем внимание на двойной слеш \\ и на ^ вместо пробела.
Еще может понадобиться заменить shell (/bin/sh), устанавливаемый по-умолчанию на /bin/bash.
Чтобы это сделать выполняем:
sudo /opt/pbis/bin/config LoginShellTemplate /bin/bash
Автоматическое монтирование ресурсов - pam.mount
Теперь можно настроить автоматическое монтирование сетевых ресурсов, например папки с профилем пользователя.
Тут возникает небольшое затруднение. Монтировать ресурсы можно только от имени суперпользователя. Поэтому нельзя просто положить в rc.local строку вида mount -t cifs //server /mountpoint.
К счастью есть PAM-модуль pam_mount, который позволяет монтировать ресурсы с повышенными привилегиями на этапе входа пользователя в систему.
Устанавливаем модуль:
sudo apt-get install libpam-mount
Оказалось, что с установками по-умолчанию модуль pam_mount.so не монтирует ресурсы. Для того, чтобы модуль работал корректно, нужно отредактировать файл /etc/pam.d/common-session.
По-умолчанию, модуль pam_mount.so имеет флаг optional и располагается в файле /etc/pam.d/common-session после модуля pam_lsass.so, который имеет флаг sufficient. Таким образом модуль опциональный модуль pam_mount.so игнорируется, при корректном прохождении достаточного для аутентификации модуля pam_lsass.so.
Дальше конфигурируем pam_mount. При входе пользователя обрабатываются два файла - глобальный /etc/security/pam_mount.conf.xml и файл ~/.pam_mount.conf.xml с ресурсами, монтируемыми индивидуально каждому пользователю.
Этот файл довольно неплохо откомментирован, поэтому подробно описывать не имеет смысла и реально нужно редактировать единственную строку:
<volume fstype="cifs" server="servername" path="shared" mountpoint="~/shared" options="nodev,nosuid"/>
Соотвественно отредактировать параметры server, path и mountpoint.
При этом, path не должне начинаться с “/”, а сразу указывать на папку, но при этом может указывать на вложенную папку. То есть если в Windows адрес файла: \\server\shared\directory1\file.txt, то для того чтобы он был виден в смонтированной папке - path должен быть path=“shared\directory1”.
Pam_mount и сессия SSH
Для того, чтобы pam_mount корректно работал в сессии SSH нужно отредактировать конфигурацию сервера SSH - файл /etc/ssh/sshd_config.
Параметру ChallengeResponseAuthentication дать значение no.
Без этой правки, из-за особенностей работы OpenSSH при подключении по SSH ресурсы не монтируются с помощью pam_mount с ошибкой:
conv->conv(...): Conversation error
Некоторые подробности тут:
http://community.centrify.com/t5/DirectControl-Express-for-UNIX/Try-to-auto-mount-cifs-home-dir-on-Ubuntu-using-Centrify-AD-Pam/td-p/8640
https://bugzilla.mindrot.org/show_bug.cgi?id=926#c35
https://bugzilla.mindrot.org/show_bug.cgi?id=688
Также, это неприятное обстоятельство можно обойти выполнив в сессии SSH команду:
su -l $USER
То есть фактически залогинившись в сессии SSH еще раз с именем текущего пользователя.
В этому случае OpenSSH не принимает участия создании сессии и ресурсы монтируются.
Discussion
при попытке входа пользователя домена, темнеет экран и снова выкидывает для ввода логина и пароля. не ругается что пароль не верен.
версия xubuntu 14.04
Денис, такое поведение бывает при отсутствии хомдира пользователя или если у него нет на нее прав.
у меня другой вопрос. можно ли заставить pbis получать unix атрибуты с AD? допустим у меня есть nfs-шара с хоумдирами, она примонтирована, вижу свой каталог, например /home/xxx с атрибутами 770 1290:3490 (uid:gid от балды). в AD пользователю ххх@domain.com в соответствующей вкладке прописаны unix атрибуты uid 1290 и gid 3490, но при авторизации через pam_lsass пользователю они не присваиваются. соответсвенно не могу в нее попасть и наблюдаю ситуацию, как у Дениса)))