12. Основи DNS ч.1
Перш ніж почати розбирати DNS – систему доменних імен – слід зрозуміти, що таке «домен». Загалом під доменом можна розуміти область, зокрема - область імен. І це зав'язано під ієрархію.
Все як із директоріями у лінуксі. Є коренева директорія. Аналог - кореневий домен:
У кореневій директорії є інші директорії, наприклад home, bin, usr і т.д.. У кореневому домені є інші домени, наприклад, com, ru, org і т.п. - вони називаються доменами першого рівня:
У директорії /home є інші директорії, наприклад user1. У домені com є інші домени, наприклад, google. Це домени другого рівня:
/home/user1 .com.google
У директорії user1 є файли, наприклад file1. У домені google є імена, наприклад, drive:
/home/user1/file1 .com.google.drive
Замість file1 могла бути інша директорія з іншими піддиректоріями, а всередині drive могли бути домени четвертого рівня тощо за тією ж логікою.
Щоправда доменні імена прийнято писати навпаки, тобто. спочатку домени третього рівня, потім другого, потім першого. Ну а кореневий домен практично ніде не пишуть, окрім як у налаштуваннях dns серверів:
У цій адресі, умовно, drive – ім'я хоста, google.com – домен. А drive.google.com називається повним доменним ім'ям або fqdn. Правда за цією адресою стоїть безліч серверів і тому не зовсім правильно говорити, що drive - це ім'я хоста.
Якщо спробуємо пінганути цю адресу:
ping drive.google.com
ми побачимо, що він посилається на інший. І навіть це не факт, що адреса хоста, але не будемо поки що лізти в такі нетрі.
І щоб усі ці області імен були не лише на словах, а справді працювали, існує система доменних імен – DNS. Те, що DNS використовується для перетворення імен в IP адреси ви вже знаєте.Ви знаєте ім'я, ви знаєте адресу DNS сервера, DNS сервер знає, яка адреса стоїть за цим ім'ям і використовуючи таблицю маршрутизації ви можете дістатися до цільового сервера.
Але функції DNS цим не обмежуються. Щоб розібратися, чим займається ця система доменних імен нам потрібно поговорити з нею її мовою. І в цьому нам допоможе утиліта nslookup. Але перш ніж почнемо, трохи згадаємо про саму утиліту.
У найпростішому варіанті, якщо просто передати їй ім'я:
nslookup google.com
ми побачимо адресу сервера, який нам відповів, а також адресу, яку ми запросили. У даній відповіді їх дві: перша - IPv4 адреса, друга - IPv6.
У моїй домашній мережі DNS сервером виступив мій роутер. Більшість домашніх роутерів мають і DNS сервер, і DHCP сервер. Який при видачі адрес серед dhcp опцій вказує DNS сервером себе. Звичайно, DNS сервер на вашому роутері не знає всі адреси у світі, він лише перенаправляє ваші запити на інші сервери DNS (рекурсивний DNS сервер). Іноді у молодих фахівців формується помилкова думка, що можна вказати як DNS сервер будь-якої gateway в будь-якому місці. Але це помилка через багатофункціональність домашніх роутерів, де просто на роутері є сервер DNS.
Можемо запитати адресу іншого DNS сервера, просто вказавши його в команді nslookup:
nslookup google.com 1.1.1.1
Як бачите, тепер адреса DNS сервера інша і відповідь за адресами теж відрізняється. Те, що відповідь інша - нічого дивного, тому що за гуглом стоїть безліч адрес.
Так ось, щоб зрозуміти DNS, потрібно поговорити з ним його мовою. Ця мова складається із записів та їх типів.
Те, що DNS сервер нам відповідав до цього - тобто. видавав IP адресу google.com – це був тип запису А – адреса. Додамо до команди nslookup опцію type=A:
nslookup -type=A google.com
Відповідь, яку ми бачимо - це запис DNS.
Пам'ятаєте, ми бачили IPv6 адресу? У неї інший тип - 4А (АААА):
nslookup -type=AAAA google.com
Тобто.у DNS є різні типи записів і виконують різні завдання, тим самим координально розширюють завдання DNS сервера. Наприклад, А запис дозволяє визначити, яка IP адреса стоїть за таким ім'ям. У той же час MX запис дозволяє знайти адресу поштового сервера, не знаючи ні імені, ні адреси.
І щоб зрозуміти, як це все пов'язано і в чому основна суть DNS нам потрібен один тип запису - SOA - start of authority:
nslookup -type=SOA google.com
Російською це перекладають як «початковий запис зони», але це переклад не подобається, оскільки він передає головну ідею - авторитет. Під авторитетом я маю на увазі когось, у кого є повноваження і до кого є довіра.
Уявімо собі банківську організацію. Умовно, ви приходите до банку, хочете відкрити рахунок та покласти гроші. По суті, ви передаєте свої гроші якійсь людині, яку ви бачите вперше в житті. Але ви розумієте, що це працівник банку, а у вас є певна довіра до банку. Якщо загалом простежити ланцюжок, є якась найвища точка, умовно, центробанк. Центробанк довіряє вищому керівництву якогось банку, вище керівництво довіряє своїм підлеглим менеджерам, менеджери довіряють своїм працівникам. А ви, своєю чергою, довіряєте працівникам банку. Ці працівники можуть абсолютно різними завданнями займатися – хтось грошові перекази робить, хтось кредити видає тощо. Тобто. послуги можуть бути різні і все пов'язано на тому, що є авторитет, який підтверджується ланцюжком повноважень і довіри.
У цьому й суть DNS. Типи записів – це типи послуг. Так, кінцеві користувачі звертаються до сервера DNS за цими послугами, але всі ці послуги так чи інакше пов'язані на авторитеті. Ці повноваження та довіра поширюються не на все довкола, а лише на обмежену область, яка називається зоною. Тобто. є авторитет, який відповідає за якусь зону. Наприклад, ви не знаєте IP адреси гугла - але довіряєте його серверам DNS, які і повідомляють вам потрібну адресу.Або, скажімо, ви не знаєте, який поштовий сервер у такого домену - DNS сервер вам підкаже і ви цьому довіритеся. зоні. І потім google перевіряє наявність цього запису. побачив у вашій зоні.
Повернемося до SOA запису:
nslookup -type=SOA google.com
У цьому запиті ми запитуємо, хто є авторитетною особою зони google.com. У відповіді ми бачимо, що головним DNS-сервером цієї зони є ns1.google.com. Так, у самому записі замість собачки - точка, але насправді це собачка, просто так склалося, що пишуть крапку. Далі йде трохи технічної інформації. для інших DNS серверів, до неї ми ще повернемося, а поки що опустимо такі деталі.
Ще варто звернути увагу на запис «Non-authoritative answer» - тобто відповідь, яку ми отримали, не є авторитетною. Ви довіряєте співробітникові, і банк Інша справа ви просите когось піти в банк замість вас. кине, банк тут не до чого. І google.com тут не до чого, тому ви бачите, що ця відповідь не від авторитетного джерела, а від когось третього. А авторитетні джерела - ті хто відповідають за зону google.com нижче: ns1.google.com, ns2.google.com і т.д.
Тобто, якщо запитати інформацію безпосередньо у авторитетного джерела:
nslookup -type=SOA google.com ns1.google.com
такого попередження не буде.
Найчастіше авторитетні сервери не відповідають за інших і не спрямовують на інші зони:
nslookup -type=SOA pikabu.ru ns1.google.com
Як бачите, тут пишеться refused.сервер ns1.google.com відмовився надсилати мій запит на інші сервери, щоб видати відповідь, тобто. він не рекурсивний. Хоча рекурсивні та авторитетні DNS сервери можна поєднувати, коли це стосується публічних адрес та інтернету – їх поділяють.
Умовно, у вас є домен і ви хочете підняти авторитетний сервер для користувачів з інтернету, щоб вказував на ваш вебсайт і поштовий сервер. Не варто використовувати цей сервер як рекурсивний. Оскільки ваш днс сервер будь-які роботи почнуть використовувати для DDOS атак на інші сервера, тобто. будуть використовувати сервер для запитів на інші сервери, щоб навантажити їх і зробити недоступними. DNS сервера - один із найпопулярніших векторів атак. Також у публічних серверів завжди є ризик злому і будь-якими атаками можуть нашкодити вашим локальним користувачам, які використовують цей сервер як рекурсивний.
На цьому місці я хотів би показати різницю між доменами та зонами. Грубо кажучи, домени – це про області імен, а зони – це про те, хто відповідає і як це технічно реалізовано.
Наприклад, є домен yandex.ru:
nslookup -type=SOA yandex.ru
У нього авторитетним DNS сервером є ns1.yandex.ru, а адресою адміністратора – [email protected].
А є домен cloud.yandex.ru:
nslookup -type=SOA cloud.yandex.ru
У нього головним DNS сервером є ns3.yandex.ru та адреса адміністратора інший – [email protected]. cloud.yandex.ru знаходиться в домені yandex.ru, але зона - інша. Тобто. умовно є якась організація, вона має якісь підрозділи. Різні підрозділи адмініструють різні люди. І щоб вони могли додавати будь-які записи в рамках свого піддомену, можна наділити їх авторитетом цієї зони. Це називається делегування домену. Делегування домену працює через NS записи, які вказують на сервер DNS.
Як приклад давайте подивимося ланцюжок, хто відповідає за зону і кому делегує наступну. Почнемо з кореневої зони:
За кореневу зону відповідають кореневі сервери DNS. Про них можна почитати в інтернеті, раджу у вільний час ознайомитись.
А ми беремо будь-який із кореневих DNS серверів і шукаємо там запис NS, що веде на домен першого рівня ru:
nslookup -type=NS ru. c.root-servers.net
Так ми знаходимо DNS сервери, які містять інформацію про цю зону.
Потім спитаємо у будь-якого з них, хто відповідає за зону ru:
nslookup -type=SOA ru. f.dns.ripn.net
Інші сервери теж відповідають, але головним вважається сервер із літерою а.
Підемо далі і запитаємо у цих серверів, хто містить інформацію про домен yandex.ru:
nslookup -type=NS yandex.ru. a.dns.ripn.net
Наприклад, сервер ns1.yandex.RU.
Подивимося, хто відповідає за зону yandex.ru:
nslookup -type=SOA yandex.ru. ns1.yandex.RU.
Ну, це ми вже бачили, коли дивилися про cloud.yandex.ru.
Ну і з сервера ns1.yandex.ru подивимося, який NS сервер делегований cloud.yandex.ru:
nslookup -type=NS cloud.yandex.ru. ns1.yandex.RU.
Так влаштовано структуру DNS. Крім SOA, NS і A записів є інші, але їх ми розберемо наступного разу.
Питання – а де дістати домени? Для внутрішньої мережі можна використовувати один із виділених доменів першого рівня, припустимо, lan. Так як dns сервера свої, можна використовувати будь-які домени, хоч google.com. Єдине, що для локальних користувачів така ідея створюватиме проблеми, оскільки на справжній Google вже не вийде зайти по цьому імені. Проте подібним чином можна забороняти доступ до якихось доменів - створювати зони на локальних серверах, які ведуть унікуди.
Але локальні записи працюють тільки в локальній інфраструктурі, там, де ви контролюєте, який сервер DNS прописаний у користувачів. Якщо ж у вас сайт, пошта чи інші сервіси, які мають бути доступні всім в інтернеті, для них потрібне окреме публічне ім'я, яке треба купувати. Їх продають реєстратори доменних назв. Принаймні майже всі імена другого рівня продаються.Є якісь послуги, які можуть дати домен третього рівня безкоштовно, але з такими доменами будуть певні проблеми. Наприклад, безкоштовними або дуже дешевими доменами часто користуються спамери, через що в цілому падає репутація домену, внаслідок чого багато спам-фільтрів упереджено ставляться до таких доменів. І є великий шанс, що ваша пошта на такому домені майже завжди потраплятиме до спаму.
Що стосується покупки нормального домену, то все не так погано, але й не те щоб супер. Є сайти, які продають домени, наприклад – reg.ru. Загалом домени продаються на рік чи кілька років.
Коротке, красиве доменне ім'я більше приваблює користувачів, тому на них завжди є конкуренція. Деякі купують такі імена сотнями та перепродують за величезними цінами.
Загалом можна знайти імена, які коштують не так дорого. Але завжди звертайте увагу на ціну продовження. Тому що нерідко можна купити непогані імена по знижці за дуже дешево, а через рік чи три сума продовження коштуватиме у кілька разів дорожче.
Після покупки домену ви можете налаштувати NS записи на свої сервери або використовувати публічні DNS сервери. Найчастіше публічні DNS записи можна виставити у реєстраторів доменних імен, тобто вам не потрібно мати свій DNS сервер, який дивиться в інтернет.
Нерідко замість серверів DNS реєстратора люди воліють використовувати DNS сервери хмарних провайдерів. Вони можуть мати свої переваги, особливо коли ви використовуєте їх хмари для інших сервісів, наприклад, для пошти.
Але якщо ви придбали громадський домен, не варто його використовувати в локальній інфраструктурі. Інакше у вас вийде каша з локальними та публічними днями записами. Вам доведеться всі локальні записи виставляти в інтернет, або робити копію зони на локальному сервері з іншими записами. Ну і від цього всякі проблеми будуть, наприклад, одна з найчастіших проблем - багато хто використовує адресу домену як адресу сайту, скажімо, google.com.Але в мережі, де є домен контролер, адреса домену має бути на ньому. Можна, звичайно, цю проблему вирішити граблями, але краще так не робити.
Але якщо прямий хочеться публічний домен використовувати з локальної інфраструктури, можна делегувати домен третього рівня. Скажімо, публічний домен - google.com, а в локальній мережі використовувати домен corp.google.com, що вказує на сервери DNS, доступні тільки в локальній мережі.
Наразі це все, але в темі DNS ще багато чого доведеться вивчити. Сьогодні ми розібрали, що таке домен, що таке зона, поговорили про делегування, обговорили локальні та публічні домени.
© Авторські права 2022, GNU Linux Pro, CC-BY-SA-4.0. Ревізія 76dc2655.
Найпростіший спосіб ввести Linux у домен
Всім привіт! Термін Microsoft Active Directory Domain Services включає безліч технологій, тому відразу уточню, в цій статті мова піде про використання контролера домену тільки для аутентифікації користувачів. Тобто у фіналі, потрібна можливість будь-якому співробітнику підприємства сісти за будь-яку робочу станцію Linux, використовуючи свій доменний логін та пароль. Починаючи з Windows 2000 Server для аутентифікації користувачів домену використовується протокол Kerberos, розроблений ще в 80-х роках минулого століття, алгоритм роботи якого, ІМХО, є прикладом відмінного інженерного хаку, в хорошому (початковому:) сенсі цього слова. Наприкінці статті є посилання на опис його роботи, а зараз треба сказати, що є кілька реалізацій цього протоколу і рішення з цієї статті не прив'язане лише до Microsoft Active Directory Отже, на підприємстві вже розгорнутий контролер домену, найімовірніше - Microsoft Active Directory нами - робоча станція Linux (приклади будуть для Debian, але працюватиме і в інших дистрибутивах і, навіть, у моїй коханій FreeBSD:). Як ввести її до домену? Так дуже просто:
student@debian:~$ sudo apt install krb5-user -yУ Debian навіть не знадобиться редагувати, але переконайтеся, і, якщо потрібно, вкажіть ці рядки у файлі конфігурації Kerberos клієнта (достатньо лише їх)
student@debian:~$ sudo nano /etc/krb5.conf[libdefaults] default_realm = CORP.RUЗамість CORP.RU має бути ім'я домену (Kerberos сфери) Вашого підприємства І все, можна "входити" в домен:
student@debian:~$ kinit ivanovii Password for [email protected]: student@debian:~$ klist Оплата: FILE:/tmp/krb5cc_1000 Default principal: [email protected] Valid starting Expires Service principal 00:09:13 02/22/2023 10:09:13 krbtgt/[email protected] renew until 02/23/2023 00:09:09ivanovii - зареєстрований в домені логін користувача, замініть його на той, який є у Вас, можна навіть використовувати Administrator. В результаті роботи команди kinit було здійснено аутентифікацію користувача та отримано Ticket-Granting Ticket (TGT) "квиток на видачу квитків", що дозволяє, надалі, отримати квитки на доступ до зареєстрованих в домені сервісів, реалізуючи таким чином технологію єдиного входу - single sign- on (SSO). Можна закінчувати статтю :) Стривайте, але, наприклад, в оснащенні Active Directory Users and Computers ніякої робочої станції Linux не з'явилося, як же так? Так, дійсно, контролер домену як і раніше нічого не знає про нашу робочу станцію, фактично, навпаки, це наша робоча станція, завдяки параметру default_realm = CORP.RU і відповідним записам SRV в DNS
student@debian:~$nslookup -q=SRV _kerberos._udp.corp.ru . kdc.corp.ru internet address = A.B.C.Dзнає розташування контролера домену, і цього достатньо для роботи з його Kerberos підсистемою.Для чого може знадобитися реєстрація Linux системи в Active Directory і як це зробити - тема окремої статті, а зараз повернемося до нашого завдання - вхід доменним обліковим записом в Linux систему За процес автентифікації користувачів при вході в Linux відповідає бібліотека PAM якою я згадував у цій статті. У нашому випадку додамо модуль модуль, який використовує Kerberos автентифікацію:
student@debian:~$ sudo apt install libpam-krb5 -yУ Debian новий модуль додасться в конфігурацію PAM автоматично, спочатку логін/пароль перевірятимуться в Kerberos, і, у разі невдачі, в локальній базі користувачів:
student@debian:~$less /etc/pam.d/common-auth. auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000 auth [success=1 default=ignore] pam_unix.so nullok try_first_pas .
student@debian:~$ sudo login ivanovii Password: Authentication failurestudent@debian:~$ sudo tail /var/log/auth.log . Feb 22 01:18:43 debian login[1587]: pam_krb5(login:auth): user ivanovii authenticated as [email protected] Feb 22 01:18:43 no identify user (від getpwnam(ivanovii)).
автентифікація пройшла успішно, але далі система нічого не знає про нашого користувача (ні UID, ні GID ні інших атрибутів)
$ id ivanovii id: 'ivanovii': no such userОсь тепер ми підійшли до етапу, заради якого писалася стаття:) Якщо почати шукати традиційне рішення цього завдання, то, швидше за все, Ви дізнаєтеся про бібліотеку Name Service Switch (NSS) і модулі LDAP, WinBIND або SSSD для неї. Але якщо … просто створити обліковий запис після успішної аутентифікації? Виявляється, бібліотеку PAM можна розширювати своїми власними скриптами, використовуючи модуль pam_script. Давайте додамо його до системи:
student@debian:~$ sudo apt install libpam-script -ystudent@debian:~$less /etc/pam.d/common-auth . auth [success=3 default=ignore] pam_krb5.so minimum_uid=1000 auth sufficient pam_script.so auth [success=1 default=ignore] pam_unix.so nullok try_first_pass .
Якщо чесно, то така конфігурація не тільки не підходить для нашого завдання, але і дуже не хороша з точки зору безпеки, легко довести її до ситуації, коли буде достатньо знати логін локального користувача, наприклад root, для підключення до системи, пароль підійде будь-який ( ось за це любив FreeBSD, вона за нас ніколи нічого не робить:) Тому, виправте конфігурацію розташувавши модулі так:
student@debian:~$ sudo nano /etc/pam.d/common-authauth [success=2 default=ignore] pam_krb5.so minimum_uid=1000 auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass auth requisite pam_deny.so auth sufficient pam_script.so auth requi.У цьому випадку, після успішної автентифікації врахованого запису в Kerberos, виконання перестрибне два наступних кроку і запустить модуль pam_script. Залишається тільки написати скрипт, який перевірить наявність облікового запису, і, у разі його відсутності в системі, створить:
student@debian:~$ sudo nano /usr/share/libpam-script/pam_script_auth#!/bin/bash id "$PAM_USER" &>/dev/null || useradd -m -s /bin/bash "$PAM_USER"student@debian:~$ sudo chmod +x /usr/share/libpam-script/pam_script_authstudent@debian:~$ sudo login ivanovii Password: . ivanovii@debian:~$ id uid=1001(ivanovii) gid=1001(ivanovii) groups=1001(ivanovii) ivanovii@debian:~$ klist Опис: FILE:/tmp/krb5cc_1001_0zzvqR Default principal: ivan starting Expires Service principal 02/22/2023 04:14:30 02/22/2023 14:14:30 krbtgt/[email protected] renew until 02/23/2023 04:14:30Linux у домені Active Directory
Перед адміністраторами іноді постають завдання інтеграції серверів Linux і робочих станцій у середу домену Active Directory. Зазвичай потрібно:
1. Надати доступ до сервісів на сервері Linux користувачам домену.
2. Пустити на Linux сервер адміністраторів під своїми доменними обліковими даними.
3. Налаштувати вхід на Linux робочу станцію для користувачів домену, причому бажано, щоб вони могли при цьому скуштувати всі принади SSO (Я, наприклад, не дуже люблю часто вводити свій довгий пароль).
Зазвичай для надання Linux системі користувачів та груп з домену Active Directory використовують winbind або налаштовують бібліотеки nss для роботи з контролером домену Active Directory за протоколом LDAP. Але сьогодні ми підемо іншим шляхом: використовуватимемо PowerBroker Identity Services (Продукт відомий також під ім'ям Likewise).
Встановлення.
Є дві версії продукту: Enterprise та Open. Мені для реалізації моїх завдань вистачило Open версії, тому все написане далі стосуватиметься її.
Отримати Open версію можна на сайті виробника, але посилання Вам нададуть в обмін на Ваше ім'я, назву компанії та e-mail.
Існують 32-х та 64-х пакети у форматах rpm та deb. (А також пакети для OS X, AIX, FreeBSD, SOlaris, HP-UX)
Вихідники (Open edition) доступні в git-репозирії: git://source.pbis.beyondtrust.com/pbis.git
Я встановлював PBIS на Debian Wheezy amd64:
wget http://download.beyondtrust.com/PBISO/7.1.0/1203/pbis-open-7.1.0.1203.linux.x86_64.deb.sh ./pbis-open-7.1.0.1203.linux.x86_64.deb. sh
Вміст пакету встановлюється в /opt/pbis. Також у системі з'являється новий runscript lwsmd, який власне запускає агента PBIS.
До системи додається модуль PAM pap_lsass.so.
Утиліти (переважно консольні), необхідні для функціонування PBIS, а також адміністратору, що полегшують життя, розміщуються в /opt/pbis/bin
Введення домен.
Перед введенням в домен слід переконатися, що контролери домену доступи та доменні імена коректно розгортаються в IP. (Інакше слід налаштувати resolv.conf)
Для введення в домен призначено дві команди: /opt/pbis/bin/domainjoin-cli та /opt/pbis/bin/domainjoin-gui. Одна з них працює у командному рядку, друга використовує libgtk для відображення графічного інтерфесу.
Для введення в домен потрібно вказати: ім'я домену, логін і пароль доменного користувача з правами для введення ПК в домен, контейнер для розміщення об'єкта комп'ютера в домені - все те саме, що й при введенні в домен windows ПК.
Після введення в домен буде потрібно перезавантаження.
Зверніть увагу – PBIS вміє працювати із сайтами Active Directory. Клієнт PBIS буде працювати з контролерами сайту, в якому він знаходиться!
Після перезавантаження.
Після перезавантаження і id, і getent видадуть вам користувачів та групи домену (національні символи обробляються коректно. Пробіли замінюються на символ "^").
У доменній DNS зоні з'явиться запис із ім'ям вашого ПК.
Не поспішайте від імені доменного користувача. Спочатку має сенс (але не обов'язково) налаштувати PBIS.
/opt/pbis/bin/config --list
[Eventlog] AllowDeleteTo AllowReadTo AllowWriteTo MaxDiskUsage MaxEventLifespan MaxNumEvents [Lsass] DomainSeparator SpaceReplacement EnableEventlog LogInvalidPasswords Providers [Lsass - PAM] DisplayMotd PAMLogLevel UserNotAllowedErrorLsas CreateHomeDir CreateK5Login SyncSystemTime TrimUserMembership LdapSignAndSeal LogADNetworkConnectionEvents NssEnumerationEnabled NssGroupMembersQueryCacheOnly NssUserMembershipQueryCacheOnly RefreshUserCredentials Cache DomainManagerUnknownDomainCacheTimeout MachinePasswordLifespan MemoryCacheSizeCap HomeDirPrefix HomeDirTemplate RemoteHomeDirTemplate HomeDirUmask LoginShellTemplate SkeletonDirs UserDomainPrefix DomainManagerIgnoreAllTrusts DomainManager RequireMembershipO SmartcardEnabled SmartcardRequiredForLogin [Lsass - Local provider] Local_AcceptNTLMv1 Local_HomeDirTemplate Local_HomeDirUmask Local_LoginShellTemplate Local_SkeletonDirs [User Monitor] UserMonitorCheckInterval [System Initi
Одна з відмінностей Enterprise версії – можливість керувати цими налаштуваннями через GPO.
Варто звернути увагу до HomeDirPrefix, HomeDirTemplate.
Я також одразу поставив "RequireMembershipOf" - тільки користувачі, члени груп або SID з цього списку можуть авторизуватися на комп'ютери.
Опис кожного параметра можна отримати, наприклад:
/opt/pbis/bin/config --detail RequireMembershipOf
/opt/pbis/bin/config RequireMembershipOf "Адміністратори^Linux"
Зверніть увагу - PBIS не використовує атрибути SFU або інші атрибути Acrive Directory для отримання loginShell користувача, а також його uid і gid.
loginShell для доменних користувачів задається в налаштуваннях PBIS, причому встановлення різних loginShell різним користувачам – можливе лише в Enterprise версії.
uid формується як хеш SID користувача.
gid - як хеш SID primaryGroup користувача.
Таким чином, на двох ПК користувач отримає завжди однакові uid і gid.
Тепер можна входити до системи від імені доменного користувача. Після входу доменного користувача зверніть увагу на висновок klist – PBIS отримає для користувача необхідні квитки kerberos. Після цього можна безпроблемно звертатися до ресурсів на windows ПК (Головне, щоб програмне забезпечення підтримувало GSSAPI). Наприклад: тепер я без додаткових запитів паролів (і мій пароль ніде не збережений!) відкриваю будь-які smb ресурси домену в Dolphin. Також Firefox (при налаштуванні network.negotiate-auth.trusted-uris) дозволяє використовувати SSO при доступі до Web-порталів з доменною авторизацією (природно, якщо SSO налаштована на сервері)
А як же SSO доступ до ресурсів на Linux ПК?
Можна й так! PBIS заповнює /etc/krb5.keytab та підтримує його актуальним. Тому серверне програмне забезпечення з підтримкою GSSAPI може бути налаштоване для SSO.
Наприклад, для доступу до сервера по ssh, конфігураційний файл /etc/ssh/sshd_config (шлях у вашій системі може відрізнятися)
GSSAPIAauthentication yes
І при підключенні вказати доменне ім'я комп'ютера (присутнє в його SPN — інакше квиток kerberos не може бути виписаний)
UsePAM yes
(PBIS надає модуль для PAM у тому числі)
Також логічно буде додати директиву «AllowGroups» і вказати через пробіл доменні групи, користувачам яких ви маєте намір дати доступ до сервера ssh.
На клієнтському Linux ПК конфігурацію клієнта ssh достатньо включити:
GSSAPIAauthentication yes
Природно, на клієнтському Linux комп'ютері повинен бути налаштований kerberos. Найпростіший спосіб виконати цю умову - так само ввести клієнтський комп'ютер до домену і працювати від імені доменного користувача.
На клієнтському Windows ПК (член домену) при використанні Putty слід у властивостях SSH з'єднання встановити прапор «Attempt GSSAPI authentification (SSH-2 only)» (У різних версіях цей пункт називається по-різному).
Також у секції Connection --> Data можна поставити перемикач у позицію «Use system username»
Якщо ви маєте намір організувати таким чином ssh доступ адміністраторів до linux серверів - гарною ідеєю буде заборонити на них вхід root по ssh і додати linux-адміністраторів (а ще краще їхню доменну групу) у файл sudoers.
Це не єдині сценарії застосування PBIS. якщо стаття здасться Вам цікавою – в наступному напишу як організувати samba файловий сервер у домені для доменних користувачів без winbind.
Додаткову інформацію на тему можна отримати на форумі спільноти PowerBroker Identity Services: forum.beyondtrust.com
- Хорошу повторюваність (порівняйте послідовність дій цієї статті з інструкцією з налаштування winbind)
- Кешування даних з каталогу (доменний користувач може увійти на ПК, коли домен недоступний, якщо його облікові дані в кеші)
- Для PBIS не потрібне формування в каталозі AD додаткових атрибутів користувача
- PBIS розуміє сайти AD та працює з контролерами свого сайту.
- Велику безпеку (samba створює облік комп'ютера з паролем, що не закінчується)
- У платній версії (якщо виникне така необхідність) PBIS агент управляємо через GPO (хоча це можна і викреслити. якщо ви не маєте наміру її купувати)
UPD 2 Прийшов зворотний зв'язок від користувача sdemon72. Можливо, комусь буде корисно.
Привіт! Спробував ваш рецепт на свіжій linuxmint-18-mate-64bit, все вийшло з деякими застереженнями:
1.З отриманням програми через сайт у мене виникли складнощі (не захотів писати реальний номер телефону, а бутафорський не прокотив — надійшов лист із сумнівами щодо його приводу), натомість знайшов репозиторій із найсвіжішими версіями: repo.pbis.beyondtrust.com/apt.html
2. При запуску програми видає помилки, щоб їх уникнути, потрібно перед запуском зробити таке:
2.1. Встановити ssh:
sudo apt-get install ssh
2.2. Виправити /etc/nsswitch.conf:
hosts: files dns mdns4_minimal [NOTFOUND=return]
(тобто переносимо dns з кінця рядка на другу позицію)
2.3. Виправити /etc/NetworkManager/NetworkManager.conf:
#dns=dnsmasq
(Тобто коментуємо цей рядок)
2.4. Перезапустити network-manager:
sudo service network-manager restart
Після цього все спрацювало на ура! Буду дуже вдячний, якщо внесете ці доповнення до статті, т.к. у пошуку сабжу вона випадає в перших рядках. Залишати коментарі я не можу (забороняє сайт), тож пишу вам особисто.
Якщо цікаво – історія моїх розвідок тут: linuxforum.ru/topic/40209
З повагою, Дмитро
UPD 3: Чому безкоштовну версію PBIS не вдасться застосувати у великій компанії
У безкоштовній версії працює лише один алгоритм генерації UNIX iD (uid та gid) за SID доменного користувача. Так от він не забезпечує унікальності
цих ідентифікаторів. Коли у вас дуже старий домен або просто багато користувачів дуже високий ризик, що два і більше користувачів отримають однакові ідентифікатори у системі з OpenPBIS. У платній версії є можливість вибору між алгоритмами генерації id, але вона коштує значно дорожче за аналогічний продукт від Quest Software ;(.
