Авторизация на основе групп AD
Ранее, мы предоставили доступ к сети Интернет любому пользователю Active Directory. Теперь ограничим доступ с помощью групп AD DS.
Для начала, создаем 2 группы пользователей, например:
- squidusers. Пользователи squid, которым будет предоставлен доступ к сети Интернет с ограничениями.
- squidsuperusers. Этим пользователям будет предоставлен неограниченный доступ.
Теперь на прокси-сервере открываем конфигурационный файл squid:
vi /etc/squid/squid.conf
Добавляем после настройки аутентификации:
external_acl_type squid_users_from_ad_krb ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g [email protected]
external_acl_type squid_superusers_from_ad_krb ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g [email protected]
external_acl_type squid_users_from_ad_ntlm %LOGIN /usr/lib64/squid/ext_wbinfo_group_acl -d
* где
- squid_users_from_ad_krb — произвольное название acl, авторизованных пользователей в AD через kerberos, принадлежащих группе squidusers в домене DOMAIN.LOCAL.
- squid_superusers_from_ad_krb — произвольное название acl, авторизованных пользователей в AD через kerberos, принадлежащих группе squidsuperusers в домене DOMAIN.LOCAL.
- squid_users_from_ad_ntlm — произвольное название acl, авторизованных пользователей в AD через NTLM.
В секции acl:
#acl auth proxy_auth REQUIRED
acl squid_users_acl_krb external squid_users_from_ad_krb
acl squid_superusers_acl_krb external squid_superusers_from_ad_krb
acl squid_users_acl_ntlm external squid_users_from_ad_ntlm squidusers
acl squid_superusers_acl_ntlm external squid_superusers_from_ad_ntlm squidsuperusers
* где
- squid_users_acl_krb — произвольное название acl для всех, кто входит в squid_users_from_ad_krb;
- squid_superusers_acl_krb — произвольное название acl для всех, кто входит в squid_superusers_from_ad_krb;
- squid_users_acl_ntlm — произвольное название acl для всех, кто входит в squid_users_from_ad_ntlm;
- squid_superusers_acl_ntlm — произвольное название acl для всех, кто входит в squid_superusers_from_ad_ntlm;
* предыдущую acl для общей аутентификации комментируем.
В секции allow:
#http_access allow auth
http_access allow squid_superusers_acl_krb
http_access allow squid_superusers_acl_ntlm
http_access allow squid_users_acl_krb
http_access allow squid_users_acl_ntlm
* разрешаем доступ для созданных ранее acl; предыдущее разрешение для всех пользователей AD запрещаем. На данном этапе разницы между пользователями групп squidusers и squidsuperusers нет — позже мы настроим ограничение доступа к сайтам, где будем применять разные группы для предоставления различных прав.
Перечитываем конфигурацию прокси-сервера:
squid -k reconfigure
LDAP
Для проверки доступности и работоспособности службы LDAP можно запросить отчет о репликации:
sudo samba-tool drs showrepl
Default-First-Site-Name\DC2 DSA Options: 0x00000001 DSA object GUID: 303f45ca-3a45-4169-ad71-0903ac3e7ab9 DSA invocationId: 4750cc0a-ba23-4492-a1cd-3c66f5b3b073 ==== INBOUND NEIGHBORS ==== CN=Configuration,DC=samdom,DC=example,dc=com Default-First-Site-Name\DC1 via RPC DSA object GUID: ce07ab44-222f-4882-b4f5-ed382f6b2047 Last attempt @ Fri Dec 6 10:27:20 2019 MSK was successful 0 consecutive failure(s). Last success @ Fri Dec 6 10:27:20 2019 MSK DC=samdom,DC=example,dc=com Default-First-Site-Name\DC1 via RPC DSA object GUID: ce07ab44-222f-4882-b4f5-ed382f6b2047 Last attempt @ Fri Dec 6 10:27:20 2019 MSK was successful 0 consecutive failure(s). Last success @ Fri Dec 6 10:27:20 2019 MSK DC=DomainDnsZones,DC=samdom,DC=example,dc=com Default-First-Site-Name\DC1 via RPC DSA object GUID: ce07ab44-222f-4882-b4f5-ed382f6b2047 Last attempt @ Fri Dec 6 10:27:20 2019 MSK was successful 0 consecutive failure(s). Last success @ Fri Dec 6 10:27:20 2019 MSK CN=Schema,CN=Configuration,DC=samdom,DC=example,dc=com Default-First-Site-Name\DC1 via RPC DSA object GUID: ce07ab44-222f-4882-b4f5-ed382f6b2047 Last attempt @ Fri Dec 6 10:27:20 2019 MSK was successful 0 consecutive failure(s). Last success @ Fri Dec 6 10:27:20 2019 MSK DC=ForestDnsZones,DC=samdom,DC=example,dc=com Default-First-Site-Name\DC1 via RPC DSA object GUID: ce07ab44-222f-4882-b4f5-ed382f6b2047 Last attempt @ Fri Dec 6 10:27:20 2019 MSK was successful 0 consecutive failure(s). Last success @ Fri Dec 6 10:27:20 2019 MSK ==== OUTBOUND NEIGHBORS ==== CN=Configuration,DC=samdom,DC=example,dc=com Default-First-Site-Name\DC1 via RPC DSA object GUID: ce07ab44-222f-4882-b4f5-ed382f6b2047 Last attempt @ Fri Dec 6 08:27:31 2019 MSK was successful 0 consecutive failure(s). Last success @ Fri Dec 6 08:27:31 2019 MSK DC=samdom,DC=example,dc=com Default-First-Site-Name\DC1 via RPC DSA object GUID: ce07ab44-222f-4882-b4f5-ed382f6b2047 Last attempt @ Thu Dec 5 17:24:10 2019 MSK was successful 0 consecutive failure(s). Last success @ Thu Dec 5 17:24:10 2019 MSK DC=DomainDnsZones,DC=samdom,DC=example,dc=com Default-First-Site-Name\DC1 via RPC DSA object GUID: ce07ab44-222f-4882-b4f5-ed382f6b2047 Last attempt @ Thu Dec 5 17:24:10 2019 MSK was successful 0 consecutive failure(s). Last success @ Thu Dec 5 17:24:10 2019 MSK CN=Schema,CN=Configuration,DC=samdom,DC=example,dc=com Default-First-Site-Name\DC1 via RPC DSA object GUID: ce07ab44-222f-4882-b4f5-ed382f6b2047 Last attempt @ Thu Dec 5 17:24:10 2019 MSK was successful 0 consecutive failure(s). Last success @ Thu Dec 5 17:24:10 2019 MSK DC=ForestDnsZones,DC=samdom,DC=example,dc=com Default-First-Site-Name\DC1 via RPC DSA object GUID: ce07ab44-222f-4882-b4f5-ed382f6b2047 Last attempt @ Thu Dec 5 17:24:10 2019 MSK was successful 0 consecutive failure(s). Last success @ Thu Dec 5 17:24:10 2019 MSK ==== KCC CONNECTION OBJECTS ==== Connection -- Connection name: 49744c99-ca35-4811-af8f-73119e8b31f5 Enabled : TRUE Server DNS name : DC1.windomain.le Server DN name : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,dc=com TransportType: RPC options: 0x00000001 Warning: No NC replicated for Connection!
При проверке может выдаваться следующее предупреждение:
Кроме этого, для проверки корректности работы репликации каталогов, добавьте нового пользователя на ранее установленном контроллере домена, и убедитесь, что этот пользователь автоматически появился на новом контроллере.
Завершающие команды
После успешного выполнения команды Назначения:
# Разрешить автоматический запуск службы контроллера домена:sudo systemctl unmask samba-ad-dcsudo systemctl enable samba-ad-dc
# Скопировать автоматически созданную конфигурацию службы Kerberossudo cp -b /var/lib/samba/private/krb5.conf /etc/krb5.conf
# Запустить доменную службу Samba sudo systemctl start samba-ad-dc
Проверка результатов Назначения
Подробно команды для проверки результатов настройки контроллера домена описаны в статье Присоединение Samba к существующему домену AD. Разница только в том, что домена AD сейчас нет, сервер только один, соответственно, опрашивать нужно только один сервер, и в ответах будет только один сервер.
Создание реверсивных зон
С помощью команды samba-tool dns zonecreate можно добавить необязательную зону реверсивного поиска:
samba-tool dns zonecreate samdom.example.com 2.0.10.in-addr.arpa -U Administrator
Password for :Zone 2.0.10.in-addr.arpa created successfully
Если требуется использовать несколько реверсивных зон, просто выполните команду несколько раз с указанием параметров соответствующих подсетей.Изменение реверсивных зон не требует перезапуска сервисов Samba или BIND.
Разрешение имён для клиентских машин
После выполнения указанных выше настроек DNS сервер не может получать и, соответственно, выдавать информацию об именах и IP-адресах клиентских машин.
Если в домене используются клиентские машины, получающие динамические IP-адреса от сервера DHCP, сервер DNS может быть настроен на автоматическое получение информации о выданных адресах. Примерный порядок настройки см. в статье Динамическое обновление DNS клиентских машин FreeIPA;
Если в домене используются клиентские машины, которым присваиваются статические адреса, то:
- Можно использовать для присвоения этих статических адресов сервер DHCP с динамическим обновлением адресов;
1. An overview of the lab environment
For demonstrations of this article to add CentOS 8 to Windows Domain Controller (Active Directory), we will use virtual machines running in an Oracle VirtualBox installed on my Linux Server virtualization environment.
We have a Microsoft Server 2012R2 Active Directory Domain Controller with the IP address 192.168.0.107, CentOS 8 host with the IP address 192.168.0.117 and RHEL 8 with IP Address 192.168.0.106. In this article I will only cover the part to add CentOS 8 to Windows Domain Controller on the client side. So this article requires a pre-configured Windows Active Directory.
I have only used snippets from my CentOS 8 Server but I have verified the steps on both RHEL 8 and CentOS 8.
Вход в виртуальную машину с помощью учетной записи домена
Чтобы убедиться, что виртуальная машина успешно присоединена к управляемому домену, запустите новое SSH-подключение, используя учетную запись пользователя домена. Убедитесь, что был создан корневой каталог и применяется членство в группе из домена.
-
Создайте новое SSH-подключение с консоли. Используйте учетную запись домена, принадлежащую к управляемому домену, с помощью команды , например , и введите адрес виртуальной машины, например . При использовании Azure Cloud Shell используйте общедоступный IP-адрес виртуальной машины, а не внутреннее DNS-имя.
-
После успешного подключения к виртуальной машине убедитесь, что корневой каталог был инициализирован правильно:
Вы должны находиться в каталоге /home с собственным каталогом, совпадающим с учетной записью пользователя.
-
Теперь убедитесь, что членство в группе разрешается правильно:
Вы должны видеть свое членство в группе из управляемого домена.
-
Если вы вошли в виртуальную машину в качестве члена группы администраторов контроллера домена AAD, убедитесь, что вы можете правильно использовать команду :
Summary
In this article we learned how we can join a Linux client (CentOS/RHEL 7/8) to Windows AD Domain using realmd tool. The realmd system provides a clear and simple way to discover and join identity domains. It does not connect to the domain itself but configures underlying Linux system services, such as SSSD or Winbind, to connect to the domain.
It can run a discovery search to identify available AD and Identity Management domains and then join the system to the domain, as well as set up the required client services used to connect to the given identity domain and manage user access. Additionally, because SSSD as an underlying service supports multiple domains, realmd can discover and support multiple domains as well.
Настройка SQUID
Для скрипта запуска squid добавим следующее:
vi /etc/default/squid
KRB5_KTNAME=/etc/squid/proxy.keytab
export KRB5_KTNAME
* в данном случае, мы задаем переменную KRB5_KTNAME, в которой указан путь до кейтаб файла.
Открываем конфигурационный файл squid:
vi /etc/squid/squid.conf
И добавляем:
auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -d -s HTTP/[email protected]
auth_param negotiate children 20
auth_param negotiate keep_alive on
auth_param ntlm program /usr/bin/ntlm_auth —diagnostics —helper-protocol=squid-2.5-ntlmssp —domain=DOMAIN
auth_param ntlm children 10
auth_param ntlm keep_alive off
* где /usr/lib64/squid/negotiate_kerberos_auth — путь до библиотеки аутентификации по kerberos, ее путь может отличаться — это зависит от версии системы; HTTP/[email protected] — учетная запись в keytab.
Также настраиваем, чтобы squid требовал аутентификацию. Для этого в секции acl добавим:
acl auth proxy_auth REQUIRED
Далее это:
http_access allow localnet
Меняем на:
http_access allow auth
* в нашем случае acl localnet использовалась для предоставления доступа.
Проверяем настройки конфигурационного файла:
squid -k parse
И если ошибок нет:
squid -k reconfigure
4. Configure Winbind with smb.conf
Configure by replacing the existing content under section with the following content to add Linux to windows active directory. Modify the realm and workgroup value as per your environment.
You can also use Red Hat’s AD Integration Helper to help generate optimal configuration values for connecting to your organizations Active Directory.
workgroup = GOLINUXCLOUD realm = GOLINUXCLOUD.COM security = ads idmap config * : backend = autorid idmap config * : range = 100000-19999999 idmap config * : rangesize = 1000000 template homedir = /home/%D/%U template shell = /bin/bash winbind use default domain = false winbind offline logon = true log file = /var/log/samba/log.%m max log size = 50 log level = 0
security=ads describes the membership in an Active Directory domain.
The parameters idmap* and winbind enum* map Windows users and groups to Unix users and groups.
Advertisement
Usually system users and groups are assigned IDs in the range from 0 to 999, and local users and groups are assigned IDs starting from 1000. With this in mind, it seems pretty reasonable to start assigning IDs to domain users and groups starting from 1000000. We should also differentiate between the domain users and groups and the local built-in accounts existing on a member server, such as the local administrator, the local guest, and so on. These two groups must not overlap, so we assign the range 1000000 to 19999999 to domain built-in user and group accounts
Run the following command to verify that you can resolve the standard SRV records:
# host -t SRV _kerberos._udp.golinuxcloud.com. _kerberos._udp.golinuxcloud.com has SRV record 0 100 88 win-71humtros3m.golinuxcloud.com. # host -t SRV _ldap._tcp.golinuxcloud.com. _ldap._tcp.golinuxcloud.com has SRV record 0 100 389 win-71humtros3m.golinuxcloud.com.
Stop the service if it is in running state:
# systemctl stop winbind
Разрешение проверки пароля для SSH
По умолчанию пользователи могут входить в виртуальную машину только с помощью проверки подлинности на основе открытых ключей SSH. Проверку подлинности на основе пароля пройти невозможно. При присоединении виртуальной машины к управляемому домену эти учетные записи домена должны использовать проверку подлинности на основе пароля. Обновите конфигурацию SSH, чтобы разрешить проверку подлинности на основе пароля, как показано ниже.
-
Откройте файл sshd_conf с помощью редактора:
-
Для строки PasswordAuthentication установите значение yes:
По завершении сохраните и закройте файл sshd_conf с помощью команды редактора.
-
Чтобы применить изменения и позволить пользователям входить с помощью пароля, перезапустите службу SSH:
7. Client Validation
After you add CentOS 8 to Windows Domain Controller it is necessary that you run some checks on the client host i.e. CentOS 8 to make sure it is able to reach Active Directory properly.
You can test whether everything is working properly with . The command runs an encrypted RPC call, which is only possible if the server really is a member in the domain:
# wbinfo -t checking the trust secret for domain GOLINUXCLOUD via RPC calls succeeded
List AD users.
# wbinfo -u GOLINUXCLOUD\administrator GOLINUXCLOUD\guest GOLINUXCLOUD\krbtgt
List AD groups.
# wbinfo -g GOLINUXCLOUD\winrmremotewmiusers__ GOLINUXCLOUD\domain computers GOLINUXCLOUD\domain controllers GOLINUXCLOUD\schema admins GOLINUXCLOUD\enterprise admins GOLINUXCLOUD\cert publishers GOLINUXCLOUD\domain admins GOLINUXCLOUD\domain users GOLINUXCLOUD\domain guests GOLINUXCLOUD\group policy creator owners GOLINUXCLOUD\ras and ias servers GOLINUXCLOUD\allowed rodc password replication group GOLINUXCLOUD\denied rodc password replication group GOLINUXCLOUD\read-only domain controllers GOLINUXCLOUD\enterprise read-only domain controllers GOLINUXCLOUD\cloneable domain controllers GOLINUXCLOUD\protected users GOLINUXCLOUD\dnsadmins GOLINUXCLOUD\dnsupdateproxy
Работа над ошибками
Winbind не запускается
При запуске Samba обнаруживаем, что winbind не запустился:
# /etc/init.d/winbind status * winbind is not running
В журнале log.winbindd обнаруживаем запись:
[2010/03/06 13:54:34, 2] winbindd/winbindd_util.c:235(add_trusted_domain) Added domain BUILTIN S-1-5-32 [2010/03/06 13:54:34, 2] winbindd/winbindd_util.c:235(add_trusted_domain) Added domain STORAGE S-1-5-21-3963871611-1338977097-196861091 [2010/03/06 13:54:34, 0] winbindd/winbindd_util.c:782(init_domain_list) Could not fetch our SID - did we join? [2010/03/06 13:54:34, 0] winbindd/winbindd.c:1385(main) unable to initialize domain list
Видим, что добавлен «встроенный домен» (BUILTIN) и домен «название компьютера» (STORAGE), подключиться к домену AD не удалось.
Решение: Переподключить компьютер в домен. Удалять придётся с самого контроллера, т.к. комадна net ads leave скорее всего не поможет.
Ошибка получения билета Kerberos
При попытке получить билет Kerberos получили:
kinit: KDC reply did not match expectations while getting initial credentials
Решение: указать имя домена в другом регистре. Скорее всего нужны все заглавные
Настройка прав доступа на файлы в Samba
Сделаю небольшое пояснение по правам доступа в файловом сервере samba. Вопрос этот сложный и объемный. Ему можно посвятить и отдельную статью. Но для полноты картины по настройке самбы, расскажу самое основное.
Как я уже ранее сказал, изменять права доступа к каталогам на файловом сервере можно с помощью команды setfacl. Давайте сейчас посмотрим на права доступа, которые установлены:
# getfacl /mnt/samba # file: mnt/shara # owner: admin51 # group: пользователи\040домена user::rwx group::r-x other::---
С такими правами что-то создавать в папке сможет только пользователь admin51, а пользователи домена смогут только просматривать файлы и каталоги. Сделаем более прикладной вариант. Добавим права доступа на чтение и запись еще одной доменной группе — gr_it.
# setfacl -m g:gr_it:rwx /mnt/shara
Обращаю внимание, что иногда при копировании команд setfacl они не отрабатывают, выдавая не очень понятную ошибку:
setfacl: Option -m: Invalid argument near character 1
Наберите команду с клавиатуры, либо просто удалите и наберите снова ключ -m, он почему-то при копировании часто дает эту ошибку.
Смотрим, что получилось:
# getfacl /mnt/shara # file: mnt/shara # owner: admin51 # group: пользователи\040домена user::rwx group::r-x group:gr_it:rwx mask::rwx other::---
То, что надо. Теперь пользователи группы gr_it имеют полные права на шару. Создадим одним таким пользователем папку test1 на нашей шаре и посмотрим, какие права она получит.
# getfacl /mnt/shara/test1 # file: mnt/shara/test1 # owner: user1 # group: пользователи\040домена user::rwx group::--- other::---
Права на папку имеет только ее создатель и больше никто. Для того, чтобы наследовались права с вышестоящего каталога, необходимо на этот вышестоящий каталог добавить дефолтные права доступа. Примерно вот так.
# setfacl -m d:g:gr_it:rwx,d:g:'пользователи домена':rx /mnt/shara
Смотрим, что получилось:
# getfacl /mnt/shara # file: mnt/shara # owner: admin51 # group: пользователи\040домена user::rwx group::r-x group:gr_it:rwx mask::rwx other::--- default:user::rwx default:group::r-x default:group:пользователи\040домена:r-x default:group:gr_it:rwx default:mask::rwx default:other::---
Создадим теперь тем же пользователем еще одну папку test2 и проверим ее права.
# getfacl /mnt/shara/test2 # file: mnt/shara/test2 # owner: user # group: пользователи\040домена user::rwx group::--- group:пользователи\040домена:r-x group:gr_it:rwx mask::rwx other::--- default:user::rwx default:group::r-x default:group:пользователи\040домена:r-x default:group:gr_it:rwx default:mask::rwx default:other::---
Применилось наследование с вышестоящих папок. Не забывайте про дефолтные права и учитывайте их при настройке прав доступа на файловом сервере.
Для удобной и корректной работы с правами доступа я обычно для крупных, корневых директорий выставляю права аккуратно через setfacl в консоли. Какие-то мелкие изменения по пользователям и группам в более низших иерархиях директорий делаю через windows acl с какой-нибудь виндовой машины.
Еще важно знать одну особенность выставления прав доступа в linux. В моей практике часто требуется дать какому-нибудь пользователю доступ в одну директорию, которая располагается там, где у пользователя нет вообще никаких прав
В windows эта проблема решается просто — даются права на конкретную папку, а пользователю кладется ярлык на эту папку. В итоге он имеет доступ к нужной директории и больше никуда.
В linux так сделать не получится. Для того, чтобы дать таким образом доступ на отдельную директорию пользователю, необходимо, чтобы по всем вышестоящим директориям у него были права на исполнение, то есть X. Их придется выставлять вручную по всем вышестоящим папкам. Результат будет такой же, как и в винде — пользователь получит доступ на чтение только в указанную папку, но для этого придется выполнить больше действий. Если не знаешь этот нюанс, можно потратить много времени, прежде чем поймешь, в чем проблема.
Запуск и проверка сервиса sssd[править]
Если все настройки выполнены правильно, то после запуска сервиса sssd:
# service sssd start
будут доступны авторизационные данные для пользователя administrator:
# getent passwd administrator administrator:*:1310400500:1310400513:Administrator:/home/DOM.LOC/administrator:/bin/bash # id administrator uid=1310400500(administrator) gid=1310400513(domain users) группы=1310400513(domain users),1310400520(group policy creator owners),1310400519(enterprise admins),1310400512(domain admins),1310400518(schema admins),1310400572(denied rodc password replication group) # su - administrator $ whoami administrator $ pwd /home/DOM.LOC/administrator
Или для [email protected], если установлена опция use_fully_qualified_names = True:
# id [email protected] uid=1310400500([email protected]) gid=1310400513(domain [email protected]) группы=1310400513(domain [email protected]),1310400520(group policy creator [email protected]),1310400519(enterprise [email protected]),1310400512(domain [email protected]),1310400518(schema [email protected]),1310400572(denied rodc password replication [email protected])
Внимание! Если машина до этого была в других доменах или есть проблемы со входом пользователей рекомендуется очистить кэш sssd:
# systemctl stop sssd # rm -f /var/lib/sss/db/* # rm -f /var/lib/sss/mc/* # systemctl start sssd
Подключение файловых ресурсовправить
Рассматриваемые способы позволяют подключать файловые ресурсы (file shares) для доменного пользователя без повторного ввода пароля (SSO, Single Sign-On).
Настройка Ubuntu Server
1. Настройка локальной сети
Начнем работу с Ubuntu Server, для создания локальной сети между машинами необходимо отключить DHCP и настроить статический IP-адрес, и в настройках сети машины установить «Сетевой мост».
В данном случае установим IP-адрес сервера 10.0.0.100, имя хоста ubuntu.laba.local, домен laba.local
Для этого вводим следующие команды:
# su -
# nano /etc/network/interfaces
И вводим следующие данные:
Рис. 1. Файл /etc/network/interfaces
# nano /etc/hosts
Рис. 2. Файл /etc/hosts
# echo ubuntu.laba.local > /etc/hostname
# reboot
После перезагрузки сервера заходим в настройки «Виртуальной машины» и ставим в настройках сети «Сетевой мост».
Рис. 3. Настройки сети
# ping 10.0.0.100
2. Настройка сервера
Теперь можно приступить к основной работе с сервером, для начала выполним обновление
# apt-get update && apt-get upgrade -y
Для работы нашего домена нужно установить необходимые пакеты
# apt-get install git attr build-essential libacl1-dev libattr1-dev libblkid-dev libgnutls-dev libreadline-dev python-dev libpam0g-dev python-dnspython gdb pkg-config libpopt-dev libldap2-dev dnsutils libbsd-dev krb5-user docbook-xsl libcups2-dev acl ntp ntpdate winbind -y
Во время установки, нужно будет провести настройку аутентификации Kerberos:
Рис. 4. Настройка аутентификации Kerberos
Далее в окне ввода имени машины — вводим ubuntu. 3. Установка и настройка Samba
Скачаем Samba
# git clone -b v4-1-stable git://git.samba.org/samba.git samba4
# cd samba4
Настроим и произведем сборку Samba
# ./configure --enable-debug --enable-selftest
# make
# make install
Проверим правильность установки Samba, если версии Samba и клиента SMB одинаковые, то все установилось правильно.
# /usr/local/samba/sbin/samba -V
Version 4.1.23
# /usr/local/samba/bin/smbclient -V
Version 4.1.23
Теперь инициализируем наш контроллер домена, следующей командой:
# /usr/local/samba/bin/samba-tool domain provision --realm=laba.local --domain=LABA --adminpass="password" --server-role=dc --dns-backend=SAMBA_INTERNAL
Как пример пароля: DOMAINserver123.
Теперь запустим Samba в стандартном режиме.
# /usr/local/samba/sbin/samba
Проверка работы Samba как контроллера домена
# /usr/local/samba/bin/smbclient -L localhost -U%
Рис. 5. Вывод ответа на команду
Проверим работу аутентификации, подключившись к общей директории «netlogon», используя аккаунт администратора домена, который был создан во время настройки.
# /usr/local/samba/bin/smbclient //localhost/netlogon -UAdministrator -c ‘ls’
Рис. 6. Результат аутентификации
4. Настройка DNS Samba
Samba уже содержит в себе собственный полнофункциональный DNS сервер, он был инициализирован командой «—dns-backend=SAMBA_INTERNAL». Теперь настроим его:
# echo domain DOMAIN.LOCAL >> /etc/resolv.conf
# nano /usr/local/samba/etc/smb.conf
В данном файле установим dns forwarder = 8.8.8.8
5. Тестирование DNS
Настроенный DNS влияет на правильность работы с Active Directory. Без правильных записей DNS, Kerberos не будет работать, поэтому проверим правильность работы DNS
# host -t SRV _ldap._tcp.laba.local
# host -t SRV _kerberos._udp.laba.local
# host -t A ubuntu.laba.local
На данные команды должны выводиться следующие строки.
Рис. 7. Результаты команд
6. Настройка Kerberos
# nano /usr/local/samba/share/setup/krb5.conf
Меняем REALM на LABA.LOCAL
Рис. 8. Файл /usr/local/samba/share/setup/krb5.conf
7. Тестированине Kerberos
# kinit [email protected]
Рис. 9. Тестирование Kerberos
Отключим срок действия пароля, чтобы не возникло проблем в будущем.
# /usr/local/samba/bin/samba-tool user setexpiry administrator --noexpiry
Проверка получения билетов.
# klist -e
8. Создание директории пользователей
# mkdir -m 770 /Users
# chmod g+s /Users
# chown root:users /Users
# nano /usr/local/samba/etc/smb.conf
Дописываем в конце файла следующие строки:
Рис. 10. Файл /usr/local/samba/etc/smb.conf
1. Overview on realmd tool
RealmD is a tool that will easily configure network authentication and domain membership. With RHEL/CentOS 7, RealmD is fully supported and can be used to join IdM, AD, or Kerberos realms. The main advantage of using realmd is the ability to provide a simple one-line command to enroll into a domain as well as configure network authentication.
For example, realmd can easily configure:
- PAM Stack
- NSS Layer
- Kerberos
- SSSD
- Winbind
The realmd system supports the following domain types:
- Microsoft Active Directory
- Red Hat Enterprise Linux Identity Management
The following domain clients are supported by realmd:
- SSSD for both RHEL/CentOS Identity Management and Microsoft Active Directory
- Winbind for Microsoft Active Directory
Following table lists some of the most used realm commands:
Предоставление привилегий суперпользователя группе «Администраторы контроллера домена AAD»
Чтобы предоставить членам группы администраторов контроллера домена AAD права администратора на виртуальной машине CentOS, добавьте запись в /etc/sudoers. После добавления члены группы администраторов контроллера домена AAD могут использовать команду на виртуальной машине CentOS.
-
Откройте файл sudoers для редактирования:
-
Добавьте следующую запись в конец файла /etc/sudoers. Группа администраторов контроллера домена AAD содержит пробелы в имени, поэтому включите escape-символ обратной косой черты в имя группы. Добавьте собственное доменное имя, например aaddscontoso.com:
По завершении сохраните и закройте редактор с помощью команды редактора.
Заключение
На этом все. Я рассмотрел наиболее типовую ситуацию, которая может быть полезной при использовании структуры AD совместно с linux серверами. При написании статьи использовал официальные руководства:
- Deployment, Configuration and Administration of Red Hat Enterprise Linux 6
- sssd.conf — Linux man page
Почему-то из руководства по RHEL 7 раздел, посвещенный SSSD убрали, хотя в 5 и 6 есть. Может просто я не заметил, так как структура сильно поменялась. Люблю я CentOS в первую очередь за отличную документацию Redhat. Там есть подробное описание практически всего, с чем приходилось сталкиваться. Надо только не лениться в английском языке разбираться.
Онлайн курс по Linux
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Administrator Linux. Professional» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Что даст вам этот курс:
- Знание архитектуры Linux.
- Освоение современных методов и инструментов анализа и обработки данных.
- Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
- Владение основными рабочими инструментами системного администратора.
- Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
- Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.
Проверьте себя на вступительном тесте и смотрите подробнее программу по .