Как ввести centos 7 в домен windows

CentOS Linux 7 — Присоединение к домену Active Directory средствами realmd/SSSD и настройка аутентификации и авторизации через доменные группы безопасности

Предварительные условия

Присоединение к домену Active Directory

# yum install realmd sssd adcli krb5-workstation

# realm discover ad.holding.com --verbose

# nano /etc/realmd.conf

# realm join --verbose --user=volodya 
 --user-principal="host/kom-vm01.ad.holding.com@AD.HOLDING.COM" 
 --computer-ou="OU=Linux Servers,OU-KOM,DC=ad,DC=holding,DC=com" 
 kom-dc01.ad.holding.com

Настройка Kerberos-клиента

# nano -Y sh /etc/krb5.conf

Настройка SSSD

# nano -Y sh /etc/sssd/sssd.conf

# systemctl stop sssd
# ( rm -f /var/lib/sss/db/* ) && ( rm -f /var/lib/sss/mc/* )
# systemctl start sssd

Проверка взаимодействия с AD

# cat /etc/nsswitch.conf | grep sss

passwd:     files sss
shadow:     files sss
group:      files sss
services:   files sss
netgroup:   files sss

# cat /etc/pam.d/system-auth | grep sss

auth        sufficient    pam_sss.so forward_pass
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
password    sufficient    pam_sss.so use_authtok
session     optional      pam_sss.so

# getent passwd petya

petya@ad.holding.com:*:398447:200613:Петя Резинкин:/home/petya@ad.holding.com:/bin/bash

# getent passwd petya@ad.holding.com

petya@ad.holding.com:*:398447:200613:Петя Резинкин:/home/petya@ad.holding.com:/bin/bash

# getent group KOM-Linux-Admins@ad.holding.com

kom-linux-admins@ad.holding.com:*:396844:petya@ad.holding.com,vova@ad.holding.com

# su - petya@ad.holding.com

$ id


uid=398447(petya@ad.holding.com) gid=200613(domain users@ad.holding.com) 
groups=200613(domain users@ad.holding.com),445177(internet-users@ad.holding.com),
396844(kom-linux-admins@ad.holding.com)

Доступ к SUDO

# nano -Y sh /etc/sudoers.d/kom-linux-admins

# su - petya@ad.holding.com

$ sudo whoami

[sudo] password for petya@ad.holding.com: ******
root

# chmod 0440 /etc/sudoers.d/kom-linux-admins

Настройка SSHD

# nano -Y sh /etc/ssh/sshd_config

# systemctl restart sshd

Ограничение доступа к системе через PAM

# nano -Y sh /etc/security/access-groups-to-login

# chown root:root /etc/security/access-groups-to-login
# chmod 600 /etc/security/access-groups-to-login

# nano -Y sh /etc/pam.d/login

# tail -f /var/log/secure

# nano -Y sh /etc/pam.d/sshd

# tail -f /var/log/secure

2017-11-13 16:53:18 15262 3

В развитой инфраструктуре, где имеется большое количество рабочих станций и серверов, управлением учетными записями обычно осуществляется посредством Windows Active Directory. Поэтому управление линукс серверами так же удобнее осуществлять через централизованное хранение учетных записей. Рассмотрим пример добавления линуксовой машины с операционной системой CentOs7 в домен Windows.

Отключаем SELINUX

sed -i «s/SELINUX=enforcing/SELINUX=disabled/» /etc/selinux/config

Установка iptables

systemctl stop firewalld

systemctl disable firewalld

yum install -y iptables-services

После установки запускаем iptables

systemctl start iptables

systemctl enable iptables

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

yum install -y authconfig samba samba-winbind samba-client

pam_krb5 krb5-workstation vim net-tools bind-utils samba-winbind-clients

Настройка DNS

Указываем в качестве DNS сервера наш контроллер домена

cat /etc/resolv.conf

# Generated by NetworkManager
search test.un
nameserver 172.20.1.56

Если на сервере настроен DHCP, то убедитесь что сервер получает правильные настройки dns-сервера и домена

Проверяем что имя домена резолвится

nslookup test.un

Получаем следующее:

Server:		172.20.1.56
Address:	172.20.1.56#53

Name:	test.un
Address: 172.20.1.56

Присоединение сервера к домену

Запускаем утилиту authconfig-tui

Указываем:
Информация пользователя — Использовать Winbind
Аутентификация — Использовать Kerberos

Жмем далее

Заполняем следующие поля:

• Область — область kerberos, совпадает с именем домена в верхнем регистре;
• KDC(Key Distribution Center ) — kerberos сервер, выступает как сервер по управлению и хранению билетов;
• Сервер администратор — совпадает с KDC;
• Остальные два пункта говорят нам использовать DNS для определения имен серверов и KDC для областей.

Жмем далее

Заполняем следующие поля:

• Модель защиты — выбираем ads(означает, что используются протоколы, совместимые со службами ADS Windows 2008R2);
• Домен — вводим NetBios имя домена, без конечно части;
• Контроллеры домена — указываем адреса контроллеров домена;
• Область ADS — совпадает с именем домена;
• Оболочка шаблона — указывает какую оболочку будут иметь доменные пользователи на linux машине.

Жмем ОК

Запускаем демон Winbind

systemctl start winbind

systemctl enable winbind

Далее производим присоединение к домену

net ads join -U Administrator

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

Using short domain name -- TEST
Joined "CENTOS7-TEST" to dns domain "test.un"
No DNS domain configured for centos7-test. Unable to perform DNS Update.
DNS update failed: NT_STATUS_INVALID_PARAMETER

Машина в домене

Для того чтобы пользователи и группы домена отображались на сервере и вы могли получать доступ к ним, необходимо в файле /etc/samba/smb.conf добавить строки

winbind enum users = yes
winbind enum groups = yes

Для проверки можно использовать утилиту wbinfo и getent

wbinfo -u

Покажет пользователей домена:

TESTadministrator
TESTguest
TESTkrbtgt
TESTtest1
TESTtest2

wbinfo -g

Покажет группы домена:

TESTwinrmremotewmiusers__
TESTdomain computers
TESTdomain controllers
TESTschema admins
TESTenterprise admins
TESTcert publishers
TESTdomain admins
TESTdomain users
TESTdomain guests
TESTgroup policy creator owners
TESTras and ias servers
TESTallowed rodc password replication group
TESTdenied rodc password replication group
TESTread-only domain controllers
TESTenterprise read-only domain controllers
TESTcloneable domain controllers
TESTprotected users
TESTdnsadmins
TESTdnsupdateproxy
TESTsamba

Команда «getent passwd» и «getent group» отобразит локальные учетные записи + доменные и точно так же группы соответственно

getent passwd

....
test:x:1000:1000:test:/home/test:/bin/bash
TESTadministrator:*:16777216:16777218::/home/TEST/administrator:/bin/bash
TESTguest:*:16777217:16777218::/home/TEST/guest:/bin/bash
TESTkrbtgt:*:16777218:16777218::/home/TEST/krbtgt:/bin/bash
TESTtest1:*:16777219:16777218::/home/TEST/test1:/bin/bash
TESTtest2:*:16777220:16777218::/home/TEST/test2:/bin/bash	

Для использования доменных учетных записей необходимо сделать следующее:

1. Изменить значение директивы «winbind use default domain» в файле /etc/samba/smb.conf с false на true, что говорит использовать домен winbind по-умолчанию. И мы можем указывать доменных пользователей без приставки домена.

   [root@centos7-test test]# su test1
   bash-4.2$ id
   uid=16777219(test1) gid=16777218(domain users)
   группы=16777218(domain users),16777217(BUILTINusers) 
   		

2. Добавить директиву «winbind separator» в файл /etc/samba/smb.conf

   winbind separator = ^

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

В большинстве сред домен Active Directory является центральным центром информации для пользователя, а это значит, что для систем Linux необходимо каким-то образом получить доступ к этой пользовательской информации для запросов на аутентификацию.

В этой статье мы покажем вам, как присоединить  системы CentOS 7 / RHEL 7 в домен Active Directory.

Прежде чем присоединиться к домену AD, нам необходимо убедиться, что мы установили службы времени (NTP) и DNS.

При наличии этих инфраструктурных служб нам понадобятся следующие пакеты, установленные на сервере CentOS / RHEL:

• realmd: управляет регистрацией и членством в доменах Active Directory
• samba:  служба samba
• samba-common: общие инструменты для серверов и клиентов
• oddjob: Это служба D-bus, которая запускает odds задания для клиентов
• oddjob-mkhomedir: используется odds службами задания для создания домашних каталогов для учетных записей AD, если это необходимо
• sssd:  демон System Security Services
• adcli: : Это инструменты для присоединения и управления доменами AD

– Используйте следующую команду для установки необходимых пакетов:

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

– Чтобы обнаружить идентификатор домена, мы будем использовать команду обнаружения области, которая вернет полную конфигурацию домена и список пакетов, которые должны быть установлены для системы, которая будет зарегистрирована в домене.

# realm discover yallalabs.local
YALLALABS.LOCAL
  type: kerberos
  realm-name: YALLALABS.LOCAL
  domain-name: YALLALABS.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
yallalabs.local
  type: kerberos
  realm-name: YALLALABS.LOCAL
  domain-name: yallalabs.local
  configured: no

– Чтобы присоединиться к домену AD, добавьте компьютер в папку по умолчанию в домене AD, используя следующую команду:

sudo realm join --user=administrator@yallalabs.local yallalabs.local
Password for administrator@yallalabs.local:

– Если вы хотите добавить его в назначенный организационный блок в Active Directory, вам сначала необходимо создать подразделение или, по крайней мере, обеспечить его существование.

Следующей командой мы присоединяем сервер к домену AD и добавим учетную запись компьютера в подразделение Linux:

# sudo realm join --user=administrator@yallalabs.local --computer-ou=OU=Linux,OU=Servers,DC=YALLALABS,DC=LOCAL yallalabs.local
Password for administrator@yallalabs.local:

Если у вас есть эта ошибка:

” realm: Couldn’t join realm: Joining the domain YALLALABS.LOCAL failed“

просто перезапустите realmd и повторите попытку

– Для тестирования системы успешно присоединился домен, используя следующую команду:

# realm list
YALLALABS.LOCAL
  type: kerberos
  realm-name: YALLALABS.LOCAL
  domain-name: yallalabs.local
  configured: kerberos-member
  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
  login-formats: %U@yallalabs.local
  login-policy: allow-realm-logins

– Чтобы отобразить информацию о пользователе из домена, выполните следующую команду:

# id yl01@yallalabs.local 
uid=344601106(yl01@YALLALABS.LOCAL) gid=344600513(domain users@YALLALABS.LOCAL) groups=344600513(domain users@YALLALABS.LOCAL),344601107(linuxadmins@YALLALABS.LOCAL)

– Чтобы разрешить вход в систему только определенным учетным записям из домена, используйте следующую команду:

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

# realm permit  User1@yallalabs.local User2@yallalabs.local

– Чтобы разрешить только одной группе Active Directory используйте следующую команду: в этом примере мы разрешим группе ADAD LinuxAdmins войти в систему

# realm permit -g LinuxAdmins@yallalabs.local

– Чтобы предоставить разрешения sudo для группы Active Directory, в этом примере мы добавим группу ADAddins ActiveWorks в sudoers, запустив команду visudo и добавив следующую строку:

# visudo
%LinuxAdmins@yallalabs.local        ALL=(ALL)       ALL

– Чтобы покинуть домен Active Directory, вы можете использовать следующую команду:

# realm leave --user=--user=administrator@yallalabs.local yallalabs.local

– Если вы хотите покинуть домен и удалить учетную запись компьютера, вы можете использовать дополнительный параметр -remove в конце команды

# realm leave --user=--user=administrator@yallalabs.local yallalabs.local --remove
Password for administrator@yallalabs.local:

Давно не касался Linux (постепенно стал забывать, как он выглядит :().

На «дохлой» машинке, товарищи попросили организовать Файл-сервер интегрированный с AD. Никогда ранее с AD линуксовые сервера интегрировать мне не доводилось, поэтому решил понять, как это сделать… Попробую в тестовой среде, далее транслирую людям в продакшин, если все получится…

Для начала, необходимо включить наш сервак Linux в домен.

Домен: test.loc

Контроллер: 192.168.10.176 (dc1.test.loc)

Linux сервак: centos

Выключаем firewalld:

systemctl stop firewalld && systemctl disable firewalld

Настроим синхронизацию времени с контроллером домена. Это важно, у меня должно быть одинаковое время с контроллером домена. Убедитесь, что стоят одинаковые часовые пояса.

Устанавливаем утилиту для синхронизации времени chrony:

yum install chrony

Добавляем в конфиг /etc/chrony.conf адрес контроллера домена. И делаем его единственным сервером для синхронизации, остальные удаляем.

cd /etc

ls

nano chrony.conf

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

Сохраняем конфиг, запускаем chrony и добавляем в автозагрузку.

systemctl start chronyd && systemctl enable chronyd

Проверим, что с синхронизацией.

cat /var/log/messages | grep chronyd

Странно, но у меня почему-то отразилось вот так:

Попытаюсь понять, что не так: проверю DNS клиент.

nano /etc/resolv.conf

nameserver 192.168.10.176

Также, в силу того, что SSSD будет использовать Kerberos, нам нужно убедиться в том, что у нас корректно настроен NTP-клиент и время синхронизировано с контроллерами домена AD. Настраиваем конфигурационный файл NTP-клиента:

nano /etc/ntp.conf

Перезапускаем службу ntpd и проверяем статус синхронизации времени:

# service ntpd restart

# ntpq -4 -p

# date -R

Теперь вроде ГУД.

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

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

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

Настраиваем параметры системы, которые будут использованы при присоединении к домену для заполнения атрибутов operatingSystem и operatingSystemVersion.

nano /etc/realmd.conf

[active-directory]

os-name = CentOS Linux

os-version = 7.9.2009

realm discover TEST.LOC

realm join -U testd.khlebalin TEST.LOC

Как оказалось, таким образом Linux учетку не принимает:

Правильно будет вот так (несмотря на то, что это доменная учетка):

realm join -U d.khlebalin TEST.LOC

Теперь все ГУД. Если ошибок нет, то можем наблюдать наш сервер в домене:

Еще гляну вот так:

adcli info test.loc

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

nano /etc/sssd/sssd.conf

use_fully_qualified_names = False

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

authconfig —enablemkhomedir —enablesssdauth –updateall

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

systemctl enable sssd.service && systemctl restart sssd

Пробую авторизоваться под собой:

Но что-то пошло не так…

Странно, но в логах контроллера, не вижу, чтоб я вообще стучался с данного сервера, на контроллер и соответственно никаких сведений о том, что в авторизации отказано, тоже нет ☹

Придется погрузится в детали и попробовать понять, что не так…

Возможно, я не доустановил еще один пакет, а именно Kerberos-клиент, доставлю его:

yum install realmd sssd adcli krb5-workstation

Еще раз проверю успешность обнаружения домена:

realm discover dc1.test.loc –verbose

Убедимся в том, что в keytab-файле присутсвуют записи типа host/<server fqdn>@<DONAIN FQDN>:

klist -kt | grep host/cent

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

nano /etc/krb5.conf

# Configuration snippets may be placed in this directory as well

includedir /etc/krb5.conf.d/

includedir /var/lib/sss/pubconf/krb5.include.d/

[logging]

default = FILE:/var/log/krb5libs.log

kdc = FILE:/var/log/krb5kdc.log

admin_server = FILE:/var/log/kadmind.log

[libdefaults]

dns_lookup_realm = true

dns_lookup_kdc = true

ticket_lifetime = 24h

renew_lifetime = 7d

forwardable = true

rdns = false

pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt

# default_realm = EXAMPLE.COM

default_ccache_name = KEYRING:persistent:%{uid}

default_realm = TEST.LOC

[realms]

# EXAMPLE.COM = {

#  kdc = kerberos.example.com

#  admin_server = kerberos.example.com

# }

TEST.LOC = {kdc = dc1.test.loc

admin_server = dc1.test.loc

}

[domain_realm]

# .example.com = EXAMPLE.COM

# example.com = EXAMPLE.COM

test.loc = TEST.LOC

SSSD у меня уже установлен:

# yum install authconfig sssd

Используем утилиту authconfig чтобы включить поддержку SSSD в NSS и PAM:

authconfig —enablesssd —enablesssdauth —update

Проверим, что вызов sss появился в конфигурационных файлах NSS и PAM:

cat /etc/nsswitch.conf | grep sss

cat /etc/pam.d/system-auth | grep sss

Добавим в конец файла system-auth директиву для создания домашнего каталога пользователя в случае его отсутствия:

nano /etc/pam.d/system-auth

session required        pam_mkhomedir.so umask=0022 skel=/etc/skel

Поправлю главный конфигурационный файл SSSD:

# touch /etc/sssd/sssd.conf

# chmod 0600 /etc/sssd/sssd.conf

# nano /etc/sssd/sssd.conf

[sssd]

domains = test.loc

config_file_version = 2

services = nss, pam

[domain/test.loc]

ad_server = test.loc

ad_domain = test.loc

krb5_realm = TEST.LOC

realmd_tags = manages-system joined-with-adcli

#cache_credentials = True

id_provider = ad

#krb5_store_password_if_offline = True

default_shell = /bin/bash

ldap_id_mapping = True

use_fully_qualified_names = True

fallback_homedir = /home/%u@%d

access_provider = simple

#debug_level=9

[pam]

Настрою автозапуск службы sssd в процессе загрузки ОС и выполним её запуск, который должен выполниться без ошибок:

# chkconfig sssd on

# service sssd start

Проверю возможность получения информации о доменных пользователях:

Пробую снова:

su — d.khlebalin@test.loc

И опять, отлуп ☹

Как-то не задалось ☹

Запускаю службу (или тут правильнее наверно сказать, запускаю демона):

systemctl start sssd

Но не тут-то было:

Посмотрим логи:

cat /var/log/secure

Тут какая-то дичь:

Иду на форума: https://forums.centos.org/viewtopic.php?t=73614

Знающие люди пишут, что ошибка в krb5.conf, смотрю его еще раз:

nano /etc/krb5.conf

Поправляю:

[logging]

default = FILE:/var/log/krb5libs.log

kdc = FILE:/var/log/krb5kdc.log

admin_server = FILE:/var/log/kadmind.log

[libdefaults]

default_realm = TEST.LOC

[realms]

TEST.LOC = {

}

[domain_realm]

.test.loc = TEST.LOC

Снова пробую: systemctl start sssd

Ошибки больше нет.

Запрашиваю свою доменную учетку:

getent passwd d.khlebalin

d.khlebalin@test.loc:*:379201103:379200513:Dmitriy Khlebalin:/home/d.khlebalin@test.loc:/bin/bash

Наконец, свершилось чудо.

Настройка SSHD.

Если говорить про SSH, то никакой специальной настройки sshd здесь не требуется, так как по умолчанию ssh-сервер уже настроен на использование PAM, а тот в свою очередь был ранее настроен нами на использование доменной аутентификации с помощью sss.

В файле /etc/ssh/sshd_config достаточно раскомментировать и включить параметры GSSAPI:

nano /etc/ssh/sshd_config

GSSAPI options GSSAPIAuthentication yes

GSSAPICleanupCredentials yes…

service sshd restart

Попробую авторизоваться под своей доменной учеткой:

Теперь все работает…

А вот прав локального админа на сервере нет…, хотя учетка обладает правами доменного администратора:

Надо это исправить:

groups d.khlebalin

Попробую добавить учетку в группу wheel (но не уверен, что это работает)

gpasswd -a d.khlebalin wheel

Пришло время приступить непосредственно к Samba.

Устанавливаем сам файловый сервер самба.

yum install samba

У меня он уже стоит, поэтому ставить нечего:

Что с конфигом?

Начал «пилить», но на одном из форумов, наткнулся на то, что такой вариант или вовсе не работает, или работает с «костылями». sssd не поддерживает NTLM авторизацию, только kerberos. Самба, судя по логам, упорно пытается авторизовать пользователя по ntlm.

Получается, все, что сделал до этого, все зря… Знающие люди рекомендуют связку winbind+samba.

Придется переделать…Но это дела будущих свершений.

Продолжение следует…

Всем хорошей работы!!!

02.03.2021 —

Posted by |
linux and unix servers

Мне понадобилось настроить авторизацию доменный учетных записей Active Directory по ssh на linux сервер. В моем случае это будет система CentOS 7. Данная возможность будет очень удобна для организаций с внедренной доменной структурой Windows. С помощью групп доступа в AD вы сможете централизованно управлять доступом к linux серверам.

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

Если у вас еще нет готового сервера, то можете воспользоваться моими материалами на эту тему — установка и настройка centos 7. Так же рекомендую настроить iptables для корректной работы сервера с доменом windows. Далее я не буду каcаться этого вопроса, мы просто отключим фаерволл, потому что его настройка не тема этой статьи.

Выключаем firewalld:

# systemctl stop firewalld && systemctl disable firewalld

Настроим синхронизацию времени с контроллером домена. Это важно, у вас должно быть одинаковое время с контроллером домена. Проверьте его и убедитесь, что стоят одинаковые часовые пояса.

Устанавливаем утилиту для синхронизации времени chrony:

# yum install chrony

Добавляем в конфиг /etc/chrony.conf адрес контроллера домена. И делаем его единственным сервером для синхронизации, остальные удаляем.

server xs-winsrv.xs.local iburst

Сохраняем конфиг, запускаем chrony и добавляем в автозагрузку.

# systemctl start chronyd && systemctl enable chronyd

Проверим, что с синхронизацией.

# cat /var/log/messages | grep chronyd

Jul 12 17:58:38 xs-centos7-test chronyd[10620]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)

Jul 12 17:58:38 xs-centos7-test chronyd[10620]: Frequency 0.000 +/- 1000000.000 ppm read from /var/lib/chrony/drift

Jul 12 17:02:54 xs-centos7-test chronyd[10620]: Selected source 10.1.3.4

Jul 12 17:02:54 xs-centos7-test chronyd[10620]: System clock wrong by -3348.457170 seconds, adjustment started

Jul 12 17:02:54 xs-centos7-test chronyd[10620]: System clock was stepped by -3348.457170 seconds

Все в порядке. Синхронизировали время с контроллером домена. По логу видно, что время на сервере убежало вперед на 56 минут, но мы это исправили.

Устанавливаем софт, который нам понадобится, для корректного ввода 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:

# mcedit /etc/sssd/sssd.conf

use_fully_qualified_names = False

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

# authconfig --enablemkhomedir --enablesssdauth --updateall

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

# systemctl enable sssd.service && systemctl restart sssd

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

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

# mcedit /etc/sssd/sssd.conf

access_provider = simple

simple_allow_users = user55@xs.local

simple_allow_groups = gr_linux_adm@xs.local

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

# systemctl restart sssd

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

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

Jul 12 18:10:44 xs-centos7-test sshd[4163]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.1.3.221 user=lin-user

Jul 12 18:10:44 xs-centos7-test sshd[4163]: Accepted password for lin-user from 10.1.3.221 port 51063 ssh2

Jul 12 18:10:45 xs-centos7-test sshd[4163]: pam_unix(sshd:session): session opened for user lin-user by (uid=0)

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

Jul 12 18:08:28 xs-centos7-test sshd[4059]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.1.3.221 user=vzap

Jul 12 18:08:28 xs-centos7-test sshd[4059]: pam_sss(sshd:account): Access denied for user vzap: 6 (Permission denied)

Jul 12 18:08:28 xs-centos7-test sshd[4059]: Failed password for vzap from 10.1.3.221 port 51057 ssh2

Jul 12 18:08:28 xs-centos7-test sshd[4059]: fatal: Access denied for user vzap by PAM account configuration [preauth]

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

Ограничение доступа к sudo по доменным группам

Ограничение доступа к ssh по группам и пользователям настроили, теперь надо разрешить доменным учетным записям получать права суперпользователя в системе. Сейчас у них нет такой возможности.

[sudo] password for lin-user:

lin-user is not in the sudoers file. This incident will be reported.

Создаем новый файл в директории /etc/sudoers.d.

# mcedit /etc/sudoers.d/xs

%gr_linux_adm@xs.local ALL=(ALL) ALL

Выставляем минимальные права на файл:

# chmod 0440 /etc/sudoers.d/xs

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

Реализовать то же самое можно было через настройки sssd. В его конфиге можно было указать группы, которым разрешен доступ к sudo. Но в целом это не принципиально. Так, как сделал я, мне показалось проще. Не нужно использовать полные имена объектов в AD, в которых легко запутаться, особенно тем, кто не очень в этом ориентируется. Мне же понадобились только конечные имена групп. Более подробно об этом можно почитать в руководстве redhat. Ссылку приведу в конце.

Заключение

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

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

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