Меню Рубрики

Установка active directory на centos

Vladimir Drach. Official Web-Site. — Личный сайт Владимира Драча

Самба 4: Установка контроллера домена на CentOS 7

Понедельник, 10 Апрель 2017 20:56

Начиная с версии 4.0, Самба может работать как контроллер домена (ДК) Active Directory (AD). В этой статье показано, как настроить Samba 4 в качестве контроллера домена с Windows 10 в CentOS 7 и CentOS 6.

Понадобится 3 операционные системы, первая сервер CentOS 7, вторая Windows 10 клиент для удаленного управления, и CentOS 7 (CentOS 6).

Статья является более углублённым материалом по сравнению с опубликованной ранее методикой.

192.168.1.190 Samba4 AD centos7 Пульт дистанционного управления 192.168.1.191 win 10 192.168.1.22 — клиент Аутентификация — CentOS 7 192.168.1.192 — Аутентификация клиента Samba 4 на CentOS 6

192.168.1.190 Samba4 AD centos7

Основой является система CentOS 7 с минимальной установкой и отключенным selinux.

Сделайте запись в /etc/hosts-файле.

Установите все пакеты, необходимые для компиляции базы Samba 4.

Теперь скачайте пакет Samba 4 . Я использую samba-4.6.0, которая является последней версией на момент загрузки.

Теперь установите Samba 4.

Установка займет около 10 минут в зависимости от скорости системы.

Теперь мы начнем подготавливать домен.

Во время подготовки домена могут возникнуть ошибки.

Чтобы исправить их, пожалуйста, закомментируйте строку ниже ,в файле /etc/krb5.conf.

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

Убедитесь, что порты в брандмауэре открыты.

Создайте сценарий автозапуска службы во время перезагрузки.

Добавление узла Windows к домену

Пульт дистанционного управления 192.168.1.191 win 10

Убедитесь, что хост добавлен статическим IP-адресом..

Добавление хоста к домену.

Для управления samba4 с помощью Windows, мы должны иметь установленные инструменты Microsoft Remote Server (RSAT)..

Установка инструментов RSAT в Windows 10

После перезагрузки перейдите к введению dsa.msc

Выберите домен my.domain и щелкните правой кнопкой мыши новый -> Пользователи.

Создание тестового пользователя.

Аутентификация клиента Samba 4 на CentOS 7

192.168.1.22 — клиент Аутентификация — CentOS 7

Проверьте соединение с Samba 4:

Проверьте, способны ли мы получить пользователя от samba4..

Получите пользователя без имени домена.

Аутентификация клиента с Samba 4 на CentOS 6

192.168.1.192 — Аутентификация клиента Samba 4 на CentOS 6.

Измените файл конфигурации Kerberos..

Мы будем использовать adcli команду, для того,чтобы присоединиться к домену..

Убедитесь, что билет kerberos создан.

Изменение конфигурации SSSD , проверка подлинности..

источник

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

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

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

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

Информационная таблица

xs.local название домена
10.1.3.4 ip адрес контроллера домена
xs-winsrv.xs.local полное имя контроллера домена
xs-centos7-test имя сервера centos, который вводим в домен
administrator учетная запись администратора домена
gr_linux_adm группа в AD, для которой разрешено подключение к серверам по ssh
lin-user учетная запись в AD для проверки подключений по ssh

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

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

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

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

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

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

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

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

Если не получили никакой ошибки, значит все прошло нормально. Можно зайти на контроллер домена и проверить, появился ли наш 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 серверами. При написании статьи использовал официальные руководства:

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

Онлайн курс по Linux

Помогла статья? Есть возможность отблагодарить автора

Автор Zerox

45 комментариев

Мне помогла когда загонял в другой домен и сломалась база.
systemctl stop sssd
# rm -f /var/lib/sss/db/*
# rm -f /var/lib/sss/mc/*
# systemctl start sssd

Добрый день. Добавил в домен веб-сервер.
Его учетка, httpd, пытается аутентифицироваться в домене, в домене нет такой учетки.
Как можно запретить доменную аутентификацию для учетной записи веб-сервера?

Я не помню точно подробностей, но есть настройка на тему того, где проверять учетные записи. Сначала там должны быть указаны локальные учетки, потом все остальные. Кажется в /etc/nsswitch.conf.

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

Почему тут используется не полное название домена, а просто xs?

Не помню уже, но у меня работало с такими настройками.

Имя файла значения не имеет. Это просто файл. Как я понял, демон просто просматривает все файлы в директории, и считывает их. А имена — по боку.

С чем может быть связана эта ошибка сразу после realm join ?

]# journalctl REALMD_OPERATION=r2487182.19481
— Logs begin at Tue 2018-11-13 15:15:08 MSK, end at Wed 2018-12-12 10:08:07 MSK. —
Dec 12 10:08:03 dev.domain.ru realmd[19484]: * Resolving: _ldap._tcp.domain.ru
Dec 12 10:08:03 dev.domain.ru realmd[19484]: * Performing LDAP DSE lookup on: 10.193.21.11
Dec 12 10:08:03 dev.domain.ru realmd[19484]: * Performing LDAP DSE lookup on: 10.7.21.11
Dec 12 10:08:03 dev.domain.ru realmd[19484]: * Performing LDAP DSE lookup on: 10.7.21.13
Dec 12 10:08:03 dev.domain.ru realmd[19484]: * Successfully discovered: domain.ru
Dec 12 10:08:07 dev.domain.ru realmd[19484]: * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net
Dec 12 10:08:07 dev.domain.ru realmd[19484]: * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.U5L0TZ -U user.user ads join domain.ru
Dec 12 10:08:07 dev.domain.ru realmd[19484]: Enter user.user’s password:
Dec 12 10:08:07 dev.domain.ru realmd[19484]: Failed to join domain: failed to join domain ‘domain.ru’ over rpc: Insufficient quota exists to complete the operation.
Dec 12 10:08:07 dev.domain.ru realmd[19484]: ! Joining the domain domain.ru failed

Помогло добавление вручную этого компьютера в AD.
После этого realm join сработал.

Сорри, а где описана установка параметра hostname на сервере?
Не совсем понятно, в каком виде должен быть хостнейм на момент, когда сервер требуется ввести в домен
Он должен быть вида «name» или «name.domain» ?

name
Вы не можете включить в домен хост, который уже принадлежит домену.

Нашел единственную статью на эту тему (http://www.pivpav.com/post/166), но там все довольно скомкано, человек рассказывает явно для более опытных пользователей CentOS 7. У Вас же все расписанно более подробно, для новичков. Может быть удасться получить более развернутую инструкцию от Вас, если идея понравится.

Прочитал. В целом, в статье ничего сложного нет. Если удалось настроить по этой статье, то и по той тоже получится. По сути надо только сделать скрипт на ruby, проверить его работоспособность и добавить его в конфиг sshd, как указано у автора. Схема, судя по всему, рабочая получается, но реально костыльная. Я не знаю, насколько это все оправданно. Лично я не считаю авторизацию по сертификатам удобнее и безопаснее хороших паролей. Реально безопасно, это когда сертификат и пароль. А когда что-то одно из этого, то разницы принципиальной не вижу. Вопрос удобства. Лично я предпочитаю пароли.

К сожалению, я не смог найти второй пакет для установки, ruby-ldap , ruby и ruby-net-ldap ставятся, второй же не находится, пробовал добавлять репозитории, все по Вашим статьям, спасибо огромное, но этот пакет почему то не находит для установки. А скрипт у меня не работает, причина может быть в том, что не доставились нужные компоненты.

Да, тут уже разбираться надо более детально. Скорее всего пакет стал называться немного по-другому, или под текущую версию ruby его нет.

Подскажите, а как бы Вы реализовали подобную задачу? Соотнося с Вашей статьей по вводу CentoS 7 в AD?
Я пытался использовать его скрипт на Ваше подключение, но не работает, ключ не возвращается при запросе, видимо дело в разных переменных которые указаны в sssd.config у него и при добавление по Вашей инструкции… адаптировать же его скрипт у меня так и не получилось =( Вести пк в домен по его инструкции так же не вышло, куда не кинь, везде клин =(

Читайте также:  Установка авточехлов на митсубиси асх

Я бы так делать в принципе не стал. Пересекать linux и windows без крайней необходимости не стоит. Мне хватает того, что файловые сервера с samba периодически после обновления выпадают из домена или появляются проблемы с доступом и правами. Это все очень усложняет сопровождение.

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

Добрый день!
Эксперемент завершился удачно, удалось настроить авторизацию по ssh ключам модернизировав скрип из той статьи.
Правда я чуть красивее сделал, добавил новый атрибут пользователям в AD назвал его sshPublicKeys, что б не городить огород с вкаладкой notes и прочее.
К сожалению, не от меня зависело, была задача, надо сделать, пришлось крутиться =)
Спасибо Вам большое! =)
P:S прошу прощения, случайно отправил в общую ленту еще… так получилось, если мешается, удалите, пожалуйста.

Можете свой скрипт привести? Это может быть полезно остальным.

Да, конечно. Хотя он не сильно отличается, вместо атрибута info указан атрибут sshPublicKeys и в config убрана папка, скрипт ищет по всему AD

require ‘rubygems’
require ‘net/ldap’

config = <
:host => «domain.com»,
:port => 389,
:username => «administrator@domain.com»,
:password => «password administrator»,
:base => «DC=domain,DC=com»,
>

ldap = Net::LDAP.new :host => config[:host],
:port => config[:port],
:auth => <
:method => :simple,
:username => config[:username],
:password => config[:password],
>

filter = Net::LDAP::Filter.eq «sAMAccountName», username
attributes = [«sshPublicKeys»]

ldap.search(:base => config[:base], :filter => filter, :attributes => attributes ) do |entry|
puts entry[:sshPublicKeys].first
end

И ф файле /etc/ssd/sshd_config раскоментим строки
AuthorizedKeysCommand /usr/bin/you_script
AuthorizedKeysCommandUser nobody

На контроллере домена, пользователям нужно добавить артибут sshPublicKeys и внести туда открытую часть ключа, ну или если не хочется мучиться с добавлением, можно указать ключ в поле Notes вкладки Telefones и в скрипте указать вместо sshPublicKeys атрибут info

А есть возможность еще расширить функционал? Хранить в домене ключи ssh и сделать авторизацию по ним?

Подскажите как перезавести ПК на Linux в домен еще раз, в том случае если удалил его из UA в домене?

Просто ввести его еще раз, точно так же, как и первый раз. На самой системе ничего делать не надо.

]# realm discover domain
realm: Couldn’t connect to realm service: Error calling StartServiceByName for org.freedesktop.realmd: Timeout was reached

realm discover XXX-XXXXXX.RU
realm: Couldn’t connect to realm service: Ошибка вызова StartServiceByName для org.freedesktop.realmd: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.realmd timed out

Что может послужить проблемой?

Мне помогло перезагрузить систему, ну так на сайте RedHad написали …

И снова здравствуйте, нужен совет, после внедрения ПК в домен возникла потребность выполнения скрипта, который при авторизации доменного пользователя в его директорию /home/(domain)/(user)/mounfolder монтировал определенную шару допустим \\NFS\(SomeGroup_folder). Просто для Виндовых юзеров есть NETLOGON\disk.bat в котором указано кому и какую шару подключать, а вот в Linux мне не особо понятно как это сделать. На просторах ближе всего подходит метод с библиотекой libpam-moun, но вопрос решит ли она мне эту проблему?

Точно не знаю. В винде это решается на уровне групповых политик домена windows. Соответственно, тут тоже должен быть какой-то инструмент, аналог этих политик, для выполнения каких-то действий при логине. Но если речь конкретно про подключение диска, которое можно описать простым sh скриптом, то можно попробовать реализовать запуск скрипта при логоне с помощью .bash_login или .bashrc, если используется оболочка bash. Если другая, то уже ее средствами.

вопрос решился прям сам по себе, так сказать сам задал вопрос и в нем было решение, помогла библиотека libpam-mount, в настройка pam_mount.conf.xml указал каким группам что подключать и все заработало, теперь в зависимости от того кто вошел в систему монтируются нужные ему ресурсы. Так я это дело вписал в скрипт, который вводит комп в домен — ставит нужные либы, спрашивает имя и айпи домена, настраивает скрим монтирования шар. теперь ввод *.nix ПК в домен занимает три минуты)))

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

Сборная солянка с головы и интернета, есть скрипт вот его текст, там я думаю разберешя

Удали тот пост выше, там криво вставилось вот
https://drive.google.com/open? >

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

Вводим centos в домен с юзером admin-of-ad в домен example.com:

realm join -U admin-of-ad example.com
Правим /etc/samba/smb.conf

[global]
workgroup = example
security = ads
kerberos method = system keytab
realm = example.com

[share]
comment = My shared folder
path = /data/share
public = yes
writeable = yes
browseable = yes
guest ok = yes
val > directory mask = 0775
create mask = 0664
vfs objects = acl_xattr
inherit permissions = yes
inherit acls = yes
map acl inherit = yes
store dos attributes = yes

Если шарится папка на ext*, то в параметры монтирования /etc/fstab надо дописать атрибуты acl и user_xattr. Должно хватить и acl, но мы же нанотехнологичные чуваки. Для XFS ничё не надо, всё «искоробки»:

Читайте также:  Установка гусениц на мотоблок

UU > Разрешаем полный доступ на уровне ugo. Локально всё равно только по ssh можно цепляться (ну только если у вас не проходной двор), а демон самбы сам разрулит кому можно, а кто идёт пасти бобров.

chmod 777 /data/share
Конкретно в CentOS самба после установки сама не запускается. И ей даже не разрешено это делать. Так что разрешаем запускаться:

systemctl enable smb.service
Разрешаем firewalld пускать самбу в сеть:

firewall-cmd —permanent —zone=public —add-service=samba
Применить правила без разрыва соединений:

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

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

Да, да, именно такие проблемы у меня иногда бывают. Я не понимаю, из-за чего это происходит, но права в итоге слетают. Я много разбирался с этой ситуацией. У меня уже готов черновик статьи, где я настраиваю самбу в домене. Пытался настроить все через sssd, вместо winbind, но ничего не получилось. Пришлось вернуться к winbind. Буквально на днях будет статья, она уже фактически готова, но только проблемы, которые возникают, победить не получилось. Я не могу их сам спровоцировать, чтобы понять, в какой момент и из-за чего они слетают.

Есть мнение что это все из за тог что в настройках самбы есть параметр (winbind offline logon = yes) который препятствует срабатыванию обновления (getent passwd), так как параметр (winbind cache time = 300) игнорируется, но тут вопрос — ради эксперимента в домене добавил юзера «тест», по команде wbinfo -u он появился , но вот getent paswd не отработал. Получается что pam.d не передал данные, короче непонятно голова вспухла уже))))).

Только что снова вылетел баг, групы на шаре обновились и U >

Подскажите вы можете, дописать статью как создать папки smb с авторизации по AD?
Заранее благодарен.

Давно собираюсь, но все времени не хватает. Там уже winbind надо будет настраивать а не sssd.

Ввожу команду:
# realm discover LOCAL.DOMAIN.RU
local.domain.ru
type: kerberos
realm-name: LOCAL.DOMAIN.RU
domain-name: local.domain.ru
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 LOCAL.DOMAIN.RU
See: journalctl REALMD_OPERATION=r5497964.10339
realm: Couldn’t join realm: Joining the domain local.domain.ru failed

Пробую с логами (-v):
# realm join -v -U administrator LOCAL.DOMAIN.RU
* Resolving: _ldap._tcp.local.domain.ru
* Performing LDAP DSE lookup on: 192.168.102.8
* Successfully discovered: local.domain.ru
Password for administrator:
* Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net
* LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.KAEP3Y -U administrator ads join local.domain.ru
Enter administrator’s password:
Failed to join domain: failed to lookup DC info for domain ‘local.domain.ru’ over rpc: The specified I/O operation on %hs was not completed before the time-out period expired.
! Joining the domain local.domain.ru failed
realm: Couldn’t join realm: Joining the domain local.domain.ru failed

Проверял resolve:
[root@siteadmin

]# getent hosts local.domain.ru | awk ‘< print $1 >’
192.168.106.5
192.168.101.4

Ping к слову не идёт, но в компании говорят, что отключили возможность пингования со стороны сервера (но меня всё равно это смущает).

Мой вопрос:
— Команда «realm discover LOCAL.DOMAIN.RU» не говорит ли о том что доступ есть?
— Если команда «realm discover» видит сервер, то почему появляется ошибка «failed to lookup DC»?

«Аутентификация — происходит от английского слова authentication, которое можно перевести как идентификация или проверка подлинности. Это полностью отражает суть процесса — проверка подлинности пользователя, т.е. мы должны удостовериться, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.

Авторизация — перевод слова authorization означает разрешение, т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права.»

Как запомнить? Легко. Аутентификация — КТО ТЫ, авторизация — МОЖНО ЛИ.

Доброе.
Firewalld отключили, а про SELinux — ни слова. Или он в этом случае «не мешает» ?

Специально не проверял. Статья писалась с отключенным selinux. Я в начале статьи привел ссылку на настройку centos, там я отключаю selinux. Вообще, у меня во всех статьях он отключен. Вопрос настройки selinux я нигде не рассматриваю.

Если задача только в авторизации по ssh, то samba, группы в AD — лишнее. Достаточно модуля pam_krb5. Проще и надёжнее.

Да тут вроде тоже ничего сложного. Все очень быстро и просто делается. Это с winbind ковыряться долго, а sssd достаточно просто заводит в домен и все системные конфиги сам правит.

источник

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