Ssh на centos через active directory. аутентификация на linux с учетной записью контроллера домена

Summary

Winbind can be used with different backends , , , and . These backends will help the Red Hat Enterprise Linux system figure out the SID to uid/gid mappings. If you are using winbind, you will need to choose most appropriate backend for your environment. i.e. If this is for a single system, where keeping the uid/gid info the same across multiple systems is not important. The default tdb backend may be appropriate. If you need uid/gid info to be consistent across many systems, one of the other backends will be more appropriate. i.e: or .

Lastly I hope the steps from the article to join/add CentOS 8 to Windows Domain Controller on Linux was helpful. So, let me know your suggestions and feedback using the comment section.

Related Searches: join centos 8 to windows domain. rhel 8 active directory authentication. rhel 8 oddjob. centos 8 samba active directory. realm join. join centos to windows domain. how to join domain in redhat linux. centos 8 samba active directory. join centos 8 to windows domain

Полезные комманды

$ smbclient -N -L 10.0.0.117	показывает ресурсы компьютера с адресом 10.0.0.117
$ smbclient //10.0.0.117/common	Вход в расшаренную директорию. Пользователь unix от которого выполняется команда должен быть зарегистрирован в домене.
# net ads join -U pavel -d 3	Добавить в домен пользователя pavel
# winbindd -d 3 -i	Режим отладки (-d), winbindd запускается не как демон (-i)
# wbinfo -a mydomain\\myuser%mypasswd	авторизируемся в домене (через winbindd, wbinfo входит в этот пакет)
# ldapsearch	запросы к LDAP серверу, в нашем случае к MS Active Directory
# tdbdump /etc/samba/secrets.tdb	просмотреть содержимое файла *.tdb

Предоставление привилегий суперпользователя группе «Администраторы контроллера домена AAD»

Чтобы предоставить членам группы администраторов контроллера домена AAD права администратора на виртуальной машине CentOS, добавьте запись в /etc/sudoers. После добавления члены группы администраторов контроллера домена AAD могут использовать команду на виртуальной машине CentOS.

Откройте файл sudoers для редактирования:
Добавьте следующую запись в конец файла /etc/sudoers. Группа администраторов контроллера домена AAD содержит пробелы в имени, поэтому включите escape-символ обратной косой черты в имя группы. Добавьте собственное доменное имя, например aaddscontoso.com:

По завершении сохраните и закройте редактор с помощью команды редактора.

Подключение CentOS 7 к домену

Устанавливаем софт, который нам понадобится, для корректного ввода centos в домен windows.

# yum install realmd sssd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools

Вводим Centos 7 в домен:

# realm discover XS.LOCAL
xs.local
  type: kerberos
  realm-name: XS.LOCAL
  domain-name: xs.local
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools

# realm join -U administrator XS.LOCAL
Password for administrator:

Если не получили никакой ошибки, значит все прошло нормально. Можно зайти на контроллер домена и проверить, появился ли наш linux сервер в домене.
Изменим немного конфиг sssd для того, чтобы не нужно было вводить полное имя домена при логине, а только username.

# mcedit /etc/sssd/sssd.conf

use_fully_qualified_names = False

Разрешаем доменным пользователям создавать домашние директории:

# authconfig --enablemkhomedir --enablesssdauth --updateall

Запускаем службу sssd и добавляем в автозагрузку:

# systemctl enable sssd.service && systemctl restart sssd

Проверяем авторизацию по ssh, подключившись по любой доменной учетной записи.
Для пользователя будет создана домашняя директория /home/lin-user@xs.local.

Настройка сети и hostname.

Как правило, настройки сети и hostname задаются при установке CentOS, но если требуется изменить:

Способ 1. Через мастер настройки Network Manager:

Способ 2. Через редактирование текстовых конфигураций:

Опеределяем имя файла с конфигурацией интерфейса:

Значит искомый файл: /etc/sysconfig/network-scripts/ifcfg-eno16777984. Открываем:

У меня сетевых интерфейса два и настройки выглядят так:

Учтите, что служба network парсит все, что лежит в данной папке и начинается с ifcfg- *, добавляя эти настройки ввиде дополнительных IP-адресов к данному адаптеру. Например, если создать два файла: ifcfg-eno1 и ifcfg-eno1–2, то интерфейс будет иметь два айпи адреса и настройки содержащиеся в этих файлах.

Разобраться с настройками можно с помощью команды:

Зачастую при использовании AD DC в Samba возникают проблемы с поддержкой TCP/IP v6, поэтому отключаем поддержку :

Применяем настройки ядра:

и перезапускаем сеть:

Поумолчанию net-tools не включены в CentOS7 Minimal. Устанавливаем, если нужно и проверяем настройки сети:

Доменный контроллер Samba4

Samba позволяет организовать аналог контроллера домена Windows 2003/2008 на Linux системах. С выходом четвертой версии Samba появилась возможность использовать групповые политики и ряд других функций, стандартных для контроллеров на базе Microsoft Windows Server.

В качестве DNS-backend можно использовать BIND9_DLZ. Однако настройка в связке с ним является довольно трудоемкой и “сырой”, поскольку в официальных версиях Samba4 отсутствует его поддержка. В то же время, Samba позволяет использовать свой штатный DNS-backend — SAMBA_INTERNAL, вполне пригодный для использования в небольших корпоративных сетях.

В данной заметке будет рассмотрено, как настроить AD DC в Samba4 на CentOS 7.2 Minimal при использовании штатного DNS-backend — Samba_Internal.

1. An overview of the lab environment

For demonstrations of this article to add CentOS 8 to Windows Domain Controller (Active Directory), we will use virtual machines running in an Oracle VirtualBox installed on my Linux Server virtualization environment.

We have a Microsoft Server 2012R2 Active Directory Domain Controller with the IP address 192.168.0.107, CentOS 8 host with the IP address 192.168.0.117 and RHEL 8 with IP Address 192.168.0.106. In this article I will only cover the part to add CentOS 8 to Windows Domain Controller on the client side. So this article requires a pre-configured Windows Active Directory.

I have only used snippets from my CentOS 8 Server but I have verified the steps on both RHEL 8 and CentOS 8.

8. Configure the NSS and PAM stack for authentication

Execute the following command to configure NSS and PAM stack. We use to make sure the home directory for active directory users are automatically created when they login.

# authselect select winbind with-mkhomedir --force
Backup stored at /var/lib/authselect/backups/2021-03-03-19-16-20.jS4CgG
Profile "winbind" was selected.
The following nsswitch maps are overwritten by the profile:
- passwd
- group

Make sure that winbind service is configured and enabled. See winbind documentation for more information.

- with-mkhomedir is selected, make sure pam_oddjob_mkhomedir module
  is present and oddjobd service is enabled
  - systemctl enable oddjobd.service
  - systemctl start oddjobd.service

Ensure that has the following and entries. In this file, you have to tell Linux that it should use Winbind before trying to authenticate locally on Linux.

passwd:     files winbind
group:      files winbind

Enable and start/restart service:

# systemctl enable oddjobd --now

Test resolving AD users and groups and authentication of users.

# getent passwd GOLINUXCLOUD\\administrator
GOLINUXCLOUD\administrator:*:1100500:1100513::/home/GOLINUXCLOUD/administrator:/bin/bash

# id GOLINUXCLOUD\\administrator
uid=1100500(GOLINUXCLOUD\administrator) gid=1100513(GOLINUXCLOUD\domain users) groups=1100513(GOLINUXCLOUD\domain users),1100500(GOLINUXCLOUD\administrator),1100572(GOLINUXCLOUD\denied rodc password replication group),1100518(GOLINUXCLOUD\schema admins),1100519(GOLINUXCLOUD\enterprise admins),1100520(GOLINUXCLOUD\group policy creator owners),1100512(GOLINUXCLOUD\domain admins),100001(BUILTIN\users),100000(BUILTIN\administrators)

Исправления и альтернативные варианты

1. Создание несуществующих в AD учетных записей

В вебинаре создание учетной записи происходит до проверки ее подлинности, поэтому лучше расположить модули так:

# cat /etc/pam.d/common-auth

...
auth          pam_krb5.so minimum_uid=1000
auth          pam_unix.so nullok_secure try_first_pass
auth    requisite                       pam_deny.so
auth    sufficient                      pam_script.so
auth    required                        pam_permit.so
...

Вариант решения — не удалять в скрипте /tmp/krb5cc_0 и обновлять TGT через cron

client1:~# crontab -l

0 */8 * * * kinit -R >/dev/null 2>&1

Усиливается проблема (уже была) параллельного подключения нескольких пользователей к рабочей станции

Особенно, если для отладки пользователи постоянно создаются/удаляются

...
  sed -i.bak -e "/\/home\/$PAM_USER/d" /etc/fstab
...

4. Configure Winbind with smb.conf

Configure by replacing the existing content under section with the following content to add Linux to windows active directory. Modify the realm and workgroup value as per your environment.

You can also use Red Hat’s AD Integration Helper to help generate optimal configuration values for connecting to your organizations Active Directory.

        workgroup = GOLINUXCLOUD
        realm = GOLINUXCLOUD.COM
        security = ads
        idmap config * : backend = autorid
        idmap config * : range = 100000-19999999
        idmap config * : rangesize = 1000000
        template homedir = /home/%D/%U
        template shell = /bin/bash
        winbind use default domain = false
        winbind offline logon = true
        log file = /var/log/samba/log.%m
        max log size = 50
        log level = 0

security=ads describes the membership in an Active Directory domain.

The parameters idmap* and winbind enum* map Windows users and groups to Unix users and groups.

Usually system users and groups are assigned IDs in the range from 0 to 999, and local users and groups are assigned IDs starting from 1000. With this in mind, it seems pretty reasonable to start assigning IDs to domain users and groups starting from 1000000. We should also differentiate between the domain users and groups and the local built-in accounts existing on a member server, such as the local administrator, the local guest, and so on. These two groups must not overlap, so we assign the range 1000000 to 19999999 to domain built-in user and group accounts

Run the following command to verify that you can resolve the standard SRV records:

# host -t SRV _kerberos._udp.golinuxcloud.com.
_kerberos._udp.golinuxcloud.com has SRV record 0 100 88 win-71humtros3m.golinuxcloud.com.


# host -t SRV _ldap._tcp.golinuxcloud.com.
_ldap._tcp.golinuxcloud.com has SRV record 0 100 389 win-71humtros3m.golinuxcloud.com.

Stop the service if it is in running state:

# systemctl stop winbind

5. Join/Add CentOS 8 to Windows Domain Controller

We join the Linux client with Windows Active Directory by executing on the client host:

It is possible that you may get the following ERROR while joining Linux client to Windows AD using Samba Winbind.

Joined 'centos-8' to dns domain 'GOLINUXCLOUD.COM'
DNS Update for centos-8.golinuxcloud.com failed: ERROR_DNS_UPDATE_FAILED
DNS update failed: NT_STATUS_UNSUCCESSFUL

5.1 How to fix «DNS Update for DOMAIN failed. ERROR_DNS_UPDATE_FAILED»?

You can either choose to avoid doing any DNS updates while you add CentOS 8 to Windows Domain Controller by using

# net ads join -U Administrator --no-dns-updates  golinuxcloud.com

Or to fix error observed above, perform the following steps

Add following information to .

# echo "127.0.0.1 `hostname` `hostname -a`" >> /etc/hosts

Make sure that the IP address of the DNS server is in . The IP address should be the DNS server you want to update the new DNS ‘A’ record.

# cat /etc/resolv.conf
search golinuxcloud.com
nameserver 192.168.0.107

On your Windows Domain Controller, select «DNS Manager» for your server. Select your server in the Forward Lookup Zone and right click to open Properties. Select the Dynamic updates to «» or «» on the Windows DNS server.

Next restart the DNS service to activate the changes and re-try to add CentOS 8 to Windows Domain Controller

# net ads join -U Administrator golinuxcloud.com
Enter Administrator's password:
Using short domain name -- GOLINUXCLOUD
Joined 'centos-8' to dns domain 'GOLINUXCLOUD.COM'

Вводим CentOS 7 в домен с помощью winbind

Если у вас виртуальная машина, проще установить ее с нуля. Если не хочется по какой-то причине, можно просто удалить все установленные ранее пакеты через команду yum remove. Я поступил именно так.

Устанавливаем недостающие пакеты:

Не забудьте о настройке синхронизации времени, которую мы делали на предыдущих шагах. Надо это проделать, если вы сразу начали настройку с данного пункта. Так же убедитесь, что все в порядке с dns, и контроллеры домена пингуются по именам.

Формируем конфиг для kerberos.

Для удобства дублирую таблицу с информацией, чтобы не пришлось скролить страницу вверх.

xs.local	название домена
10.1.3.4	ip адрес контроллера домена
xs-winsrv.xs.local	полное имя контроллера домена
xs-design	имя сервера centos, который вводим в домен
admin51	учетная запись администратора домена

Вывод после работы команды у меня такой:

Это не страшно, продолжаем настройку. Заводим сервер с CentOS в домен:

На выходе получил:

В принципе, ничего страшного. Нам придется самим создать A запись на DNS сервере. Я не понимаю, почему иногда она не создается автоматически. Во время написания статьи, я использовал один сервер, у него не было этой ошибки при вводе в домен. Когда проверял статью на втором сервере, получил эту ошибку. Проверяем на контроллере домена в списке компьютеров наш сервер и создаем руками А запись, соответствующую имени сервера и его IP адресу.

Теперь рисуем конфиг для самбы примерно такой.

У меня русский язык на контроллере домена, поэтому и имена групп на русском. Проблем с этим не возникает. Не забудьте создать директорию /mnt/shara.

Запускаем samba и winbind и добавляем в автозагрузку.

Выполняем ряд проверок, чтобы убедиться, что все в порядке, winbind работает и samba будет получать актуальную информацию о пользователях и группах домена.

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

Проверим теперь авторизацию в домене.

В данном случае control — имя пользователя домена, pass — его пароль. Успешная проверка выглядит так, как у меня. В завершении проверок посмотрим, корректно ли система сопоставляет доменные учетные записи локальным.

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

Проверяем, что получилось.

Уберем доступ на чтение у всех остальных, оставим полные права для пользователя admin51 и на чтение у пользователей домена.

Идем на любую виндовую машину и пробуем зайти на шару по адресу \\ip-адрес-сервера. Попадаем на нашу шару.Если не получилось зайти, проверьте настройки iptables. На время отладки можно их отключить. Так же убедитесь, что у вас запущена служба smb.service.

Смотрим расширенные параметры безопасности:

Получилось то, что хотели. Управлять правами доступа можно через windows acl с любой машины windows, где учетная запись пользователя домена будет обладать необходимыми правами. Если по какой-то причине это не получится (а я с такими ситуациями сталкивался достаточно часто), на помощь придут консольные утилиты getfacl для проверки прав и setfacl для изменения прав. Документация по этим командам есть в сети и легко ищется. Я рекомендую всегда использовать эти команды, когда вы выполняете изменение прав по большому дереву каталогов. Через консоль выставление прав будет выполнено раз в 5-10 быстрее, чем через windows acl. На больших файловых архивах разница может быть в десятки минут или даже часы.

Настройка Samba и вход в домен

Для того, чтобы войти в домен, необходимо прописать правильные настройки в файле . На данном этапе вас должны интересовать только некоторые опции из секции . Ниже — пример части файла конфигурации Samba с комментариями по поводу значения важных параметров:

   # Эти две опции нужно писать именно в заглавном регистре, причём workgroup без
   # последней секции после точки, а realm - полное имя домена 
   workgroup = DOMAIN
   realm = DOMAIN.COM

   # Эти две опции отвечают как раз за авторизацию через AD
   security = ADS
   encrypt passwords = true
   # Просто важные 
   dns proxy = no 
   socket options = TCP_NODELAY

   # Если вы не хотите, чтобы самба пыталась при случае вылезти в лидеры в домене или рабочей группе,
   # или даже стать доменконтроллером, то всегда прописывайте эти пять опций именно в таком виде
   domain master = no
   local master = no
   preferred master = no
   os level = 0
   domain logons = no

   # Отключить поддержку принтеров
   load printers = no
   show add printer wizard = no
   printcap name = /dev/null
   disable spoolss = yes

После того, как вы отредактируете выполните команду

testparm

Она проверит вашу конфигурацию на ошибки и выдаст суммарную сводку о нём:

# testparm
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions

Как видно мы задали правильные параметры для того, чтобы наш компьютер стал членом домена. Теперь пора попытаться непосредственно войти в домен. Для этого введите команду:

net ads join -U username -D DOMAIN

И в случае успеха вы увидите что-то похожее на:

# net ads join -U username -D DOMAIN
Enter username's password:
Using short domain name -- DOMAIN
Joined 'SMBSRV01' to realm 'domain.com'

Используемые параметры команды net

: Обязательный параметр, вместо необходимо подставить имя пользователя с правами администратора домена, и указать пароль.

: — собственно сам домен, домен можно и не указывать, но лучше всё же это всегда делать — хуже не будет.

: , можно не указывать, но бывают случаи когда автоматически сервер не находит контроллер домена.

: В AD часто используется OU (Organizational Unit), есть в корне домена OU = Office, в нем OU = Cabinet, чтобы сразу добавить в нужный можно указать так: sudo net ads join -U username createcomputer=«Office/Cabinet».

Если больше никаких сообщений нет — значит всё хорошо. Попробуйте попинговать свой компьютер по имени с другого члена домена, чтобы убедиться, что в домене всё прописалось так, как надо.

Так же можно набрать команду:

net ads testjoin

Если все хорошо, можно увидеть:

#net ads testjoin
Join is OK

Но иногда после сообщения о присоединении к домену выдаётся ошибка наподобие:

DNS update failed!

Это не очень хорошо, и в этом случае рекомендуется ещё раз прочитать раздел про настройку DNS чуть выше и понять, что же вы сделали не так. После этого нужно удалить компьютер из домена и попытаться ввести его заново. Если вы твердо уверены, что всё настроили верно, а DNS всё равно не обновляется, то можно внести вручную запись для вашего компьютера на ваш DNS сервер и всё будет работать. Конечно, если нет никаких других ошибок, и вы успешно вошли в домен. Однако лучше всё же разберитесь, почему DNS не обновляется автоматически. Это может быть связано не только с вашим компьютером, но и с некорректной настройкой AD.

Прежде чем выяснять, почему же не обновляется DNS, не забудьте перезагрузить компьютер после введения в домен! Вполне возможно, что это решит проблему.

Если всё прошло без ошибок, то поздравляем, вы успешно вошли в домен! Можете заглянуть в AD и убедиться в этом. Кроме того хорошо бы проверить, что вы можете видеть ресурсы в домене. Для этого установите :

sudo aptitude install smbclient

Теперь можно просматривать ресурсы компьютеров домена. Но для этого нужно иметь билет kerberos, т.е. если мы их удалили, то получаем опять через kinit (см. выше). Посмотрим какие ресурсы предоставлены в сеть компьютером :

smbclient -k -L workstation

Вы должны увидеть список общих ресурсов на этом компьютере.

Настройка iptables.

После того как настройка и тестирование завершены можно задать правила и включить iptables. Но для начала убедимся, что альтернативный firewalld отключен:

если активен, то убираем из автозагрузки и отключаем:

По желанию можно так же отключить Network Manager (команда nmtui), поскольку все настройки сети можно производить, редактируя /etc/sysconfig/network-scripts/.

Проверяем статус Network Manager:

убираем из автозагрузки и отключаем:

Для Enterprise Linux, возможно, потребуется убрать из автостарта ipchains:

В минимальных дистрибутивах, таких как Centos 7.2 minimal пакет iptables поумолчанию может отсутствовать. Устанавливаем:

и добавляем правила:

Запускаем iptables и добавляем в автозагрузку:

Листинг всех правил с номерами строк и портов можно получить по команде:

Подготовка сервера

Для подготовки сервера безопасности с доступом к данным по LDAP необходим сервер с правильно настроенным временем. Также необходимо правильно настроить межсетевой экран и систему безопасности SELinux.

Время

Установим часовой пояс:

timedatectl set-timezone Europe/Moscow

* в данном примере используется московское время.

Затем устанавливаем и запускаем утилиту для синхронизации времени chrony.

yum install chrony

systemctl enable chronyd —now

Имя сервера

Для корректной работы сервера, необходимо, задать ему полное доменное имя (FQDN). Выполняем команду:

hostnamectl set-hostname ipa-server.dmosk.local

* где ipa-server.dmosk.local — имя сервера, которое будет использоваться.

Брандмауэр

Необходимо открыть несколько портов, которые используются службами FreeIPA:

firewall-cmd —permanent —add-port=53/{tcp,udp} —add-port=80/tcp —add-port=88/{tcp,udp} —add-port=123/udp —add-port=389/tcp —add-port=443/tcp —add-port=464/{tcp,udp} —add-port=636/tcp

firewall-cmd —reload

Ограничение доступа ssh по группам и пользователям домена

На текущий момент подключиться к серверу может любой пользователь домена. Исправим это и разрешим подключаться только пользователям из группы gr_linux_adm. Для этого правим конфиг /etc/sssd/sssd.conf, добавляя туда новые параметры.

Обращаю внимание, что параметр access_provider у вас уже будет установлен в другое значение. Надо это изменить

Вы можете добавить разрешение как для конкретного пользователя, так и для целых групп. Сохраняйте конфиг и перезапускайте sssd.

Теперь подключиться по ssh к серверу сможет только пользователь домена user55 и все члены группы gr_linux_adm.

Для разбора полетов и решения проблем нужно использовать лог файл — /var/log/secure. Вот пример успешного подключения:

А вот кусок лога подключения доменного пользователя, для которого доступ по ssh закрыт.

Здесь видно, что идентификация пользователя прошла корректно, но доступ к серверу запрещен.

Настройка CentOS

Kerberos

Устанавливаем следующие пакеты:

yum install cyrus-sasl-gssapi krb5-workstation krb5-devel

Открываем конфигурационный файл Kerberos:

vi /etc/krb5.conf

Редактируем следующие строки:

…
default_realm = DOMAIN.LOCAL
..

DOMAIN.LOCAL = {
kdc = 192.168.0.15
kdc = 192.168.0.16
kdc = 192.168.0.17
admin_server = domain.local
}

* DOMAIN.LOCAL — наш домен; kdc — перечень контроллеров домена; admin_server — первичный контроллер (в данном примере будет использоваться случайный).

Проверяем настройки krb, запросив тикет:

kinit domainuser

klist

При правильных настройках мы увидим на подобие:

Ticket cache: KEYRING:persistent:0:0
Default principal: domainuser@DOMAIN.LOCAL

Valid starting Expires Service principal
15.05.2018 10:08:33 15.05.2018 20:08:33 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
renew until 22.05.2018 10:08:30

Проверяем keytab-файл, который мы перенесли на сервер с контроллера домена:

kinit -V -k -t /etc/squid/proxy.keytab HTTP/proxy.domain.local@DOMAIN.LOCAL

* где /etc/squid/proxy.keytab — путь до keytab-файла; HTTP/proxy.domain.local@DOMAIN.LOCAL — принципал, который был задан при создании файла.

И снова:

klist

Картина, примерно, следующая:

Ticket cache: KEYRING:persistent:0:krb_ccache_9MN6pt8
Default principal: HTTP/proxy.domain.local@DOMAIN.LOCAL

Valid starting Expires Service principal
16.05.2018 09:35:20 16.05.2018 19:35:20 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
renew until 23.05.2018 09:35:20

Зададим файлу следующие права:

chown squid:squid /etc/squid/proxy.keytab

chmod u+rwx,g+rx /etc/squid/proxy.keytab

NTLM

Устанавливаем следующие пакеты:

yum install samba-winbind samba-winbind-clients pam_krb5 krb5-workstation

Конфигурируем

authconfig —enablekrb5 —krb5kdc=domain.local —krb5adminserver=domain.local —krb5realm=domain.LOCAL —enablewinbind —enablewinbindauth —smbsecurity=ads —smbrealm=domain.LOCAL —smbservers=domain.local —smbworkgroup=domain —winbindtemplatehomedir=/home/%U —winbindtemplateshell=/bin/bash —enablemkhomedir —enablewinbindusedefaultdomain —update

* где domain.local — это наш домен, domain — домен в сокращенной нотации. Регистр важен.
* если после ввода команды мы увидим ошибку Job for winbind.service failed because the control process exited with error code. See «systemctl status winbind.service» and «journalctl -xe» for details — игнорируем ее. Она возникает из-за того, что наш сервер еще не в домене.

Добавляем сервер в домен:

net ads join -U administrator

* где administrator — учетная запись в AD с правами на ввод компьютеров в домен.

Разрешаем автозапуск winbind и запускаем его:

systemctl enable winbind

systemctl start winbind

Проверяем, что наш сервер умеет обращаться к службе каталогов:

wbinfo -t

wbinfo -g

* первая команда проверяет возможность отправлять запросы на контроллер домена; вторая — выводит список групп, находящихся в каталоге.

Настройка прав доступа на файлы в Samba

Сделаю небольшое пояснение по правам доступа в файловом сервере samba. Вопрос этот сложный и объемный. Ему можно посвятить и отдельную статью. Но для полноты картины по настройке самбы, расскажу самое основное.

Как я уже ранее сказал, изменять права доступа к каталогам на файловом сервере можно с помощью команды setfacl. Давайте сейчас посмотрим на права доступа, которые установлены:

# getfacl /mnt/samba

# file: mnt/shara
# owner: admin51
# group: пользователи\040домена
user::rwx
group::r-x
other::---

С такими правами что-то создавать в папке сможет только пользователь admin51, а пользователи домена смогут только просматривать файлы и каталоги. Сделаем более прикладной вариант. Добавим права доступа на чтение и запись еще одной доменной группе — gr_it.

# setfacl -m g:gr_it:rwx /mnt/shara

Обращаю внимание, что иногда при копировании команд setfacl они не отрабатывают, выдавая не очень понятную ошибку:

setfacl: Option -m: Invalid argument near character 1

Наберите команду с клавиатуры, либо просто удалите и наберите снова ключ -m, он почему-то при копировании часто дает эту ошибку.

Смотрим, что получилось:

# getfacl /mnt/shara

# file: mnt/shara
# owner: admin51
# group: пользователи\040домена
user::rwx
group::r-x
group:gr_it:rwx
mask::rwx
other::---

То, что надо. Теперь пользователи группы gr_it имеют полные права на шару. Создадим одним таким пользователем папку test1 на нашей шаре и посмотрим, какие права она получит.

# getfacl /mnt/shara/test1

# file: mnt/shara/test1
# owner: user1
# group: пользователи\040домена
user::rwx
group::---
other::---

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

# setfacl -m d:g:gr_it:rwx,d:g:'пользователи домена':rx /mnt/shara

Смотрим, что получилось:

# getfacl /mnt/shara

# file: mnt/shara
# owner: admin51
# group: пользователи\040домена
user::rwx
group::r-x
group:gr_it:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:пользователи\040домена:r-x
default:group:gr_it:rwx
default:mask::rwx
default:other::---

Создадим теперь тем же пользователем еще одну папку test2 и проверим ее права.

# getfacl /mnt/shara/test2

# file: mnt/shara/test2
# owner: user
# group: пользователи\040домена
user::rwx
group::---
group:пользователи\040домена:r-x
group:gr_it:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:пользователи\040домена:r-x
default:group:gr_it:rwx
default:mask::rwx
default:other::---

Применилось наследование с вышестоящих папок. Не забывайте про дефолтные права и учитывайте их при настройке прав доступа на файловом сервере.

Для удобной и корректной работы с правами доступа я обычно для крупных, корневых директорий выставляю права аккуратно через setfacl в консоли. Какие-то мелкие изменения по пользователям и группам в более низших иерархиях директорий делаю через windows acl с какой-нибудь виндовой машины.

Еще важно знать одну особенность выставления прав доступа в linux. В моей практике часто требуется дать какому-нибудь пользователю доступ в одну директорию, которая располагается там, где у пользователя нет вообще никаких прав

В windows эта проблема решается просто — даются права на конкретную папку, а пользователю кладется ярлык на эту папку. В итоге он имеет доступ к нужной директории и больше никуда.

В linux так сделать не получится. Для того, чтобы дать таким образом доступ на отдельную директорию пользователю, необходимо, чтобы по всем вышестоящим директориям у него были права на исполнение, то есть X. Их придется выставлять вручную по всем вышестоящим папкам. Результат будет такой же, как и в винде — пользователь получит доступ на чтение только в указанную папку, но для этого придется выполнить больше действий. Если не знаешь этот нюанс, можно потратить много времени, прежде чем поймешь, в чем проблема.

Заключение

На этом все. Я рассмотрел наиболее типовую ситуацию, которая может быть полезной при использовании структуры AD совместно с linux серверами. При написании статьи использовал официальные руководства:

Deployment, Configuration and Administration of Red Hat Enterprise Linux 6
sssd.conf — Linux man page

Почему-то из руководства по RHEL 7 раздел, посвещенный SSSD убрали, хотя в 5 и 6 есть. Может просто я не заметил, так как структура сильно поменялась. Люблю я CentOS в первую очередь за отличную документацию Redhat. Там есть подробное описание практически всего, с чем приходилось сталкиваться. Надо только не лениться в английском языке разбираться.

Заключение

Deployment, Configuration and Administration of Red Hat Enterprise Linux 6
sssd.conf — Linux man page