Въвеждане на CentOS 7 в домейн на Active Directory и SSH авторизация на потребителите на домейна
Подготовка на сървъра
Ако все още нямате готов сървър, тогава можете да използвате моите материали по тази тема - инсталиране и конфигуриране на centos 7. Също така препоръчвам да настроите iptables за сървъра да работи правилно с домейна на Windows. Освен това няма да засягам този въпрос, просто ще деактивираме защитната стена, тъй като нейната конфигурация не е темата на тази статия.
Настройте синхронизация на времето с домейн контролера. Това е важно, трябва да имате едно и също време с домейн контролера. Проверете го и се уверете, че часовите зони са еднакви.
Инсталирайте помощната програма за синхронизиране на времетоchrony :
Запазваме конфигурацията, стартираме chrony и я добавяме към автоматично зареждане.
Нека проверим това със синхронизацията.
Всичко е наред. Синхронизирано време с домейн контролера. Дневникът показва, че времето на сървъра е изпреварило с 56 минути, но ние го поправихме.
Свързване на CentOS 7 към домейн
Инсталираме софтуера, от който се нуждаем, за да въведем правилно centos в домейна на windows.
Въвеждаме Centos 7 в домейна:
Ако не получите никаква грешка, значи всичко е минало добре. Можете да отидете до домейн контролера и да проверите дали нашият linux сървър се е появил в домейна. Нека променим малко конфигурацията наsssd, така че да не е необходимо да въвеждате пълното име на домейн, когато влизате, а само потребителско име.
Позволете на потребителите на домейна да създават домашни директории:
Стартирайте услугата sssd и добавете към стартирането:
Ограничаване на ssh достъпа от групи и потребители на домейн
В момента всеки потребител на домейн може да се свърже със сървъра. Нека поправим това и позволим само на потребители от групатаgr_linux_adm да се свързват. За да направите това, редактирайте конфигурацията /etc/sssd/sssd.conf, като добавите нови параметри там.
рисувамимайте предвид, че параметърът access_provider вече ще бъде зададен на различна стойност. Трябва да променим това. Можете да добавите разрешение за конкретен потребител или цели групи. Запазете конфигурацията и рестартирайте sssd.
Сега само потребителят на домейна user55 и всички членове на групата gr_linux_adm могат да се свързват чрез ssh към сървъра.
За разбор и разрешаване на проблеми трябва да използвате лог файла - /var/log/secure. Ето пример за успешна връзка:
И ето част от регистрационния файл на потребителската връзка на домейна, за който достъпът през ssh е затворен.
Тук можете да видите, че идентификацията на потребителя е правилна, но достъпът до сървъра е отказан.
Ограничаване на достъпа до sudo по домейн групи
Ограничаването на достъпа до ssh от групи и потребители е конфигурирано, сега трябва да разрешите на акаунтите на домейни да получат права на суперпотребител в системата. Сега те нямат тази възможност.
Създайте нов файл в директорията /etc/sudoers.d.
Задайте минималните разрешения за файла:
Вече можете да влезете в системата с домейн акаунт от групата gr_linux_adm и да получите пълни права в системата.
Възможно е да се приложи същото чрез настройките на sssd. В неговата конфигурация беше възможно да се посочат групи, на които е разрешен достъп до sudo. Но като цяло това не е важно. Както го направих, ми се стори по-лесно. Няма нужда да използвате пълните имена на обекти в AD, които лесно се объркат, особено за тези, които не са много запознати с това. Трябваха ми само крайните имена на групите. Можете да прочетете повече за това в ръководството на redhat. Ще дам линк накрая.
Заключение
Това е всичко. Обхванах най-честата ситуация, която може да бъде полезна при използване на AD структура с linux сървъри. ПриКогато писах тази статия, използвах официалните ръководства:
По някаква причина разделът за SSSD беше премахнат от ръководството за RHEL 7, въпреки че е в 5 и 6. Може би просто не съм забелязал, защото структурата се е променила много. Обичам CentOS на първо място заради отличната документация на Redhat. Има подробно описание на почти всичко, с което трябваше да се справя. Необходимо е само да не бъдете мързеливи на английски език, за да разберете.
Онлайн курс "Linux Administrator"
Да, изглежда, че и тук няма нищо сложно. Всичко се прави много бързо и лесно. Отнема много време за ровене с winbind и sssd просто го пренася в домейна и всички системни конфигурации се управляват.
Мил. Защитната стена беше деактивирана, но нито дума за SELinux. Или той "не пречи" в случая?
“Authentication - идва от английската дума authentication, която може да се преведе като идентификация или удостоверяване. Това напълно отразява същността на процеса - удостоверяване на потребителя, т.е. трябва да сме сигурни, че потребителят, който се опитва да получи достъп до системата, е този, за когото се представя.
Въвеждам командата: # realm discover LOCAL.DOMAIN.RU local.domain.ru type: kerberos realm-name: LOCAL.DOMAIN.RU domain-name: local.domain.ru configured: no server-software: active-directory client-software: sssd required-package: oddjob изисква d-пакет: oddjob-mkhomedir необходим-пакет: sssd необходим-пакет: adcli необходим-пакет: samba-common-tools
Опитвам се: # realm join -U администратор LOCAL.DOMAIN.RU Вижте: journalctl REALMD_OPERATION=r5497964.10339 realm: Не може да се присъедини към realm: Присъединяването към домейна local.domain.ru е неуспешно
Опитвам с регистрационни файлове (-v): # realm join -v -U администратор LOCAL.DOMAIN.RU * Разрешаване: _ldap._tcp.local.domain.ru *Performing LDAP DSE lookup on: 192.168.102.8 * Successfully discovered: local.domain.ru Password for administrator: * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net * LANG=C LOGNAME=root /usr /bin/net -s /var/cache/realmd/realmd-smb-conf.KAEP3Y -U administrator ads join local.domain.ru Enter administrator’s password: Failed to join domain: failed to lookup DC info for domain ‘local.domain.ru’ over rpc: The specified I/O operation on %hs was not completed before the time-out period expired. ! Присъединяването към домейна local.domain.ru е неуспешно realm: Не може да се присъедини към realm: Присъединяването към домейна local.domain.ru е неуспешно
Отметнато решение: [root@siteadmin
]# getent hosts local.domain.ru awk ‘< печат $1 >' 192.168.106.5 192.168.101.4
Пинг не може да става, но компанията казва, че са деактивирали възможността за пинг от страна на сървъра (но все още ме обърква).