Загальна мудрість щодо автентифікації Active Directory для серверів Linux?

Яка загальна думка в 2014 році щодо автентифікації / інтеграції Active Directory для серверів Linux та сучасних операційних систем Windows Server (орієнтована на CentOS / RHEL)?

За роки з моїх перших спроб інтеграції у 2004 році, схоже, найкращі практики навколо цього змінилися. Я не зовсім впевнений, який метод наразі має найбільшу швидкість.

У полі я бачив:

Winbind / Samba
Straight-up LDAP
Іноді LDAP + Kerberos
Microsoft Windows Services для Unix (SFU)
Microsoft Identity Management для Unix
NSLCD
SSSD
FreeIPA
Centrify
Powerbroker ( так само )

Вінбінд завжди здавався жахливим і ненадійним. Комерційні рішення типу Centrify та аналогічно завжди працювали, але здавалися непотрібними, оскільки ця можливість задіяна в ОС.

В останніх кількох установок, які я зробив, було додано функцію Microsoft Identity Management для Unix до сервера Windows 2008 R2 та NSLCD на стороні Linux (для RHEL5). Це працювало до RHEL6, де відсутність обслуговування NSLCD та управління ресурсами пам’яті змусило змінити SSSD. Red Hat також здавалося, що підтримує підхід SSSD, так що це добре для мого використання.

Я працюю з новою установкою, у якій контролери домену - це основні системи Windows 2008 R2 і не мають можливості додавати функцію управління ідентичністю для ролі Unix. І мені кажуть, що ця функція застаріла вже не присутня в Windows Server 2012 R2 .

Перевагою встановлення цієї ролі є наявність цього графічного інтерфейсу, в той час як дозволяє легко керуватися атрибутами користувача в один крок.

Але ...

Параметр Інструменти сервера для мережевої інформації (NIS) для інструментів віддаленого адміністрування сервера (RSAT) застарілий. Використовуйте вбудовані параметри LDAP, клієнта Samba, Kerberos або не-Майкрософт.

Це ускладнює покладання на нього, якщо це може порушити сумісність вперед. Замовник хоче використовувати Winbind, але все, що я бачу з боку Red Hat, вказує на використання SSSD.

Який правильний підхід?
Як ви справляєтесь із цим у своєму оточенні?

У березні 2014 року Red Hat опублікувала довідкову архітектуру для інтеграції Red Hat Enterprise Server з Active Directory . (Цей матеріал, безумовно, повинен бути актуальним та актуальним.) Я не люблю публікувати це як відповідь, але насправді просто занадто багато матеріалу для передачі у поле відповідей.

Цей документ (виправлений) є надзвичайним для преси, схоже, фокусується на нових функціях Red Hat Enterprise Linux (RHEL) 7. Він був опублікований на Саміті минулого тижня.

Якщо це посилання залишиться несвіжим, будь ласка, повідомте мене, і я відповідно оновлю відповідь.

Я особисто використовував WinBind досить надійно для аутентифікації. Існує дуже рідкісний збій служби, який вимагає, щоб хтось із root або іншим локальним обліковим записом увійшов і відмовив winbindd. Це, мабуть, може бути вирішено за допомогою належного моніторингу, якщо ви докладете зусиль для цього.

Варто зазначити, що Centrify має додаткові функціональні можливості, хоча це може бути забезпечено окремим управлінням конфігурацією. (Лялечка тощо)

Редагувати 16.06.14:

Red Hat Enterprise Linux 7 Інструкція з інтеграції Windows

re: "Комерційні рішення типу Centrify та аналогічно завжди працювали, але здавалися непотрібними, оскільки ця можливість задіяна в ОС".

Добре, я думаю, що більшість з нас вже багато років чує, що операційна система XYZ нарешті розбиває головоломку інтеграції AD. Проблема ІМХО полягає в тому, що для постачальника ОС інтеграція AD - це функція прапорця, тобто їм потрібно доставити щось, що сорта працює, щоб отримати цей прапорець, і цей прапорець зазвичай працює лише на ...

1. їх платформи ОС і
2. поточну версію цієї платформи та
3. проти новітньої версії Active Directory.

Реальність полягає в тому, що більшість середовищ не є монолітними з точки зору постачальника ОС та версії ОС, і вони матимуть старіші версії AD. Ось чому такий постачальник, як Centrify, повинен підтримувати 450+ ароматів UNIX / Linux / Mac / тощо. проти Windows 2000 до Windows 2012 R2, а не лише RHEL 7 знову Windows 2012 R2.

Крім того, вам потрібно врахувати, як розгортається ваша AD, так чи підтримує інтеграцію AD постачальника ОС ОС лише для контролерів домену (RODC), односторонні трести, надає підтримку в багатьох лісах тощо. Що робити, якщо у вас є наявний простір UID (який ви хочете), чи є інструменти міграції для міграції UID в AD. І чи підтримує AD постачальника ОС операційну здатність відображати декілька UID в одній AD в ситуаціях, коли ваш простір UID не є рівним. А як же ... ну ви розумієте.

Тоді виникає питання підтримки ...

Поняття інтеграції AD може здатися простим концептуально і може бути "безкоштовним" з останньою ОС постачальника, і, ймовірно, може працювати, якщо у вас є лише одна версія ОС від одного постачальника і у вас є ванільна AD, яка є останньою версією, і у вас є договір про підтримку преміум-класу з постачальником ОС, який намагатиметься вирішити будь-які проблеми, які виникнуть. В іншому випадку ви можете розглянути спеціалізоване рішення третьої сторони.

Параметр Інструменти сервера для мережевої інформації (NIS) для інструментів віддаленого адміністрування сервера (RSAT) застарілий.

Це не дивно для мене - NIS - це свідчення того, що НД нас ненавидів і хотів, щоб ми були нещасними.

Використовуйте вбудовані параметри LDAP, клієнта Samba, Kerberos або не-Майкрософт.

Це хороша порада. Враховуючи вибір, я б сказав "Використовувати рідний LDAP (над SSL, будь ласка)" - для цього доступно багато варіантів, два з яких мені найбільше знайомі як pam_ldap + nss_ldap (від PADL) або комбінований nss-pam- ldapd (який виник як вилка і бачив постійні розробки та вдосконалення).

Оскільки ви конкретно запитуєте про RedHat, варто зазначити, що RedHat надає вам інші альтернативи за допомогою SSSD.
Якщо у вашому середовищі є все-RedHat (або просто є велика кількість систем RedHat), які розглядають офіційно підтримуваний «RedHat спосіб робити речі», безумовно, вартий вашого часу.

Оскільки я сам не маю досвіду роботи з RedHat / SSSD, я просто збираюся переглядати документи, але він виглядає досить міцним і добре продуманим.

З запропонованих методів дозвольте навести список плюсів і мінусів:

Прямо вгору Керберос / LDAP

Плюси: чудово працює при правильному налаштуванні. Рідко ламаються, стійкі, переживають мережеві збої. У AD немає змін, немає змін схеми, немає доступу адміністратора до AD. Безкоштовно.

Мінуси: відносно важко налаштувати. Необхідно змінити кілька файлів. Не буде працювати, якщо сервер автентифікації (Kerberos / LDAP) недоступний.

Winbind

Плюси: просте налаштування. Основна функціональність судо. Безкоштовно.

Мінуси: Підтримка інтенсивна. Не є стійким до мережі. Якщо виникла проблема з мережею, машини Linux можуть вийти з AD, що вимагає перереєстрації сервера, завдання підтримки. Необхідний доступ до облікового запису адміністратора AD. Можливо, щоб внести зміни в схему AD.

Відцентруйте / аналогічно і т.д.

Плюси: відносно просте налаштування.

Мінуси: Змінює функціональність sudo на власну, складніше підтримувати. Вартість ліцензії на один сервер. Потрібні додаткові навички управління.

SSSD

Плюси: один конфігураційний файл, простий у налаштуванні. Працює з усіма теперішніми та майбутніми методами аутентифікації. Масштабований, росте з системою. Працюватиме в відключеному режимі. Мережа пружна. Не потрібно вносити жодних змін до схеми AD. Немає необхідності в облікових даних адміністратора AD. Безкоштовно, підтримується.

Мінуси: Не має виграшних служб, таких як автоматичне оновлення DNS. Потрібно налаштувати спільні CIFS.

Підсумок

Дивлячись на переваги та недоліки, SSSD - явний переможець. Якщо це нова система, немає ніяких причин використовувати інше, ніж SSSD. Це інтегратор, який працює з усіма існуючими методами аутентифікації і може зростати з системою, оскільки нові методи можна додавати, коли вони доступні. Він використовує нативні методи Linux і набагато надійніші та швидкіші. Якщо кешування ввімкнено, системи працюватимуть навіть у повністю відключених системах з повним збоєм у мережі.

Winbind може використовуватися для існуючих систем, якщо для зміни є багато роботи.

У Centrify виникли проблеми з інтеграцією, які могли б дорого коштувати. Більшість помилок виправлені в новому випуску, але все ж є такі, які викликають головні болі.

Я працював з усіма цими методами, і SSSD - явний переможець. Навіть для старих систем рентабельність інвестицій для перетворення з Winbind в SSSD дуже висока. Якщо немає конкретної причини не використовувати SSSD, завжди використовуйте SSSD.

Потрібно прокоментувати це:

Варто зазначити, що Centrify має додаткові функціональні можливості, хоча це може бути забезпечено окремим управлінням конфігурацією. (Лялечка тощо)

Оскільки хтось, хто працює з Centrify, не впевнений, звідки цей коментар. Подивіться на це, і ви зможете побачити, що функція човна, яку ви не отримуєте за допомогою інструменту config mgmt ala Puppet, не має. Наприклад, підтримка відображення декількох UID-кодів на один обліковий запис AD (Зони), підтримка повноцінних трастів домену Active Directory (що рішення Red Hat документи на сторінці 3, які він не підтримує) тощо.

Але повернемося до цього посібника з Red Hat. Чудово, що Red Hat публікує це, варіанти хороші. Зауважте, це дає клієнту 10 варіантів зробити базову інтеграцію AD. Більшість варіантів є варіантами Winbind, а на сторінці 15 перераховані переваги та недоліки кожного, і для кожного необхідного є безліч ручних кроків (з відповідними недоліками / відсутністю функціоналу на вище). Перевага Centrify Express полягає в тому, що для інших коментарів, зазначених вище, це:

1. це просто встановити без виводу всіх кроків вручну і ...
2. безкоштовно і ...
3. не обмежується Red Hat V7, що важливо, оскільки питання стосувалося Linux, а не один варіант - Centrify підтримує понад 300 смаків * nix та ...
4. підтримує всі варіанти Windows AD, а не тільки Windows 2008. Вони опублікували порівняння Centrify проти Winbind тут , але це не є відкритим вихідним кодом.

Зрештою, це зводиться до того, що ви хочете прокрутити його самостійно або перейти до комерційного рішення. Дійсно, де ви і як проводите свій час.