Аутентифікація та авторизація в домені 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 може працювати некоректно в тому випадку, якщо в конфігурації smb.conf діапазонidmap недостатньо великий. Хоча насправді ми не маємо необхідності отримувати повний список усіх груп і користувачів домену, а достатньо виконати перевірку для якоїсь однієї конкретної групи, наприклад, для доменної групи безпеки, яку ми спеціально створили для об'єднання адміністраторів серверів Linux…
…і для доменного облікового запису будь-якого користувача, який ми плануємо використовувати для входу на наш Ubuntu Server…
Створимо в каталозі домашніх папок користувачів підкаталог для доменних користувачів відповідно до налаштувань нашого smb.conf (як ім'я каталогу використовуємо NetBIOS-ім'я домену):
Перевіримо, що після встановлення бібліотеки libpam-winbind відповідні PAM-модулі для Winbind активовано.
Правимо файл /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 сприймає common-файли можна просто запустивши його і якщо щось йому не сподобається, він повідомить нам про це:
Якщо ж все-таки десь напортачили, то можна змуситиpam-auth-update виправити параметри common-файлів у їх вихідні значення, вибравши у вказаному повідомленніYes, або окремою командою:
Інші common-файли наводжу інформативно. У них ми редагувати вручну нічого не будемо, оскільки конфігураторpam-auth-update вже вніс усі необхідні редагування з посиланням наwinbind.
Після вказаних налаштувань перевіряємо вхід до системи, використовуючи облікові дані користувача домену AD. Як логін вказуємо доменний логін користувача (без доменної частини). При цьому перевіряємо, що в систему вдається увійти тільки тим користувачам, які включені в доменну групу безпеки KOM-SRV-Linux-Administrators. У разі виникнення проблем при вході слідкуємо за системним логом аутентифікації:
Помічено, що у випадку, якщо в домені AD у властивостях груп безпеки, членом яких є користувач, що аутентифікується, присутній непустий атрибутsIDHistory (група раніше була мігрована в поточний домен з іншого домену), то в процесі входу в Linux може з'являтися ряд повідомлень типу:
Ця ділянка скрипта використовується для банального виведення підказки про те, що для виконання адміністративних дій потрібно використовувати sudo . При цьому тут виконується перевірка членства користувача, що залогінився, в групах викликом утилітиgroups, яка у свою чергу при виклику в контексті доменного користувача намагатиметься повернути список доменних груп, до яких він входить. При цій операції використовуєтьсяWinbind, який має проблеми з читанням з домену AD груп, які мають непустий атрибут.sIDHistory.
Отже, ми вже маємо можливість локального та віддаленого (по SSH) входу на наш Linux-сервер, використовуючи обліковий запис користувача домену AD з обмеженням членства в доменній групі безпеки. Однак для виконання таким користувачем адміністративних дій в Linux-системі нам потрібно включити для цього користувача можливість виконання sudo . Найпростіше видати цей дозвіл не для конкретного користувача, а відразу для зазначеної доменної групи. Для цього нам потрібно внести зміни до системного конфігураційного файлу /etc/sudoers . Пряме редагування цього файлу не рекомендується, тому скористаємося спеціальним інструментомvisudo, який при збереженні файлу sudoers виконує його перевірку:
Наведу фрагмент файлу, в якому описуються групи доступу, що мають можливість виконуватиsudo (тут був доданий останній рядок фрагмента):
Після збереження файлу знову входимо в систему доменним користувачем і пробуємо виконати будь-яку командуsudo.
На цьому все. У наступній нотатці ми розглянемо процедуру налаштуванняSingle sign-on (SSO ) при підключенні до Linux-сервера на базіUbuntu Server 14.04 LTS за протоколомSSH з клієнтських комп'ютерів під керуваннямWindows