Skip to main content
Все материалы

Аутентификация файловых серверов GNU/Linux в домене Windows на базе AD. Аутентификация Samba в домене Windows. Часть 2.

Оценить: 

Конфигурационные файлы

Мы будем настраивать только доступ к серверу GNU/Linuxс использованием Samba. Авторизация пользователей останется локальной, с использованием /etc/passwd.

Присвоим нашему новому серверу статический IP-адрес. Пусть им будет 192.168.7.9.

Для начала нужно проверить, какой сервер у нас используется в качестве DNS. Им в нашей сети должен быть контроллер домена. У нас адрес сервера определен как 192.168.7.2. Правим файл /etc/resolv.conf. Он должен выглядеть следующим образом:

search lab.local
nameserver 192.168.7.2

Проверим, все ли работает:

#host 192.168.7.2
2.7.168.192.in-addr.arpa domain name pointer lab-dc1.lab.local.
#

Естественно, в вашем случае имена будут другими. Обязательно сделайте в домене lab.local запись в DNS, ссылающуюся на наш новый сервер. Запись в DNS неозначает того, что наш GNU/Linuxсервер включен в домен. Проверим:

linux-test:~ # host 192.168.7.9
9.7.168.192.in-addr.arpa domain name pointer test-linux.lab.local.
linux-test:~ # host test-linux
test-linux.lab.local has address 192.168.7.9
linux-test:~ #

Для корректной работы в домене Windows требуется несколько служб: Kerberos, LDAP и Samba. В общем случае требуется только настройка Samba; настройка других служб не является обязательной. Но будет лучше, если мы их настроим: они могут пригодиться в будущем.

Kerberos настраивается просто — через один файл /etc/krb5.conf. Основными параметрами является REALM, указывающий на наш домен и адрес сервера Kerberos — этоадрес контроллера домена. Файл /etc/krb5.conf выглядит примерно так:

linux-test:~ # more /etc/krb5.conf
[libdefaults]
        default_realm = LAB.LOCAL
        clockskew = 300
#       default_realm = EXAMPLE.COM

[realms]
LAB.LOCAL = {
        kdc = 192.168.7.2
        default_domain = lab.local
        admin_server = 192.168.7.2
}
#       EXAMPLE.COM = {
#                kdc = kerberos.example.com
#               admin_server = kerberos.example.com
#       }

[logging]
        kdc = FILE:/var/log/krb5/krb5kdc.log
        admin_server = FILE:/var/log/krb5/kadmind.log
        default = SYSLOG:NOTICE:DAEMON
[domain_realm]
        .lab.local = LAB.LOCAL
[appdefaults]
pam = {
        ticket_lifetime = 1d
        renew_lifetime = 1d
        forwardable = true
        proxiable = false
        minimum_uid = 1
        external = sshd
        use_shmem = sshd
        clockskew = 300
}

Секция [libdefaults] указывает на домен по умолчанию. У нас это LAB.LOCAL. Далее, в секции [realms] указываются параметры для LAB.LOCAL— имя домена и адрес сервера Kerberos. В нашем случае, в качестве сервера Kerbeors выступает контроллер домена. В секции [logging] указывается местоположение лог-файлов. Эти файлы пригодятся для процедуры поиска неисправности, если что-то пойдет не так.

Проверим работу Kerberos:

linux-test:~ # kinit Administrator@LAB.LOCAL
Password for Administrator@LAB.LOCAL:
linux-test:~ # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@LAB.LOCAL

Valid starting     Expires            Service principal
04/05/12 11:22:23  04/05/12 21:22:35  krbtgt/LAB.LOCAL@LAB.LOCAL
        renew until 04/06/12 11:22:23
linux-test:~ #

Команда kinit получаетот сервера тикет, а klist показывает полученные тикеты от сервера. Выполнение kinit неявляется обязательным, но ведь нужно как-то проверить работу Kerberos?

Настройка LDAP тожене является обязательной — Samba сама построит необходимые файлы и сделает нужные запросы. Но LDAP может пригодиться в дальнейшем. Конфигурация OpenLDAP хранится в файле /etc/openldap/ldap.conf. Обратите внимание: в системе может быть два файла ldap.conf. У них разные предназначения и даже немного разный синтаксис. В каталоге /etc/openldapлежит файл ldap.confдля OpenLDAP (идля Samba), а в файле /etc/ldap.confхранится конфигурация для разрешения имен через LDAP (дляnss_ldap). К файлу /etc/ldap.conf мы вернемся в других статьях, а сейчас настроим /etc/openldap/ldap.conf.

linux-test:~ # cat /etc/openldap/ldap.conf
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT	12
#TIMELIMIT	15
#DEREF	never
uri     ldap://192.168.7.2
base    DC=lab,DC=local
linux-test:~ #

Как видите, все очень просто — нужно указать URI сервера LDAP (этонаш контроллер домена) и базу для поиска.

Теперь переходим к самому сложному — настройке Samba.

В состав Samba входят 3 демона — smbd, nmbd и winbind. Все они берут настройки из файла /etc/samba/smb.conf.

Smbd отвечает за доступ клиентов к службе SMB/CIFS (собственно, это и есть сервер Samba). Nmbd — это служба разрешения имен для Netbios. Winbind — служба разрешения имен (и компьютеров и пользователей) через доменные службы Windows.

Во многих руководствах можно встретить упоминание того, что кроме Samba, требуется настраивать и winbind — службу, отвечающую за отношения между GNU/Linux и домена Windows. В частном случае, когда нужно настроить только Samba, настройки winbind можно опустить. Winbind обеспечивает авторизацию в домене Windows самых различных служб, обеспечивая интерфейс между модулями PAM и контроллером домена Windows. При неработающем winbind Samba остается работоспособной. Но настроив winbind, мы делаем возможным дальнейшее расширение нашего сервера за счет добавления различных служб, авторизующихся через контроллер домена.

Мы сделаем самый простой сервер, открыв всем пользователям доступ к некоторому общему каталогу файлов и к домашнему каталогу пользователей. Более подробно о настройке доступа к серверу Samba мыбудем говорить в других статьях.

В файле /etc/samba/smb.confмы должны указать следующие строки:

[global]
        workgroup = LAB
        passdb backend = ldapsam:ldap://192.168.7.2
        printing = cups
        printcap name = cups
        printcap cache time = 750
        cups options = raw
        map to guest = Bad User
        logon path = \\%L\profiles\.msprofile
        logon home = \\%L\%U\.9xprofile
        logon drive = P:
        usershare allow guests = Yes

Здесь мы указываем сокращенное наименование нашего домена (LAB) и место, где хранятся пароли — параметр passdb backend, указывающий на то, что пароли находятся на сервере LDAP, в качестве которого выступает контроллер домена. Кстати, можно указать и несколько серверов, перечислив их через пробел. Это пригодится в том случае, если у нас несколько контроллеров домена. Строка usershare allow guests = Yes разрешает пользователям управлять доступом к своим папкам, открывая их для гостей. Остальные строки относятся к управлению печатью и процессу регистрации. В нашем случае они не являются обязательными и перекочевали из конфигурационного файла дистрибутива Samba.

Продолжим редактирование секции [global] файла smb.conf.

domain logons = No
        domain master = No
        security = ADS
        encrypt passwords = yes

Строки domain logons и domain master разрешают использовать Samba в качестве контроллера домена. Это не наш случай, и поэтому для них установлено No.

Строка security = ADS имеет ключевое значение. Тем самым мы указываем Samba, что сервер является членом домена Windows и за авторизацию отвечает AD. Строка encrypt passwords= yes означает, что используются зашифрованные пароли.

Вернемся к редактированию все той же секции [global].

ldap admin dn = Administrator@lab.local
        ldap delete dn = No
        ldap group suffix = ou=Groups
        ldap idmap suffix = ou=Idmap
        ldap machine suffix = ou=Computers
        ldap passwd sync = Yes
        ldap ssl = No
        ldap suffix = DC=lab,DC=local
        ldap timeout = 5
        ldap user suffix = ou=Users

Эти строки относятся к управлению соединением с LDAP сервером. Заметьте, что форма записи DN администратора имеет форму user@domain— она должна совпадать с тем, что мы указывали при тестировании Kerberos. Остальные строки указывают суффиксы различных местоположений в AD.

Следующие строки относятся уже к Kerberos:

realm = LAB.LOCAL
        template homedir = /home/%D/%U
        winbind refresh tickets = yes
        kerberos method = system keytab

Здесь мы указываем REALM и метод аутентификации в Kerberos.

Теперь — строки,которые относятся к настройке winbind:

winbind separator = /
        winbind enum users = yes
        winbind enum groups = yes
        winbind nested groups = yes
        winbind use default domain = No
        winbind nss info = rfc2307
        winbind offline logon = yes

Здесь указаны различные параметры работы Winbind: формаразделителя имен домена и пользователя, разрешение для winbind перечислять имена пользователей и групп, разрешение оффлайновой аутентификации и т.п. Эти настройки рекомендованы разработчиками Samba.

Секция глобальных настроек закончена. Обратите внимание, что у нас нет строк password serverи idmap backend, которые можно встретить в других руководствах. Samba должна сама разобраться, откуда берутся пароли.

Переходим к настройке каталогов. Здесь все просто:

[homes]
        comment = Home Directories
        valid users = %S, %D%w%S
        browseable = No
        read only = No
        inherit acls = Yes
        available = Yes
  [profiles]
        comment = Network Profiles Service
        path = %H
        read only = No
        store dos attributes = Yes
        create mask = 0600
        directory mask = 0700
[users]
        comment = All users
        path = /home
        read only = No
        inherit acls = Yes
        veto files = /aquota.user/groups/shares/
[groups]
        comment = All groups
        path = /home/groups
        read only = No
        inherit acls = Yes
[SRV]
        comment = Common files
        path = /local
        write list = Administrator
        guest ok = Yes
        hosts allow = 192.168.7.

К стандартному списку разделяемых каталогов, распространяемому вместе с дистрибутивом Samba, мы добавили только секцию [SRV] — общедоступный каталог.

Конфигурирование всех необходимых файлов закончено, и мы приступаем к проверке работоспособности нашего сервера.

Проверка работоспособности

Здесь мы проверим корректность наших настроек и включим наш новый сервер в домен Windows. Сначала проверим корректность настройки Samba:

linux-test:~ # testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[homes]"
Processing section "[profiles]"
Processing section "[users]"
Processing section "[groups]"
Processing section "[SRV]"
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions

Как видно, каких-либо серьезных предупреждений и ошибок конфигурации у нас нет.

Теперь запустим по очереди демоны smbd, nmbd иwinbindd. Сделаем это через файлы /etc/init.d/smb, /etc/init.d/nmbи /etc/init.d/winbind. Можно выполнить это и вручную, что может оказаться полезным для получения различной дополнительной информации. О том, как это сделать, можно прочесть во встроенных руководствах (man) по smbd, nmbd иwinbindd.

Проверим состояние нашего домена и нашего сервера в домене. Состояние домена можно получить командой net adsinfo:

linux-test:~ # net ads info
LDAP server: 192.168.7.2
LDAP server name: LAB-DC1.lab.local
Realm: LAB.LOCAL
Bind Path: dc=LAB,dc=LOCAL
LDAP port: 389
Server time: Thu, 05 Apr 2012 13:03:47 MSK
KDC server: 192.168.7.2
Server time offset: 4
linux-test:~ #

Каквидно, все в порядке. Если какие-то параметры, выводимые командой, не совпадают с нашим планом, надо искать причину.

Теперь проверим состояние нашего сервера в домене:

linux-test:~ # net ads status -U Administrator
Enter Administrator's password:
No machine account for 'LINUX-TEST' found
linux-test:~ #

Отсюда следует, что наш сервер не включен в домен. Запрос к контроллеру домена делается от имени администратора, и пароль нужно указывать от учетной записи администратора домена Windows.

Включим наш сервер в домен:

linux-test:~ # net ads join -U Administrator
Enter Administrator's password:
Using short domain name -- LAB
Joined 'LINUX-TEST' to realm 'lab.local'
DNS Update for linux-test.lab.local failed: ERROR_DNS_UPDATE_FAILED
DNS update failed!
linux-test:~ #

Итак, наш новый сервер включен в домен, о чем свидетельствуют строки

Using short domain name -- LAB
Joined 'LINUX-TEST' to realm 'lab.local'

Динамическое изменение DNS у нас не прошло. Это не страшно, поскольку оно и не планировалось. Теперь рекомендуется перезапустить все наши процессы — smbd, nmbd и winbindd. Заметим, что после перезапуска до дальнейших проверок должно пройти несколько минут.

Проверим статус нашего сервера в домене:

linux-test:~ # net ads status -U Administrator
Enter Administrator's password:

В ответ мы получим распечатку состояния нашего нового сервера в домене. Там будут указаны различные поля AD, относящиеся к нашему серверу. Наш сервер GNU/Linux мы также увидим на вкладке Computers, запустив средство администратора AD наконтроллере домена.

Можно проверить список пользователей домена:

linux-test:~ # net ads user -U Administrator
Enter Administrator's password:
Administrator
Guest
krbtgt
usertest
linux-test:~ #

И проверим работу winbind:

linux-test:~ # wbinfo -t
checking the trust secret for domain LAB via RPC calls succeeded
linux-test:~ #
И получим список пользователей в домене:
linux-test:~ # wbinfo -u
LAB/administrator
LAB/guest
LAB/krbtgt
LAB/usertest
linux-test:~ #
Можно проверить состояние домена через wbinfo:
linux-test:~ # wbinfo -D LAB
Name              : LAB
Alt_Name          : lab.local
SID               : S-1-5-21-3914562201-450990341-53424453
Active Directory  : Yes
Native            : Yes
Primary           : Yes
linux-test:~ # wbinfo -P
checking the NETLOGON dc connection succeeded
linux-test:~ #

Все в порядке.

Теперь самая главная проверка:попробуем открыть каталоги на нашем новом сервере, используя рабочую станцию под управлением Windows 7.Наша рабочая станция включена в домен. Мы должны увидеть наш новый сервер на вкладке Network обозревателя Windows, указавлибо имя, либо IP-адрес:

Теперь можно переходить к дальнейшим процедурам настройки нашего сервера. Далее мы рассмотрим некоторые нюансы описанного процесса в зависимости от дистрибутива GNU/Linux и подробнее рассмотрим настройку прав доступа к серверу Samba.

Работа выполнена на базе Информационно-вычислительного центра МЭИ.

Авторы статьи: Хорьков Сергей Николаевич, Коркин Владислав Сергеевич, Тютиков Дмитрий Алексеевич.

 

Данный материал написан участником сообщества. В статье представлено мнение автора, которое может не совпадать с мнением корпорации Microsoft. Microsoft не несет ответственности за проблемы в работе аппаратного или программного обеспечения, которые могли возникнуть после использования материалов данной статьи.