Windows вже давно поставляється в комплекті з інтегрованою системою мережевої автентичності і єдиного входу. До Windows 2000 контролери доменів Windows NT надавали клієнтам Windows служби автентифікації, використовуючи протокол NTLM. Хоча NTLM не був так захищений, як здавалося спочатку, він був дуже корисним, оскільки давав зручне вирішення проблеми необхідності підтримувати дублікати облікових записів користувача на різних серверах мережі.
Починаючи з Windows 2000, корпорація Майкрософт перейшла з NTLM на Active Directory та її інтегровані служби автентифікації Kerberos. Kerberos був значно захищенішим за NTLM, а також краще масштабувався. До того ж, Kerberos був стандартом галузі, що вже використовується системами Linux і UNIX, що відкрило браму інтеграції цих платформ з Windows.
Перевірка автентичності Linux
Спочатку Linux (а також засоби та бібліотеки GNU, що працювали на ньому) не розраховувався на єдиний механізм автентичності. Як наслідок цього, розробники додатків Linux зазвичай бралися до розробки власних схем автентичності. Їм вдавалося досягти цього або за рахунок пошуку хеш-кодів імен і паролів у /etc/passwd (текстовому файлі, який традиційно містить облікові дані користувачів Linux) або надання зовсім іншого (і окремого механізму).
Асортимент механізмів перевірки справжності, що вийшов, був некерованим. У 1995 р. компанія Sun запропонувала механізм, що називається модулями автентифікації (Pluggable Authentication Modules - PAM). PAM надавали загальний набір інтерфейсів API автентифікації, який міг використовуватися всіма розробниками додатків, а також серверний елемент, що настроюється адміністратором, що дозволяє використовувати різні «підключаються» схеми автентифікації. Використання інтерфейсів API PAM для перевірки автентичності та інтерфейсів API перемикача сервера імен (Name Server Switch - NSS) для пошуку відомостей про користувача дозволило розробникам додатків Linux писати менше коду, а адміністраторам Linux керувати процесом автентичності і налаштовувати його з одного місця.
Більшість випусків Linux постачалися кількома модулями автентифікації PAM, включаючи модулі, що підтримують автентифікацію в каталозі LDAP і автентифікацію з використанням Kerberos. Ці модулі можна використовувати для автентифікації в Active Directory, але на це існують значні обмеження, про які я розповім нижче в цій статті.
Samba та Winbind
Samba- це проект із відкритим вихідним кодом, метою якого є інтеграція між середовищами Windows та Linux. Samba містить компоненти, що дають комп'ютерам Linux доступ до служб файлів та друку Windows, а також надають служби на основі Linux, які імітують контролери доменів Windows NT 4.0. Використовуючи клієнтські компоненти Samba, комп'ютери Linux можуть користуватися службами автентифікації Windows, що надаються контролерами доменів Windows NT і Active Directory.
Для нас особливо цікава частина Samba, звана Winbind. Winbind - це демон («служба» у термінах Windows), що працює на клієнтах Samba і діє як проксі для зв'язку між PAM і NSS, що працюють на комп'ютері Linux, з одного боку, і Active Directory, що працює на контролері домену, з іншого. Зокрема, Winbind використовує Kerberos для перевірки автентичності за допомогою Active Directory та LDAP для отримання інформації про користувачів та групи. Winbind також надає додаткові послуги, такі як можливість виявляти контролер домену, використовуючи алгоритм, подібний до DCLOCATOR Active Directory, і можливість скидати паролі Active Directory, зв'язуючись з контролером домену за допомогою RPC.
Winbind вирішує низку проблем, які зберігаються при простому використанні Kerberos за допомогою PAM. Зокрема, замість жорсткого кодування контролера домену для автентифікації PAM Winbind вибирає контролер домену шляхом пошуку за записами локатора DNS подібно до того, як це робить модуль DC LOCATOR Майкрософт.
Три стратегії автентифікації
Враховуючи доступність LDAP, Kerberos та Winbind на комп'ютерах Linux, існують три різні стратегії реалізації, які можна застосувати, щоб дати комп'ютеру Linux можливість використовувати Active Directory для автентифікації.
Використання автентифікації LDAPНайпростіший, але найменш задовільний спосіб використання Active Directory для автентифікації - налаштувати PAM на використання автентичності LDAP, як показано на Рис. 1. Хоча Active Directory і є службою LDAPv3, клієнти Windows використовують для автентифікації Kerberos (з NTLM як резервний варіант), а не LDAP.
Під час перевірки автентичності LDAP (назвою LDAP) ім'я користувача та пароль надсилаються відкритим текстом через мережу. Це небезпечно і неприпустимо більшість цілей.
Рис. Перевірка автентичності в Active Directory за допомогою LDAP
Єдиним способом пом'якшення цього ризику відкритої передачі облікових даних є шифрування каналу зв'язку клієнт-Active Directory з використанням чогось на зразок SSL. Це безперечно можливо, але покладає додаткове навантаження управління сертифікатами SSL як на комп'ютер контролера домену, так і на комп'ютер Linux. Крім того, використання модуля LDAP PAM не підтримує зміни скинутих паролів.
Використання LDAP та KerberosІншою стратегією використання Active Directory для перевірки автентичності Linux є налаштування PAM на використання автентичності Kerberos і NSS на використання LDAP для пошуку інформації про користувачів та групи, як показано на Рис. 2. Ця схема має перевагу відносної захищеності, і в ній використовуються вбудовані можливості Linux. Але вона не використовує записи розташування служби (SRV) DNS, які публікують контролери доменів Active Directory, що змушує перевірити певний набір контролерів домену, щоб перевірити справжність по них. Це також не дає особливо інтуїтивного способу керування поточними паролями Active Directory або, донедавна, адекватного пошуку членів груп.
Рис. 2. Перевірка автентичності в Active Directory за допомогою LDAP та Kerberos
Використання WinbindТретім способом використання Active Directory для автентифікації Linux є налаштування PAM і NSS на виконання викликів до керуючої програми Winbind. Winbind переведе різні запити PAM і NSS до відповідних викликів Active Directory, використовуючи LDAP, Kerberos або RPC, залежно від того, що буде найбільш підходящим. На Рис. 3наведено наочний приклад цієї стратегії.
Рис. Перевірка автентичності в Active Directory за допомогою Winbind
Наш план реалізації
Удосконалена інтеграція з Active Directory змусила мене вибрати Winbind для Red Hat Enterprise Linux 5 (RHEL5) для мого проекту інтеграції Linux-Active Directory. RHEL5 – поточна версія комерційного випуску Red Hat Linux, і вона досить популярна у корпоративних центрах обробки даних.
Щоб RHEL5 перевіряв справжність через Active Directory, потрібні по суті п'ять наступних окремих дій:
- Знайти та завантажити відповідний пакет Samba та інші залежні компоненти.
- Зібрати Samba.
- Встановити та настроїти Samba.
- Налаштувати Linux, саме PAM та NSS.
- Налаштувати Active Directory.
У наступних розділах цієї статті описані докладніше.
Пошук потрібних програм
Одним з найбільших відмінностей між Linux і Windows є те, що Linux складається з маленького ядра операційної системи і величезної колекції компонентів, що окремо завантажуються і встановлюються. Це уможливлює створення дуже ретельно підібраних комплектів Linux, оптимальних для певних завдань, але також робить дуже складними налаштування сервера та управління ним. Різні дистрибутиви справляються з цим у різний спосіб. Red Hat (і його некомерційна родичка Fedora) використовують для встановлення цих компонентів та управління ними диспетчер пакетів Red Hat Package Manager (RPM).
Компоненти Linux для Red Hat мають дві форми. Файли RPM містять двійкові файли, які були заздалегідь скомпільовані та зібрані для певного поєднання версії компонента, випуску Linux та архітектури ЦП. Так що можна завантажити і встановити, наприклад, версію 1.3.8-5 стандартної системи друку UNIX (Common UNIX Printing System - CUPS), зібрану для Fedora версії 10, що працює на ЦП архітектури Intel x86. Враховуючи наявність дюжини різних архітектур ЦП, більш ніж 100 випусків Linux та тисяч пакетів та версій, можна побачити, що вибирати доводиться із неймовірної кількості двійкових пакетів RPM.
Вихідні файли RPM, з іншого боку, містять реальний вихідний код цього пакета. Від користувача очікується, що він завантажить та встановить вихідні файли, налаштує параметри збирання, після чого сам скомпілює та скомпонує двійкові файли. Ідея збирання власної операційної системи є жахливою для фахівця з Windows, що звикли встановлювати те, що Microsoft надає на компакт-диску установки Windows, але диспетчер пакетів робить процес відносно безболісним і напрочуд надійним. Група Samba випускає оновлення та виправлення безпеки шаленими темпами; лише за липень і серпень 2008 вийшло чотири випуски Samba 3.2, які містили понад 100 усунених помилок і виправлень безпеки. Для цього проекту я завантажив файли вихідного коду останньої стабільної версії Samba, версії 3.0.31.
Чому я завантажив вихідний код Samba замість попередньо скомпілюваного набору двійкових файлів? Спочатку я, звісно, спробував зробити перше. Але після багатьох годин з відладчиком я виявив, що завантажені мною двійкові файли не були зібрані потрібним для підтримки автентичності Active Directory способом. Зокрема, код, що підтримує зіставлення ідентифікаторів Linux в Active Directory, був відключений у стандартних зборках, так що мені довелося перебудовувати Samba з належними параметрами збірки. Я докладно розгляну питання зіставлення ідентифікаторів нижче.
Навіть хоча Linux сам по собі є маленьким ядром, у випуску Red Hat Enterprise заздалегідь встановлено безліч пакетів. Зазвичай це серйозно спрощує життя, дозволяючи розпочати з повної та працюючої операційної системи, але заздалегідь встановлені пакети часом конфліктують із програмами, які передбачається встановити пізніше.
Я не ввімкнув Samba в установку Red Hat (зазвичай Samba встановлюється за замовчуванням), оскільки мені потрібно було використовувати новішу версію. Однак новіша версія Samba вимагає нових версій кількох інших бібліотек та службових програм, які вже були встановлені. Проблеми, пов'язані з подібною залежністю, діють на нерви, але можна легко вирішити, використовуючи RPM.
Існує безліч веб-вузлів, на яких розміщуються двійкові пакети RPM. Той, що я використовував (просто тому, що він знайшовся першим), називається PBONE і розташований на rpm.pbone.net. Він має зручний спосіб пошуку пакетів, і на ньому є всі двійкові файли, які були необхідні для моєї архітектури ЦП (i386) та випусків операційної системи (Red Hat Enterprise Linux 5/Fedora 7 та 8).
Мені довелося завантажити та оновити пакети, перераховані на Рис. 4, щоб зібрати та встановити останню версію Samba 3.0 (існує ще нове дерево версій 3.2, працювати з яким я не пробував). Зауважте, що всі ці пакети призначені для випуску Fedora Core (fc). Дистрибутив Red Hat заснований на тих же вихідних кодах, що використовуються у Fedora, та повністю сумісний з нею. Пакети, зібрані для Fedora Core 7 і пізніших версій, працюватимуть у RHEL5 без змін. Помістіть завантажені файли RPM у каталог /usr/src/redhat/RPMS.
Рис. 4. Пакети, необхідні для складання та встановлення Samba 3.0.31
Складання Samba
Перший етап складання Samba полягає у завантаженні правильного вихідного пакета RPM. Я завантажив пакет RPM вихідних кодів Samba 3.0.31 з веб-сайту PBONE. Далі помістіть завантажений файл RPM вихідних кодів /usr/src/redhat/SRPMS; це стандартний каталог для пакетів RPM вихідних кодів під час процесу збирання.
Відкрийте сеанс терміналу («Вікно командного рядка» у термінах Windows) і перейдіть до папки SRPMS. Після того, як це зроблено, встановіть пакет вихідних кодів за допомогою команди, як показано на Рис. 5.
Рис. 5. Встановлення пакета RPM вихідних кодів Samba
Якщо з'явиться попередження про помилку "user mockbuild does not exist-using root" («макетної збірки користувача не існує – використовується корінь»), не хвилюйтеся. Ця помилка вказує на те, що службові програми макетної збірки не встановлені. Процес складання працюватиме і без них.
Далі перейдіть до каталогу /usr/src/redhat/SPECS та виправте файл samba.spec, що містить параметри збирання Samba. Знайдіть рядок, що починається з "CFLAGS=", і переконайтеся, що "--with-shared-modules=idmap_ad,idmap_rid" існує. Цей параметр гарантує, що в процесі збирання буде включений код, який правильно перетворює унікальні ідентифікатори (unique identifiers - UID) Linux для Active Directory. На Рис. 6наведено цей параметр.
Рис. 6. Параметр складання with-shared-modules («з модулями, що спільно використовуються»)
Далі може знадобитися оновити деякі бібліотеки на комп'ютері, щоб належним чином зібрати і встановити Samba; це залежить від того, які версії бібліотек вже встановлені. У моєму випадку мені довелося встановити пакети, перераховані на Рис. 4, використовуючи команду rpm-install; в деяких випадках мені довелося, втім, використовувати варіант --force, щоб подолати деякі проблеми залежності.
Щоб зібрати Samba, перейдіть до каталогу /usr/src/redhat та виконайте команду rpmbuild -bb SPECS/samba.spec, як показано на Рис. 7. В результаті цієї процедури новий файл RPM samba-3.0.31-0.i386 залишиться в каталозі /usr/src/redhat/RPMS. Ми встановимо цей файл RPM пізніше за ходом проекту.
Рис. 7. Створення двійкового файлу RPM Samba
Налаштування роботи Linux з мережею
Щоб перевіряти справжність за допомогою Active Directory, комп'ютер Linux повинен мати можливість зв'язуватися з контролером домену. Щоб це могло статися, необхідно налаштувати три параметри мережі.
По-перше, важливо переконатися, що мережний інтерфейс на комп'ютері Linux налаштований належним чином або шляхом використання протоколу DHCP, або шляхом призначення відповідної IP-адреси і мережної маски за допомогою команди ifconfig. У разі RHEL5 можна налаштувати роботу з мережею, вибравши її (Network) із меню System | Administration (Система | Адміністрація), як показано на Рис. 8.
Рис. 8. Налаштування мережі
Далі переконайтеся, що служба дозволу імен DNS для комп'ютера Linux встановлена на використання того ж сервера імен DNS, який використовують контролери домену; в більшості випадків це контролер домену в домені, до якого потрібно приєднати комп'ютер Linux, припускаючи, що використовується DNS, інтегрована з Active Directory. Засіб дозволу DNS налаштовується на вкладці DNS тієї ж службової програми налаштування мережі, яка використовувалася для налаштування мережі, як показано на Рис. 9.
9. Встановлення основного засобу дозволу DNS
Нарешті, після завершення цих дій, потрібно встановити ім'я Linux для відображення його імені в домені. Хоча це ім'я можна встановити, використовуючи програму налаштування мережі, це, схоже, не завжди працює належним чином.
Натомість змініть файл /etc/hosts і додайте запис під записом localhost.localdomain у формі
Налаштування синхронізації часу на Linux
Протокол Kerberos покладається на наявність у систем автентифікації годинника з досить високою точністю синхронізації. За промовчанням Active Directory допускає максимальне відхилення за п'ять хвилин. Щоб гарантувати перебування систем Linux та годин систем контролерів домену в межах цього значення, необхідно налаштувати системи Linux на використання служби протоколу NTP контролера домену.
Далі на сервері Linux запустіть службову програму Date & Time (Дата і час) з меню System | Administration та виберіть вкладку протоколу NTP. Встановіть прапорець Enable Network Time Protocol ("Увімкнути протокол NTP") та додайте IP-адресу контролера домену, яку потрібно використовувати як мережне джерело часу. Зверніть увагу, що це повинен бути контролер домену в домені, що містить роль FSMO імітатора основного контролера домену (primary domain controller - PDC). На Рис. 10наведено приклад встановлення мережевого джерела часу для Linux.
Рис. 10. Налаштування протоколу NTP
Налаштування PAM та NSS
PAM та NSS надають засіб з'єднання програми Linux, такого як робоче середовище, та Winbind. Подібно до багатьох служб Linux, PAM і NSS налаштовуються через текстові файли. Спочатку ми розглянемо налаштування PAM.
PAM надає чотири засоби використання додатків, що стосуються перевірки автентичності. Засіб автентифікації дозволяє застосунку визначити, хто використовує його. Засіб облікових записів надає функції керування обліковими записами, які не стосуються автентифікації, таких як обмеження часу входу. Засіб паролів надає механізми для запиту паролів та управління ними. Засіб сеансів виконує завдання установки та видалення програми, які стосуються користувача, такі як ведення журналу або створення файлів у категорії конкретного користувача.
Файли налаштування PAM в Red Hat зберігаються в каталозі /etc/pam.d, в якому буде знаходитись текстовий файл для кожної програми, яка використовує PAM для автентифікації. Наприклад, файл /etc/pam.d/gdm містить інформацію про налаштування PAM для Gnome Desktop Manager (GDM), віконного середовища за замовчуванням у Red Hat. У кожному файлі налаштування PAM міститься кілька рядків, кожен з яких визначає будь-який аспект процесу автентифікації PAM. На Рис. 11показано вміст налаштування PAM для GDM.
Рис. 11. Файл налаштування РАМ для Gnome Desktop Manager
Кожен запис у файлі налаштування PAM має форму<группа управления> <элемент управления> <модуль> <параметры>, де<группа управления>відповідає засобу, до якого належить запис налаштування: автентифікації, облікових записів, паролів або сеансів. Керуючі ключові слова, описані на Рис. 12, кажуть PAM, як обробити запис налаштування. Третій стовпець файлу містить ім'я спільної бібліотеки PAM у каталозі безпеки /lib/. Загальні бібліотеки містять динамічно завантажуваний виконуваний код, подібний до DLL у Windows. Додаткові терміни після імені модуля - це параметри, які передаються модулем PAM загальної бібліотеки.
Рис. 12. Керуючі ключові слова PAM
Ключове слово | Опис |
| Required («Обов'язково») | Якщо модуль спрацьовує успішно, то PAM продовжує обчислювати записи для групи управління, і результати будуть визначені результатами модулів, що залишаються. Якщо ні, то PAM продовжить обчислення, але поверне збій додатку, що викликав. |
| Requisite («Необхідно») | Якщо модуль успішно спрацьовує, PAM продовжує обчислювати записи групи управління. Якщо ні, то PAM здійснить повернення додатку, що викликав, без подальшої обробки. |
| Sufficient («Досить») | Якщо модуль спрацює успішно, то PAM поверне успішний результат додатку, що викликав. Якщо ні, PAM продовжить обчислення, але результати будуть визначені наступними модулями. |
| Optional («Необов'язково») | PAM ігнорує результати модуля, якщо це єдиний модуль, вказаний для групи управління. |
| Include («Увімкнути») | PAM включає вміст файлу налаштування PAM, на який дається посилання, а також містяться в ньому процеси та записи. |
Можна помітити, що кожна група управління має кілька записів. PAM обробляє записи в порядку, викликаючи названий модуль. Потім модуль повертає успіх або збій, і PAM діє залежно від ключового слова, що управляє.
Можна помітити, що файл PAM для GDM має system-auth для всіх груп керування. Це спосіб, яким PAM встановлює поведінку при автентичності за промовчанням для GDM. Модифікуючи system-auth, можна модифікувати цю поведінку для всіх програм, у яких є файл system-auth у налаштуваннях PAM. Файл system-auth за замовчуванням показано на Рис. 13.
Рис. 13. Файл system-auth модуля PAM
Модуль перемикача блоку перетворення імен (NSS) приховує конкретні відомості про сховище даних систем від розробника програми, приблизно так само, як PAM приховує подробиці автентифікації. NSS дозволяє адміністратору вказати спосіб, яким зберігаються бази даних системи. Зокрема, адміністратор може вказати, як зберігається інформація про ім'я користувача та пароль. Оскільки нам потрібно, щоб програми шукали інформацію про користувачів в Active Directory за допомогою Winbind, нам потрібно змінити налаштування NSS, щоб показати це.
Red Hat включає маленьку графічну програму для налаштування PAM і NSS, звану system-config-authentication. Вона піклується про більшість змін (але не всіх), які необхідно ввести у файли system-auth і nss.conf.
Запустіть програму system-config-authentication, і можна буде побачити діалог, подібний до показаного на Рис. 14. Встановіть прапорець Winbind як на вкладці User Information (Інформація про користувача, вона налаштовує файл nss.conf), так і на вкладці Authentication (Перевірка автентичності), вона модифікує файл system-auth.
Рис. 14. Діалог systemconfig-authentication
Натисніть кнопку Configure Winbind, і буде відображено діалог, наведений на Рис. 15. У полі Winbind Domain введіть ім'я домену, в якому має перевірятися автентифікація користувачів, і виберіть «оголошення» як модель безпеки. Введіть доменне ім'я DNS домену Active Directory у полі Winbind ADS Realm. У полі Winbind Domain Controllers введіть або ім'я контролера домену, за допомогою якого потрібно перевіряти справжність для цієї системи Linux, або зірочку, що вказує на те, що Winbind слід вибрати контролер домену, запитуючи записи SRV в DNS.
Рис. 15. Налаштування діалогу Winbind
Виберіть відповідний інтерпретатор за замовчуванням, який повинні мати користувачі Active Directory; у цьому випадку я вибрав bash (Bourne-again Shell). Не намагайтеся скористатися кнопкою Join Domain («Приєднатися до домену») на цьому етапі. Комп'ютер буде приєднано до домену пізніше.
У файл /etc/pam.d/system-auth необхідно внести ще одну додаткову зміну після того, як він був модифікований для підтримки Winbind. Коли користувач Linux входить до системи, система вимагає від користувача наявності домашнього каталогу. Домашній каталог містить багато параметрів та елементів налаштування конкретного користувача багато в чому подібно до реєстру Windows. Проблема тут полягає в тому, що оскільки користувачі створюються в Active Directory, Linux не автоматично створюватиме домашній каталог користувача. На щастя, PAM можна настроїти на виконання цього як частина налаштування сеансу.
Відкрийте файл /etc/pam.d/system-auth, потім прокрутіть екран вниз і вставте рядок "session optional map_mkhomedir.so skel=/etc/skel umask=0644" перед останнім рядком у розділі сеансу (див. Рис. 16). Цей рядок налаштовує PAM створення домашнього каталогу для користувача, якщо такого ще не існує. Вона буде використовувати /etc/skel як «скелет» шаблону і призначить маску прав 0644 (читання та запис для власника, читання для основної групи та читання для решти) нової папки.
Рис. 16. Створення домашнього каталогу для користувачів
Встановлення та налаштування Samba
Щоб інсталювати двійкові файли Samba, щойно створені, перейдіть до каталогу /usr/src/redhat/RPMS. Усі файли RPM, створені командою rpmbuild, з'являться у цьому каталозі. Пам'ятайте, що Samba включає двійкові файли, які дозволяють клієнту Linux отримати доступ до спільного сховища файлів Windows (або Samba), а також коду, що дозволяє системі Linux діяти як файловий сервер Windows, сервер друку Windows і контролер домену в стилі Windows NT 4.0.
Щоб дозволити Linux проводити автентифікацію в Active Directory, всього цього не потрібно; досить загальних файлів Samba та двійкових файлів клієнта Samba. Ці файли для нашої зручності розбиті на два файли RPM: samba-client-3.0.31-0.i386.rpm та samba-common-3.0.31-0.i386.rpm. Встановіть файли RPM за допомогою rpm --install. Наведу приклад: rpm --install samba-common-3.0.31-0.i386.rpm. (Зверніть увагу, що перед цим потрібно встановити файл RPM -common.)
Після встановлення двійкових файлів клієнта Samba необхідно модифікувати налаштування Samba за промовчанням, щоб переконатися, що Winbind обробляє автентифікацію належним чином за допомогою Active Directory. Усю інформацію про налаштування Samba (і клієнта, і сервера) можна знайти у текстовому файлі smb.conf, який за умовчанням знаходиться у каталозі /etc/samba. Smb.conf може містити величезну кількість параметрів, і повна розповідь про його вміст виходить за рамки цієї статті. На веб-сайті samba.org та в довідковій системі Linux про smb.conf розказано докладніше.
Першим етапом налаштування Winbind є використання Active Directory для автентифікації. Модель безпеки в smb.conf необхідно встановити на оголошення. Службова програма system-config-authentication вже мала встановити це сама, але перевірка ніколи не завадить. Відкрийте для редагування файл smb.conf і знайдіть розділ, позначений Domain Member Options ("Параметри члена домену"). Знайдіть рядок, що починається із "security" і переконайтеся, що він читається як "security = ads". На наступному етапі налаштування визначається, як Winbind зіставить учасників безпеки Windows, таких як користувачі та групи, з ідентифікаторами Linux, і це потребує більш детального пояснення.
Проблема зіставлення ідентифікаторів
У автентичності користувачів Linux за допомогою Active Directory існує одна велика і поки що не згадана мною проблема - проблема унікальних ідентифікаторів (UID) для користувачів та груп. Внутрішньо ні Linux, ні Windows не називають користувачів їх реальними іменами, використовуючи натомість унікальний внутрішній ідентифікатор. У Windows використовуються ідентифікатори безпеки (SID), які є структурою змінної довжини і дають унікальний засіб пізнання кожного користувача в домені Windows. SID також містить унікальний ідентифікатор домену, щоб Windows могла розрізняти користувачів у різних доменах.
Схема Linux набагато простіша. Кожен користувач на комп'ютері Linux має ідентифікатор UID, що представляє собою просто 32-розрядне ціле число. Але область дії ідентифікатора UID обмежена самим комп'ютером. Немає жодної гарантії, що користувач з ідентифікатором UID 436 на одному комп'ютері Linux ідентичний користувачеві з ідентифікатором UID 436 на іншому комп'ютері Linux. Як наслідок, користувачеві необхідно підключатися до кожного комп'ютера, доступ якого йому потрібен, що є небажаною ситуацією.
Мережеві адміністратори Linux зазвичай вирішують цю проблему, надаючи мережну автентифікацію за допомогою або мережевої інформаційної системи (Network Information System - NIS), або загального каталогу LDAP. Мережева система автентифікації надає ідентифікатор UID для користувача, і всі комп'ютери Linux, що користуються цією системою, будуть користуватися тими ж ідентифікаторами користувача та групи. У цій ситуації я використовую Active Directory для надання унікальних ідентифікаторів користувачів та груп.
Для вирішення цієї проблеми я використовую дві стратегії. Перша (а також найбільш очевидна) стратегія – створити ідентифікатор UID для кожного користувача та групи та зберегти цей ідентифікатор за допомогою відповідного об'єкта в Active Directory. При її застосуванні, коли Winbind перевіряє справжність користувача, я можу подивитись його ідентифікатор UID і надати його Linux як внутрішній ідентифікатор даного користувача. Winbind посилається на цю схему як зіставлення ідентифікаторів Active Directory (або idmap_ad). На Рис. 17показаний процес зіставлення ідентифікаторів Active Directory.
Рис. 17. Процес зіставлення ідентифікаторів Active Directory
Єдиним недоліком зіставлення ідентифікаторів Active Directory є необхідність надання механізму наявності ідентифікаторів кожного користувача та групи, а також їх унікальності в межах лісу. Докладнішу інформацію можна знайти на бічній панелі «Налаштування Active Directory для порівняння ідентифікаторів Active Directory».
На щастя, існує ще одна стратегія зіставлення ідентифікаторів, що тягне набагато менше адміністративних витрат. Згадаймо, що ідентифікатор SID Windows унікально ідентифікує користувача всередині домену, а також сам домен. Частина ідентифікатора SID, що унікально ідентифікує користувача всередині домену, називається відносним ідентифікатором (RID) і є насправді 32-розрядним цілим числом. Так що Winbind може просто витягти RID із SID під час входу користувача в систему і потім використовувати RID як унікальний внутрішній ідентифікатор UID. Winbind посилається на цю стратегію як зіставлення ідентифікаторів RID або idmap_rid. На Рис. 18показано, наскільки реально працює зіставлення RID.
Рис. 18. Зіставлення RID
Зіставлення RID має перевагу нульових адміністративних витрат, але його не можна використовувати в багатодоменному середовищі через ймовірність наявності одного значення RID у користувачів у кількох доменах. Але за наявності одного домену Active Directory зіставлення RID – це правильний вибір.
Щоб настроїти стратегію зіставлення ID у Winbind, відкрийте файл /etc/samba/smb.conf для редагування знову і додайте рядок "idmap backend = ad" для використання стратегії зіставлення Active Directory, або "idmap backend = rid" для використання стратегії зіставлення RID. Переконайтеся у відсутності інших рядків, які вказують на стратегію зіставлення у файлі.
Існує низка інших параметрів, які потрібно додати до файлу smb.conf для Winbind. Навіть якщо PAM встановлений на створення домашнього каталогу для кожного користувача під час його входу в систему, необхідно сказати Winbind, що це за ім'я. Ми робимо це шляхом додавання рядка "template homedir = /home/%U" до smb.conf (див. Рис. 19). Це говорить Winbind, що домашнім каталогом для кожного користувача, який засвідчив свою автентифікацію за допомогою Active Directory, буде /home/<имя пользователя>. Не забудьте спершу створити каталог /home.
Рис. 19. Вказівка імені домашнього каталогу
Приєднання до домену та вхід до системи
Тепер, коли мережа, PAM, NSS і Samba Winbind налаштовані правильно, настав час приєднати комп'ютер Linux до домену. Це можна зробити за допомогою команди Net програми Samba. У запиті інтерпретатора команд виконайте "net ads join -U"<имя администратора>". Замініть<имя администратора>іменем облікового запису, що має достатньо повноважень для приєднання комп'ютерів до домену.
Команда net запросить пароль користувача. Якщо все спрацює нормально, вона приєднається до комп'ютера в домені. Для виявлення створеного облікового запису комп'ютера можна використовувати оснастку Active Directory - користувачі та комп'ютери.
Протестувати стан приєднання можна за допомогою тестового засобу Winbind, що називається wbinfo. Якщо виконати wbinfo -t, будуть протестовані стосунки довіри між комп'ютером та доменом. В результаті виконання wbinfo -u будуть перераховані всі користувачі домену, а wbinfo -g - всі групи.
У разі успішного приєднання комп'ютера Linux до домену наступним етапом буде спроба входу в систему за допомогою облікового запису користувача та пароля Active Directory. Вийдіть із системи на комп'ютері Linux і увійдіть до системи, використовуючи ім'я користувача Active Directory. Якщо все спрацює правильно, то можливість входу в систему має бути присутньою.
Налаштування Active Directory для процесу зіставлення ідентифікаторів Active Directory
Ця інформація застосовується лише для тих, хто використовує зіставлення ідентифікаторів Active Directory. Ті, хто вирішив використовувати зіставлення RID, можуть спокійно не звертати уваги на цю панель.
Перед тим, як увійти в систему на сервері Red Hat, використовуючи обліковий запис Active Directory, необхідно внести деякі зміни до Active Directory. По-перше, у схему Active Directory доведеться внести атрибути, які використовуються Winbind для зберігання інформації користувача. Під час роботи з Windows Server 2003 R2 схема готова до застосування. У разі більш ранньої версії схеми Active Directory її доведеться розширити, використовуючи пакет служб Microsoft Services for UNIX (SFU).
Додаткову інформацію можна знайти за адресою Services for UNIX на TechNet. SFU також включає додаткову сторінку властивостей для користувачів Active Directory Users та оснащення консолі керування комп'ютерами Майкрософт (Computers Microsoft Management Console - MMC), що дозволяє керувати інформацією про індивідуальний та груповий модифікатори, необхідної Linux.
Після того, як схема встановлена належним чином, необхідно надати ідентифікатори Linux всім користувачам (і груп, членами яких вони є), які можуть зайти на комп'ютер Linux. Це означає, що необхідно визначити значення для атрибутів uidNumber та gidNumber для користувачів та груп, які можуть зайти на комп'ютер Linux. Але слід пам'ятати про деякі вимоги до цих атрибутів:
- Linux вимагає ідентифікатора UID для кожного користувача, що засвідчує свою справжність. Оскільки нам необхідно керувати інформацією про користувачів в Active Directory, то кожен обліковий запис користувача, який входитиме в систему на комп'ютері Linux, повинен мати унікальний атрибут uidNumber. Конкретне значення, що використовується для uidNumber, є несуттєвим, але воно має бути унікальним для всіх користувачів, які можуть входити на комп'ютер Linux.
- Кожен користувач Linux повинен також мати ідентифікатор групи за промовчанням, так що кожен користувач Active Directory, що входить до комп'ютера Linux, також вимагає значення для атрибута gidNumber. Це значення має бути унікальним серед користувачів, але має унікально визначати групу.
- Кожна група Active Directory повинна мати унікальне значення для свого атрибуту gidNumber. Строго кажучи, для груп цілком нормально не мати значення для атрибуту gidNumber, але при автентичності користувача Winbind очікує, що кожна група, до якої той належить, матиме унікальне значення gidNumber. Ймовірно, набагато простіше просто переконатися в наявності кожної групи унікального значення gidNumber.
- Winbind очікує, що кожний користувач, який він перебуває в Active Directory, буде членом групи користувачів домену, так що він також очікує, що група користувачів домену має значення для свого атрибуту gidNumber.
А якщо це не запрацює?
Встановлення комп'ютера Linux на автентифікацію за допомогою Active Directory і через Winbind - нетривіальний проект. Існує маса елементів, які потрібно налаштувати, та безліч речей, які можна зробити неправильно. Той факт, що кожна версія Linux або Samba дещо різняться за своїми можливостями, не полегшує це завдання. Але існує низка джерел, що містять інформацію про те, що відбувається.
По-перше, це файл журналу системи Linux, що ведеться у /var/log/messages. Samba буде поміщати в цей файл повідомлення про значні події, такі як зникнення файлів або погана настройка. Крім файлу журналу системи, свої файли журналу є у Samba і Winbind. Їх можна знайти в /var/log/samba, і вони нададуть користувачеві додаткову інформацію.
Докладність (і обсяг) повідомлень журналів, що видаються Winbind, можна збільшити, змінивши сценарій запуску для встановлення рівня налагодження. Відредагуйте сценарій інтерпретатора команд /etc/init.d/winbind та додайте "-d 5" до команди winbind. Це збільшить рівень налагодження до 5 (припустимі значення від 1 до 10), що змусить winbind створювати більш детальні повідомлення про помилки.
Якщо Winbind доходить до зв'язку з контролером домену, можна провести запис мережевих пакетів за допомогою службової програми типу Netmon 3.1. Це дозволяє проаналізувати, що саме Winbind намагається зробити. Також можна вивчити журнал безпеки Windows на контролері домену, в який будуть внесені спроби автентифікації.
Тепер, коли це заробило, що ми маємо?
Якщо все злагоджено працює, то тепер можна входити в системи Linux, використовуючи облікові дані, що підтримуються в Active Directory. Це величезне покращення порівняно з локальним управлінням ідентифікацією на комп'ютері Linux або використанням небезпечної системи типу NIS. Це дозволяє централізувати управління користувачами в одному сховищі посвідчень Active Directory.
Але тут не вистачає деяких речей, які могли б зробити це рішення справді корисним. По-перше, отримання технічної підтримки тут – справа удачі. Багато організацій Linux не дуже розуміються на Active Directory, а підтримка, яку можна отримати від спільноти Linux, цілком залежить від того, хто прочитав ваше повідомлення і його настрої на сьогоднішній день.
Крім того, пакет Samba не має засобів перенесення або розгортання. У разі наявності облікових записів Linux, з якими пов'язані ідентифікатори користувачів та повноваження, необхідно вручну переконатися, що вони зберігають свої ідентифікатори UID під час перенесення їх до Active Directory.
Нарешті, одна з найважливіших програм Active Directory, групова політика, не доступна з Samba, хоча над цим йде робота. Хоча систему Linux можна приєднати до Active Directory за допомогою Samba, її не можна керувати, використовуючи групову політику.
Рішення від сторонніх виробників
Перевірка справжності для комп'ютерів Linux за допомогою Active Directory - очевидно, гарна справа, але створення власного рішення за допомогою Samba Winbind втомлює, якщо не просто кошмарне. Читачі можуть подумати, що хтось із винахідливих постачальників ПЗ повинен виступити з більш простим у використанні рішенням, і вони мають рацію.
Чотири постачальники комерційного програмного забезпечення розробили прості в установці та використанні версії того, що я продемонстрував у цій статті. Вони надають код і засоби перенесення для багатьох популярних версій Linux, UNIX і Apple Macintosh, а також підтримку управління комп'ютерами Linux за допомогою групової політики.
Чотири компанії це: Centrify, Likewise Software, Quest Software та Symark. Усі чотири постачальники надають схожі функції, включаючи керування груповою політикою у широкому спектрі випусків Linux. Likewise Software нещодавно відкрила код своєї реалізації, що називається Likewise Open, хоча її компонент групової політики залишається комерційним продуктом. Likewise Open буде доступним для кількох великих випусків Linux. (Розкрити секрет: поки я писав цю статтю, моя компанія, NetPro, була придбана Quest Software.)
Чи має сенс будувати власну систему автентичності, використовуючи Samba і Winbind, коли доступні комерційні варіанти? Якщо бюджет не передбачає грошей на програми інтеграції, використання Samba з його відкритим кодом має перевагу безкоштовності. При цьому також отримуєш весь вихідний код, що може бути привабливою перевагою. Але перенесення існуючих комп'ютерів Linux та їх існуючих ідентифікаторів UID – дуже терниста проблема.
З іншого боку, якщо потрібно заощадити час на реалізацію та установку, або є існуючі комп'ютери Linux, які потрібно перенести, або краща відповідь фахівця на питання, то знайомство з комерційними рішеннями має сенс. У разі необхідності управління групової політикою їм немає альтернативи.
Але будь-яке рішення щодо інтеграції автентичності системами Linux з Active Directory скорочує зусилля, що йдуть на керування кількома обліковими записами користувачів, покращує безпеку системи та надає єдине сховище посвідчень для керування та аудиту. І це досить обґрунтовані причини, щоб спробувати застосувати його.
Джил Кіркпатрік- Вперед >
Двофакторна аутентифікація (2FA) — це метод аутентифікації, який для входу в обліковий запис або пристрій вимагає кілька фрагментів інформації. Крім комбінації імені користувача та пароля, 2FA вимагає, щоб користувач вводив додаткову інформацію, таку як одноразовий пароль (OTP, наприклад, шестизначний перевірочний код).
В цілому, 2FA вимагає від користувача введення інформації різних типів:
- Щось, що користувач знає (наприклад, пароль)
- Щось, що користувач має (наприклад, код підтвердження, згенерований спеціальним додатком – автентифікатором).
2FA – це підвид багатофакторної автентифікації (MFA). Метод MFA на додаток до того, що користувач знає, і тому, що має, вимагає чогось, чим він є. Це біометричні дані: розпізнавання відбитків пальців чи голоси тощо.
2FA допомагає захистити процес автентифікації для певного сервісу або пристрою: навіть якщо пароль був зламаний, зловмиснику також знадобиться код безпеки, а для цього потрібен доступ до пристрою користувача, в якому знаходиться програма-автентифікатор. З цієї причини багато онлайн-сервісів пропонують можливість увімкнути 2FA для облікових записів користувачів, щоб підвищити безпеку акаунтів на рівні автентифікації.
У цьому мануалі ви дізнаєтеся, як настроїти 2FA за допомогою модуля Google PAM для користувача без привілеїв root в Ubuntu 18.04. Оскільки ви налаштовуєте 2FA для не-root користувача, у разі блокування ви все одно зможете отримати доступ до комп'ютера зі свого облікового запису root. Інструкції мануалу досить загальні, тому їх можна застосувати як до серверів, так і настільних установок, як локальних, так і віддалених.
Вимоги
- Сервер Ubuntu 18.04 або настільне робоче середовище. Сервер Ubuntu 18.04 потрібно налаштувати на .
- Аутентифікатор, встановлений на мобільний пристрій (наприклад, Google Authenticator або Authy). З його допомогою ви скануватимете QR-коди безпеки.
1: Встановлення модуля Google PAM
Щоб настроїти 2FA в Ubuntu 18.04, вам потрібно встановити модуль Google PAM для Linux. Pluggable Authentication Module (PAM) – це механізм автентифікації Linux. Модуль Google PAM дозволить вашому користувачеві проходити аутентифікацію 2FA, використовуючи згенеровані Google коди OTP.
Спочатку увійдіть у систему як користувач sudo, якого ви створили під час початкового настроювання сервера:
ssh [email protected] _server_ip
Оновіть індекс пакетів Ubuntu, щоб отримати останню версію автентифікатора:
sudo apt-get update
Обновивши репозиторії, установіть останню версію модуля PAM:
sudo apt-get install libpam-google-authenticator
Це дуже маленький пакет без залежностей, тому установка займе кілька секунд. У наступному розділі ми налаштуємо 2FA для користувача sudo.
2: Налаштування двофакторної автентифікації
Тепер, коли ви встановили модуль PAM, запустіть його, щоб згенерувати QR-код для користувача. Це створить код, але серед Ubuntu не потрібно 2FA, поки ви не включите її.
Запустіть команду google-authenticator, щоб запустити та налаштувати модуль PAM:
google-authenticator
Команда задасть вам кілька питань щодо конфігурації. Спочатку вона запитає, чи ви хочете, щоб токени були обмежені за часом. Токени автентифікації, обмежені за часом, закінчуються через певний інтервал (за замовчуванням становить 30 секунд більшості систем). Токени з обмеженим часом дії безпечніші, ніж токени без такого обмеження, і більшість реалізацій 2FA використовують їх. Ви можете вибрати тут будь-який варіант, але ми рекомендуємо вибрати Yes та використовувати токени автентифікації, обмежені за часом:
Do you want authentication tokens to be time-based (y/n) y
Відповівши y на це питання, ви побачите кілька рядків виведення в консолі:
- QR-код: це код, який потрібно сканувати за допомогою програми-автентифікатора. Після того, як ви відсканували його, програма буде створювати новий OTP кожні 30 секунд.
- Секретний ключ: це альтернативний спосіб налаштування програми автентифікації. Якщо ви використовуєте програму, яка не підтримує сканування QR, ви можете ввести секретний ключ, щоб настроїти автентифікатор.
- Код перевірки: це перший шестизначний код, який генерує цей конкретний QR-код.
- Аварійні скретч-коди. це одноразові токени (також вони називаються резервними кодами), вони дозволять вам пройти аутентифікацію 2FA, якщо ви втратите пристрій-аутентифікатор. Зберігайте ці коди в надійному місці, щоб уникнути блокування облікового запису.
Після того, як ви налаштували свою програму-автентифікатор і зберегли свої резервні коди в безпечному місці, програма запитає, чи хочете ви оновити файл конфігурації. Якщо ви оберете n, вам потрібно буде знову запустити програму налаштування. Введіть y, щоб зберегти зміни та продовжити:
Do you want me to update your "~/.google_authenticator" file (y/n) y
Далі програма запитає, чи ви хочете заборонити використання кодів аутентифікації більше одного разу. За замовчуванням ви можете використовувати кожен код лише один раз, навіть якщо ще не минуло 30 секунд з моменту його створення. Це найбезпечніший вибір, тому що він запобігає атакам повторного відтворення від зловмисника, якому якимось чином вдалося отримати ваш використаний код підтвердження. Тому краще заборонити використання кодів більше одного разу. Дайте відповідь y, щоб заборонити багаторазове використання одного і того ж токена:
Do you want to disallow multiple uses of the same authentication
token? Цей список ви знаєте, що протягом 30-х років, але це зростає
ваші зміни до пояснень або навіть допоможуть людині-всього аттаки (y/n) y
Потім потрібно вказати, чи ви хочете, щоб токени автентифікації приймалися деякий час після закінчення їх звичайного терміну дії. Коди дуже чутливі до часу, тому вони можуть не спрацювати, якщо ваші пристрої не синхронізовані. Ця опція дозволяє обійти цю проблему, збільшивши час дії кодів перевірки за промовчанням, щоб коди автентифікації були прийняті у будь-якому випадку (навіть якщо ваші пристрої тимчасово не синхронізовані). Найкраще переконатися в тому, що час на всіх ваших пристроях синхронізований, тому що відповідь yes трохи знизить безпеку системи. Дайте відповідь n на це питання, щоб не збільшувати термін дії токена:
By default, tokens є good for 30 seconds and in order to compensate for
можливий time-skew між клієнтом і сервером, які можуть бути extra
token before and after the current time. If you experience problems with poor
time synchronization, ви можете збільшити window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) n
Останнє питання: чи ви хочете включити обмеження кількості спроб входу до системи. Це не дозволить користувачеві зробити більше трьох невдалих спроб входу в систему протягом 30 секунд, що посилить безпеку системи. Увімкніть це обмеження, відповівши y:
If the computer that you are logging into isn"t hardened against brute-force
Login attempts, Ви можете забезпечувати обмеження обмеження для authentication module.
By default, ці обмеження attackers не більше 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y
Ви налаштували та згенерували коди 2FA за допомогою модуля PAM. Тепер потрібно включити 2FA у вашому середовищі.
3: Активація 2FA в Ubuntu
Модуль Google PAM тепер генерує коди 2FA для користувача, але система Ubuntu ще не знає, що їй потрібно використовувати коди в процесі аутентифікації. На цьому етапі потрібно оновити конфігурацію Ubuntu, щоб налаштувати підтримку токенів 2FA на додаток до звичайної автентифікації.
Тут є два шляхи:
- Ви можете вимагати двофакторної аутентифікації щоразу, коли користувач входить до системи, і кожен раз, коли користувач запитує права sudo.
- Ви можете вимагати 2FA лише під час входу в систему, тоді при запиті прав sudo буде потрібно лише пароль користувача.
Перший варіант буде ідеальним для загального середовища, де бажано захистити будь-які дії, що вимагають привілеїв sudo. Другий підхід практичніший для локального середовища робочого столу, де ви є єдиним користувачем у системі.
Примітка: Якщо ви вмикаєте 2FA на віддаленій машині, до якої ви отримуєте доступ по SSH, вам необхідно виконати кроки два і три з мануалу , перш ніж продовжувати роботу. Інші кроки в цьому мануалі застосовні до всіх установок Ubuntu, але віддалені середовища потребують додаткових налаштувань, щоб сервіс SSH знав про 2FA.
Якщо ви не використовуєте SSH для доступу до установки Ubuntu, ви можете відразу ж перейти до інших кроків у цьому мануалі.
Запит 2FA при вході в систему та підвищення прав sudo
Щоб система використовувала 2FA під час входу та подальших запитів на підвищення привілеїв, вам необхідно відредагувати файл /etc/pam.d/common-auth, додавши рядок до кінця існуючого файлу.
Файл common-auth застосовується до всіх механізмів автентифікації в системі, незалежно від середовища. Він також застосовується до запитів автентифікації, які відбуваються після входу користувача в систему, наприклад, під час запиту прав sudo, коли встановлений новий пакет з терміналу.
Відкрийте файл:
sudo nano /etc/pam.d/common-auth
До кінця файлу додайте:
...
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
Цей рядок включає в систему аутентифікації Ubuntu підтримку 2FA під час входу через модуль Google PAM. Опція nullok дозволяє існуючим користувачам увійти до системи, навіть якщо вони не налаштували автентифікацію 2FA для свого облікового запису. Іншими словами, користувачі, які налаштували 2FA, повинні будуть ввести код автентифікації при наступному вході в систему, у той час як користувачі, які не запустили команду google-authenticator, зможуть увійти до системи за своїми стандартними обліковими даними, доки вони не налаштують 2FA.
Збережіть та закрийте файл.
Запит 2FA лише при вході в систему
Якщо ви хочете, щоб 2FA запитувалася тільки при вході в систему в середовищі робочого столу, вам потрібно відредагувати конфігураційний файл менеджера робочого стола, який ви використовуєте. Ім'я файлу конфігурації зазвичай збігається з ім'ям середовища робочого столу. Наприклад, файл конфігурації для gdm (середовища Ubuntu за замовчуванням, починаючи з Ubuntu 16.04), - /etc/pam.d/gdm.
У разі headless сервера (яким є віртуальний сервер), натомість вам потрібно відредагувати файл /etc/pam.d/common-session. Відкрийте відповідний файл залежно від вашого середовища:
sudo nano /etc/pam.d/common-session
Додайте виділені рядки до кінця файлу:
#
# /etc/pam.d/common-session - session-related modules common to all services
#
...
# # and here are more per-package modules (the "Additional" block)
session required pam_unix.so
session optional pam_systemd.so
# end of pam-auth-update config
auth required pam_google_authenticator.so nullok
Тепер Ubuntu вимагатиме 2FA, коли користувач підключається до системи через командний рядок (локально чи віддалено через SSH), але на запуск команд із sudo це поширюватися не буде.
Ви налаштували Ubuntu для підтримки 2FA. Тепер настав час протестувати конфігурацію і переконатися, що при вході до вашої системи Ubuntu вам буде запропоновано ввести код безпеки.
4: Тестування двофакторної автентифікації
Раніше ви налаштували 2FA для створення кодів кожні 30 секунд. Тепер спробуйте увійти до свого середовища Ubuntu.
Спочатку вийдіть із системи і знову увійдіть у своє середовище Ubuntu:
ssh [email protected] _server_ip
Якщо ви використовуєте автентифікацію на основі пароля, вам буде запропоновано ввести пароль користувача:
Примітка: Якщо на віддаленому сервері ви використовуєте автентифікацію за сертифікатами, пароль не буде запрошено. Ключ буде передано та прийнято автоматично. Вам потрібно буде ввести лише код підтвердження.
Введіть пароль, після чого вам буде запропоновано ввести код 2FA:
Verification code:
Після цього ви потрапите до системи:
[email protected] _server_ip: ~#
Якщо 2FA була увімкнена тільки для входу в систему, вам більше не потрібно буде вводити коди підтвердження 2FA, поки не закінчиться сеанс або ви не вийдете вручну.
Якщо ви увімкнули 2FA через файл common-auth, вам буде запропоновано вказати його також при кожному запиті привілеїв sudo:
[email protected] _server_ip: ~# sudo -s
sudo password for 8host:
Verification code:
[email protected] _server_ip:
Ви переконалися, що конфігурація 2FA працює належним чином. Якщо щось пішло не так і система не запросила коди підтвердження, поверніться до третього розділу керівництва і переконайтеся, що ви відредагували правильний файл аутентифікації Ubuntu.
5: Запобігання блокуванню 2FA
На випадок втрати або знищення мобільного пристрою важливо передбачити методи резервного копіювання для відновлення доступу до вашого облікового запису за допомогою 2FA. Коли ви налаштовуєте 2FA вперше, у вас є кілька варіантів відновлення доступу після блокування:
- Збережіть резервну копію секретних кодів конфігурації в безпечному місці. Ви можете зробити це вручну, але деякі автентифікації, такі як Authy, надають функції резервного копіювання коду.
- Збережіть коди відновлення в безпечному місці за межами середовища з підтримкою 2FA, до якого можна отримати доступ у разі потреби.
Якщо у вас немає доступу до параметрів резервного копіювання, ви можете спробувати відновити доступ до локального середовища або віддаленого сервера з підтримкою 2FA іншим шляхом.
6: Відновлення доступу до локального середовища (опціонально)
Якщо у вас є фізичний доступ до машини, ви можете завантажити в режимі відновлення, щоб вимкнути 2FA. Режим відновлення – це цільовий тип (подібний до рівня виконання) в Linux, який використовується для виконання адміністративних завдань. Вам потрібно буде відредагувати деякі налаштування в GRUB, щоб увійти до режиму відновлення.
Щоб отримати доступ до GRUB, спочатку перезавантажте комп'ютер:
Коли з'явиться меню GRUB, переконайтеся, що запис Ubuntu виділено. Це ім'я установки 18.04 за промовчанням, але воно може відрізнятися, якщо ви змінили його вручну після встановлення.
Потім натисніть клавішу e на клавіатурі, щоб відредагувати конфігурацію GRUB перед завантаженням вашої системи.
Перейдіть в кінець файлу і знайдіть рядок, який починається з linux і закінчується $vt_handoff. Перейдіть до кінця цього рядка і додайте systemd.unit=rescue.target. Переконайтеся, що ви залишаєте пробіл між $vt_handoff і systemd.unit=rescue.target. Це дозволить машині Ubuntu завантажитись у режимі відновлення.
Після внесення змін збережіть файл за допомогою комбінації клавіш Ctrl + X. Ваша машина перезавантажиться, і ви опинитеся в командному рядку. Натисніть клавішу Enter, щоб перейти до режиму відновлення.
Опинившись у командному рядку, відкрийте конфігураційний файл Google Authenticator, який знаходиться у домашньому каталозі заблокованого користувача.
nano /home/8host/.google-authenticator
Перший рядок у цьому файлі – секретний ключ користувача, який використовується для налаштування автентифікатора.
Тепер у вас є два варіанти:
- Ви можете скопіювати секретний ключ та настроїти автентифікатор.
- Якщо ви хочете почати з чистого аркуша, ви можете повністю видалити файл ~/.google-authenticator, щоб вимкнути 2FA для цього користувача. Після повторного входу в систему ви зможете знову налаштувати 2FA і отримати новий секретний ключ.
У будь-якому випадку, ви можете відновити систему після блокування 2FA в локальному середовищі за допомогою завантажувача GRUB. Далі ми розповімо, як відновити доступ до заблокованого віддаленого середовища.
7: Відновлення доступу до віддаленого середовища (опціонально)
Якщо ваш обліковий запис sudoer заблоковано у віддаленому середовищі, ви можете тимчасово відключити або переналаштувати 2FA за допомогою користувача root.
Увійдіть до системи як користувач root:
ssh [email protected] _server_ip
Після входу в систему відкрийте файл налаштувань Google Authenticator, який знаходиться в домашньому каталозі заблокованого користувача:
sudo nano /home/8host/.google_authenticator
Перший рядок у цьому файлі – це секретний ключ користувача, який вам потрібний для налаштування автентифікатора.
Тепер у вас є два шляхи:
- Якщо ви бажаєте налаштувати новий або стертий пристрій, ви можете використовувати секретний ключ для переналаштування програми автентифікатора.
- Якщо ви бажаєте почати з чистого листа, ви можете повністю видалити файл /home/8host/.google_authenticator, щоб вимкнути 2FA для цього користувача. Після входу в систему як користувач sudo, ви зможете ще раз налаштувати 2FA і отримати новий секретний ключ.
За будь-якого з цих варіантів ви зможете відновитися після випадкового блокування 2FA, використовуючи обліковий запис root.
Висновок
У цьому мануалі ви налаштували 2FA на машині Ubuntu 18.04. Двофакторна автентифікація забезпечує додатковий рівень захисту облікового запису та системи в цілому. Крім стандартних облікових даних, вам також потрібно ввести додатковий код підтвердження для входу в систему. Це робить неможливим отримати несанкціонований доступ до вашого облікового запису, навіть якщо зловмиснику вдасться отримати ваші облікові дані.
Tags: ,- Встановлена система ROSA Enterprise Linux Server версії не нижче 6.8 у конфігурації "Стандартний сервер РОСА"
- Доступ до репозиторій
- Пристрій Рутокен ЕЦП/Рутокен ЕЦП Flash/Рутокен ЕЦП SC разом із рідером. На пристрій повинен бути записаний сертифікат
Для отримання доступу до репозиторій отримайте у служби підтримки ключ і виконайте наступну команду з правами адміністратора:
Echo<ключ>> /etc/rosa-support-id-server
Застосовність
В інструкції описано встановлення та налаштування утиліт ROSA Enterprise Linux Server, необхідних для аутентифікації з використанням Рутокен ЕЦП. У прикладі використається архітектура AMD64; для 32-розрядної системи всі дії будуть аналогічні до назв папок.
Після виконання наведеної нижче процедури автентифікація по Рутокен ЕЦП стане можливою, але не буде обов'язковою.
Встановлення компонентів
Встановіть необхідні та видаліть конфліктуючі утиліти (потрібні права адміністратора):
Su yum install ccid opensc pam_pkcs11 gdm-plugin-smartcard yum remove coolkey
Встановіть бібліотеку PKCS#11 для Рутокен ЕЦП (важливо встановлювати бібліотеку після установки утиліт):
- Перейдіть на сайт Рутокен: https://www.rutoken.ru/support/download/pkcs/.
- Перейдіть на вкладку «Користувачам GNU/Linux» та натисніть посилання «Бібліотека rtPKCS11ecp для GNU/Linux RPM 64-bit (x64)».
- Завантажте та встановіть пакет (потрібен пароль адміністратора).
Налаштування
Перевірка відображення пристрою в системі та наявності на ньому потрібної інформації
- Запустіть pcscd(потрібні права адміністратора):
- Завершіть існуючий процес pcscd, якщо такий був:
З цього моменту токен має бути вставлений у відповідний роз'єм.
- Виконайте:
- Відкрийте окрему вкладку або вікно терміналу та виконайте в ній наступну команду:
У виводі повинні бути видні параметри та назва пристрою. Приклад виведення наведено нижче.
- Перевірте наявність на токені потрібної інформації за допомогою наступної команди (потрібний пароль від токена):
У висновку повинен бути Certificate Object. Такі параметри, як ID та label, можуть відрізнятися від наведених нижче.
Додавання сертифіката довірені
- Створіть базу даних довірених сертифікатів (потрібні права адміністратора):
- Скопіюйте сертифікат з токена (потрібний пароль токена. Параметр ID можна взяти з виводу команди pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so -O -l) :
- Додайте сертифікат у довірені (потрібні права адміністратора):
Зміна конфігураційних файлів
Для зміни конфігураційних файлів потрібні права адміністратора.
pam_pkcs11.conf
- Створіть (наприклад, на робочому столі) текстовий файл pam_pkcs11.conf з таким вмістом:
- Помістіть файл у каталог /etc/pam_pkcs11/:
system-auth
- Підключіть модуль до системи авторизації PAM:
- Відкрийте файл system-auth у редакторі nanoабо mcedit:
- Додайте вгорі наступний рядок:
- Збережіть файл (
subject_mapping
- Виконайте команди:
- Скопіюйте виведення попередньої команди у файл /etc/pam_pkcs11/subject_mapping та вкажіть, якому користувачеві належить сертифікат.
Рядок конфігурації має вигляд:
Виведення команди pkcs11_inspect -><имя_пользователя>
Перевірка аутентифікації через консоль
- Відкрийте нове вікно або вкладку консолі.
- Виконайте команду su<имя_пользователя>(ім'я користувача вказано у subject_mapping).
Приклад виведення:
Після перевірки аутентифікації через консоль можна прибрати режим налагодження. Для цього у файлі /etc/pam.d/sysauth у доданому рядку заберіть слово debug, а у файлі /etc/pam_pkcs11/pam_pkcs11.conf поставте напроти debug false замість true.
Налаштування блокування екрану
- Відкрийте для редагування файл pkcs11_eventmgr (потрібні права адміністратора):
Після редагування конфігураційний файл має виглядати так:
Pkcs11_eventmgr (# Run in background? Implies debug=false if true daemon = true; # show debug messages? debug = false; # polling time in seconds polling_time = 1; # expire time in seconds # default = 0 (no expire) exp 0; # pkcs11 module to use pkcs11_module = /usr/lib64/librtpkcs11ecp.so; # # list of events and actions # Card inserted event card_insert # end action sequence # quit: end program on_error = ignore; ) # Card has been removed event card_remove ( on_error = ignore; action = "gdmflexiserver"; ) # Too much time card removed event expire_time ( on_error = ignore; action = "/bin /false"; ) )
- Додати утиліту pkcs11_eventmgrв автозавантаження. Для цього відредагуйте файл.bash_profile користувача, що проходить аутентифікацію:
- Додайте в кінець файлу рядок, що запускає pkcs11_eventmgr.
Приклад файлу.bash_profile після редагування:
При виборі аутентифікації за допомогою токена екран виглядатиме приблизно так.
З 2020 року використання шифрування за ГОСТ Р 34.10-2001 опиниться під забороною, а отже, всі організації, які взаємодіють із держструктурами, змушені терміново впроваджувати наступний стандарт – 2012 року. Якщо ти працюєш в одній з них, то не проходь мимо: у цій статті ми поговоримо про те, як вирішити проблему, використовуючи сервер CentOS 7 і пакет CryptoPro JCP.
Якщо ж ти вперше чуєш про все це, то невелика історична довідка.
У 1994 році у ФСБ розробили низку стандартів та заходів, покликаних захистити обмін документами між організаціями та іншими учасниками цього процесу. Одним із таких заходів безпеки став електронний цифровий підпис документів, а одним із стандартів - ГОСТ Р 34.10-94, де описано алгоритм формування та перевірки електронного цифрового підпису. Прийнятий і введений у дію ухвалою Держстандарту Росії від 23 травня 1994 року за номером 154, він пропрацював до 2001 року.
На зміну прийшов усім відомий ГОСТ Р 34.10-2001 – покращений стандарт, розроблений для забезпечення більшої стійкості алгоритму. Але час не стоїть на місці, змінюються алгоритми та методи криптозахисту, і через одинадцять років ГОСТ Р 34.10-2001 змінюють на ГОСТ Р 34.10-2012.
У новому стандарті перший варіант вимог до параметрів залишився незмінним. Довжина секретного ключа становить близько 256 біт, та передбачено використання хеш-функції з довжиною хеш-коду 256 або 512 біт. Головна ж відмінність нового стандарту – варіанти з додатковими параметрами та схемами, у тому числі хешуванням за стандартом ГОСТ Р 34.11-2012 «Стрибог».
INFO
Стрибог - бог стародавніх слов'ян, який заступається вітрам, погоді та всьому, що пов'язане з повітряним простором. Можливо, і хмарним технологіям також. Докладніше про це шифрі читай у статтях "" та "".
У лютому 2014 року ФСБ оголосила про початок переходу на використання нового національного стандарту ГОСТ Р 34.10-2012 у засобах електронного підпису для інформації, що не містить відомостей, що становлять державну таємницю. У світ вийшов документ за номером 149/7/1/3-58 від 31 січня 2014 року «Про порядок переходу до використання нових стандартів ЕЦП та функції хешування», він встановлював такі вимоги.
- Після 31 грудня 2013 року припинити сертифікацію засобів електронного підпису на відповідність вимогам до засобів електронного підпису, затвердженим наказом ФСБ Росії від 27.12.2011 року №796, якщо у цих засобах не передбачається реалізація функцій відповідно до ГОСТу Р 34.10-201.
- Після 31 грудня 2018 року заборонити використання ГОСТ Р 34.10-2001 для формування електронного підпису.
Міністерство зв'язку навіть створило план переходу на стандарт (PDF). Проте на практиці виявилося, що все не так просто, і перехід довелося відкласти до 31 грудня 2019 року. Причини такі.
- Багато державних та муніципальних органів не готові перейти на використання нового стандарту електронного підпису ГОСТ-2012 через відсутність підтримки на рівні ПЗ.
- Щоб випускати сертифікати нового зразка, необхідно обладнання, яке підтримує новий ГОСТ, та сертифікат Головного центру, що свідчить, сформований з використанням ГОСТ-2012. Посвідчувальні центри отримали його лише влітку 2018 року. Потрібний додатковий час, щоб випустити сертифікати для всіх користувачів.
Зараз у ході два стандарти криптозахисту для роботи ЕЦП, але тим, хто використовує ГОСТ-2001, терміново потрібно щось робити. Зима, як кажуть, близько, а це означає, що на нас чекає низка випробувань при впровадженні підтримки ГОСТ-2012.
Я розповім, як розвернути сертифікований ФСБ засіб СКЗІ (CryptoPro JCP) на сервері Linux під керуванням Java JDK. До речі, якщо ти досі використовуєш ДЕРЖСТАНДАРТ-2001, на сайті CryptoPro є чудова, раджу тобі її прочитати, зайвим не буде.
Весь документообіг між учасниками обміну відбувається за принципом СМЕВ (система міжвідомчої електронної взаємодії). Додаток може бути учасником такої системи, але може і не бути ним зовсім принцип обміну документами від цього не змінюється. Для простоти розуміння намалював невелику схему.
Ціни
Як завжди, постає питання ліцензування програмного рішення. CryptoPro JCP недешевий, і якщо одна робоча станція обійдеться в 1200 рублів, то серверні ліцензії коштують значно дорожче – близько 30 000 за кожне ядро (або два ядра процесора Intel з відключеним Hyper Threading).
Встановлення та налаштування криптопровайдера
У прикладах я використовуватиму віртуальну машину з CentOS 7, але ти не обмежений у виборі апаратного забезпечення та дистрибутива Linux. Усі дії та команди будуть такими самими.
Насамперед створимо локального користувача, під яким працюватиме ПЗ, що використовує підпис документів.
$ sudo useradd -d /opt/user -p<Тут указываем пароль>-s /bin/bash user; sudo grep user /etc/passwd
Правильно встановимо Java JDK. Викачуємо необхідний дистрибутив.
$wget --header "Cookie: oraclelicense=a" .gz -O jdk-8u191-linux-x64.tar.gz
Розпаковуємо архів та перевіряємо, чи готова папка з Java для копіювання.
$ tar zxvf jdk-8u191-linux-x64.tar.gz; ls -al;
Копіюємо папку в розділ для прикладного ПЗ. Я зазвичай використовую /opt.
$ sudo cp -rf jdk1.8.0_191 /opt/
Перевіряємо, що скопіювалося правильно. Якщо потрібно, міняємо власника папки на root.
$ ls -al /opt/jdk1.8.0_191/ $ sudo chown -R root:root /opt/jdk1.8.0_191/; cd /opt/jdk1.8.0_191/; ls -al;
Прописуємо змінні оточення Java JDK для всіх користувачів за замовчуванням.
$ sudo vi /etc/profile.d/oracle.sh
У файл пишемо наступне:
Export JAVA_HOME=/opt/jdk1.8.0_191 export JRE_HOME=/opt/jdk1.8.0_191/jre export PATH=$PATH:/opt/jdk1.8.0_191/bin:/opt/jdk1.8.0_191/jre/
Якщо на сервері стоїть кілька версій Java JDK, необхідно зареєструвати альтернативи для нової версії.
$ sudo alternatives --install /usr/bin/java java /opt/jdk1.8.0_191/bin/java 2 $ sudo alternatives --install /usr/bin/jar jar /opt/jdk1.8.0_191/bin/jar 2 $ sudo alternatives --install /usr/bin/javac javac /opt/jdk1.8.0_191/bin/javac 2 $ sudo alternatives --set jar /opt/jdk1.8.0_181/bin/jar $ sudo alternatives --set jar /opt/jdk1.8.0_191/bin/jar $ sudo alternatives --set javac /opt/jdk1.8.0_191/bin/javac $ sudo alternatives --config java
У меню вибираємо опцію 2 (або ту, що призведе до використання новішої версії Java). Не забуваймо виправити права на JRE systemPrefs.
$ sudo chmod 777 -R /opt/jdk1.8.0_191/jre/.systemPrefs
Перевіряємо встановлену версію Java.
$ java -version
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
Копіюємо папку з дистрибутивом CryptoPro JCP у розділ для прикладного ПЗ.
$ sudo cp -rf jcp-2.0.40035 /opt/
Перевіряємо, що все скопіювалося коректно.
$ ls -al /opt/jcp-2.0.40035/
Видаємо права на запуск скриптів.
$ sudo chmod +x /opt/jcp-2.0.40035/*.sh
Перевіряємо власника та права на папку, має бути root. Переходимо до неї.
$ ls -al /opt/jcp-2.0.40035/; cd /opt/jcp-2.0.40035/;
Щоб уникнути проблем при інсталяції, перевір кількість ядер на процесорі і звірся з ліцензією. Дізнатися кількість ядер можна командою nproc.
Переходимо до встановлення криптопровайдера JCP. Під час встановлення необхідно буде відповісти на низку запитань.
Продовження доступне лише учасникам
Варіант 1. Приєднайтесь до спільноти «сайт», щоб читати всі матеріали на сайті
Членство у спільноті протягом зазначеного терміну відкриє тобі доступ до ВСІХ матеріалів «Хакера», збільшить особисту накопичувальну знижку та дозволить накопичувати професійний рейтинг Xakep Score!
