Ssh на centos 7 через active directory

Ввод 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

Выключаем firewalld:

# systemctl stop firewalld && systemctl disable firewalld

Перед дальнейшей настройкой, убедитесь, что с вашего сервера centos вы без проблем пингуете и резолвите контроллер домена по полному имени. Если есть какие-то проблемы, исправьте это либо указанием нужного dns сервера, либо правкой файла hosts.

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

Устанавливаем утилиту для синхронизации времени 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.confuse_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.confaccess_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

Обращаю внимание, что имя данного файла не должно содержать точки. Я сначала не знал об этом и сделал файл с именем xs.local и долго не мог понять, почему не работает. Когда изменил имя файла, все заработало.

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

# chmod 0440 /etc/sudoers.d/xs

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

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

Не нужно использовать полные имена объектов в AD, в которых легко запутаться, особенно тем, кто не очень в этом ориентируется. Мне же понадобились только конечные имена групп.

Более подробно об этом можно почитать в руководстве redhat. Ссылку приведу в конце.

Заключение

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

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

Источник: https://serveradmin.ru/vvod-centos-7-v-domen-active-directory-i-avtorizatsiya-po-ssh-domennyih-polzovateley/

Авторизация по SSH в Centos 7 для группы доменных пользователей,

Авторизация по SSH в Centos 7

Необходимо настроить авторизацию по SSH в CentOS 7 определенной группы пользователей контроллера домена, а так же дать права sudo для этой группы пользователей

Исходные данные

domain.local — название контроллера домена
192.168.1.12 — его ip адрес
srv-dc-01.domain.local — название сервера контроллера домена
srv-routing-02 — название linux машины, которую вводим в домен
admin — администратор домена
linux_adm — группа пользователей домена, которым разрешено подключение по ssh

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

Меняем hostname

[root@localhost ~]# hostnamectl set-hostname srv-routing-02

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

[root@localhost ~]# yum install chrony

Настраиваем chrony. Оставляем только наш контроллер домена

[root@localhost ~]# nano /etc/chrony.conf
server srv-dc-01.domain.local iburst

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

[root@localhost ~]# systemctl start chronyd [root@localhost ~]# systemctl enable chronyd

Проверяем

[root@localhost ~]# cat /var/log/messages | grep chronyd
Oct 15 16:47:06 [localhost] chronyd[29373]: chronyd exiting
Oct 15 16:48:01 [localhost] chronyd[774]: chronyd version 3.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND +ASYNCDNS +IPV6 +DEBUG)
Oct 15 16:48:01 [localhost] chronyd[774]: Frequency 0.000 +/- 1000000.000 ppm read from /var/lib/chrony/drift
Oct 15 16:48:02 [localhost] chronyd[774]: Source 192.168.1.2 offline
Oct 15 16:48:02 [localhost] chronyd[774]: Source 192.168.1.2 online

Добавляем адреса основного и резервного контроллера домена в /etc/hosts

[root@localhost ~]# cat /etc/hosts
192.168.1.2 srv-dc-01.domain.local
192.168.1.3 srv-dc-02.domain.local

Правим файл resolv.conf, добавляем директиву search

[root@localhost ~]# cat /etc/resolv.conf
# Generated by NetworkManager
search domain.local
nameserver 192.168.1.3
nameserver 192.168.1.2

Подключаем CentOS 7 к контроллеру домена

Устанавливаем необходимый софт

[root@localhost ~]# yum install realmd sssd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients policycoreutils-python

Водим сервер с CentOS 7 в домен

[root@localhost ~]# realm discover DOMAIN.LOCAL
domain.local type: kerberos realm-name: DOMAIN.LOCAL domain-name: domain.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[root@localhost ~]# realm join —user=admin domain.local
Password for admin:

Проверяем наш контроллер домена. В списке компьютеров должен появиться наш linux сервер

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

Что бы при подключении к серверу не надо было вводить польное имя домена (%username%@domain.local), а только %username%, меняем конфиг утилиты sssd.
Так же меняем название создаваемой директории пользователя

[root@localhost ~]# nano /etc/sssd/sssd.conf
use_fully_qualified_names = False
fallback_homedir = /home/%u

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

[root@localhost ~]# authconfig —enablemkhomedir —enablesssdauth —updateall

Добавляем утилиту sssd в автозагрузку и перезапускаем её

[root@localhost ~]# systemctl enable sssd.service
[root@localhost ~]# systemctl restart sssd

Чтобы проверить в каких группах пользователь

[root@localhost ~]# id %username%

Чтобы заново считать данные о пользователе с контроллера домена ( почистить весь кэш), например после добавления пользователя в др. группу. 

[root@localhost ~]# sss_cache -E

Или только для определенного пользователя

[root@localhost ~]# sss_cache -u user1

Разрешаем подключение только для группы linux_adm на контроллере домена (создали её заранее), и для пользователя user

[root@localhost ~]# nano /etc/sssd/sssd.conf
access_provider = simple
simple_allow_users = user@domain.local
simple_allow_groups = linux_adm@domain.local

Перезапускаем службу sssd

[root@localhost ~]# systemctl restart sssd

Для проверки ограничения доступа для пользователей контроллера домена мониторим лог-файл /var/log/secure

Доступ закрыт:

Oct 16 09:47:51 [localhost] sshd[6687]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=user.domain.local user=Test1
Oct 16 09:47:51 [localhost] sshd[6687]: pam_sss(sshd:account): Access denied for user Test1: 6 (Permission denied)
Oct 16 09:47:51 [localhost] sshd[6687]: Failed password for Test1 from 192.168.1.99 port 37140 ssh2
Oct 16 09:47:51 [localhost] sshd[6687]: fatal: Access denied for user Test1 by PAM account configuration [preauth]

Читайте также:  Autoruns инструкция. autoruns rus скачать

Доступ разрешен:

Oct 16 09:48:17 [localhost] sshd[6690]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=user.domain.local user=Test2
Oct 16 09:48:17 [localhost] sshd[6690]: Accepted password for Test2 from 192.168.1.99 port 37158 ssh2
Oct 16 09:48:17 [localhost] sshd[6690]: pam_unix(sshd:session): session opened for user Test2 by (uid=0)

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

Создаем файл (имя файла должно быть без точек)

[root@localhost ~]# nano /etc/sudoers.d/domain
%linux_adm@domain.local ALL=(ALL) ALL

Выставляем права

[root@localhost ~]# chmod 0440 /etc/sudoers.d/domainАвторизация по SSH в Centos 7 для группы доменных пользователей, последнее изменение: Ноябрь 7, 2018, автор: Максим Макаров

Источник: https://ITDraft.ru/2018/10/16/avtorizacija-po-ssh-v-centos-7-dlja-gruppy-domennyh-polzovatelej/

Отключение или включение корневого входа SSH и безопасного доступа..

Мы все знаем, что CentOS поставляется с правами доступа root для внешнего мира по умолчанию. Это означает, что вы не можете напрямую войти в систему как пользователь root через SSH, но вы все равно можете использовать root-привилегии, используя вместо этого команду «sudo».

 Однако иногда удобнее входить в систему прямо в качестве пользователя root. Вот почему в этой статье мы поговорим о том, как включить, отключить и защитить регистрацию SSH на сервере при попытке входа в систему с правами администратора.

Прежде чем мы начнем, нам нужно будет выполнить несколько требований, прежде чем продолжить эту статью.

Требования:

  • Установленный CentOS ;
  • Доступ через SSH к вашему VPS;
  • Обычный пользователь, который может использовать «su» или «sudo» для получения привилегий root;

Войдите в свой CentOS VPS через SSH в качестве обычного пользователя с привилегиями sudo:

ssh user_name@Server_IP_Address -p Port_Number

Отключить вход  root через SSH

Чтобы отключить вход в корневой каталог, нам нужно изменить главный файл конфигурации ssh «sshd_config» с помощью текстового редактора по вашему выбору. В нашем примере мы будем использовать nano в качестве редактора.

nano /etc/ssh/sshd_config

Теперь найдите эту строку ниже в файле.

#PermitRootLogin no

Раскомментируйте строку, удалив «#» с начала строки. Строка в файле должна выглядеть так:

PermitRootLogin no

Выполняя следующую команду, мы перезапустим службу демона SSH:

systemctl restart sshd.service

Теперь, когда мы попытаемся войти в систему как пользователь root, вы должны получить ошибку “Access Denied”.

login as: root
root@Server_IP_Address password:
Access denied
root@Server_IP_Address password:

На этом этапе вы не можете входить в систему напрямую как root, но вы можете войти в систему как обычный пользователь с привилегиями sudo и использовать команду «sudo» или «su» для переключения на пользователя root. Например:

login as: username
username@Server_IP_Address password:
Last login: Fri Oct 05 22:48:21 2018 from IP_address
[username@hostname ~]$ su —
Password:
Last login: Fri Oct 05 22:52:45 CDT 2018 from IP_address on pts/1
[root@hostname ~]#

Включить SSH Root Login

Чтобы включить ведение журнала в качестве пользователя root, нам необходимо изменить основной файл конфигурации ssh «sshd_config» с помощью текстового редактора по вашему выбору. В нашем примере мы будем использовать nano в качестве редактора.

nano /etc/ssh/sshd_config

Найдите в файле следующую строку.

PermitRootLogin no

Закомментируйте строку, добавив «#» в начале строки или изменив «нет» на «да», как в приведенных ниже примерах.

#PermitRootLogin no

или же

PermitRootLogin yes

После сохранения файла мы должны перезапустить службу sshd.

systemctl restart sshd.service

Теперь вы можете попытаться войти в систему напрямую как пользователь root.

login as: root
root@Server_IP_Address password:
Last login: Fri Oct 05 22:55:23 2018 from IP_address
[root@hostname ~]#

Безопасный доступ к SSH в CentOS 7

В этом разделе мы предоставим вам несколько простых советов о том, как защитить SSH-доступ на вашем сервере CentOS 7.

Изменение порта сервера SSH

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

nano /etc/ssh/sshd_config

Затем вам нужно найти строку, которая ссылается на номер порта. После того, как вы найдете номер порта, который (значение по умолчанию должно быть 22), вы можете изменить значение по умолчанию на нужный номер.

Когда вы закончите редактирование, нажмите Ctrl + O, а затем нажмите Ctrl + X, чтобы сохранить и выйти.

Перезапустите службу демона SSH, выполнив команду:

systemctl restart sshd.service

Отключение протокола SSHv1

Существует две версии SSH-протоколов: SSHv1 и SSHv2. Использование протокола SSHv1 не рекомендуется, поскольку это более старая версия и менее безопасна, чем новый протокол SSHv2. В следующем разделе мы отключим SSHv1. Если вам нужна эта версия по какой-либо причине, вы можете игнорировать эту часть.

Откройте конфигурационный файл SSH с помощью этой команды:

nano /etc/ssh/sshd_config

Раскомментируйте линию

Protocol 2,1

и отредактируйте ее:

Protocol 2

Теперь мы должны перезапустить службу SSH, чтобы новая конфигурация вступила в силу. Мы можем сделать это, выполнив эту команду:

systemctl restart sshd.service

Отключение доступа root также является одним из способов защитить ваш SSH-сервер, который мы показали вам в начале статьи.

В этой статье мы узнали, как отключить и разрешить вход root в SSH. Мы также узнали, как защитить SSH-сервер, изменив номер порта, отключив доступ root и отключив SSH-протокол SSHv1.

Источник: https://andreyex.ru/centos-7/otklyuchenie-ili-vklyuchenie-kornevogo-vhoda-ssh-i-bezopasnogo-dostupa-ssh-v-centos-7/

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

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

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

Установка Samba 4

192.168.1.190 Samba4 AD centos7

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

# sestatus SELinux status: disabled [root@samba4 ~]#

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

[root@samba4 ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.1.190 samba4.my.domain samba4 [root@samba4 ~]#

Установите epel repo.

[root@~]# yum install epel-release -y

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

[root@~]# yum install perl gcc libacl-devel libblkid-devel gnutls-devel readline-devel python-devel gdb pkgconfig krb5-workstation zlib-devel setroubleshoot-server libaio-devel setroubleshoot-plugins policycoreutils-python libsemanage-python setools-libs-python setools-libs popt-devel libpcap-devel sqlite-devel libidn-devel libxml2-devel libacl-devel libsepol-devel libattr-devel keyutils-libs-devel cyrus-sasl-devel cups-devel bind-utils libxslt docbook-style-xsl openldap-devel pam-devel bzip2 vim wget -y

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

[root@samba4 ~]# wget https://download.samba.org/pub/samba/stable/samba-4.6.0.tar.gz

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

[root@samba4 ~]# tar -zxvf samba-4.6.0.tar.gz [root@samba4 ~]# cd samba-4.6.0 [root@samba4 samba-4.6.0]# ./configure —enable-debug —enable-selftest —with-ads —with-systemd —with-winbind [root@samba4 samba-4.6.0]# make && make install

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

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

[root@samba4 samba]# samba-tool domain provision —use-rfc2307 —interactive Realm [my.domain]: Domain [SUNIL]: Server Role (dc, member, standalone) [dc]: dc DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: DNS forwarder IP address (write 'none' to disable forwarding) [4.2.2.1]: Administrator password: Retype password: Looking up IPv4 addresses Looking up IPv6 addresses No IPv6 address will be assigned Setting up share.ldb Setting up secrets.ldb Setting up the registry Setting up the privileges database Setting up idmap db Setting up SAM db Setting up sam.ldb partitions and settings Setting up sam.ldb rootDSE Pre-loading the Samba 4 and AD schema Adding DomainDN: DC=sunil,DC=cc Adding configuration container Setting up sam.ldb schema Setting up sam.ldb configuration data Setting up display specifiers Modifying display specifiers Adding users container Modifying users container Adding computers container Modifying computers container Setting up sam.ldb data Setting up well known security principals Setting up sam.ldb users and groups ERROR(ldb): uncaught exception — operations error at ../source4/dsdb/samdb/ldb_modules/password_hash.c:2820 File «/usr/local/samba/lib64/python2.7/site-packages/samba/netcmd/__init__.py», line 176, in _run return self.run(*args, **kwargs) File «/usr/local/samba/lib64/python2.7/site-packages/samba/netcmd/domain.py», line 471, in run nosync=ldap_backend_nosync, ldap_dryrun_mode=ldap_dryrun_mode) File «/usr/local/samba/lib64/python2.7/site-packages/samba/provision/__init__.py», line 2175, in provision skip_sysvolacl=skip_sysvolacl) File «/usr/local/samba/lib64/python2.7/site-packages/samba/provision/__init__.py», line 1787, in provision_fill next_rid=next_rid, dc_rid=dc_rid) File «/usr/local/samba/lib64/python2.7/site-packages/samba/provision/__init__.py», line 1447, in fill_samdb «KRBTGTPASS_B64»: b64encode(krbtgtpass.encode('utf-16-le')) File «/usr/local/samba/lib64/python2.7/site-packages/samba/provision/common.py», line 55, in setup_add_ldif ldb.add_ldif(data, controls) File «/usr/local/samba/lib64/python2.7/site-packages/samba/__init__.py», line 225, in add_ldif self.add(msg, controls) [root@samba4 samba]#

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

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

——— #includedir /etc/krb5.conf.d/ ———

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

[root@samba4 etc]# samba-tool domain provision —use-rfc2307 —interactive Realm [my.domain]: Domain [SUNIL]: Server Role (dc, member, standalone) [dc]: DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: DNS forwarder IP address (write 'none' to disable forwarding) [4.2.2.1]: Administrator password: Retype password: Looking up IPv4 addresses Looking up IPv6 addresses No IPv6 address will be assigned Setting up secrets.ldb Setting up the registry Setting up the privileges database Setting up idmap db Setting up SAM db Setting up sam.ldb partitions and settings Setting up sam.ldb rootDSE Pre-loading the Samba 4 and AD schema Adding DomainDN: DC=sunil,DC=cc Adding configuration container Setting up sam.ldb schema Setting up sam.ldb configuration data Setting up display specifiers Modifying display specifiers Adding users container Modifying users container Adding computers container Modifying computers container Setting up sam.ldb data Setting up well known security principals Setting up sam.ldb users and groups Setting up self join Adding DNS accounts Creating CN=MicrosoftDNS,CN=System,DC=sunil,DC=cc Creating DomainDnsZones and ForestDnsZones partitions Populating DomainDnsZones and ForestDnsZones partitions Setting up sam.ldb rootDSE marking as synchronized Fixing provision GUIDs A Kerberos configuration suitable for Samba AD has been generated at /usr/local/samba/private/krb5.conf Setting up fake yp server settings Once the above files are installed, your Samba4 server will be ready to use Server Role: active directory domain controller Hostname: samba4 NetBIOS Domain: SUNIL DNS Domain: my.domain DOMAIN SID: S-1-5-21-2936486394-2075362935-551615353 [root@samba4 etc]#

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

[etc]#firewall-cmd —add-port=53/tcp —permanent;firewall-cmd —add-port=53/udp —permanent;firewall-cmd —add-port=88/tcp —permanent;firewall-cmd —add-port=88/udp —permanent; firewall-cmd —add-port=135/tcp —permanent;firewall-cmd —add-port=137-138/udp —permanent;firewall-cmd —add-port=139/tcp —permanent; firewall-cmd —add-port=389/tcp —permanent;firewall-cmd —add-port=389/udp —permanent;firewall-cmd —add-port=445/tcp —permanent; firewall-cmd —add-port=464/tcp —permanent;firewall-cmd —add-port=464/udp —permanent;firewall-cmd —add-port=636/tcp —permanent; firewall-cmd —add-port=1024-5000/tcp —permanent;firewall-cmd —add-port=3268-3269/tcp —permanent [root@samba4 ~]# firewall-cmd —reload

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

[root@samba4 ~]# cat /etc/systemd/system/samba.service [Unit] Description= Samba 4 Active Directory After=syslog.target After=network.target [Service] Type=forking PIDFile=/usr/local/samba/var/run/samba.pid ExecStart=/usr/local/samba/sbin/samba [Install] WantedBy=multi-user.target [root@samba4 ~]# [root@samba4 ~]# systemctl enable samba Created symlink from /etc/systemd/system/multi-user.target.wants/samba.service to /etc/systemd/system/samba.service. [root@samba4 ~]# systemctl start samba

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

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

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

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

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

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

Запустите установщик.

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

Читайте также:  Linux инструкции. статьи по linux. полезные советы по администрированию linux

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

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

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

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

Установка пакетов:

[root]# yum -y install realmd sssd oddjob oddjob-mkhomedir adcli samba-common

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

[root@centos7 ~]# realm discover my.domain my.domain type: kerberos realm-name: my.domain domain-name: my.domain 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 login-policy: allow-realm-logins [root@centos7 ~]#

Присоединение к домену.

[root@centos7 ~]# realm join my.domain Password for Administrator: [root@centos7 ~]#

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

[root@centos7 ~]# id SUNIL\testuser uid=1570001104(Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.) gid=1570000513(domain Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.) groups=1570000513(domain Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.) [root@centos7 ~]#

Настройка sssd.

[root@centos7 ~]# cat /etc/sssd/sssd.conf [sssd] domains = my.domain config_file_version = 2 services = nss, pam [domain/my.domain] ad_domain = my.domain krb5_realm = my.domain realmd_tags = manages-system joined-with-samba 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 = ad [root@centos7 ~]#

Перезагрузка sssd.

[root@centos7 ~]# systemctl restart sssd [root@centos7 ~]# systemctl enable sssd

Проверка пользователя.

[root@centos7 ~]# id Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. uid=1570001105(Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.) gid=1570000513(domain Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.) groups=1570000513(domain Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.),1570000512(domain Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.),1570000572(denied rodc password replication Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.) [root@centos7 ~]#

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

[root@centos7 ~]# vim /etc/sssd/sssd.conf ———— ———— use_fully_qualified_names = False ———— ————

Источник: http://drach.pro/blog/linux/item/136-samba-under-centos

Настройка SSH аутентификации по ключам в Linux

В интернете полно инструкций как настроить SSH аутентификацию по ключам на сервере Linux. Но каждый раз при настройке мне приходится искать их заново, потому что некоторые нюансы я забываю. Поэтому оставлю тут эту инструкцию в первую очередь для себя и добавлю полезную информацию о журналах отпечатков (fingerprint) ключей, которая нигде не встречается.

Итак, чтобы подключится к *Nix хосту через SSH, нужно предоставить серверу пару: логин + пароль, или логин + ключ. Настройка SSH аутентификации по ключам не только повышает уровень защищенности сервера, но и упрощает жизнь администратору за счет более удобного подключения к серверу.

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

Желательно хранить закрытый ключ на зашифрованном разделе (Bitlocker, EFS), тем самым вы защититесь от кражи закрытого файла с ключом.

Создание SSH ключей для Putty

Для подключения к серверам Linux из Windows я предпочитаю использовать старый-добрый клиент PuTTy. В состав пакета поставки putty входит небольшая утилита puttygen, которая может быть использована для генерации RSA и DSA ключей.

Скачайте утилиту с официального сайта https://the.earth.li/~sgtatham/putty/latest/x86/puttygen.exe и запустите ее. В окне PuTTy Key Generator нажмите кнопку Generate и произвольно подвигайте мышкой для создания некой рандомной последовательности.

Утилита сгенерирует пару ключей: открытый и закрытый.

Нам интересны следующие возможности интерфейса

Key passphrase Здесь можно указать пароль для защиты закрытого ключа
Save public key Кнопка для сохранения открытого ключа в файл, который нужно будет поместить на удаленный сервер
Save private key Кнопка для сохранения закрытого ключа Файл с закрытым ключом должен храниться на клиенте (желательно защищённом) и будет использоваться для подключения к удаленному серверу.
SSH-2 RSA 2048 Указывается тип ключа и его длина. В нашем примере достаточно будет выбрать SSH-2 RSA.

Формат файла ключа, который генерирует утилита puttygen напрямую не подходит для openssh, который запушен на моем сервере.

Поэтому мне придется скопировать в буфер значение открытого ключа из окна puttygen в буфер обмена (я выделил его на скриншоте выше). Этот код нужно будет поместить в файл на сервере.

Но также сохраните открытый и закрытый ключи в 2 файла с помощью соответствующих кнопок.

Настройка SSH на Linux для аутентификации с помощью ключей

В большинстве дистрибутивов Linux уже настроена поддержка аутентфикации с помощью сертификатов. Откройте конфигурационной файл сервера SSH (/etc/ssh/sshd_config) и раскомментируйте или добавьте следующие стройки:

HostKey /etc/ssh/ssh_host_dsa_key PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys

Перезапустите SSH командой:

# /etc/init.d/sshd restart

Затем создадим файл с ключом на сервере:

# mkdir ~/.ssh # chmod 0700 ~/.ssh # touch ~/.ssh/authorized_keys

# chmod 0644 ~/.ssh/authorized_keys

В файл authorized_keys нужно вставить ключ, скопированный из окна puttygen и сохранить его.

Затем на стороне клиента откройте Putty и перейдите в раздел Connection -> SSH -> Auth. Нажмите кнопку Browse и укажите путь к закрытому ключу, который вы сохранили ранее (расширение.ppk)

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

Теперь можно подключиться к серверу (нет необходимости перезапускать демона sshd).

Укажем только имя пользователя (в нашем случае это root).

Наличие строки « Authenticating with public key «rsa-key-20161208″» говорит о том, что вы успешно аутентифицировались с помощью ключа RSA.

Журнал подключений по SSH с помощью ключей

Как правило, администратор должен знать, когда и какой ключ или сертификат использовался для подключения к серверу. Однако, в большинстве дистрибутивов эта информация в журналах не отображается. Однако, к примеру, в CentOS 7 со стандартными настройками и уровнем журналирования INFO, отпечатки ключей сохраняются в журнал (# cat /var/log/secure).

В том случае, если в вашем журнале нет этой информации, исправить это не сложно. Отредактируйте конфигурационный файл /etc/ssh/sshd_config, изменив уровень журналирования:

LogLevel VERBOSE

И перезапустите sshd:

# /etc/init.d/sshd restart

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

# cat /var/log/secure
May 20 12:23:17 server sshd[8746]: Connection from 192.168.10.15 port 60162
May 20 12:23:19 server sshd[8746]: Found matching RSA key: 5b:7b:2a:14:29:11:bf:3a:8f:bd:24:99:21:34:cd:e6 May 20 12:23:19 server sshd[8746]: Postponed publickey for root from 192.168.10.

15 port 60162 ssh2 [preauth] May 20 12:23:19 server sshd[8746]: Found matching RSA key: 5b:7b:2a:14:29:11:bf:3a:8f:bd:24:99:21:34:cd:e6 May 20 12:23:19 server sshd[8746]: Accepted publickey for root from 192.168.10.

15 port 60162 ssh2

May 20 12:23:19 server sshd[8746]: pam_unix(sshd:session): session opened for user root by (uid=0)

Как видите, теперь в журнале отображается отпечаток ключа, позволяющий идентифицировать пользователя.

Источник: https://vmblog.ru/nastrojka-ssh-autentifikacii-po-klyucham-v-linux/

Как присоединить серверы centos 7 / rhel 7 к домену active directory

В большинстве сред домен 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 в конце команды

Читайте также:  Postfix на centos 7 + все необходимое: dovecot + imap + mariadb + postfixadmin + roundcube + clamav + spamassassin + антиспам + шифрование

Источник: http://itisgood.ru/2018/07/13/kak-prisoedinit-servery-centos-7-rhel-7-k-domenu-active-directory/

Setup CentOS to authenticate via Active Directory

This how-to was created on CentOS 6.4 as a client and Windows 2008 Standard R2 as the AD Server. I then followed this how-to on 2 other servers to verify the steps were accurate.

Before you start this process make sure that you either edit your selinux configuration to allow this process or disable it. By default selinux will not allow this authentication method to occur and you will simply get an invalid password response when attempting to log in.

# yum -y install authconfig krb5-workstation pam_krb5 samba-common oddjob-mkhomedir sudo ntp

This will install: — authconfig which we will use to setup the configuration file basics, there may be parts missing or not quite accurate here, so some of the files seem to need a little massaging to work right later.

— krb5-workstation which installs required libraries and binaries to perform authentication against active directory using the kerberos protocol — pam_krb5 this package provides libraries for PAM (Pluggable Authentication Modules) to interface with kerberos — samba-common will installed the required libraries and binaries to join the linux box to the domain so domain accounts are trusted by the local machine — oddjob-mkhomedir this package is used to automatically create home directories when your AD users log into the server the first time

— sudo will be used to configure which AD users have permission to perform elevated operations on the linux computer.

# authconfig —disablecache —enablewinbind —enablewinbindauth —smbsecurity=ads —smbworkgroup={AD DOMAIN NAME(short version all caps)} —smbrealm={AD DOMAIN NAME(long version all caps)} —enablewinbindusedefaultdomain —winbindtemplatehomedir=/home/{AD DOMAIN NAME(long version all lower case)}/%U —winbindtemplateshell=/bin/bash —enablekrb5 —krb5realm={AD DOMAIN NAME(long version all caps)} —enablekrb5kdcdns —enablekrb5realmdns —enablelocauthorize —enablemkhomedir —enablepamaccess —updateall

This will create the initial configuration files to setup samba and kerberos. Next we will update the initial files to make sure they are correct.

[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log

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

[libdefaults] default_realm = AD DOMAIN NAME.XXX} dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d

forwardable = true

[realms] {AD DOMAIN NAME.XXX} = { admin_server = {pdc host name}.{ad domain name.xxx} kdc_server = {pdc host name}.{ad domain name.xxx}

}

{ad domain name.xxx} = {
}

[domain_realm] .{ad domain name.xxx} = {AD DOMAIN NAME.XXX}

{ad domain name.xxx} = {AD DOMAIN NAME.XXX}

xxx = your domain extenion. i.e. loc, local, com, …
pdc = your global catalog servers hostname

# kinit {ad username}

You should be returned to a prompt with no output if authentication works correctly. If you receive an error at this point, stop and resolve the error. If you do get an error, it will be something related to the krb5.conf file and the active directory setup. Compare all of your configuration directives and try it again until you can authenticate against AD with this command.

# ntpdate {fqdn of ad server}

This will ensure the servers times are in sync as the time is used in hashing passwords during the process of joining the domain.

# net ads join {AD DOMAIN NAME(long version all lower case)} -U {ad user authorized to join computers to domain}

You can then test that the join succeeded if you have any doubts using

# net ads testjoin

That command will reply with a good indicator if your all good to go.

This step is reliant on /etc/sama/smb.conf configuration file. If you have problems here, that would be a good place to start troubleshooting the issue.

# mkdir /home/{ad domain name.xxx}
# chmod 777 /home/{ad domain name.xxx}/

Now when your AD users log into this box, a home directory will be created for them automatically in this location.

This will update the authentication system so that AD users that are members of the linuxusers group will be able to access the system. Other AD users will not.

#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_krb5.so use_first_pass

auth required pam_deny.so

account required pam_access.so account required pam_unix.so broken_shadow account [default=ignore success=1] pam_succeed_if.so uid < 16777216 quiet account [default=bad success=ignore] pam_succeed_if.so user ingroup linuxusers quiet account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_krb5.so

account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_krb5.so use_authtok

password required pam_deny.so

session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so

session optional pam_krb5.so

Pay close attention to the account directives, this is where you stipulate the order of what accounts are authorized to access services via PAM.

# echo '%linuxusers ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

This will allow your users who are part of the active directory group 'linuxusers' to perform elevated tasks on the server via sudo. The NOPASSWD can be replaced with ALL which will cause the server to ask the user again for their password. More secure, but if you're box is secured in other ways (as mine are) I find this to be more annoying than anything else…

Источник: https://community.spiceworks.com/how_to/44885-setup-centos-to-authenticate-via-active-directory

Centos 7 active directory ldap

In this example I am using CentOS 7 and Windows Server 2012 R2, . Learn how to join a CentOS Linux server to a Microsoft Windows Active.

Deveo LDAP Sync application * DeveoAuth extension for Active Directory * Deveo Jenkins. Support for LDAP Subgroups for access to projects and repos. * Canceling Deveo Account. 23 votes · 0 comments. SSH host keys issues on RHEL/CentOS 7 * All articles →.

Установка и настройка puppet на CentOS. Как настроить OpenVPN с аутентификацией через LDAP. SSH на CentOS 7 через Active Directory.

This tutorial needs Windows Active Directory Domain Service in your LAN. Make sure it's possible to get an AD user info or not.

New computers and containers. *Inbuilt eScan Remote Support. With the help of Active Directory synchronization, the. 10 & above (32 & 64 bit), SLES 10 SP3 & above (32. LDAP & POP3 Authentication. *24×7 FREE Online Technical. RHEL 4 & above (32 & 64 bit), CentOS 5.

Now we need to configure SQUID authentication,to do that we need to configure helpers. Helpers are modules,written as scripts,which authenticate users. Helper reads username/password pairs from Standard Input one pair at a time in a single line of text, and writes a single line of text to Standard Output that is either “OK”  or “ERR” (in case of problems).

Install And Configure LDAP Server In CentOS 7. 389-DS (389 Directory Server) is an open source enterprise class LDAP server for Linux, and is developed.

Top posts & pages. Install nginx, php-fpm, mariadb, phpmyadmin (lemp) on localhost for mac osx along with multiple sites ssh2 solution for php 7 on centos 7.

If the Active Directory server ad1_example. LDAP IBM directory server 4. 1 & Redhat EAS3 problem. Com is the non-default server: ad1_example. Slapd: relocation error: /usr/ldap/.

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

After upgrading to CentOS 7 it’s no longer possible to login via LDAP. With CentOS 6 I used the package pam_ldap which worked fine, but now pam_ldap is no longer.

Will join Squid server (Centos7) into windows domain and configure AD. It allows Squid to connect to a LDAP directory to validate the user .

Источник: http://offerov.net/centos-7-active-directory-ldap/

Centos 7: Join Active Directory Domain and Locking Down Sudo and SSH Access

Joining A Domain

Before we start…

We’re going to assume your AD domain is “netdoggy.com” and user netdoggytech has rights to add workstation objects to the domain.  Also, you’ll need certain packages installed on your Centos 7 system.  Here’s how you get them:

yum install realmd samba samba-common oddjob oddjob-mkhomedir sssd ntpdate ntp

Once installed, run this command (input the password for netdoggytech when prompted):

realm join –user=netdoggytech@netdoggy.com netdoggy.com (that’s two hyphens before user)

Let’s confirm the domain information populated correctly:

realm list

That’s it?  Yup.

Setup NTP

systemctl start ntpd.service

systemctl enable ntpd.service

Verify the peer by issuing this command: ntpq -p

Removing Domain Name from SSH Login

Great, but when I log into the  box via SSH, do I really have to input my username as DOMAINUSERNAME?  The answer is no.  Here’s how you change that (I’m assuming you know how to use vi…if you don’t, there are plenty of great tutorials on the Internet):

vi /etc/sssd/sssd.conf

See that line that says “use_fully_qualified_names = True”, change that to:

use_fully_qualified_names = False

Once changes, go ahead and hit the Esc key and perform a write quit.  In other words, hit Esc and type :wq to save the file and get back to a command prompt.  Cycle the sssd service by performing the following command:

systemctl restart sssd

Restrict Logins to Domain Admins

vi /etc/ssh/sshd_config

Add the following line:

AllowGroups root wheel «domain admins»

systemctl restart sshd

Giving Domain Admins (or any other AD group) Sudo

Let’s make it a little more interesting…let’s lockdown SSH logins so that only Domain Admins can log into the box. Issue this command:

visudo

Find the line that says root ALL=(ALL) ALL.  Right below it, add this line:

%domain admins ALL=(ALL) ALL

As added security, you can make it so you will be prompted to enter in the root password of your box rather than re-entering your password when you sudo up.  Add the following line below # Defaults specification

Defaults rootpw

Источник: https://netdoggy.wordpress.com/linux/centos/adding-centos-7-to-the-domain/

Ссылка на основную публикацию