Centos ввод в домен

Ввод CentOS 7 в домен Active Directory и авторизация по SSH доменных пользователей

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

• 1 Подготовка сервера
• 2 Подключение CentOS 7 к домену
• 3 Ограничение доступа ssh по группам и пользователям домена
• 4 Ограничение доступа к sudo по доменным группам
• 5 Заключение
• 6 Дополнительные материалы по CentOS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверяем авторизацию по ssh, подключившись по любой доменной учетной записи.

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

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

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

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

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

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

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

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

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

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

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

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

Теперь вы можете зайти в систему доменной учетной записью из группы 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. Там есть подробное описание практически всего, с чем приходилось сталкиваться. Надо только не лениться в английском языке разбираться.

Вики IT-KB

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

Инструменты пользователя

Инструменты сайта

Боковая панель

Содержание

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

Процедура присоединения Linux-системы к домену Active Directory с помощью SSSD (System Security Services Daemon) и RealmD (Realm Discovery) подробно рассматривалась ранее на примере Debian GNU/Linux 8.6. Данная статья является «выжимкой» основных этапов присоединения к домену Active Directory для системы на базе CentOS Linux 7.4.

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

На нашей Linux-системе, для успешного присоединения и членства в домене Active Directory, должно быть соблюдено как минимум два условия:

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

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

Проверяем успешность обнаружения домена:

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

Выполняем присоединение к домену (в ходе присоединения будет запрошен пароль доменного пользователя с правами на ввод в домен, указанного в опции –user ):

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

Настраиваем конфигурационный файл, ранее установленного клиента Kerberos. Это может быть нужно в случае если мы захотим использовать удалённое Single sign-on (SSO) подключение через сервер SSHD (например через клиент Putty с Windows-системы, как это было описано ранее)

Пример готовой конфигурации:

Настройка SSSD

Настраиваем конфигурацию службы sssd

Пример готовой конфигурации:

Очищаем кэш sss и перезапускаем службу sssd:

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

Проверяем то, что в системе успешно зарегистрированы модули работы SSSD с PAM/NSS:

Проверяем успешность получения информации о пользователе из AD по логину:

Проверяем успешность получения информации о пользователе из AD по UPN:

Проверяем успешность получения информации из AD о членах доменной группы безопасности:

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

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

Доступ к SUDO

Настроим доступ к возможности вызывать команду sudo, основанный на членстве в доменной группе безопасности: Создадим в каталоге /etc/sudoers.d/ новый файл, в котором будут перчислены группы безопасности:

Наполним файл (каждая отдельная группа с правилами доступа в отдельной строчке. в нашем примере используется одна группа с полным доступом):

Войдём в сесcию доменного пользователя, входящего в группу, которой мы разрешили выполять sudo:

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

Как видим, работает. Осталось ограничить доступ на редактирование файла, в котором описаны правила предоставления доступа к sudo:

Настройка SSHD

Насстроим службу sshd для того, чтобы можно было использовать SSO-подключение.

Включим опции конфигурационного файла:

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

Чтобы ограничить доступ к CentOS Linux 7 на базе доменных групп безопасности, создадим новый конфигурационный файл, в котором будут перечислены группы (как локальные так и доменные), которым нужно обеспечить вход в систему:

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

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

Настроим в системном конфиге /etc/pam.d/login правила PAM таким образом, чтобы в ходе авторизации при локальном входе на консоль нашей Linux-системы использдвался созданный нами выше файл со списком разрешённых групп:

Вставляем перед строкой « account include system-auth » вызов проверки нашего файла с группами:

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

Теперь попробуем подключиться на консоль нашей Linux-системы, используя доменные учётные записи (те, которым разрешен вход через группу безопасности и те, которым не разрешён вход). В процессе проверки в отдельной сессии запустим наблюдение за логом безопасности, чтобы видеть то, что происходит в ходе авторизации для разрешённых и неразрешённых для входа пользователей.

Теперь аналогичным образом настроим в конфиге, относящемся к обработке авторизации в SSHD ( /etc/pam.d/sshd ) правила PAM таким образом, чтобы в ходе авторизации при удалённом входе через SSH-сервер использовался созданный нами выше файл со списком разрешённых групп (в нашем примере используется тот же файл, что и для локального входа, хотя это могут быть разные файлы и группы доступа):

Вставляем перед строкой « account include password-auth » вызов проверки нашего файла с группами:

Внимание! Невнимательное редактирование данного файла может привести в невозможности входа в систему через SSH-сервер, поэтому в ходе дальнейших проверок не закрывайте текущую сесиию, чтобы была возможность исправить возможные ошибки

Теперь попробуем удалённо подключиться к SSH-серверу нашей Linux-системы, используя доменные учётные записи (те, которым разрешен вход через группу безопасности и те, которым не разрешён вход). В процессе проверки в отдельной сессии запустим наблюдение за логом безопасности, чтобы видеть то, что происходит в ходе авторизации для разрешённых и неразрешённых для входа пользователей.

Если дополнительно требуется доменная аутентификация/авторизация в других сервисах CentOS Linux, например в веб-сервере Apache то, в качестве примера можно использовать статью Настройка Kerberos аутентификации с SSO на веб-сервере Apache с помощью SSSD

CentOS: Samba сервер в домене

Всем нам, так или иначе, но приходится подниматься файловые сервера. И даже не важно — какого размера ваша компания или парк компьютеров — файловая шара пригодится всегда, как для обмена информации, или её централизованного хранения, либо как место хранения перемещаемых профилей доменных пользователей Windows (как пример — разберём именно эту ситуацию).

Для работы нам понадобятся 3 ващи: samba, winbind и kerberos, и ntp — устанавливаем:

Первым делом нам нужно синхронизировать время на нашем linux-сервере с контролером домена, для этого мы отредактируем конфигурационный файл ntp:

После чего первый раз синхронизируем время вручную:

и запустим ntpd, добавив его попутно в автозагрузку

Теперь мы переходим к настройке kerberos:

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

Командой klist мы можем проверить выданный нам тикет

Ну а теперь мы можем переходить к самому интересному — настройке samba:

Вы можете создать и отдельную группу в AD для доступа к серверу. Список групп можно посмотреть командой wbinfo -g, а список пользователей — wbinfo -u (для того что бы команды начали работать, необходимо запустить winbind, что мы сделаем немного позже, после его конфигурирования).

Теперь в файле nsswitch.conf нам нужно добавить что для доступа к AD мы будем использовать winbind (вообще winbind – это демон, работающий на клиентах samba и действующий как прокси для связи между PAM и NSS, работающими на компьютере linux, с одной стороны, и AD, работающей на контроллере домена, с другой. В частности, winbind использует kerberos для проверки подлинности с помощью AD и LDAP для получения информации о пользователях и группах).

К моему сожалению, в CentOS 6 пакет samba-common не содержит шаблон конфигурационного файла PAM-модулей, для аутентификации через сервис winbind (system-auth-winbind). По этому нам придётся создать его самостоятельно:

Так же, по непонятной мне причине, параметр session required pam_mkhomedir.so не работает из файла /etc/pam.d/system-auth-winbind, по этому нам придётся дополнительно его описать в файле /etc/pam.d/samba

Теперь мы можем запустить samba и войти в домен:

После чего мы должны получить сообщение о том, что наш сервер теперь является доменной машиной:

Помните, что вы должны вводить сервер в домен под учётной записью администратора домена, либо пользователем, имеющим права на ввод компьютеров в домен. Теперь запустим winbind и проверим — всех ли мы видим:

Если всё видно, значит всё хорошо, нам остаётся лишь настроить фаервол, что бы он не блокировал порт samba (я как всегда напомню о своём любимом псевдоинтерфейсе system-config-firewall-tui) и перезагрузиться. После этого наш сервер готов к работе и всё что нам остаётся — на контролере домена указать месторасположение профиля пользователя. Так же не забудьте в DNS прописать ваш linux сервер.

т.к. в конфигурации samba мы указали path = /profiles/%U, то пользователь, при обращении к \fileserverprofile будет попадать сразу в собственную директорию, что упрощает нам жизнь при создании пользователя (пусть до профиля у всех пользователей будет одинаков), так и то, что другие пользователи, просто физически не видят что там есть данные других пользователей, что в какой то мере сможет остановить многих шалунов

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

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Админствующий FM

пятница, 29 июля 2011 г.

добавление RHEL (CentOS) 5 сервера в домен Active Directory

Вдосталь наэксперементировавшись с openLDAP и 389 Directory Server, всё-таки решил остановиться на Active Directory от Microsoft для централизованного управления моим зоопарком из Windows и RHEL серверов. Если ввод в домен рабочей станции или сервера Windows довольно тривиальная задача, то присоединение к домену Linux системы оказалось не на много сложнее 🙂 Прогресс не стоит на месте, Red Hat приложила (да и Microsoft тоже) немело усилий для безпроблемного сосуществования и взаимодействия различных операционных систем.

В качестве примера возьмем сервер с RHEL 5.6 на борту с именем server01 и заведем его в Active Directory домен ACME.LOCAL

Для начала проверяем что в имени машины присутствует имя домена
[root@server01

] vim /etc/sysconfig/network
HOSTNAME=server01.acme.local
если нет — правим файл и, затем, выполняем команду
[root@server01

Указываем короткое и полное имя этого сервера
[root@server01

] vim /etc/hosts
127.0.0.1 server01 server01.acme.local localhost localhost.localdomain

Важный момент: прописываем IP нашего контроллера домена как DNS сервер
[root@server01

] vim /etc/resolv.conf
nameserver 192.168.1.1

Далее необходимо синхронизаровать системное время между сервером и контроллером домена.
Правим конфигурационный файл службы точного времени:
[root@server01

] vim /etc/ntp.conf
добавляя строку:
server dc.acme.local

] chkconfig ntpd on
и запускаем ее:
[root@server01

] service ntpd start

Ставим клиент Samba 3.3
[root@server01

] yum install samba3x samba3x-common samba3x-client
Можно использовать Samba 3.0 который идет в поставке RHEL версии 5.4 и ранее, но для домена на основе Windows Server 2008 R2 рекомендуется использовать samba-3.3. В моем случае это позволило побороть сообщения в журнале /var/log/messages
Jul 11 11:05:01 server01 winbindd[26769]: [2011/07/11 11:05:01, 0] rpc_client/cli_pipe.c:rpc_api_pipe(790)
Jul 11 11:05:01 bird winbindd[26769]: rpc_api_pipe: Remote machine DC.acme.local pipe NETLOGON fnum 0xc00creturned critical error. Error was NT_STATUS
_PIPE_DISCONNECTED А теперь самая магия. Запускаем нижеследующую команду одной строкой либо с обратными слешами:

] authconfig —update —kickstart
—enablewinbind
—enablewinbindauth
—smbsecurity=ads
—smbworkgroup=ACME
—smbrealm=ACME.LOCAL
—smbservers=DC.ACME.LOCAL
—smbidmapuid=10000-20000
—smbidmapgid=10000-20000
—winbindtemplatehomedir=/home/%U
—enablemkhomedir
—winbindtemplateshell=/bin/bash
—enablewinbindusedefaultdomain
—enablelocauthorize
—enablekrb5
—krb5realm ACME.LOCAL
—krb5kdc DC.ACME.LOCAL
—krb5adminserver DC.ACME.LOCAL
Эта команда вносит все необходимые изменения в конфигурационные файлы системы:
* настраивает клиент Kerberos /etc/krb5.conf
* добавляет службу winbind в /etc/nsswitch.conf для passwd, shadow и group
* изменяет должным образом /etc/samba/smb.conf на работу в домене
* стартует службу winbind позволяет которая обмениваться информацией с NT системами

Переходим к инициализации клиента Kerberos (пакет krb5-client обычно уже установлен)
сбрасываем кэш сессий
[root@server01

] kdestroy
Создаем новый кеш, указывая имя доменного администратора и вводим его пароль по запросу
[root@server01

] kinit administrator
Если всё прошло без ошибок, то закешированый Kerberos-тикет можно просмотреть командой
[root@server01

] klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@ACME.LOCAL

Valid starting Expires Service principal
07/18/11 19:27:18 07/19/11 05:27:48 krbtgt/ACME.LOCAL@ACME.LOCAL
renew until 07/19/11 19:27:18

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached Вот теперь настал момент добавления нашего сервера в домен:
[root@server01

] net ads join -U administrator
Должно появится поле ввода пароля для администратора домена administrator@ACME.LOCAL
После ввода которого и при корректной настройке система сообщит об успешном завершении операции
Using short domain name — ACME
Joined ‘SERVER01’ to realm ‘acme.local’ и стартуем winbind

] service winbind restart

Если что-то не получается, для начала надо проверять подключение к DNS и логи winbind.

На этом настройка завершена. В Active Directory появилась учетная запись server01 в «Domain Computers», можно подлключаться по SSH, используя учетные записи пользователей домена.

login as: jsmith
jsmith@192.168.1.2’s password:

Ubuntu

Ввод компьютера Ubuntu в домен Active Directory Windows

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

Обновиться

Установить

Настройка DNS

Изменить настройки DNS на вашей машине, прописав в качестве DNS сервера контроллер домен и в качестве домена поиска — контроллер домен. В Ubuntu Desktop это можно сделать через Network Manager, в Ubuntu Server необходимо изменить содержимое файла /etc/resolv.conf

Вместо «mydomain.com» — Ваш домен. Вместо IP-адресов — IP-адреса Ваших контроллеров домена.

Задать нужное имя компьютера в файле /etc/hostname

Отредактировать файл /etc/hosts так, чтобы в нём была запись с полным доменным именем компьютера и обязательно коротким именем хоста, ссылающаяся на один из внутренних IP

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

Настройка синхронизации времени

Исправить файл /etc/ntp.conf, добавив в него информацию о вашем сервере времени:

После чего перезапустить демон ntpd:

Настройка авторизации через Kerberos

Изменить файл /etc/krb5.conf указав название своего домена вместо DOMAIN.COM и своего контроллера домена

Обратить внимание на регистр написания имени домена. Везде, где домен был написан в верхнем регистре, его обязательно нужно писать именно в верхнем регистре.

Проверить, что мы можем авторизоваться в домене. Для этого выполнить команду

Вместо username вписать имя существующего пользователя домена. Имя домена необходимо писать заглавными буквами! Если не получили никаких ошибок — значит вы настроили всё верно и домен отдаёт вам билет Kerberos. Убедиться в том, что билет получен, можно выполнив команду

Удалить все билеты

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

Необходимо прописать правильные настройки в файле /etc/samba/smb.conf

После того, как будет отредактирован smb.conf, выполнить команду testparm.

Ввести компьютер в домен

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

Если всё прошло без ошибок, то успешно вошли в домен! Посмотреть в AD и увидеть добавленный компьютер ubuntu01. Чтобы видеть ресурсы в домене, установите smbclient:

Теперь можно просматривать ресурсы компьютеров домена. Для этого нужно иметь билет kerberos — получаем через kinit. Посмотрим какие ресурсы предоставлены в сеть компьютером workstation:

Настройка Winbind

Добавить в файл /etc/samba/smb.conf в секцию [global] следующие строки:

Перезапустить демон Winbind и Samba в следующем порядке:

Если появится «rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)»

То отредактировать файл /etc/security/limits.conf

Перегрузиться. Запустить testparm — Не должно быть ошибок. Проверить, что Winbind установил доверительные отношения с AD командой:

Убедиться, что Winbind увидел пользователей и группы из AD командами:

Добавление Winbind в качестве источника пользователей и групп

Измените в файле /etc/nsswitch.conf две строчки, добавив в конце winbind:

Привести строку files в файле /etc/nsswitch.conf к виду:

Проверить, что Ubuntu запрашивает у Winbind информацию о пользователях и группах, выполнив:

Авторизация в Ubuntu через пользователей домена

Создадим в каталоге домашних папок пользователей подкаталог для доменных пользователей в соответствии с настройками нашего smb.conf (в качестве имени каталога используем NetBIOS-имя домена):

Проверить, что после установки библиотеки libpam-winbind соответствующие PAM-модули для Winbind активирован.

В появившемся окне должна быть включена (отмечена *) опция «Winbind NT/Active Directory authentication»

Добавьте строку в конец файла /etc/pam.d/common-session

Для появиления поля ручного ввода логина необходимо добавить в файл /etc/lightdm/lightdm.conf/ строку greeter-show-manual-login=true

Для скрытия списка пользователей необходимо добавить в файл /etc/lightdm/lightdm.conf/ строку greeter-hide-users=true

Для разрешения входа пользователей AD группы groupdomain можно исправить файл /etc/pam.d/common-auth добавив параметр require_membership_of к вызову pam_winbind.so

Если указанная группа не работает, можно указать SID группы