Удостоверяване и оторизация в домейна на Active Directory при свързване към Ubuntu Server LTS сървър

Както в предишните бележки по темата за интегриране на Linux в AD, в нашия пример домейн контролерите, работещи с Microsoft Windows Server 2012 R2, ще бъдат използвани като хранилище за потребителски и групови акаунти на домейн.

Инсталирайте плъгин за поддръжка наSamba4 (nss_winbind) иWinbind заPAM :

Проверяваме работата наKerberos, опитвайки се да получи билет за някой потребител на домейн.

Проверка за билет за Kerberos

Изчистване на кеша на билетите:

Конфигурацията по подразбиране наSamba4 за нови потребители е да се създаде домашна директория на потребителя с помощта на шаблона (template homedir ) /home// без обвивка (template shell ). Нека леко променим конфигурацията /etc/samba/smb.conf, като зададем параметър, описващ обвивката

Ново съдържание на smb.conf:

Моля, обърнете внимание, че в сравнение с конфигурационния файл, даден по-рано като пример, бяха добавени и редица други параметри, насочени не конкретно към нашата задача, а към оптимизиране на работата на процесите на Samba.

След като промените диапазонаidmap в smb.conf, добра идея е да нулирате кеша на Winbind:

За да влезете в новата конфигурация на smb.conf, рестартирайте услугите на Samba:

Добавяне на възможност за използване на Winbind към системния конфигурационен файл nsswitch.conf

Добавяме winbind към редоветеpasswd иgroup. Полученият файл ще изглежда така:

Уверяваме се, че следните команди връщат списък както с локални потребители, така и с групи и домейни:

Моля, имайте предвид, че при голям брой потребители и групи в домейна изходътgetent може да не работи правилно, ако диапазонътidmap в конфигурацията на smb.confне е достатъчно голям. Въпреки че всъщност не е необходимо да получаваме пълен списък на всички групи и потребители на домейна, но е достатъчно да извършим проверка за една конкретна група, например за група за сигурност на домейн, която специално създадохме, за да обединим администраторите на Linux сървъри ...

…и за всеки потребителски акаунт в домейна, който планираме да използваме за влизане в нашия сървър на Ubuntu…

Нека създадем поддиректория за потребители на домейн в директорията на домашната папка на потребителите в съответствие с настройките на нашия smb.conf (използваме името на домейна NetBIOS като име на директория):

Нека проверим дали след инсталирането на библиотеката libpam-winbind, съответните PAM модули за Winbind са активирани.

directory

Редактирайте файла /etc/pam.d/common-session. В края на файла добавете ред, определящ директивата за създаване на начална директория, ако не съществува:

Редактирайте файла /etc/pam.d/common-auth. В реда, описващ извикването pam_winbind.so, добавете допълнителен параметър require_membership_of, в който посочваме името на групата за сигурност на домейна. Тази група ще включва потребителите, на които искаме да разрешим влизане в нашия Linux сървър. Желателно е името на групата да се указва по начин, чувствителен към главни и малки букви, т.е. както е създадено в домейна на AD. Посочената група трябва да бъде група от глобален тип (с обхват в домейна на AD).

Също така имайте предвид, че не трябва да правите други промени в тези файлове освен посочените, дори прости, като промяна на отстъпите в съществуващите параметри. В противен случай ще загубим възможността да управляваме активирането/деактивирането на PAM модули чрез конфигуратораpam-auth-update. Проверете какpam-auth-update възприема общите-файлове, можете просто да го стартирате и ако нещо не му хареса, ще ни каже за това:

active

Ако въпреки това са се прецакали някъде, тогава можете да принудитеpam-auth-update да коригира параметрите на общия файл към техните оригинални стойности, като изберетеДа в посоченото съобщение или като използвате отделна команда:

Останалите общи файлове са информативни. Няма да редактираме ръчно нищо в тях, тъй като конфигураторътpam-auth-update вече е направил всички необходими промени с връзка къмwinbind.

След посочените настройки проверяваме влизането с помощта на потребителските идентификационни данни на домейна AD. Като вход, посочете потребителското име за влизане в домейна (без частта за домейна). В същото време проверяваме дали само онези потребители, които са включени в групата за сигурност на домейна KOM-SRV-Linux-Administrators, могат да влизат в системата. В случай на проблеми при влизане, ние наблюдаваме регистрационния файл за удостоверяване на системата:

Беше забелязано, че ако в домейна на AD в свойствата на групите за сигурност, на които членува удостовереният потребител, има непразен атрибутsIDHistory (групата е била мигрирана преди това към текущия домейн от друг домейн), тогава редица съобщения като:

Този раздел от скрипта се използва просто за показване на намек, че трябва да използватеsudo за извършване на административни действия. В същото време тук се проверява членството на влезлия потребител в групи чрез извикване на помощната програмаgroups, която от своя страна, когато се извика в контекста на потребител на домейн, ще се опита да върне списък с групи домейни, към които той принадлежи. Тази операция използваWinbind, който има проблеми с четенето на групи с непразен атрибут от домейна на ADsIDHistory.

И така, вече имаме възможността да влизаме локално и отдалечено (чрез SSH) в нашия Linux сървър, използвайки потребителски акаунт на AD домейн с ограничение за членство в групата за сигурност на домейна. Въпреки това, за да може такъв потребител да извършва административни действия на Linux система, трябва да разрешим на този потребител възможността да изпълняваsudo. Най-лесният начин би бил да издадете това разрешение не за конкретен потребител, а веднага за определената група домейн. За да направим това, трябва да направим промени в системния конфигурационен файл /etc/sudoers. Не се препоръчва директно редактиране на този файл, затова ще използваме специалния инструментvisudo, който проверява sudoers файла, когато е записан:

Ето фрагмент от файл, който описва групи за достъп, които могат да изпълняватsudo (последният ред на фрагмента е добавен тук):

След като запазим файла, влизаме отново като потребител на домейн и се опитваме да изпълним всяка команда сsudo.

Това е всичко. В следващата бележка ще разгледаме как да настроитеЕдинично влизане (SSO ), когато се свързвате към Linux сървър, базиран наUbuntu Server 14.04 LTS чрезSSH от клиентски компютри, работещи подWindows