1. Конфигурационные файлы.
Мы будем настраивать доступ к серверу 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.
#
Естественно, в вашем случае имена будут другими.
Обязательно сделайте запись DNS в домене lab.local, указывающую на наш новый сервер.
Запись в 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 [email protected]
Password for [email protected]:
linux-test:~ # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting Expires Service principal
04/05/12 11:22:23 04/05/12 21:22:35 krbtgt/[email protected]
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 включает в себя три демона — 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, указывающий, что пароли находятся на LDAP-сервере, который является контроллером домена.
Кстати, вы можете указать несколько серверов, перечислив их через пробел.
Это полезно, если у нас несколько контроллеров домена.
Строка usershare разрешить гости = Да позволяет пользователям контролировать доступ к своим папкам, открывая их для гостей.
Остальные строки относятся к управлению печатью и процессу регистрации.
В нашем случае они необязательны и перенесены из конфигурационного файла дистрибутива Samba.
Продолжим редактирование раздела [global] файла smb.conf. domain logons = No
domain master = No
security = ADS
encrypt passwords = yes
Входы в домен и главные линии домена позволяют использовать Samba в качестве контроллера домена.
Это не наш случай и поэтому им поставлен №.
Безопасность линии = ADS является ключевым моментом.
Таким образом мы указываем Samba, что сервер является членом домена Windows и за авторизацию отвечает AD. Строка encrypt пароли = да означает, что используются зашифрованные пароли.
Продолжим редактировать тот же раздел [global].
ldap admin dn = [email protected]
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.
Раздел глобальных настроек завершен.
Обратите внимание, что у нас нет строк сервера паролей и idmap, которые можно найти в других руководствах.
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] — публичный каталог.
Настройка всех необходимых файлов завершена, и мы приступаем к проверке работоспособности нашего сервера.
2. Проверка работоспособности.
Здесь мы проверим правильность наших настроек и включим наш новый сервер в домен Windows. Для начала проверим правильность настройки Samba:
л inux-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. Давайте проверим состояние нашего домена и нашего сервера в домене.
Статус домена можно получить с помощью команды netadsinfo. 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:~ #
Как видите, все в порядке.
Если какие-то параметры, выдаваемые командой, не совпадают с нашим планом, нужно искать причину.
Теперь проверим состояние нашего сервера в домене:
л inux-test:~ # net ads status -U Administrator
Enter Administrator's password:
No machine account for 'LINUX-TEST' found
linux-test:~ #
Отсюда следует, что наш сервер не входит в домен.
Запрос к контроллеру домена делается от имени администратора, а пароль необходимо указать от учетной записи администратора домена Windows.
Теперь нам необходимо присоединить наш сервер к домену:
л inux-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 на вкладке «Компьютеры», запустив инструмент администратора AD на контроллере домена.
Вы можете проверить список пользователей домена:
л inux-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:~ #
И получаем список пользователей в домене:
л inux-test:~ # wbinfo -u
LAB/administrator
LAB/guest
LAB/krbtgt
LAB/usertest
linux-test:~ #
Проверить статус домена можно через wbinfo:
л inux-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. Наша рабочая станция включена в домен.
Мы должны увидеть наш новый сервер на вкладке «Сеть» браузера Windows, указав имя или IP-адрес:
Теперь мы можем перейти к дальнейшим процедурам настройки нашего сервера.
В дальнейшем мы рассмотрим некоторые нюансы описываемого процесса в зависимости от дистрибутива GNU/Linux и подробнее рассмотрим настройку прав доступа к серверу Samba. Работа проводилась на базе Информационно-вычислительного центра МИИ.
Теги: #linux #Системное администрирование #сеть #kerberos #Samba #openldap #openldap #folders #folders
-
Что Такое Светодиод (Светоизлучающий Диод)?
19 Oct, 24 -
Варианты Использования Cisco Eem
19 Oct, 24