Передача билета Kerberos не работает в Chrome на macOS X

Я внедряю Okta в качестве провайдера единого входа в корпоративной среде с примерно 90 пользователями. Одна из функций Okta — это Desktop Single Sign On — возможность аутентификации пользователей с помощью Okta просто на основании входа в свою машину и, таким образом, аутентификации с доменом. Пользователь просто открывает браузер, переходит на URL-адрес Okta компании, и он автоматически входит в систему.

Без этой функции пользователю пришлось бы вводить свои учетные данные при загрузке URL-адреса Okta.

Desktop Single Sign On (DSSO) реализуется за счет того, что браузер получает билет Kerberos из операционной системы, который сам генерируется, когда пользователь аутентифицируется в домене Active Directory. Затем браузер передает этот билет на сервер, который взаимодействует с облаком Okta для аутентификации пользователя.

Поток аутентификации в нашей среде выглядит следующим образом:

1. Пользователь входит в свою машину. При входе и аутентификации в домене создается билет Kerberos.
2. Пользователь открывает браузер и либо пытается получить доступ к приложению, защищенному/интегрированному с Okta, либо идет напрямую на свой портал Okta.
3. Okta перенаправляет пользователя к нашему балансировщику нагрузки, который обрабатывает запрос в веб-приложении IWA на веб-сервере.
4. Веб-приложение IWA вызывает у браузера аутентификацию.
5. Браузер получает билет Kerberos из ОС и передает его балансировщику нагрузки, который передает его веб-приложению IWA.
6. Приложение IWA проверяет билет и извлекает профиль пользователя из Active Directory.
7. Приложение IWA создает и цифрово подписывает токен SSO и отправляет его в браузер.
8. Браузер отправляет токен обратно в Okta через POST-форму HTML.
9. Okta завершает запрос на вход и возвращает пользователя в приложение с токеном SSO.

Процесс не работает на шаге 5, и я знаю это, потому что:

1. Chrome запрашивает у пользователя учетные данные NTLM, когда запрашивается URL-адрес Okta.
2. Этот запрос возникает до того, как веб-приложение IWA и браузер настроены должным образом для DSSO (в соответствии с документацией, на которую я ссылался в начале).
3. Запрос не возникает в Chrome, Firefox и Internet Explorer на Windows (DSSO работает на Windows с Chrome, Firefox и IE).
4. Этот запрос не возникает в Safari на macOS X, но возникает с Chrome и Firefox в OS X.

Что я не могу понять, так это почему Chrome и Firefox не получают билет Kerberos из ОС в macOS X, в то время как те же браузеры в Windows без проблем получают билет.

Принятые мной шаги:

1. Настройка белого списка Chrome с помощью следующих команд терминала (рекомендовано в документации Okta):

   $ defaults write com.google.Chrome AuthServerWhitelist “*.example.com”

   $ defaults write com.google.Chrome AuthNegotiateDelegateWhitelist “*.example.com”

2. Настройка белого списка Chrome с помощью конфигурации SimpleMDM (этот метод действительно прошел, настройки были переданы в Chrome – это подтвердили, перейдя на chrome://policy и увидев эти настройки).
3. Удаление антивируса.
4. Добавление всех возможных FQDN в список серверов, разрешенных на шаге 2 – сначала только серверы, которые мы разрешили в Windows (поскольку в Windows это действительно работает), а затем список серверов Okta, рекомендованных поддержкой Okta.

Я по-прежнему не могу заставить эту функцию работать и теперь пытаюсь выяснить, есть ли способ отладить процесс, который Chrome использует для получения билета Kerberos из ОС. Какой-то отладчик для механизма получения билета Kerberos в Chrome был бы отличным, но я полагаю, что такого не существует.

Это должно работать с:

$ defaults write com.google.Chrome AuthServerWhitelist '*.example.com'
$ defaults write com.google.Chrome AuthNegotiateDelegateWhitelist '*.example.com'

Обратите внимание, что я заменил ” на ‘

Я думаю, что Chrome на macOS необычен тем, как он ищет SPN для Kerberos, когда имя хоста разрешается в CNAME. Он ищет SPN с этим CNAME и не возвращается к исходному имени хоста. Firefox, Safari и даже curl –negotiate будут работать только с SPN для имени хоста, но Chrome (и только на macOS) не сработает, если вы не зарегистрируете SPN для CNAME.

Так, например, в моем случае проблема возникла, потому что я использую Kerberos через сетевой балансировщик нагрузки. Имя хоста разрешается в что-то вроде xxxx.elb.us-east-1.amazonaws.com, чтобы заставить Chrome на macOS работать правильно, мне нужно было зарегистрировать SPN следующим образом:

setspn $acct -a HTTP/xxxx.elb.us-east-1.amazonaws.com