С конфигурационным файлом Kerberos ...
[realms] DOMAIN.COM = { kdc = dc1.domain.com admin_server = dc1.domain.com }
... Linux может разговаривать с Active Directory для проверки пароля, не обязательно являясь членом домена AD:
$ kinit jdoe Password for jdoe@DOMAIN.COM: $ klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: jdoe@DOMAIN.COM Valid starting Expires Service principal 01/12/15 15:36:16 01/13/15 01:36:25 krbtgt/DOMAIN.COM@DOMAIN.COM renew until 01/19/15 15:36:16
На этом этапе вы можете использовать PAM для определения локальных пользователей Linux в / etc / passwd, но при этом их сеансы TTY будут аутентифицированы через Active Directory. Authn через krb5 выполняется как контекст для каждого входа:
auth sufficient pam_krb5.so use_first_pass
Но если krb5 уже реализован как часть глобальных настроек PAM по умолчанию, почему Samba также не использует его? Я вижу, что /etc/pam.d/samba включает в себя Kerberized password-auth файл, но не вызывает радости при доступе к тому SMB. (Журналы отладки указывают на ошибку «не удалось получить SID», что очень похоже на «вы не являетесь частью домена».)
Мой основной вопрос: можно ли выполнить аналогичную централизацию авторизации krb5 под Samba, как это было для Shell, без всех этих дополнительных накладных расходов / сложности членства в домене? Мне нужно, чтобы службы Samba были реализованы в группе систем с кластером NIS, но я не хочу иметь разные серверные части TDBSAM в каждой системе, что приведет к путанице с паролями SMB. Было бы здорово использовать Kerberos в качестве аутентификатора. Однако я все еще хочу определить авторизацию / доступ через локальную учетную запись Linux и не открывать доступ Samba для всех пользователей домена, как в случае с присоединением к домену, эмуляцией winbind DC или полноценным сервером AD.
В качестве альтернативы: есть ли лучший вариант централизованной внутренней аутентификации для Samba в кластере Linux? Я посмотрел на CTDB, но, похоже, он был ориентирован на посредничество общего хранилища, а не на центральную аутентификацию с разрозненными томами ...
Самба означает разные вещи для разных людей. Для некоторых это способ реализовать сеть в стиле LanMan без уплаты десятины Microsoft, используя WinBind для предоставления служб псевдодоменного контроллера без фактического запуска Windows Server. Возможно, поэтому «drookie» сделал комментарий: «Похоже, у вас запущен AD, но по какой-то причине вы не хотите его использовать. Зачем тогда вообще использовать самбу? ». Зачем? Потому что я использую Samba в основном для базовой поддержки CIFS. Весь этот дополнительный домашний каталог WinBind / ADS и кэшированные данные DC - это то, чего я действительно не хотел. Я искал Linux, чтобы по-прежнему определять авторизацию и доступ, а не открывать его для всех пользователей домена. Но для разрешенных пользователей используйте аутентификацию Kerberos. (Samba - особенно Samba4 - движется к полной эмуляции узлов Linux в Active Directory в домене Windows AD, вплоть до наследования SID / GUID, членства в OU и т. Д. Их цель - избавиться от необходимости создавать локальные учетные записи Linux. потому что Samba будет создавать их на лету на основе профилей AD. Излишек для моих нужд.)
Поскольку я искал Samba в первую очередь для функциональности CIFS, я надеялся, что AD можно будет использовать только для аутентификации через вызовы Kerberos (как я уже реализовал для SSH). Если бы мне не требовалось присоединение к домену для работы Kerberos на уровне TTY / SSH, действительно ли оно мне нужно для Samba + Kerberos? К сожалению, ответ - ДА. Но, несмотря на это, я все же смог выполнить свою задачу аутентификации AD / Kerberos, не превращая хост Linux в PDC / BDC или не переводя все управление authz в режим ADS. То, что у меня есть, работает, и вот моя интерпретация того, почему:
Базовый Kerberos работает на уровне PAM / TTY, поскольку пользователь вводит свой пароль в интерактивном режиме, передавая его непосредственно в библиотеку krb5; при запуске в контексте выполнения запроса пользователем присоединение к домену не требуется. Однако в случае аутентификации общих ресурсов CIFS клиент Windows уже зашифровал пароль, введенный пользователем, поэтому к тому времени, когда Samba получит его, это будет хеш NTLMv2. Вероятно, поэтому в книге О’Рейли «Птица-носорога» говорится, что «строки модуля auth PAM полностью игнорируются Samba». В этом случае Samba должна связаться с сервером AD. надежно для получения учетных данных, чтобы точно знать, правильный ли пользователь / пароль. По этой причине необходимо присоединение к домену. По сути, присоединенная к домену Samba действует как прокси-сервер Kerberos для связи с AD и проверки учетных данных клиента.
Я обнаружил, что даже при обязательном присоединении к домену нет необходимости запускать локальный демон WinBind или превращать хост Linux в полноценный сервер AD. Вот что я сделал в конфигурационном файле Samba4:
security = ADS
passdb backend = tdbsam
realm = DOMAIN.COM
password server = *
encrypt passwords = yes
lanman auth = no
ntlm auth = no # NTLMv2
kerberos method = system keytab
username map = /etc/samba/smbusers
guest account = nfsnobody
map to guest = Bad User
obey pam restrictions = yes
Возможно, более важно указать на то, что я сделал не делать:
Самый минимум - это то, что требуется присоединение к домену для включения поиска Kerberos относительно доступа локального пользователя:
# net ads join -U Administrator
# net ads keytab create
Однако не задействованы никакие службы, которые превратили бы хост Linux в PDC / BDC или ADS с картами для авторизации доступа. Я использую Samba + Kerberos строго для проверки локальных пользователей и не более того.
Вы можете запустить самбу поверх NIS, в этом случае база данных пользователей будет синхронизирована им, и без присоединения к домену у вас будет несколько автономных серверов самбы. Это также означает, что вам придется вручную добавлять пользователей домена или, по крайней мере, их пароли на каждом сервере. Вероятно, это не то, что вам нужно.
Вы также можете поэкспериментировать с использованием AD LDAP в качестве серверной части ldap для пользователей Samba, не присоединяясь к домену.
Так что вариантов много, но, честно говоря, я не понимаю вашу точку зрения. Похоже, у вас запущен AD, но вы по какой-то причине не хотите его использовать. Зачем тогда вообще использовать самбу.