Мне понадобилось настроить авторизацию доменный учетных записей Active Directory по ssh на linux сервер. В моем случае это будет система CentOS 7. Данная возможность будет очень удобна для организаций с внедренной доменной структурой Windows. С помощью групп доступа в AD вы сможете централизованно управлять доступом к linux серверам.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Содержание:
Подготовка сервера
Если у вас еще нет готового сервера, то можете воспользоваться моими материалами на эту тему - установка и настройка 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 |
Выключаем 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 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.
Ограничение доступа 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. Там есть подробное описание практически всего, с чем приходилось сталкиваться. Надо только не лениться в английском языке разбираться.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
а с помощью этого способа заработает доменная авторизация для сервера 1с установленного на этом же centos?
Скорее всего нет. С 1С решать вопрос нужно будет отдельно. Я не знаю как, не занимался никогда.
К разделу "Ограничение доступа ssh по группам и пользователям домена".
Не получилось настроить так, как описывает автор. Однако, почитав
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/sssd-configure-additional-provider-options
оставил
access_provider = ad
а ограничил доступ группами ADDS, используя фильтр
ad_access_filter = (|(memberOf=cn=sudoers,ou=IT DEP,dc=example,dc=com)(memberOf=cn=sshers,ou=IT DEP,dc=example,dc=com))
где sudoers и sshers - имена групп, "IT DEP" - контейнер, в котором эти группы размещены. В общем, это полные distinguishedName этих групп, перечисленные через "или" - символ "|" сразу за первой скобкой.
Мне помогла когда загонял в другой домен и сломалась база.
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 ?
[root@localhost ~]# 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
#!/usr/bin/ruby
require 'rubygems'
require 'net/ldap'
exit 0 if ARGV == []
username = ARGV[0]
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 в домене?
Просто ввести его еще раз, точно так же, как и первый раз. На самой системе ничего делать не надо.
[root@localhost ~]# 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?id=0BzrWXN0Dsp4qUWxTY1UtdGFESVE
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
valid users = @"depit@example.com"
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 ничё не надо, всё «искоробки»:
UUID=dabdd229-52dc-49d6-add2-a10f9f582bf5 / ext4 defaults,acl,user_xattr 0 0
Разрешаем полный доступ на уровне ugo. Локально всё равно только по ssh можно цепляться (ну только если у вас не проходной двор), а демон самбы сам разрулит кому можно, а кто идёт пасти бобров.
chmod 777 /data/share
Конкретно в CentOS самба после установки сама не запускается. И ей даже не разрешено это делать. Так что разрешаем запускаться:
systemctl enable smb.service
Разрешаем firewalld пускать самбу в сеть:
firewall-cmd --permanent --zone=public --add-service=samba
Применить правила без разрыва соединений:
firewall-cmd --reload
Через виндовые параметры безопасности права нормально выставляются? С этим часто бывают проблемы. Вообще, я много заводил файловых серверов под линуксом в виндовый домен. Мне не нравится, как это работает. Не очень стабильно, бывают глюки, иногда права через консоль приходится выставлять. Иногда были ситуации, когда права полностью или частично слетали. Я бы не рекомендовал такое решение, если есть возможность поставить файловый сервер под виндой.
Да соглашусь, недавно ввел в линукс файлсерве в домен, в определенный момент UID GID перемешались, а в некоторых случаях вообще слетели у определенных пользователях, но поднимать виндовый серв, который жрет в два раза больше оперативи на виртуалке не охота.
Да, да, именно такие проблемы у меня иногда бывают. Я не понимаю, из-за чего это происходит, но права в итоге слетают. Я много разбирался с этой ситуацией. У меня уже готов черновик статьи, где я настраиваю самбу в домене. Пытался настроить все через sssd, вместо winbind, но ничего не получилось. Пришлось вернуться к winbind. Буквально на днях будет статья, она уже фактически готова, но только проблемы, которые возникают, победить не получилось. Я не могу их сам спровоцировать, чтобы понять, в какой момент и из-за чего они слетают.
Есть мнение что это все из за тог что в настройках самбы есть параметр (winbind offline logon = yes) который препятствует срабатыванию обновления (getent passwd), так как параметр (winbind cache time = 300) игнорируется, но тут вопрос - ради эксперимента в домене добавил юзера "тест", по команде wbinfo -u он появился , но вот getent paswd не отработал. Получается что pam.d не передал данные, короче непонятно голова вспухла уже))))).
Только что снова вылетел баг, групы на шаре обновились и UID GID тупо напрочь обновились - стали другими, в следствии на шарах права стали в виде gid=10011, а не название группы, может в крон положить скрипт который будет обновлять раз в час или в сутки типа chown -R root:"domain admins" /srv/work, та и забить про эту проблему?
Добрый день!
Подскажите вы можете, дописать статью как создать папки 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: {Device Timeout} 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"?
И правильнее будет - доменная АУТЕНТИФИКАЦИЯ.
https://interface31.ru/tech_it/2015/03/autentifikaciya-v-sistemah-windows-chast-1-ntlm.html
"Аутентификация - происходит от английского слова authentication, которое можно перевести как идентификация или проверка подлинности. Это полностью отражает суть процесса - проверка подлинности пользователя, т.е. мы должны удостовериться, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.
Авторизация - перевод слова authorization означает разрешение, т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права."
Как запомнить? Легко. Аутентификация - КТО ТЫ, авторизация - МОЖНО ЛИ.
Доброе.
Firewalld отключили, а про SELinux - ни слова. Или он в этом случае "не мешает" ?
Специально не проверял. Статья писалась с отключенным selinux. Я в начале статьи привел ссылку на настройку centos, там я отключаю selinux. Вообще, у меня во всех статьях он отключен. Вопрос настройки selinux я нигде не рассматриваю.
Если задача только в авторизации по ssh, то samba, группы в AD - лишнее. Достаточно модуля pam_krb5. Проще и надёжнее.
Да тут вроде тоже ничего сложного. Все очень быстро и просто делается. Это с winbind ковыряться долго, а sssd достаточно просто заводит в домен и все системные конфиги сам правит.