Зачем использовать 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 сек
  • вы можете использовать TLS / SSL для работы с другими
• требуется несколько циклов для проверки подлинности с небольшими пакетами
  • (шаблон журнала 401.2, 401.1, 200 с именем пользователя)
• не может использоваться в сценариях, где требуется аутентификация двойного прыжка
  • то есть учетные данные пользователя должны быть перенаправлены в службу на другом компьютере
• поддерживает старые клиенты (<Win2000)
• Подвержен несоответствиям уровня аутентификации LM (не соответствует lmcompatibilitylevel)
• используется в качестве запасного варианта для пакета переговоров, если обуздание не выполнено.
  • ( не «если доступ запрещен с помощью Curb», Curb должен прерваться, чтобы использовать NTLM - обычно это выглядит как отсутствие получения билета. Если клиент получает билет, и он не идеален, это не вызывает откат.)

Kerberos

• работает только с подключенными к домену клиентами
  • требует подключения клиента к AD DC (tcp / udp 88) И серверу (билеты извлекаются клиентом из DC через порт Curb, а затем передаются на сервер по HTTP)

• может быть в состоянии пройти через прокси, но см. пункт DC выше: вам все еще нужно быть в той же сети, что и активный DC, так же как и сервер .

  • так что теоретически, если у вас был домен, в котором подключенные к Интернету клиенты общались напрямую с подключенным к Интернету DC, это работоспособно. Но не делай этого, если только ты этого не знал.
  • В сценариях с обратным прокси-сервером (ISA / TMG) сервер перехода по протоколу должен находиться в этой сети, т.е. не клиент ... но тогда клиент на самом деле не тот, кто выполняет бит Kerberos (обязательно - подумайте, Forms auth to Curb) переход).

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

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

Пока мы на этом:

основной

• может мульти-хоп. Но делает это, выставляя ваше имя пользователя и пароль непосредственно целевому веб-приложению
  • который может делать с ними все, что захочет. Ничего .
  • «О, администратор домена просто использовал мое приложение? И я только что прочитал их электронную почту? Затем сбросил их пароль? Ой. Жаль »
• нужна защита транспортного уровня (т. е. TLS / SSL) для любой формы безопасности.
  • а затем посмотреть предыдущий выпуск
• работает с любым браузером
  • (но смотрите первый выпуск )
• требуется одна поездка в оба конца для проверки подлинности ( 401 , 200 )
• может использоваться в сценариях с несколькими прыжками, поскольку Windows может выполнять интерактивный вход в систему с основными учетными данными
  • Может потребоваться LogonTypeнастройка для достижения этой цели (думаю, что значение по умолчанию было изменено на открытый текст сети в период между 2000 и 2003 годами, но может быть ошибочным)
  • но опять же , смотрите первый выпуск .
  • Создается впечатление, что первый выпуск действительно, действительно важен? Это.

Подводить итоги:

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

Ограниченное делегирование стоит затрат на вход.

• Kerberos имеет репутацию более быстрого и безопасного механизма аутентификации, чем NTLM.
• Исторически проще было подключаться к нему через прокси-серверы, чем NTLM, из-за природы NTLM, основанной на подключении.
• Тем не менее, как вы заметили, Kerberos сложнее в настройке и требует подключения к AD, что не всегда практично.

Другой подход заключается в том, чтобы установить аутентификацию negotiateи использовать оба вместо одного вместо другого.

Из Microsoft Application Verifier , которая обнаруживает распространенные ошибки разработчика. Одной из таких ошибок является использование NTLM :

NTLM - это устаревший протокол аутентификации с недостатками, которые могут поставить под угрозу безопасность приложений и операционной системы. Наиболее важным недостатком является отсутствие проверки подлинности сервера, что может позволить злоумышленнику обманом заставить пользователей подключиться к поддельному серверу. Как следствие отсутствия аутентификации на сервере, приложения, использующие NTLM, также могут быть уязвимы к типу атаки, известной как атака «отражения». Последнее позволяет злоумышленнику перехватить сеанс аутентификации пользователя на легитимном сервере и использовать его для аутентификации злоумышленника на компьютере пользователя. Уязвимости NTLM и способы их использования являются целью увеличения исследовательской активности в сообществе безопасности.

Хотя Kerberos был доступен в течение многих лет, многие приложения все еще написаны для использования только NTLM. Это излишне снижает безопасность приложений. Однако Kerberos не может заменить NTLM во всех сценариях - главным образом в тех, где клиент должен пройти аутентификацию в системах, которые не присоединены к домену (домашняя сеть, возможно, является наиболее распространенной из них). Пакет безопасности Negotiate обеспечивает обратно-совместимый компромисс, который использует Kerberos всякий раз, когда это возможно, и возвращается к NTLM только тогда, когда нет другой возможности. Переключение кода для использования Negotiate вместо NTLM значительно повысит безопасность для наших клиентов, в то же время практически не применяя совместимость приложений. Переговоры сами по себе не являются «серебряной пулей» - бывают случаи, когда злоумышленник может принудительно перейти на NTLM, но их значительно труднее использовать. Однако одно немедленное улучшение заключается в том, что приложения, написанные для правильного использования Negotiate, автоматически защищены от атак отражения NTLM.

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

Вы должны добавить очень важный момент:

Kerberos был стандартным и открытым протоколом в Unix более 20 лет, тогда как NTLM является чисто проприетарным решением от Microsoft и известно только Microsoft.

Kerberos требуется, если вам нужно выдать себя за пользователя, чтобы получить доступ к ресурсам, которых нет на сервере iis.