Навіщо використовувати Kerberos замість NTLM в IIS?

Це те, на що я ніколи не міг відповісти так добре, як мені подобається: Яка реальна перевага використання автентифікації Kerberos в IIS замість NTLM?

Я бачив, як багато людей справді намагаються його налаштувати (включаючи і мене), і мені не вдалося придумати вагомих причин його використання. Але, мабуть, є деякі досить вагомі переваги, інакше налаштувати його не варто, чи не так?

Тільки з точки зору Windows:

NTLM

• працює як із зовнішніми (недоменними), так і внутрішніми клієнтами
• працює з обліковими записами домену та локальними обліковими записами користувачів у вікні IIS
  • використовуючи доменні облікові записи, тільки сервер вимагає прямого підключення до контролера домену (DC)
  • використовуючи локальні акаунти, вам ніде не потрібно підключення :)
  • вам не потрібно входити в систему як відповідний користувач, щоб використовувати обліковий запис
  • Крім : це не те, що рідкість для DC , щоб бути перевантажений завантаженим сервером NTLM (IIS, Exchange, TMG / ISA, і т.д.) з об'ємом NTLM запитів (для зменшення: MaxConcurrentAPI, AuthPersistSingleRequest(брехні) ., Швидше РС) ( Само референтний бонус .)
• вимагає підключення клієнта лише до сервера IIS (на порту сайту, нічого іншого. тобто все відбувається через HTTP (або HTTPS).)
• може переходити до будь-якого проксі, що підтримує HTTP Keep-Alive s
  • можливо, ви зможете використовувати TLS / SSL для роботи навколо інших
• вимагає декількох туди і назад для автентифікації з невеликими пакетами
  • (шаблон журналу 401.2, 401.1, 200 з ім'ям користувача)
• не можна використовувати в сценаріях, коли потрібна подвійна аутентифікація
  • тобто облікові дані користувача повинні бути перенаправлені до служби на іншому комп'ютері
• підтримує старших клієнтів (<Win2000)
• Чутливий до розбіжностей рівня аутентичного рівня LM (невідповідний lmcompatibilitylevel)
• використовується пакетом переговорів як резервний запас, якщо Curb не працює.
  • ( не "якщо доступ заборонено Curb", Curb повинен зламатися, щоб NTLM використовувався - зазвичай це виглядає як не отримання квитка. Якщо клієнт отримує квиток і він не є ідеальним, це не спричиняє відмову.)

Керберос

• працює лише з клієнтами, які зараз приєдналися до домену
  • вимагає підключення клієнта до AD DC (tcp / udp 88) І сервера (квитки отримує клієнт з постійного струму через порт Curb, а потім надаються серверу за допомогою HTTP)

• може пройти проксі-сервер, але див. пункт DC вище: вам все одно потрібно бути в тій самій мережі, що і активний постійний струм, як і сервер .

  • тому теоретично, якщо у вас був домен, в якому клієнти, підключені до Інтернету, спілкувалися безпосередньо в мережі, підключеній до Інтернету, це ефективно. Але не робіть цього, якщо ви вже цього не знали.
  • У сценаріях зворотного проксі (ISA / TMG) сервер переходу протоколів повинен бути у цій мережі, тобто не клієнт ... але тоді клієнт насправді не той, що робить біт Kerberos (обов'язково - подумайте, Forms auth to Curb перехід).

• квиток довготривалий (10 год), тобто менше спілкування постійного струму протягом життя квитка - і підкреслимо: це може заощадити тисячі мільйонів запитів на кожного клієнта протягом цього життя - ( AuthPersistNonNTLMвсе одно справа; перевірка PAC Kerberos раніше була річчю)

• для автентифікації потрібен один обхід , але розмір корисної навантаження для автентифікації порівняно великий (зазвичай 6-16 К) ( розмір токена { 401 , {(закодований)} 200 )
• можна використовувати з (будь ласка, завжди обмеженим ) делегуванням, щоб увімкнути автентифікацію Windows підключеного користувача до наступної служби
  • наприклад, щоб дозволити UserAдоступ до IIS та використовувати той самий обліковий запис користувача, коли IIS отримує доступ до SQL Server, це "делегування автентифікації".
  • ( Обмежений у цьому контексті означає ", але нічого іншого", наприклад, Exchange або інше поле SQL)
• в даний час є основним пакетом безпеки для аутентифікації переговорів
  • що означає, що учасники домену Windows віддають перевагу, коли вони можуть її отримати
• вимагає реєстрації SPN , що може бути складним. Правила, які допомагають .
• вимагає використання імені як цілі, а не IP-адреси
• причини, які можуть припинити:
  • використовуючи IP-адресу замість імені
  • SPN не зареєстровано
  • зареєстровані копії SPN
  • SPN зареєстровано проти неправильного рахунку ( KRB_ERR_AP_MODIFIED)
  • немає підключення до клієнта DNS / DC
  • налаштування клієнтського проксі / локальної інтранет-зони не використовується для цільового сайту

Поки ми в цьому:

Основні

• може мульти-хоп. Але це робиться, відкривши своє ім’я користувача та пароль безпосередньо цільовому веб-додатку
  • який потім може робити з ними все, що завгодно. Що завгодно .
  • "О, хіба що адміністратор домену просто використовував мій додаток? А я щойно прочитав їхню електронну пошту? Потім скинув їх пароль? Awww. Шкода "
• потребує безпеки транспортного рівня (тобто TLS / SSL) для будь-якої форми захисту.
  • а потім, див. попередній випуск
• працює з будь-яким браузером
  • (але дивіться перший випуск )
• для автентифікації потрібна одна туди-поїздка ( 401 , 200 )
• може використовуватися в сценаріях з декількома скачками, оскільки Windows може виконувати інтерактивний вхід з основними обліковими записами
  • Для цього LogonTypeможе знадобитися налаштувати (подумайте, що за замовчуванням змінився мережевий прозорий текст між 2000 та 2003 роками, але це може бути неправильне запам'ятовування)
  • але знову , побачити перший випуск .
  • Створюється враження, що перший випуск насправді, дійсно важливий? Це є.

Підсумовуючи:

Створення бордюру може бути складним, але є безліч путівників ( моїх ), які намагаються спростити процес, і інструменти значно покращилися з 2003 по 2008 рік ( SetSPNможна шукати дублікати, що є найпоширенішим виправданням проблеми ; використовуйтеSETSPN -S будь-який час, коли побачите вказівки щодо використання -A, і життя стане щасливішим).

Обмежена делегація вартує витрат на вступ.

• Kerberos має репутацію більш швидкого і безпечного механізму аутентифікації, ніж NTLM.
• Так само історично було простіше підключитися до проксі-серверів, ніж NTLM, через характер NTLM на основі з'єднання.
• З цього приводу, як зазначаєте, Керберосу складніше вставати і працювати, і вимагає підключення до AD, яке не завжди практично.

Іншим підходом було б встановлення автентифікації negotiateта використання обох, а не одного, а не іншого.

Від верифікатора додатків Microsoft , який виявляє поширені помилки розробника. Однією з таких помилок є використання NTLM :

NTLM - це застарілий протокол аутентифікації із недоліками, які потенційно можуть порушити безпеку програм та операційної системи. Найважливішим недоліком є ​​відсутність автентифікації сервера, яка може дозволити зловмиснику обдурити користувачів підключення до підробленого сервера. Як наслідок відсутності автентифікації сервера, додатки, що використовують NTLM, також можуть бути вразливими до типу атаки, відомої як атака "відображення". Останнє дозволяє зловмиснику захопити розмову аутентифікації користувача на законний сервер і використовувати його для аутентифікації зловмисника на комп'ютері користувача. Вразливості NTLM та шляхи їх використання є метою посилення науково-дослідної діяльності у сфері безпеки.

Хоча Kerberos був доступний протягом багатьох років, багато додатків все ще написані для використання лише NTLM. Це непотрібно знижує безпеку програм. Однак Kerberos не може замінити NTLM у всіх сценаріях - в основному в тих, де клієнту потрібно автентифікуватись на системах, які не приєднані до домену (домашня мережа, можливо, є найбільш поширеною з них). Пакет безпеки Negotiate дозволяє підтримувати зворотний компроміс, який використовує Kerberos, коли це можливо, і повертається до NTLM лише тоді, коли іншого варіанту немає. Перемикання коду на використання Negotiate замість NTLM значно підвищить безпеку для наших клієнтів, одночасно запровадивши декілька сумісностей додатків або взагалі їх немає. Переговори самі по собі не є срібною кулею - є випадки, коли зловмисник може змусити перейти на НТЛМ, але їх значно важче експлуатувати. Однак одне негайне вдосконалення полягає в тому, що програми, написані для правильного використання переговорів, автоматично захищені від атак NTLM-відображення.

Останнє застереження щодо використання NTLM: у майбутніх версіях Windows можна буде відключити використання NTLM в операційній системі. Якщо програми мають жорстку залежність від NTLM, вони просто не зможуть підтвердити автентифікацію, коли NTLM вимкнено.

Вам слід додати дуже важливий момент:

Kerberos був стандартним та відкритим протоколом в Unix протягом 20 років, тоді як NTLM - суто фірмове рішення від Microsoft і відоме лише Microsoft.

Kerberos потрібен, якщо вам потрібно видавати себе за доступ до ресурсів, які відсутні на сервері iis.