samba4 secrets.keytab regeneration (fix KVNO mismatch error)

Запишу, чтобы не затерялось.

Внезапно перестали вводиться компьютеры в домен. Подозреваю, все остальное, завязанное на контроллере домена и кейтабах, тоже бы отпало, если бы работало. Логи samba4 показали ошибку:

GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see text): Failed to find DC0$@EXAMPLE.ORG(kvno 7) in keytab FILE:/var/lib/samba/private/secrets.keytab (arcfour-hmac-md5)

Содержимое "родного" кейтаба, создаваемого при развертывании домена:

root@dc0:/var/lib/samba/private# klist -ke secrets.keytab
Keytab name: FILE:/var/lib/samba/private/secrets.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 HOST/dc0@EXAMPLE.ORG (des-cbc-crc)
   1 HOST/dc0.example.org@EXAMPLE.ORG (des-cbc-crc)
   1 DC0$@EXAMPLE.ORG (des-cbc-crc)
   1 HOST/dc0@EXAMPLE.ORG (des-cbc-md5)
   1 HOST/dc0.example.org@EXAMPLE.ORG (des-cbc-md5)
   1 DC0$@EXAMPLE.ORG (des-cbc-md5)
   1 HOST/dc0@EXAMPLE.ORG (arcfour-hmac)
   1 HOST/dc0.example.org@EXAMPLE.ORG (arcfour-hmac)
   1 DC0$@EXAMPLE.ORG (arcfour-hmac)
   1 HOST/dc0@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
   1 HOST/dc0.example.org@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
   1 DC0$@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
   1 HOST/dc0@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
   1 HOST/dc0.example.org@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
   1 DC0$@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)

Строчка с DC0$@EXAMPLE.ORG в кейтабе есть, однако KVNO отличается, отсюда и ошибка. Почему такое не случалось раньше (или случалось, но не приводило к проблеме) и как этого избежать, неведомо. В интернетах нашлись кивания на то, что такое поведение Active Directory в принципе нормально, есть даже RFC 4120, где я, правда, нужной информации не почерпнул. 

Вообще, вроде как, изменение kvno вызывать проблем с авторизацией не должно, тем более что Active Directory его значение игнорирует (исключая случай работы с RODC, но это мимо кассы). Но вот так получилось. 

Как это можно симптоматически порешать? Регенерацией кейтабов, где имеет место быть разночтение KVNO.

В примерах команды идут в одну строчку:

samba-tool domain exportkeytab  /root/1.keytab --principal=HOST/dc0.example.org@EXAMPLE.ORG
samba-tool domain exportkeytab  /root/1.keytab --principal=HOST/dc0@EXAMPLE.ORG
samba-tool domain exportkeytab  /root/1.keytab --principal='DC0$@EXAMPLE.ORG'
samba-tool domain exportkeytab  /root/2.keytab --principal=DNS/dc0.example.org@EXAMPLE.ORG
samba-tool domain exportkeytab  /root/2.keytab --principal=DNS/dc0@EXAMPLE.ORG
samba-tool domain exportkeytab  /root/2.keytab --principal=dns-dc0@EXAMPLE.ORG

Дальше проверим правильность сгенерерированных файлов и заменим старые кейтабы новыми:

cd /var/lib/samba/private/
klist -ke /root/1.keytab
klist -ke secrets.keytab
mv secrets.keytab secrets.keytab.bak
cp /root/1.keytab secrets.keytab
systemctl restart samba-ad-dc.service
klist -ke /root/2.keytab
klist -ke dns.keytab
mv dns.keytab dns.keytab.bak
cp /root/2.keytab dns.keytab
chown bind:bind dns.keytab
systemctl restart bind9.service

Аналогично следует поступить и с другими службами, если они оказались затронуты проблемой.

id: administrator: no such user

Еще одна проблема (вдогонку к этой) в работе Samba4 AD DC. 

Суть: Linux-компьютер (в моем случае Debian 8 и Ubuntu 14.04 LTS) успешно вводится в домен, какое-то время все работает. Затем происходит странное: winbind продолжает видеть группы и пользователей домена, однако линуксовые средства (getent, id) их видеть перестают, и, как следствие, авторизация доменных пользователей ломается. То есть, к примеру, wbinfo -u, wbinfo -g, wbinfo -t ведут себя ожидаемо и правильно, а id username или getent passwd успешно отрабатывают только для локальных пользователей. 

Зацепиться удалось лишь за ошибку в выводе wbinfo -i username

~# wbinfo -i administratorfailed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUNDCould not get info for user administrator

Поиски вывели вот сюда, сюда и сюда. Корень зла - бэкенд ad для idmap, через который и происходит взаимодействие winbind-а и утилит ОС. Таблетка - изменить этот бэкенд на rid.

idmap config * : backend = rid

Samba 4 AD rfc2307 + login shell

Есть проблема: при вводе в samba4-домен linux-машины winbind подгружает список пользователей с шеллом /bin/false. Это вызывает ожидаемые проблемы при логине в систему.

administrator:*:2000:2000:Administrator:/home/EXAMPLE/administrator:/bin/false

И вроде бы такое должно случаться только в случае контроллеров домена и только с winbind. Однако у меня случилось и на обычном "членском" сервере. Проблема в том, что winbind не считывает атрибут (который должен по rfc2307,  см. соответствующую опцию в smb.conf) LoginShell из свойств пользователя в Active Directory. Текущее обходное решение - добавить в smb.conf глобальный параметр:

[global]
   template shell = /bin/bash

Различные настройки Samba для разных клиентов

Samba умеет определять, какие настройки применять для различных подключенных к ней клиентов. Иногда это очень выручает. Для этого используются, во-первых, внутренние переменные (%m, %I и так далее), во-вторых, опции config file и include. 

Если вкратце, include добавляет параметры (из файла, на который указывает) к описанным в smb.conf, при этом при совпадении переопределяются опции, указанные в smb.conf ранее строки include = /path/to/file; параметры, указанные после, остаются неизменными. Параметр config file, напротив, заменяет собой smb.conf, переопределяя при совпадении все, что ниже него по тексту конфига. Подробнее о параметрах и внутренних переменных (с примерами), можно поглядеть в официальной документации проекта Samba.

Пример из жизни. Есть файловый сервер, на котором две шары: public и private, и три клиента: pc1, pc2, pc3, каждый из которых должен иметь доступ к некоторым ресурсам: pc1 - к public, pc2 - к private, pc3 - к public и private. Чтобы это реализовать, потребуются вышеописанные опции. Итак, содержимое конфигов: 

smb.conf: 

 ##for pc2
config file  = /etc/samba/smb.conf-%m
   workgroup = WORK
   server string = %h server
   netbios name = server
   dns proxy = no
   log file = /var/log/samba/log.full
   log level = 1
   max log size = 10000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   security = share
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = yes
   invalid users = root
[public]
        path = /public
        comment = Public Resource 
        guest ok = yes
        browseable = yes
        writable = yes
        force user = nobody
        force create mode = 0666
        force directory mode = 0777

##for pc3
include = /etc/samba/smb-share.conf-%m

smb.conf-pc2:

   log file = /var/log/samba/log.private

   syslog = 0 

[private]
        path = /private
        comment = Private Resource
        guest ok = yes
        browseable = yes
        writable = yes
        force user = nobody
        force create mode = 0666
        force directory mode = 0777 

 smb-share.conf-pc3:

[private]
        path = /private
        comment = Private Resource
        guest ok = yes
        browseable = no
        writable = yes
        force user = nobody
        force create mode = 0666
        force directory mode = 0777

Такая конфигурация предоставляет по умолчанию всем пользователям одну шару public. Фишка рассматриваемых параметров в том, что они срабатывают только при нахождении файла, указанного их аргументом. Отсутствие файла не является ошибкой конфигурирования - информации в лог не пишется, сам параметр игнорируется.
Таким образом, только когда к файловому серверу подключаются клиенты с NetBIOS-именами pc2 и pc3 (или с заданными IP-адресами, если используется переменная %I), срабатывают, соответственно, config file и include. В первом случае клиент pc2 видит одну шару private (плюс его действия начинают записываться в отдельный лог-файл log.private с увеличенным loglevel), во втором - клиент pc3 видит две шары - private и public и для него используются настройки из основного smb.conf.

Debian + Windows domain

Годится не только для debian-based дистрибутивов, но, думаю, и для большинства Unix-систем, где есть samba, kerberos и winbind. Задачка несложная, ввести рабочую станцию (или сервер, неважно) в домен Active Directory и получить возможность авторизации доменных пользователей как графически, так и по ssh. Мне для успешной настройки потребовались пакеты samba, winbind, krb5-user, krb5-config, nscd. Необходимые для доменной авторизации пользователей модули PAM (например, pam_winbind) были установлены автоматически как зависимости.

Исходные данные: имеется домен example.org (win2k3), рабочая станция user-test (Debian Sid), Администратор домена admin, пользователь домена user. В качестве системного DNS используются контроллеры домена (директивы nameserver в resolv.conf или dns-nameserver в interfaces).
Необходимые правки конфигов:
smb.conf:

[global]
workgroup = EXAMPLE
netbios name = user-test
server string = test debian pc
security = ADS
preferred master = no
disable spoolss = Yes
show add printer wizard = No
idmap config * : range = 15000-20000
#winbind separator = +
winbind use default domain = Yes
template shell = /bin/bash
use sendfile = Yes
realm = example.org

log file = /var/log/samba/log.full
load printers = no
printing = bsd
printcap name = /dev/null

krb5.conf:

[libdefaults]
        default_realm = EXAMPLE.ORG
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        fcc-mit-ticketflags = true
[realms]
        EXAMPLE.ORG = {
                kdc = dc1.example.org
                kdc = dc2.example.org
                admin_server = dc1.example.org
        }
[domain_realm]
        .example.org = EXAMPLE.ORG
        example.org = EXAMPLE.ORG
[login]
        krb4_convert = true
        krb4_get_tickets = false

nsswitch.conf:
#passwd:         compat
passwd:         files winbind
#group:          compat
group:          files winbind
#shadow:         compat
shadow:         files winbind
#hosts:          files dns
hosts:          files dns winbind

pam.d/common-auth:

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

pam.d/common-password:

password        [success=2 default=ignore]      pam_unix.so obscure sha512
password        [success=1 default=ignore]      pam_winbind.so use_authtok try_first_pass
password        requisite                       pam_deny.so
password        required                        pam_permit.so

pam.d/common-account:

account [success=2 new_authtok_reqd=done default=ignore]        pam_unix.so
account [success=1 new_authtok_reqd=done default=ignore]        pam_winbind.so
account requisite                       pam_deny.so
account required                        pam_permit.so

pam.d/common-session:

session         required                pam_mkhomedir.so skel=/etc/skel umask=0022
session         sufficient              pam_unix.so
session         sufficient              pam_sufficient.so

После правки коифигов и перезапуска сервисов присоединяемся к домену, предварительно синхронизировав время с контроллером домена (net time set dc1.example.org):

net ads join -Uadmin
admin's password:
Using short domain name -- EXAMPLE 

Joined 'USER-TEST' to realm 'EXAMPLE.COM'

Проверим успешность ввода с помощью wbinfo:

root@user-test:~# wbinfo -t
checking the trust secret for domain EXAMPLE via RPC calls succeeded

Команды wbinfo -u и wbinfo -g должны показать список пользователей и групп Active Directory.

net view + Системная ошибка 58

Пусть кто-то сэкономит ту пару рабочих часов, которые я просидел над поисками решения следующей проблемы:  после того, как "ничего не делали"(с) с рабочей станции (Windows XP)  перестало пускать на сетевые ресурсы сервера (Debian + Samba) с ошибкой вида "Возможно, у вас нет прав на использование этого сетевого ресурса", если используется проводник, и "системной ошибкой 58" при попытке сунуться через консоль (net view). Естественно, никаких настроек на стороне сервера и клиента не изменялось. И, конечно же, всё, что только можно, было проверено, перезапущено, перенастроено и перезагружено. 

Корень зла - в обновлении KB2536276, одно из действий которого - запрет на использование нешифрованных паролей. По ссылке выше описываются и возможные проблемы, возникающие после установки этого обновления, а также методы их решения или обхода. Если вкратце, то можно:

• поправить ключ EnablePlainTextPassword в ветке HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\LanmanWorkstation\Parameters, выставив значение "0";
• поправить конфиг samba на linux-сервере (/etc/samba/smb.conf), добавив опцию encrypt passwords = yes;
• удалить это обновление с помощью мастера установки и удаления программ.

З. Ы. Решение первоначально было найдено тут, за что автору большое спасибо.

samba + централизованное управление монтированием сетевых ресурсов

Некоторое упрощение и централизация операций с пользовательскими сетевыми дисками...
Настройки самбы:

security = user

[homes]
comment = Home Directories
browseable = no
path = /home/%u/net

read only = no
create mask = 0770
directory mask = 0770
valid users = %S
[netlogon]
comment = Network Logon Service
path = /home/%u/netlogon
guest ok = no

read only = yes
browseable = no
share modes = no

Скрипт подключения сетевых дисков (для каждого win-пользователя) l_script.cmd: 

@echo off

net use z: \\server\share1 /y

net use y: \\server\share2 /y

...

net use b: \\server\shareN /y

Настройки на рабочей станции пользователя: 

Записанный в автозагрузку скрипт обращения к удаленному скрипту (l_script.cmd на сервере) login.cmd:

@echo off

net time \\server /set /y

call \\server\netlogon\l_script.cmd

Таким образом, при логине win-пользователя в систему вызывается login.cmd, который синхронизирует время с сервером и вызывает оттуда скрипт l_script.cmd, который, в свою очередь, монтирует заданные для этого пользователя шары. Для того, чтобы при запуске системы окно консоли не вызывало испуг пользователя (с последующим звонком админу ;) ), сворачиваем его в панель задач: правый клик на ярлыке .cmd-файла в Автозагрузке - Свойства - Ярлык - пункт Окно - Свернутое в значок.

P. S.: Описанный механизм будет работать без участия пользователя лишь в случае, если учетная запись пользователя на рабочей станции полностью совпадает с учетной записью на сервере. Если по каким-то причинам это невозможно, то следует поменять скрипт login.cmd следующим образом:

@echo off

net time \\server /set /y

net use p: \\server\netlogon /USER:username password 

call p:\l_script.cmd

net use p: /delete /y

samba + ldap

Оставлю здесь ключевые грабли по проекту "Авторизация пользователей samba в LDAP". Во-первых, ссылка на описание переменных самбы - вот или вот. 

Далее, по конфигу:

netbios name = SERVER

security = user

passdb backend = ldapsam:ldap://127.0.0.1
ldap passwd sync = no
ldap suffix = dc=gmz,dc=local
ldap user suffix = ou=users
ldap group suffix = ou=groups
ldap admin dn = cn=admin,dc=gmz,dc=local
enable privileges = no
obey pam restrictions = no

domain logons = yes
domain master = yes
local master = yes

#для замуты с логонскриптами

logon path = \\%N\%U\profile

logon drive = P:
logon home = \\%N\%U

logon script = l_script.bat

Чтобы самба начала ходить к лдапу, ей нужно дать пароль админской записи: smbpasswd -w "ldap_admin_password"

По дереву LDAP'a:  дабы пользователь мог авторизовываться через ldap на самба-шарах, нужно:

1) после его создания дать ему objectClass'ы sambaSamAccount (возможно после добавления include samba.schema в slapd.conf) и shadowAccount;

2) добавить аттрибут shadowLastChange (для того, чтобы заработала смена пароля через smbpasswd)

3) добавить пользователя непосредственно в самбу: smbpasswd user 

Также следует установить пакеты smbldap-tools и samba-doc. Там есть и тема для LDAP'а или некие необходимые скрипты (в основном, похоже, интересны для построения домена).

Samba + Корзина

Интересное решение "защиты от дурака" для samba-шар - реализация Корзины на открытых файловых ресурсах. Делается через механизм VFS. Подробности и пример конфига - тут.

samba + unix accounts

Поставил я на новый сервер Lenny, завел там с полтора десятка пользователей. И нужно теперь развести, согласно данной заказчиком бумажке, этих пользователей по различным samba-шарам, с учетом указаний видимости/невидимости тех или иных общих каталогов. Умолчальный для меня способ - завести согласно списку unix-пользователей список smb-пользователей и уже средствами samba-ы развесить нужные разрешения. Однако лень. В итоге брожения по Сети на предмет поиска идеи упрощения своей тяжелой и неказистой жизни привели к следующим выводам:

1) как вариант, использовать существующие учетки системных (/etc/passwd, /etc/shadow) пользователей, авторизуясь, тем самым, через PAM. Однако тут есть существенные грабли. Как выяснилось практически и теоретически, механизм обмена аутентификационными данными у PAM и samba шифруются разными алгоритмами, и поэтому отправить самбу к PAM'у можно (obey pam restrictions = no), но бессмысленно - хеши паролей не совпадут  со всеми вытекающими. Чтобы  это обойти, требуется дополнительно отключать шифрование паролей со стороны сервера (encrypt passwords = no) и принуждать smb-клиентов отсылать пароль в plaintext, что запрещено по умолчанию как в linux, так в windows. Для этого smbclient следует запускать с указанием альтернативного конфиг-файла, в котором записано следующее (рецепт отсюда): 

[globals]
    client lanman auth = yes
    client plaintext auth = yes

В случае win-клиента необходимо поправить реестр, запустив такой reg-файл:

REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkStation\parameters]
"EnablePlainTextPassword"=dword:00000001

Или вручную, в Администрировании - рецепт тут.
Таким образом, клиент, желающий аутентифицироваться будет отправлен к PAM'у, где его будет ждать

auth    required        pam_unix.so nullok_secure

2) Можно утащить все в LDAP и c помощью того же PAM'а авторизовывать всех и вся. Рецептов - вал. Такой способ я считаю единственно верным в достаточно большой компании со сложной инфраструктурой и, возможно, частыми изменениями учетных данных и прав доступа. Внеся необходимые изменения в одном месте, получаем изменения во всех точках, касающихся авторизации.
3) Миграционно-ленивый метод. Здесь мы не выступаем против разграничения  /etc/passwd и smbpasswd. С другой стороны, мы противимся мартышкиному труду вбивания n-ного количества пользователей два раза, с последующим слежением (при необходимости) за синхронизацией изменений. Используя libpam-smbpass, мы будем создавать базу smbpasswd из существующей /etc/passwd постепенно. Тут можно поступить двояко. Или введя дополнительно в PAM следующее условие:

auth    optional        pam_smbpass.so  migrate

Таким образом, внеся это в common-auth, мы получим создание smbpasswd-записи для аутентифицирующегося пользователя в любом сервисе, использующем common-auth (login, ssh, proxy...). А так как для введения сервера "в бой" мне придется как минимум единожды залогиниться в систему всеми пользователями, то задача решится сама собой.
Или, с другой стороны, можно дополнительно к использовать первый способ. Такой сценарий идеален для миграции с шар "всё всем" на шары "каждому по потребностям" без геморроя и возмущенных звонков пользователей. Включил на месяц, а потом прикрыл plaintext-лавочку. И секурность соблюдена, и нервы в порядке.
Также необходимо добавить в common-password следующую запись:

password        optional        pam_smbpass.so nullok use_authtok try_first_pass

Это даст нам возможность автоматической синхронизации учетных данных при смене пароля unix-аккаунта. Раз уж мы используем одинаковые аутентификационные данные для работы в unix -среде и доступа на smb-ресурсы, то подобная синхронизация необходима.