У нас есть много серверов разработки Linux, доступ к которым обычно осуществляется через SSH. У каждого разработчика есть локальная учетная запись на каждом ящике, управляемая Puppet. Вход осуществляется только через закрытые ключи; нет локальных паролей.
Я хотел бы запустить Samba на этих ящиках и пройти аутентификацию в нашем домене AD. Мне не нужна аутентификация AD ни для чего, кроме Samba - все остальное доступно через SSH и закрытые ключи.
Вот мой smb.conf
:
[global]
workgroup = DOMAIN
server string = Samba Server Version %v
security = ADS
realm = DOMAIN.FQDN
encrypt passwords = yes
log level = 3
log file = /var/log/samba/%U.log
[homes]
comment = Home Directories
browseable = no
writable = yes
Я почти уверен, что конфигурация Kerberos в порядке, поскольку я присоединился к домену.
Соответствующий (т.е. нестандартный) nsswitch.conf
линии:
passwd: files winbind
group: files winbind
Похоже, проблема в Сопоставление UID AD с UID UNIX. Бэкэнд TDB по умолчанию будет создавать «виртуальные» учетные записи UNIX по запросу при подключении пользователей AD, но я этого не хочу - я хочу, чтобы пользователь foo
сопоставить с локальным пользователем foo
. Если я добавлю idmap uid
и idmap gid
строк, пользователи проходят проверку подлинности нормально, но их учетные записи не сопоставляются с учетными записями UNIX.
Любые идеи? Somoene должно быть, делал это раньше! Я не хочу переключаться на использование winbind и AD для предоставления всей информации об учетной записи из-за проблем с поддержанием согласованных UID / GID на всех машинах. Мы также многое вложили в существующую конфигурацию пользователя, управляемую Puppet, которую не хотим изобретать заново.
Убедитесь, что служба winbind запущена.
Настройте в /etc/pam.d/samba:
account [default=bad success=ok user_unknown=ignore] pam_winbind.so
account required pam_permit.so
password sufficient pam_winbind.so use_authtok
password required pam_deny.so
session required pam_limits.so
auth required pam_nologin.so
auth sufficient pam_winbind.so use_first_pass
auth required pam_deny.so
Изменения Pam иногда требуют перезапуска winbind. Не следует, но практика подсказывает, что все равно надо.
В smb.conf вам также понадобятся:
realm = YOURKERBEROSREALMNAME
password server = the host or IP of your ADC
idmap backend = rid:DOMAIN=5000-100000000
idmap uid = 10000-10000000
idmap gid = 10000-10000000
winbind use default domain = Yes
winbind enum users = Yes
winbind enum groups = Yes
Где DOMAIN - это ваша рабочая группа или имя домена, а область соответствует тому, что находится в вашем krb5.conf
После изменений в smb.conf перезапускаем сервисы samba
из http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html#id2604553
Член Samba сетевого домена Windows (в стиле NT4 или ADS) может быть настроен для обработки сопоставления удостоверений различными способами. Используемый им механизм зависит от того, используется ли демон winbindd и как настроена функциональность winbind. Здесь кратко описаны варианты конфигурации:
Winbind не используется; пользователи и группы являются локальными:
Там, где winbindd не используется, Samba (smbd) использует базовые механизмы UNIX / Linux для разрешения идентификации входящего сетевого трафика. Это делается с помощью LoginID (имени учетной записи) в запросе настройки сеанса и передачи его в вызов системной функции getpwnam (). Этот вызов реализован с использованием механизма переключения службы имен (NSS) в современных системах UNIX / Linux. Говоря «пользователи и группы являются локальными», мы подразумеваем, что они хранятся только в локальной системе, в / etc / passwd и / etc / group соответственно.
Например, когда пользователь BERYLIUM \ WambatW пытается открыть соединение с сервером Samba, входящий запрос SessionSetupAndX выполнит системный вызов для поиска пользователя WambatW в файле / etc / passwd.
Эта конфигурация может использоваться с автономными серверами Samba, серверами-членами домена (NT4 или ADS), а также для PDC, использующего серверную часть Samba passdb на основе smbpasswd или tdbsam.
похоже, что если вы просто исключите winbind из уравнения, все будет хонкидори, если ваши пользователи AD такие же, как локальные пользователи / etc / passwd.