Создание домена Active Directory в CentOS
Samba версии 4 позволяет создавать домены Active Directory с функциональностью, близкой к доменам на Windows. Уровень схемы соответствует Windows 2008 R2.
Из ограничений следует отметить отсутствие на данный момент поддержки Distributed File System (DFS) и невозможность установить ряд приложений, модифицирующих схему, напр., M$ Exchange.
Нужны дополнительные действия для репликации SYSVOL при 2-х или более КД.
Рассмотрим установку каталога Active Directory на 2-х контроллерах домена под управлением Samba 4, работающей на CentOS 7. Следует отметить, что в базовых репозиториях и EPEL пакет Samba не содержит необходимых для нас функций, поэтому потребуется ее сборка.
Ранее доступный на sernet'е (Enterprise Samba) бинарный RPM в свободном доступе доступен лишь в старой версии – по 4.2, новее – только по подписке. Мы же поставим текущую на момент написания статьи версию 4.5.3.
Отключать брандмауэр и SELinux, как рекомендуют во многих источниках, не нужно!
Перед началом желательно прочесть документацию
Setting up Samba as an Active Directory Domain Controller
Joining a Samba DC to an Existing Active Directory
Official Samba FAQ
AltLinux ActiveDirectory/DC
ArchLinux Samba 4 Active Directory domain controller
И после установки дополнительные материалы
Samba AD DC Port Usage
Rsync based SysVol replication workaround
Managing the Samba AD DC Service
Итак, приступим. 🙂
После установки выполняем обновление системы yum update, присваиваем статический адрес:
# nmcli c modify eth0 ipv4.method static ipv4.addresses 192.168.2.4/24# nmcli c modify eth0 ipv4.method static ipv4.gateway 192.168.2.254# nmcli c modify eth0 ipv4.method static ipv4.dns 192.168.2.254# systemctl restart network
Обязательно настройте синхронизацию часов, если это не было сделано в момент установки!
Устанавливаем полезные пакеты:
# yum install vim net-tools bash-completion virt-what screen mlocate
И необходимые для сборки^
# yum install wget perl gcc attr libacl-devel libblkid-devel gnutls-devel readline-devel python-devel gdb pkgconfig krb5-workstation krb5-libs krb5-devel zlib-devel setroubleshoot-server libaio-devel setroubleshoot-plugins policycoreutils-python libsemanage-python perl-ExtUtils-MakeMaker perl-Parse-Yapp perl-Test-Base popt-devel libxml2-devel libattr-devel keyutils-libs-devel cups-devel
bind-utils libxslt docbook-style-xsl openldap-devel autoconf python-crypto pam-devel
Загружаем исходники, распаковываем, запускам сборку
# wget https://ftp.samba.org/pub/samba/stable/samba-4.5.3.tar.gz# tar xzf samba-4.5.3.tar.gz# cd samba-4.5.3/# ./configure
# make
# make install
Сборка занимает порядка 10-20 минут на современном ЦПУ, на одном из старых потребовалось порядка 2-х часов.
Настройка Керберос
# mv /etc/krb5.conf /etc/krb5.conf.bak
# ln -sf /usr/local/samba/private/krb5.conf /etc/krb5.conf
Настраиваем 1-й контроллер в домене
# /usr/local/samba/bin/samba-tool domain provision –server-role=dc –use-rfc2307 –dns-backend=SAMBA_INTERNAL –realm= –domain= –interactive
Установка запустится в интерактивном режиме.
Проверка
# /usr/local/samba/bin/smbclient -L localhost -U%# /usr/local/samba/bin/smbclient //localhost/netlogon -UAdministrator -c 'ls'# host -t SRV _ldap._tcp.. localhost# host -t A ..# host -t SRV _kerberos._udp.. localhost# kinit administrator
# klist
# kdestroy
Внимание! При установке не создаются init скрипты или файлы служб systemd. Возьмите их на странице проекта.
После создания файла переопределите контексты SE Linux, напр., restorecon -F /etc/init.d/samba-ad-dc.
Настройка брандмауэра
Создайте файл настроек брандмауэра
vim /etc/firewalld/services/samba-addc.xml
Samba AD DC This option allows you to access and participate in Windows file and printer sharing networks. You need the samba package installed for this option to be useful.
<\p>
# firewall-cmd –reload
# firewall-cmd –permanent –add-service=ldap –add-service=dns –add-service=kerberos –add-service=kpasswd –add-service=ldap –add-service=ldaps –add-service=rsyncd –add-service=samba –add-service=samba-ad-dc
# firewall-cmd –reload
Вывод команды firewall-cmd –list-all должен дать примерно такое состояние
# firewall-cmd –list-allpublic (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: dhcpv6-client dns kerberos kpasswd ldap ldaps rsyncd samba samba-addc ssh ports: protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules:
Добавление объектов
Теперь уже можно подключаться к нашему домену графическими утилитами из ОС M$ Windows или использовать встроенные средства Samba
# /usr/local/samba/bin/samba-tool user create 'initPa$$word' –description='Фамилия Имя Отчество' –surname=Фамилия –given-name=Имя –initials=О –mail-address=Этот адрес электронной почты защищен от спам-ботов.
У вас должен быть включен JavaScript для просмотра.
–department='ИТ' –telephone-number=+71231234567 –userou='OU=allUsers' –must-change-at-next-login –physical-delivery-office='5 этаж' –company='ООО “Моя фирма”' –job-title=Специалист
Добавление 2-го контроллера
На 1-м контроллере сделайте копию ID mapping
# /usr/local/samba/bin/tdbbackup -s .bak /usr/local/samba/private/idmap.ldb
Остальные команды запускаются на 2-м контроллере
# /usr/local/samba/bin/samba-tool domain join DC -U”SIBMS42administrator” –dns-backend=SAMBA_INTERNAL
# mv idmap.ldb idmap.ldb.postinstall
# scp root@:/usr/local/samba/private/idmap.ldb.bak /usr/local/samba/private/idmap.ldb
После запуска по прошествии 10-15 минут проверьте состояние репликации
# /usr/local/samba/bin/samba-tool drs showrepl
При наличии 2-х и более контроллеров необходимо обеспечить механизм репликации SYSVOL. Самый простой способ использует rsync. Его ограничения – односторонняя репликация – изменения необходимо вносить только на “основном” КД, в противном случае изменения будут утеряны при очередной итерации.
Источник: http://megit.tk/index.php/80-os/linux/245-active-directory-domain-on-centos
PivPav Блог Пивоварова Павла
Сразу хочу предупредить, что данный пост скорее описание техничесской возможности хранения SSH ключей в Active Directory, и пошаговая рекомендация к тому как это сделать.
К сожалению я не нашел нормального описания данного механизма, и поэтому взялся описать то к чему пришел сам листая многочисленные статьи и документацию по SSH, AD и FreeIPA. Сразу скажу что никакого FreeIPA ставить не придется, а хранить сами ключи мы будем в поле Notes вкладки Telephones.
Потенциально нам ничего не мешает сделать отдельный атрибут в AD для этого, но я иду максимально простым путем.
Так как внутри нашей инфраструктуры установлен CentOS, то дружить с AD мы будем именно его.
Схема работы.
Схема работы проста, и достаточно очевидна, однако не вполне очевидна с точки зрения реализации. Итак по порядку
- Клиент инициирует подключение к SSHd при помощи ключа.
- Сервер SSHd проверяет корректность подключаемого пользователя при помощи SSSD (активный аккаунт, существующее имя, Allow|Deny листы)
- Сервер SSHd передает управление скрипту ldap_pubkey который возвращает в STDOUT содержимое аналогичное файлу authorized_keys. В нашем случае мы используем один публичный ssh ключ.
- Сервер предоставляет доступ, если имя пользователя и ключ верны.
Как видно все достаточно просто, поэтому приступим.
Установка и настройка SSSD.
Первым делом мы должны установить и настроить сервис sssd для авторизации наших пользователей при помощи AD
Дальше мы создаем файл /etc/sssd/sssd.conf примерно следующего содержания
[sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = domain.com [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] reconnection_retries = 3 [domain/domain.com] # Defaults debug_level = 0 cache_credentials = false enumirate = true # Providers id_provider = ldap auth_provider = ldap ldap_schema = ad ldap_id_mapping = true ldap_uri = ldaps://ad.domain.com:636 ldap_search_base = OU=Users,DC=domain,DC=com ldap_user_search_base = OU=Users,DC=domain,DC=com ldap_group_search_base = OU=Groups,DC=domain,DC=com ldap_tls_reqcert = allow ldap_idmap_range_min = 5000 # Fallback fallback_homedir = /home/%u shell_fallback = /bin/bash # AD mapping ldap_user_name = sAMAccountName ldap_user_object_class = user ldap_group_object_class = group # Bind auth ldap_default_bind_dn = [email protected] ldap_default_authtok = SecurePassword
Для того что бы сервис sssd запустился и позволял нам авторизовать наших пользователей необходимо выполнить следующие комманды
После этого сервис sssd будет перезапущен и мы можем проверять работает он или нет. Проверка достаточно простая
если мы видим подобный вывод (разумеется с реальным пользователем из AD) то значит что наш sssd работает. Я не буду тут подробно рассматривать как настраивать sssd, этому в сети посвящено огромное количество статей. Но дальше будет немного уличной магии.
Авторизация по ключу.
Итак, теперь наши пользователи из AD могут авторизоваться на нашем сервере используя свои логины и пароли. Но весь сырбор мы затеивали что бы пользователи могли авторизоваться используюя так же ssh ключ. Для этого ребята из RedHat пошли на определенную хитрость.
Как известно RedHat сейчас крайне озабочен вопросами централизации, и для этой цели выпустил два продукта RedHat IPA и FreeIPA для управления всем. Не вдаваясь в подробности FreeIPA это сочетание DNS, DHCP, Samba и LDAP, при этом активно автоматизированное при помощи говна и палок в виде скриптов на Python плюс вебморда.
Из коробки sssd прекрасно работает с FreeIPA, при этом принося в систему одну очень интересную утилиту sss_ssh_authorizedkeys.
Данный бинарник предназначен для демона sshd, который может вызывать его передавая в качестве ключа имя пользователя, а в замен бинарник лезет в FreeIPA LDAP, где забирает пользовательских SSH ключ или ключи, и выплевывает их в STDOUT.
В самом FreeIPA LDAP ключи хранятся в аттрибуте ipaSshPubKey, однако по быстрому выяснить что это за атрибут, какие параметры он содержит и тд и тп мне лично не удалось. Создание атрибута ipaSshPubKey в AD так же не помогло заставить этот бинарник заработать, поэтому я поступил проще – написал свой собственный скрипт на ruby, который делает ровно тоже самое – лезет в LDAP и выплевывает значение атрибута (в моем случае аттрибута info) в STDOUT. Итак ставим руби:
после этого можно создавать сам скрипт. Я создал его в /usr/bin/ldap_pubkey
#!/usr/bin/ruby require 'rubygems' require 'net/ldap' exit 0 if ARGV == [] username = ARGV[0] config = { :host => “ad.domain.com”, :port => 389, :username => “[email protected]”, :password => “SecurePassword”, :base => “OU=Users,DC=domain,DC=coml”, } 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 = [“info”] ldap.search(:base => config[:base], :filter => filter, :attributes => attributes ) do |entry| puts entry[:info].first end
сразу скажу что скрипт был написан на коленке, так как основная задача была проверить техничесскую возможность реализовать хранение ключей в AD. Тем не менее со своей задачей он справляется. Проверить его можно запустив, передав в качестве параметра имя пользователя
Если у пользователя в поле Notes был вписан ssh ключ – то вы его увидете.
Настраиваем SSHd.
Итак последний этап настройки – это SSH сервер.
Дело в том что по умолчанию сервер SSHd не умеет работать со сторонними программами для получения SSH ключей, однако ребята из RedHat пропатчили SSHd, на RHEL и Fedora (а значит и на CentOS), и в конфигурации /etc/ssd/sshd_config теперь есть параметр “AuthorizedKeysCommand none”. Нам его нужно раскоментировать и вписать туда наш скрипт, что бы получилось так
AuthorizedKeysCommand /usr/bin/ldap_pubkey
Но и это ещё не все. При первом логине домашняя дирректория пользователя не будет создана, поэтому нам нужно вписать ещё одну строчку в файл /etc/pam.d/sshd
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
Ну и на последок отключить SELinux, ну или сделать так что бы он не мешал созданию домашней дирректории.
В Active Directory.
Теперь дело осталось за малым – добавить ключ в AD. Для этого берем свой ключ
и копируем его в атрибут Notes вкладки Telephones пользователя как есть. Если хотите что бы ключей было несколько – копируйте несколько ключей, но каждый новый ключ с новой строки.
Теперь когда вы захотите попасть на сервер по SSH используя свой ключ вы увидете что при первом логине сервис SSHd создал домашнюю дирректорию пользователя.
На последок
Стоит пожалуй повторить что данная схема хотя и сырая, тем не менее вполне рабочая, и показывает каким образом можно хранить ключи SSH в AD. Думаю что многим это будет полезно, ну или хотя бы интересно.
В качетсве усовершенствования схемы можно добавлять отдельные атрибуты в AD, писать проверки в скрипт (сейчас их там одна), и полировать решение дальше.
Сейчас эта схема проходит тестовую обкатку в нашей организации, и я думаю что со временем я допишу тут более менее существенные замечания и изменения. Так что следите.
Источник: http://www.pivpav.com/post/166
Аутентификация Samba в домене Windows
Мы продолжаем серию статей про взаимодействие Linux и Windows.
Теперь мы рассмотрим задачу введения в домен Windows 2008R2 сервера с операционной системой CentOS Linux (версия 6.3). Как и в последних статьях, будем пользоваться штатными средствами, поставляемыми в составе дистрибутива операционной системы.
Но, в отличие от наших предыдущих статей, мы расширим задачу. Требуется организовать не только файловое хранилище на сервере под управлением CentOS Linux, но и обеспечить доступ доменных пользователей к командной и графической оболочке.
На сайте проекта CentOS можно найти информацию о настройке Samba, но эта информация касается, в основном, старых версий (CentOS 5) и охватывает небольшое количество примеров конфигурации.
Есть и другие материалы, посвященные настройке Samba для дистрибутива CentOS.
В процессе написания статьи и тестирования очень пригодилось подборка статей, опубликованных на сайте. Особенно полезными оказались следующие статьи (несмотря на то, что они опубликованы в марте–апреле 2007 года):
Для организации тестовой сети мы будем использовать виртуальную среду VMware VSphere 5, реализованную на базе архитектуры гипервизора ESXi. Эта среда активно используется в информационно-вычислительной сети МЭИ для размещения серверов и исследовательских работ.
Однако можно было бы воспользоваться и хорошо себя зарекомендовавшим Microsoft Hyper-V, а также любым другим аналогичным решением, в том числе и на основе свободного ПО, такого как гипервизор Xen или KVM.
Тестовая среда представляет собой доменную сеть на базе Active Directory (Active Directory Domain Services — AD DS), которая состоит из двух серверов инфраструктуры, работающих под управлением MS Windows Server2008 R2 EE, и одной клиентской машины — MS Windows 7 Professional. Используются IP-адреса из подсети 192.168.7.0/24.
- Наименование домена — LAB.LOCAL
- Сервер ForefrontThreat Management Gateway (TMG) 2010 — LAB-TMG.lab.local
- Клиент — LAB-CL1.lab.local
На контроллере домена LAB-DC1 установлены роли:
- cлужбы сертификации Active Directory (Active Directory Certificate Services — AD CS);
- доменные службы Active Directory (Active Directory Domain Services — AD DS);
- DHCP-сервер (Scope name: LAB.LOCAL; Address pool: 192.168.7.20–192.168.7.70);
- DNS-сервер (Type: AD-Integrated; Dynamic updates: Secure only);
- веб-службы (IIS).
Тестовая сеть и описания протоколов взаимодействия описаны в статье.
1.Требуемые пакеты
Мы устанавливаем минимально необходимый набор пакетов: рабочий стол Gnome (или другой оконный менеджер по выбору), базовый сервер и Samba. Нам потребуются:
- пакет krb5-workstation (версия не ниже 1.9), содержащий необходимые клиентские приложения для аутентификации на основе Kerberos;
- пакет oddjobmkhomedir (версия не ниже 0.30-5), предназначенный для автоматического создания каталогов пользователя при первом входе в систему;
- сам пакет Samba (версия не ниже 3.5-10), содержащий основные программы и пакет samba-winbind, отвечающий за соединение нашего сервера с контроллером домена.
2.Настройка DNS
Сначала необходимо настроить службу DNS. Это весьма важно, поскольку от корректного разрешения имен в сети зависит надежная работа нашей сети и сервисов Samba. Наш контроллер домена одновременно является и сервером DNS. Поэтому выберем в разделе Administrative Tools программу управления DNS и вручную введем имя и адрес нового сервера. На рис. 1 уже представлен результат.
Рис. 1. Задание имени и адреса в DNS.
Наш сервер DNS интегрирован с Active Directory. Можно проверить корректность прямого и обратного разрешения имен с использованием утилиты nslookup или host. Уточним: это нужно сделать обязательно, даже несмотря на то, что необходимая запись уже появилась на сервере DNS.
Нужно это сделать потому, что такая проверка — лишний тест работоспособности сети и корректности настроек. Проверка с помощью утилиты host выглядит так:
host 192.168.7.10 — определение имени по адресу, и
host test-centos.lab.local — определение адреса по имени.
В результате мы должны получить корректное разрешение имен в обоих случаях.
3.Настройка сетевого адаптера
Теперь этот IP-адрес (192.168.7.10) необходимо присвоить сетевому адаптеру вновь установленного сервера CentOS Linux. Воспользуемся пунктом меню System на рабочем столе и выберем пункт Network Connections (рис. 2).
Рис. 2. Настройка сетевого соединения.
В появившемся окне настроек зададим нужный IP-адрес. В результате мы должны получить следующее — см. рис. 3.
Рис. 3. Настройка сетевого соединения. Задание IP-адреса.
Наш сервер настроен с использованием менеджера соединений (Network Manager). Поэтому нужно обязательно отметить несколько опций:
- Connect automatically, что позволяет автоматически подключать сетевой адаптер.
- Available to all users, что разрешает пользоваться этим адаптером всем пользователям.
Можно настроить сетевое соединение вручную, отредактировав файл /etc/sysconfig/networking/devices/ifcfg-eth0, приведя его к виду, показанному на рис. 4.
Рис. 4. Настройка сетевого соединения. Файл настроек.
Ключевое слово NM_CONTROLLED разрешает или запрещает управлять соединением с использованием Network Manager. При любом способе настроек, следует установить IP-адрес сервера DNS. Это наш контроллер домена с IP-адресом 192.168.7.2.
Для применения настроек сетевого адаптера следует выполнить команду перезапуска:
/etc/init.d/network restart
4.Настройка времени
Как уже говорилось в предыдущих статьях, корректная настройка времени очень важна для работы Active Directory. Настроить время можно с использованием штатных средств системы (см. рис. 5).
Рис. 5. Настройка времени.
Но для того, чтобы полностью избежать проблем с рассинхронизацией часов, следует настроить службу времени (демон ntpd) на синхронизацию времени с контроллером домена (см. рис. 6).
Рис. 6. Настройка службы времени.
Для этого нужно отредактировать файл /etc/ntp.conf, указав в качестве сервера времени контроллер домена. Не забудьте настроить запуск демона ntpd с помощью команды chkconfig ntpd on и перезапустить его командой /etc/init.d/ntpd restart.
5.Проверка настроек
Произведя указанные настройки, следует проверить их корректность. Нужно протестировать соединение с контроллером домена, настройку времени, правильность прямого и обратного разрешения имен (см. рис. 7).
Рис. 7. Проверка настроек.
6.Настройка авторизации в домене
Теперь настала пора настроить членство нашего сервера в домене Windows. В отличие от предыдущих примеров, не будем отдельно настраивать LDAP и Kerberos. Постараемся настроить все сразу, используя утилиту командной строки authconfig, поставляемую в составе дистрибутива CentOS.
Authconfig позволяет настроить сразу все требуемые службы. При этом настраивать можно не только авторизацию в домене Windows 2008, но и использование LDAP, NIS и других способов аутентификации.
Более подробную информацию об утилите authconfig можно получить из встроенного руководства (man authconfig, онлайн-версия), либо из встроенного руководства, набрав в командной строке authconfig -help.
Достаточно будет сказать, что authconfig имеет около 50 опций настройки — представляете его возможности и, одновременно, сложности в настройке? Проще воспользоваться графическим интерфейсом к authconfig — утилитой system-config-authentication (рис. 8).
Эту утилиту можно вызвать из интерфейса администрирования системы, а можно и командной строкой. Причем второй вариант представляется предпочтительным, поскольку вывод диагностических сообщений будет происходить в окно терминала, что упростит поиск неисправностей.
Рис. 8. Вызов system-config-authentication.
В меню User Account Database можно выбрать место хранения списков пользователей и паролей. Возможными вариантами являются:
- локальная база данных паролей (файлы /etc/passwd и /etc/shadow);
- подключение к серверу LDAP;
- подключение к серверу NIS;
- использование Winbind — подключение к контроллеру домена Windows;
- использование IPAv2 — интегрированное решение, объединяющее LDAP, Kerberos, NTP, DNS и службу сертификатов.
IPAv2 позволяет авторизовать пользователей, рабочие станции, группы и вести политику управления сетевым доступом. IPAv2 позиционируется как решение, заменяющее NSSWITCH и PAM.
Более подробная информация представлена на http://www.freeipa.org/page/Main_Page.
Поскольку нашей задачей является авторизация в домене Windows, то в качестве User Account Database мы выбираем Winbind (рис. 9).
Рис. 9. Выбор User Account Database.
Необходимо указать основные параметры для authconfig. Windows Domain — это краткое наименование домена Windows 2008R2, то, которое используется в параметре workgroup файла конфигурации Samba (/etc/samba/smb.conf). О файле конфигурации Samba мы уже рассказывали в предыдущих статьях.
Security model устанавливается в ads, что соответствует значению параметра security в файле конфигурации Samba /etc/samba/smb.conf). Выбор security model = ads означает, что используются протоколы, совместимые со службами ADS Windows 2008R2.
Другие возможные значения security model:
- Domain — централизованная авторизация с использованием домена Windows 2000/2003;
- Server — используется в тех случаях, когда Samba не является членом домена, но использует централизованное хранение пользовательских аккаунтов и паролей на сервере;
- User — используется локальная база аккаунтов и паролей пользователей. При этом требуется не только пользовательский аккаунт, но и аккаунт рабочей станции.
Параметр Winbind ADS Realm аналогичен параметру REALM в файле конфигурации Samba и относится к настройкам безопасности Kerberos. Аналогичный параметр REALM указывается в файле настроек /etc/krb5.conf.
Поле Winbind Domain Controllers можно оставить пустым — имя контроллера домена определится из DNS.
Заполнять это поле следует, если по каким-то причинам служба DNS не может определить имя и IP-адрес контроллера домена.
Весьма интересен параметр Template Shell, указывающий, какая командная оболочка будет использована при регистрации доменного пользователя на нашем сервере CentOS Linux. Возможные значения командных оболочек перечислены в файле /etc/shells.
К этим значениям утилита system-config-authentication добавляет еще /bin/false, которое используется как значение по умолчанию. Если в качестве командной оболочки указать /bin/false, то доменным пользователям будет запрещен вход в систему. Параметр Template Shell аналогичен полю shell файла /etc/passwd в Linux.
Чтобы разрешить пользователям интерактивную работу в системе с использованием командной строки, этот параметр нужно установить в /bin/sh или /bin/bash.
Параметр Allow Offline Login позволяет нашему серверу CentOS Linux кэшировать пароли и, соответственно, авторизовать пользователей в случае недоступности контроллера домена.
Перейдем на вкладку Advanced Options, поскольку там есть некоторые интересующие нас параметры (см. рис. 10).
Рис. 10. Вкладка Advanced Options system-config-authentication.
На этой вкладке нас интересуют два параметра: Create home directories on the first login и Enable local access control.
Enable local access control позволяет нам указать правила регистрации пользователей на нашем сервере. Можно разрешить или запретить определенным пользователям регистрироваться с использованием терминалов или удаленных рабочих столов.
Это весьма удобно, если мы хотим, например, запретить пользователям подключаться через консольный терминал. Правила регистрации и их краткое описание содержатся в файле /etc/security/access.conf.
Параметр Create home directories on the first login позволяет снять с администратора обязанность создавать домашние каталоги для пользователей.
При указании этого параметра домашний каталог создается автоматически при первом входе пользователя в систему. Но необходимо проверить корректность наличия этой опции. В CentOS Linux за это отвечает модуль pam_oddjob_mkhomedir.so, который должен быть упомянут в файле /etc/pam.d/system-auth в строке session required pam_oddjob_mkhomedir.so skel=/etc/skel/ umask=0022.
Кроме того, домашний каталог для регистрации доменных пользователей на сервере Samba по умолчанию задается как /home/%D/%U. Это указывается параметром template homedir в файле настроек Samba. Если использовать значение по умолчанию, то администратору необходимо создать каталог /home/, где является кратким именем домена.
В нашем случае необходим каталог /home/LAB, в котором будут автоматически создаваться домашние директории пользователей.
Теперь вернемся на вкладку Identity & Authentication утилиты system-config-authentication и включим наш сервер в домен Windows 2008 R2.
Для этого нужно выбрать действие Join Domain и ввести имя администратора домена и пароль (рис. 11).
По нажатию кнопки OK, мы должны включить наш сервер в домен LAB.
Рис. 11. Указание имени и пароля администратора при вводе в домен.
Как видим, наш сервер Samba успешно включен в домен (рис. 12). Сообщение об этом появилось в окне терминала. Собственно, для этого сообщения мы и запускали system-config-authentication через командную строку в окне терминала. Если запускать через вкладку System, то сообщение о включении или невключении сервера в домен придется искать в файлах системных журналов.
Рис. 12. Включение в домен LAB.
После включения в домен в окне Authentication Configuration нажимаем кнопку Apply, и в окне терминала появляются сообщения о перезапуске Winbind и oddjobd.
Проверим включение нашего сервера в домен на контроллере (см. рис. 13).
Рис. 13. Проверка наличия в домене.
Мы видим, что наш сервер включен в домен под именем test-centos.
Теперь проверим возможность регистрации доменных пользователей на нашем сервере. Укажем доменного пользователя в ответ на приглашение о вводе имени на консоли сервера (рис. 14).
Рис. 14. Ввод имени доменного пользователя.
Как видно, имя пользователя указывается вместе с именем домена. По умолчанию разделителем является обратная косая «». Это значение можно изменить параметром winbind separator в файле настроек Samba. Выбрав кнопку Log In, получим приглашение ввести пароль. После ввода пароля получаем рабочий стол пользователя usertest (рис. 15).
Рис. 15. Рабочий стол доменного пользователя в CentOS Linux.
Таким образом, мы успешно решили задачу включения сервера CentOS Linux в домен Windows 2008 R2 и даже разрешили доменным пользователям обращаться к рабочему столу и командной строке Linux. Это дает пользователям домена дополнительные возможности использования различных операционных систем в сети предприятия.
7.Заключение
Данная работа выполнена на базе Информационно-вычислительного центра МЭИ.
Мы будем рады вашим замечаниям и предложениям. У нас есть возможности собрать тестовую сеть и отладить на ней различные варианты и конфигурации систем для обеспечения их взаимодействия.
Источник: http://www.pvsm.ru/linux/28588
Ввод samba сервера в домен Windows AD
Для того, чтобы ввести сервер Linux в домен AD, необходимо произвести настройку клиента Kerberos, Samba и Winbind. Произведем установку данных компонентов:
yum -y install krb5-user samba winbind ntp samba-winbind samba-winbind-clients pam_krb5
Производим настройку DNS Необходимо настроить DNS сервер Linux машины таким образом, чтобы основной DNS сервер был точно таким же как и на доменном контролере и в качестве домена указать название домена. (название домена прописывается маленькими буквами). За данные параметры в системе отвечает файл
/etc/resolv.conf
но в современных Linux машинах файл создается автоматически и редактирование его в ручную изменит параметры только до ближайшей перезагрузки. Для добавления необходимых параметров в данный файл необходимо изменить соответствующие директивы в файле для нужного интерфейса в каталоге:
/etc/sysconfig/network-scripts/ifcfg-«название сетевого интерфейса»
если используется DHCP, то все необходимые параметры будут получены с сервера. В итоге файл /etc/resolv.conf должен иметь примерный вид:
search domain.com nameserver 192.168.0.1
nameserver 192.168.0.2
Далее нужно указать доменное имя сервера локальной машины в файле /etc/hosts: # Имена этого компьютера
127.0.0.1 localhost
127.0.1.1 smbsrv.domain.com smbsrv
Проверяем доступность доменного контролера:
ping dc
ping dc.domain.com
Перезагружаем сервер для вступления изменений.
Настраиваем синхронизацию времени Если разница во времени будет больше 5 минут со временем доменного контроллера, сервер не сможет получить лист от Kerberos. Для проверки времени можно использовать команду:
net time set domain.com
если же в сети присутствует сервер точного времени:
ntpdate ntpservername
Для автоматической синхронизации времени сервера с сервером времени в сети необходимо добавить в файл /etc/ntp.conf дрективу:
server ntpservername
Перезагружаем службу ntpd:
systemctl restart ntpd
Настраиваем авторизации через Kerberos
Для настройки авторизации в домене через протокол Kerberos необходимо внести в файл /etc/krb5.conf следующие директивы:
[libdefaults] default_realm = DOMAIN.
COM kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true v4_instance_resolve = false v4_name_convert = { host = { rcmd = host ftp = ftp } plain = { something = something-else } }
fcc-mit-ticketflags = true
[realms] DOMAIN.COM = { kdc = dc kdc = dc2 admin_server = dc default_domain = DOMAIN.COM
}
[domain_realm] .domain.com = DOMAIN.COM domain.com = DOMAIN.COM [login] krb4_convert = false
krb4_get_tickets = false
Важное замечание: необходимо соблюдать регистр букв в названии домена. Проверяем авторизацию в домене:
kinit [email protected]
Команда при успешном выполнении не выдает никаких сообщений. Чтобы проверить получен ли билет от домена для Kerberos, необходимо выполнить следующую команду:
klist
Источник: https://raw73.wordpress.com/linux/smb_ad/
Ввод 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/[email protected].
Ограничение доступа ssh по группам и пользователям домена
На текущий момент подключиться к серверу может любой пользователь домена. Исправим это и разрешим подключаться только пользователям из группы gr_linux_adm. Для этого правим конфиг /etc/sssd/sssd.conf, добавляя туда новые параметры.
# mcedit /etc/sssd/sssd.confaccess_provider = simple simple_allow_users = [email protected] simple_allow_groups = [email protected]
Обращаю внимание, что параметр 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%[email protected] 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. Там есть подробное описание практически всего, с чем приходилось сталкиваться. Надо только не лениться в английском языке разбираться.
Помогла статья? Есть возможность отблагодарить автора
Дополнительные материалы по CentOS
| Рекомендую полезные материалы по CentOS: |
| Установка CentOS 7 в конфигурации minimal или netinstall с загрузочной флешки или по сети на диск или raid раздел.Базовая настройка CentOS 7 для работы с любым функционалом. Приведены практические советы по улучшению безопасности и удобства администрирования.Как установить точное время на сервере CentOS, настроить часовой пояс, синхронизировать время с помощью ntpdate и ntpd и другое.Подробное описание настройки сети в CentOS 7 – задать ip адрес, dhcp, отключить ipv6, dns, hostname, статические маршруты и др. |
| Подробное описание настройки прокси сервера на базе CentOS 7 со связкой squid+AD+sams2, реализован запрет доступа по url и группам пользователей.Описание установки и настройки asterisk – популярной современной sip атс. Описан расширенный функционал, покрывающий большинство потребностей стандартного офиса в современной телефонии.Установка и настройка высокопроизводительного web сервера на базе nginx и php fpm. В качестве кэша используется APC. |
| Настройка DNS сервера BIND (Named) в CentOS 7. Рассмотрены наиболее популярные конфигурации, в том числе подробное логирование.Установка Unison в CentOS 7 для двухсторонней синхронизации файлов.Настройка сервера для централизованного сбора логов с удаленных устройств и серверов с помощью программы syslog-ng. |
Источник: https://serveradmin.ru/vvod-centos-7-v-domen-active-directory-i-avtorizatsiya-po-ssh-domennyih-polzovateley/
Как присоединить серверы 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 –[email protected] yallalabs.local Password for [email protected]:
— Если вы хотите добавить его в назначенный организационный блок в Active Directory, вам сначала необходимо создать подразделение или, по крайней мере, обеспечить его существование.
Следующей командой мы присоединяем сервер к домену AD и добавим учетную запись компьютера в подразделение Linux:
# sudo realm join –[email protected] –computer-ou=OU=Linux,OU=Servers,DC=YALLALABS,DC=LOCAL yallalabs.local Password for [email protected]:
Если у вас есть эта ошибка:
” 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: %[email protected] login-policy: allow-realm-logins
— Чтобы отобразить информацию о пользователе из домена, выполните следующую команду:
# id [email protected] uid=344601106([email protected]) gid=344600513(domain [email protected]) groups=344600513(domain [email protected]),344601107([email protected])
— Чтобы разрешить вход в систему только определенным учетным записям из домена, используйте следующую команду:
эта команда изменит режим, чтобы разрешить доступ только к учетным записям по определенным учетным записям, а затем добавить указанные учетные записи в список разрешенных
# realm permit [email protected] [email protected]
— Чтобы разрешить только одной группе Active Directory используйте следующую команду: в этом примере мы разрешим группе ADAD LinuxAdmins войти в систему
# realm permit -g [email protected]
— Чтобы предоставить разрешения sudo для группы Active Directory, в этом примере мы добавим группу ADAddins ActiveWorks в sudoers, запустив команду visudo и добавив следующую строку:
# visudo %[email protected] ALL=(ALL) ALL
— Чтобы покинуть домен Active Directory, вы можете использовать следующую команду:
# realm leave –user=–[email protected] yallalabs.local
— Если вы хотите покинуть домен и удалить учетную запись компьютера, вы можете использовать дополнительный параметр -remove в конце команды
Источник: http://itisgood.ru/2018/07/13/kak-prisoedinit-servery-centos-7-rhel-7-k-domenu-active-directory/
добавление RHEL (CentOS) 5 сервера в домен Active Directory
Вдосталь наэксперементировавшись с openLDAP и 389 Directory Server, всё-таки решил остановиться на Active Directory от Microsoft для централизованного управления моим зоопарком из Windows и RHEL серверов.
Если ввод в домен рабочей станции или сервера Windows довольно тривиальная задача, то присоединение к домену Linux системы оказалось не на много сложнее 🙂 Прогресс не стоит на месте, Red Hat приложила (да и Microsoft тоже) немело усилий для безпроблемного сосуществования и взаимодействия различных операционных систем. В качестве примера возьмем сервер с RHEL 5.
6 на борту с именем server01 и заведем его в Active Directory домен ACME.LOCAL Для начала проверяем что в имени машины присутствует имя домена
[root@server01 ~ ] vim /etc/sysconfig/network
HOSTNAME=server01.acme.local если нет – правим файл и, затем, выполняем команду
[root@server01 ~ ] hostname server01.acme.local
Указываем короткое и полное имя этого сервера
[root@server01 ~ ] vim /etc/hosts
127.0.0.1 server01 server01.acme.local localhost localhost.localdomain Важный момент: прописываем IP нашего контроллера домена как DNS сервер
[root@server01 ~ ] vim /etc/resolv.conf
nameserver 192.168.1.1 Далее необходимо синхронизаровать системное время между сервером и контроллером домена. Правим конфигурационный файл службы точного времени:
[root@server01 ~ ] vim /etc/ntp.conf
добавляя строку:
server dc.acme.local
здесь – dc.acme.local – это имя контроллера домена для ACME.LOCAL. Время должно быть синхронизировано для корректной работы службы Kerberos
Настраиваем службу времени на запуск при старте системы
[root@server01 ~ ] chkconfig ntpd on
и запускаем ее:
[root@server01 ~ ] service ntpd start
Ставим клиент Samba 3.3
[root@server01 ~ ] yum install samba3x samba3x-common samba3x-client
Можно использовать Samba 3.0 который идет в поставке RHEL версии 5.4 и ранее, но для домена на основе Windows Server 2008 R2 рекомендуется использовать samba-3.3. В моем случае это позволило побороть сообщения в журнале /var/log/messagesА теперь самая магия.
Запускаем нижеследующую команду одной строкой либо с обратными слешами:
[root@server01 ~ ] authconfig –update –kickstart<\p>
–enablewinbind
–enablewinbindauth
–smbsecurity=ads
–smbworkgroup=ACME
–smbrealm=ACME.LOCAL
–smbservers=DC.ACME.
LOCAL
–smbidmapuid=10000-20000
–smbidmapgid=10000-20000
–winbindtemplatehomedir=/home/%U
–enablemkhomedir
–winbindtemplateshell=/bin/bash
–enablewinbindusedefaultdomain
–enablelocauthorize
–enablekrb5
–krb5realm ACME.LOCAL
–krb5kdc DC.ACME.LOCAL
–krb5adminserver DC.ACME.
LOCAL Эта команда вносит все необходимые изменения в конфигурационные файлы системы:
* настраивает клиент Kerberos /etc/krb5.conf
* добавляет службу winbind в /etc/nsswitch.conf для passwd, shadow и group
* изменяет должным образом /etc/samba/smb.conf на работу в домене
* стартует службу winbind позволяет которая обмениваться информацией с NT системами
Переходим к инициализации клиента Kerberos (пакет krb5-client обычно уже установлен)
сбрасываем кэш сессий
[root@server01 ~ ] kdestroy
Создаем новый кеш, указывая имя доменного администратора и вводим его пароль по запросу
[root@server01 ~ ] kinit administrator
Если всё прошло без ошибок, то закешированый Kerberos-тикет можно просмотреть командой
[root@server01 ~ ] klist
Вот теперь настал момент добавления нашего сервера в домен:
[root@server01 ~ ] net ads join -U administrator Должно появится поле ввода пароля для администратора домена [email protected] После ввода которого и при корректной настройке система сообщит об успешном завершении операциии стартуем winbind
[root@server01 ~ ] service winbind restart
Если что-то не получается, для начала надо проверять подключение к DNS и логи winbind. На этом настройка завершена. В Active Directory появилась учетная запись server01 в “Domain Computers”, можно подлключаться по SSH, используя учетные записи пользователей домена.
Источник: http://iamfm.blogspot.com/2011/07/rhel-centos-5-active-directory.html
Загрузка...
