У нас есть странная проблема с нашей настройкой ADFS, но я не могу понять, почему это происходит.
ADFS используется для подключения к Sharepoint, размещенному облачным провайдером. Их домен называется cloudsp.eu. Наш внутренний домен называется «hobnobs.internal.eu».
У нас есть веб-прокси с общедоступной DNS-записью «login.cloudsp.eu». WAP имеет опубликованное веб-приложение, настроенное как с внешними и внутренними URL-адресами как https://login.cloudsp.eu. .
Внутреннее имя службы федерации ADFS — login.cloudsp.eu.
У него также есть файл записи hosts для login.cloudsp.eu, который указывает на наш внутренний сервер ADFS, чтобы он мог разрешить имя.
Наш внутренний DNS также имеет пустую зону DNS с именем login.cloudsp.eu, настроенную для разрешения на внутренний сервер ADFS, чтобы клиенты во внутренней сети не разрешались в WAP.
Теперь все это работает хорошо. Внутренние клиенты получают SSO без необходимости проходить через WAP, а внешние клиенты подключаются к WAP, а затем перенаправляются в ADFS облачного провайдера, где они должны пройти аутентификацию с помощью своих учетных данных Sharepoint.
Проблема в следующем: -
Внутренние клиенты подключаются и аутентифицируются через единый вход в ADFS. Затем они отключаются и подключаются напрямую к Интернету. Когда они снова запускают свой браузер, они сразу же получают логин ADFS для ВНУТРЕННЕГО сервера ADFS (который теоретически они никогда не должны видеть). Кажется, что происходит то, что они попадают в WAP, который перенаправляет запросы на внутренний сервер ADFS, который представляет экран входа в систему нашего внутреннего сервера ADFS.
Это происходит только в этом конкретном сценарии (т. е. при уже подключенном через SSO), и очистка кеша браузера устраняет проблему. Итак, я предполагаю, что ADFS где-то хранит какой-то файл cookie или другой токен, и браузер повторно использует его, когда пытается аутентифицироваться?
К сведению: KMSI и PersistentSSO отключены.
