Записки старого админа

Стала как-то перед мной задача, настроить связку «FreeBSD + Samba и Windows Active Directory», вот я и решил это описать.

Собственно для чего это всё? Основная задача — FreeBSD в качестве файлового сервера с проверкой разрешений в домене.

В качестве домен контроллера использовался windows server 2003.

Samba в домене Active Directory
Вводные данные:
домен domain.local.com
контроллер домена pdc.domain.local.com

Samba должна быть собрана с поддержкой LDAP, Kerberos (MIT либо Heimdal) и, желательно, PAM.
Проверить это можно следующими командами:

# smbd -b | grep LDAP 
# smbd -b | grep KRB 
# smbd -b | grep PAM

Файл /usr/local/etc/smb.conf должен содержать как минимум:

 
realm = DOMAIN.LOCAL.COM
security = ADS
encrypt passwords = yes

PS. Обратите особое внимание, на секцию realm, да да — именно «DOMAIN.LOCAL.COM» в большом регистре — это важно. Этот параметр должен указывать на имя домена и обязательно в большом регистре букв. Да и вообще, все прописи домена, в том числе и в керберосе — тоже в большом регистре, что бы потом не было путаницы.

Параметр ADS в секции security, указывает на то что samba находится в домене и вся аутентификация и авторизация проходит на уровне домена, в нашем случае в домене: DOMAIN.LOCAL.COM. Иногда бывает ситуация, когда параметр password server, необходимо явно задать. Это необходимо только в том случае, когда samba сама не может найти домен контроллер, используя параметр realm. Происходит это, как правило, либо при некорректной настройке MS DNS сервера, либо при использовании не MS DNS серверов, несоответствующих требованиям AD и вроде бы как старых версий BIND. Подробности об использовании не MS DNS серверов с AD смотрите в книге Федора Зубанова «Active Directory. Подход профессионала».

Параметр yes в секции encrypt passwords, указывает на использование шифрования паролей.

Для интеграции samba с AD используем kerberos и файл конфигурации /etc/krb5.conf такого типа:

[logging]
          default = FILE:/var/log/krb5.log
          kdc = FILE:/var/log/krb5kdc.log
          admin_server = FILE:/var/log/kadmin.log
[libdefaults]
          default_realm = DOMAIN.LOCAL.COM
          clockskew = 500
          dns_lookup_realm = false
          dns_lookup_kdc = true
          ticket_lifetime = 324000
[realms]
         DOMAIN.LOCAL.COM = {
                  kdc = PDC.DOMAIN.LOCAL.COM
                  admin_server = PDC.DOMAIN.LOCAL.COM
                  defaul_domain = DOMAIN.LOCAL.COM
                 }
[domain_realms]
          .domain.local.com = DOMAIN.LOCAL.COM
[kadmin]

Хотя на самом то деле в данном случае и для MIT, и для Heimdal Kerberos этот файл теоретически и не нужен вообще. Все свежие библиотеки Kerberos должны самостоятельно KDC, при корректно настроенном DNS (но не все), поэтому мы и создали его.
Чтобы проверить, работает ли Kerberos выполните команду:

# kinit user@DOMAIN.LOCAL.COM

Если не авторизуется, причин может быть много, поэтому нужно смотреть лог и на то что вы получите в консоли. Самые распространенные причины:
1. Может быть неправильно настроенный DNS.
2. Возможно расхождение во времени с KDC. И в таком случае вы должны получить сообщение: «kinit(v5): Clock skew too great while getting initial credentials». Допустимое расхождение по умолчанию составляет 5 минут. Изменить это значение можно в политиках безопасности домена, но правильнее все же настроить на машине с Samba синхронизацию времени с DC. А синхронизировать на лету, можно так:

# ntpdate PDC.DOMAIN.LOCAL.COM

3. Указание параметра realm в нижнем регистре, то о чем я уже писал выше. Ошибка в этом случае будет следующей: «Cannot find KDC for requested realm while getting initial credentials».
4. При указании в kinit домена в нижнем регистре может быть проблема с авторизацией. В этом случае мы получим сообщение: «kinit: Password incorrect». Нужно писать в консоли, точно так, как я указал выше, соблюдая регистр.

Очень важным аспектом, является поиск вашего KDC в обратной зоне DNS. В документации указано, что DNS имя, которое выдается на nslookup ip_of_kdc, обязательно должно совпадать с NetBIOS именем KDC. Выполнив все эти настройки, добавляем машину в домен:

# net ads join -U user%password

Где user — любой пользователь, который имеет право на присоединение машины к домену. Теперь вы можете увидеть вашу машину с Samba в оснастке «Active Directory Пользователи и Компьютеры».

Важно запомнить:
  Если не указывать имя и пароль при подключении машины к домену, вероятнее всего, команда все равно отработает успешно и машина добавится в домен. Конечно, если все вышеперечисленное было сделано правильно и AD настроен корректно. Но с вероятностью в 98% при попытках подключиться к доменным ресурсам с использованием Kerberos вы получите в логах DC ошибку ID 8 от источника KDC:

The account did not have a suitable key for generating a Kerberos ticket. If the
encryption type is supported, changing or setting the password will generate a
proper key.

В учетной записи будет стоять имя вашей samba машины.

Далее, наша задача, научить Sambу узнавать Windows пользователей.
Для этого в Samba имеется демон winbindd. Winbind имеет несколько методов поиска в базах NSS, поддерживая аутентификацию через PAM и непосредственно с Sambой. Для настройки winbindd в файл /usr/local/etc/smb.conf добавляем следующие секции:

winbind separator = + 
или
winbind separator = \\
idmap uid = 10000-20000 
idmap gid = 10000-20000

Первая секция — служит для замены Windows разделителя ‘\’, который в конструкциях shell, как известно, служит для экранирования. Поэтому, он либо «+», либо «\\». Вторая и третья — служат для отображения доменных пользователей и групп на, соответствующие, UID и GID из заданного диапазона в UNIX сервере. Далее дело за настройкой NSS. После его настройки, появится возможность работать с доменными аккаунтами так же как и с локальными — и использовать их в chown и chgrp, в ACL, с директивой valid users в smb.conf и т.д.
Изменяем соответствующие строки в /etc/nsswitch.conf:

passwd: compat winbind
group: compat winbind

Это — все.

Далее, запуск Samba и проверка сервисов:
Проверим, аутентификацию по Kerberos:

# smbclient -k //PDC/netlogon

где PDC — имя домен-контроллера.

Проверяем работу winbind:

# wbinfo -u
# wbinfo -g

При правильной настройке выше описанных служб, эти команды должны выдать список доменных пользователей, и групп соответственно.

Можно ещё проверить принадлежность к группам доменного пользователя:

# id user
uid=10131(user) gid=10029(admins) groups=10029(admins), 10004(пользователи домена), 10024(inetaccess), 10002(BUILTIN\users)

Далее можно проверить правильность работы с доменными именами и группами на
локальные UID/GID. Для этого попробуем изменить владельца и группу папки:

# chown user /home/DOMAIN/user
# chgrp admins /home/DOMAIN/user

Теоретически не должно возникнуть никаких ошибок, если всё правильно настроено.

В принципе, поставленная задача решена, удачи вам.