4

Этот случай очень похож на вопрос по Wiktor Zychla см How to set the timeout properly when federating with the ADFS 2.0Пользователь не обязан проходить аутентификацию в ADFS 2.0 после сессии Sharepoint 2010 истекает

Мы испытываем такое же поведение, ADFS счастливо перенаправляет пользователя на Sharepoint сайт и FedAuth cookie воссоздаются, хотя ADFS должен запрашивать учетные данные - мы хотим, чтобы пользователь повторно аутентифицировался после некоторого периода простоя. В принципе, похоже, что сессия всегда раздвигается.

У нас отключены постоянные файлы cookie, поэтому cookie FedAuth удаляется, когда сеанс завершается закрытием браузера, поэтому пользователь вынужден повторно аутентифицироваться после закрытия всех окон браузера и запуска нового сеанса.

Насколько я понял, срок службы Web SSO в ADFS Snap-in контролирует время, необходимое пользователю для повторной аутентификации в AD FS (снова введите его учетные данные). Tokenlifetime и LogonTokenCacheExpirationWindow вместе контролируют, когда Sharepoint должен перенаправить обратно в AD FS, чтобы обновить файл cookie FedAuth.

Ниже приводится цитата из http://msdn.microsoft.com/en-us/library/hh446526.aspx:

Чтобы заставить пользователей повторно ввести свои учетные данные, когда они будут перенаправлены обратно в ADFS, вы должны установить веб-SSO жизни в ADFS быть меньше или равна SAMLtokenlifetime минус значение LogonTokenCacheExpirationWindow.

Итак, мы сделали следующее:

1. Установка времени жизни SAML маркера

Add-PSSnapin Microsoft.ADFS.PowerShell 

Set-AdfsRelyingPartyTrust –TargetName "[ourrelayingpartytrustreference]" –TokenLifeTime 7 

2. Установка LogonTokenCacheExpirationWindow (и отключение постоянные куки)

Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0 

$sts = Get-SPSecurityTokenServiceConfig 
$sts.UseSessionCookies = $true 
$sts.LogonTokenCacheExpirationWindow = (New-Timespan -Minutes 1) 

$sts.Update() 

iisreset 

3. Скорректированная Web SSO срок службы: 5 минут в AD FS 2.0 консоли управления Оснастка (бегущие Get-ADFSProperties в Powershell правильно возвращает SsoLifetime: 5)

Таким образом, ожидаемый результат:

  1. Пользователь запускает новый новый сеанс просит веб-сайт
  2. браузер перенаправляется к AD FS, пользователь вводит учетные данные, и браузер перенаправляется обратно на Sharepoint сайт, FedAuth печенье генерируется
  3. пользователь простаивает в течение 10 минут (чтобы убедиться, что сессия раздвижными период имеет прошло)
  4. Пользователь запрашивает другую страницу в Sharepoint, браузер перенаправляется на AD FS
  5. Поскольку срок службы Web SSO была 5 минут, и это было, как в MSDN документация инструктирует, менее SAMLtokenlifetime минус значения из LogonTokenCacheExpirationWindow (SAMLtokenlifetime - LogontokenCacheExpirationWindow = 6 минут), AD FS запрашивает у пользователя учетные данные, пользователь вводит учетные данные, а браузер перенаправляется на страницу с Sharepoint, и файл cookie FedAuth воссоздан.

Текущее фактическое поведение (шаги 1-4 подобное):

(5.) AD FS не запрашивает учетные данные, браузер перенаправляется на Sharepoint страницу и FedAuth печенье воссоздан.

Итак, для нас это похоже, что сессия AD FS никогда не заканчивается, независимо от того, что мы делаем. Если мы создадим ложную конфигурацию параметра LogonTokenCacheExpirationWindow, превышающую значение SAMLtokenlifetime (например, LogonTokecacheExpirationWindow = 8 и SAMLtokenlifetime = 7), мы получаем ожидаемое поведение цикла между Sharepoint и AD FS.

Мы отчаянно пытаемся найти решение для окончательного завершения сеанса, если пользователь некоторое время остается бездействующим.

Мы также попробовали следующие изменения конфигурации (в соответствии с руководством по http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/802b1bb6-cda3-4470-a0d1-ee709d5c4b7c/):

Set-ADFSProperties -SsoLifetime 1 

Set-ADFSProperties -ReplayCacheExpirationInterval 1 

Set-ADFSProperties -SamlMessageDeliveryWindow 1 

Нет Global.asax изменения еще сделаны.

Насколько я понимаю, мы настроили все в соответствии с документацией, однако мы не можем заставить пользователя повторно проверять подлинность. Любая помощь, указывающая на ошибку в конфигурации, оценивается.

ответ

1

Извините, если вы уже это сделали, но убедитесь, что вы перезапустили AD FS после внесения изменений в websso. Мы не получили ожидаемых результатов, пока не перезапустили службы. Кроме того, если у вас есть прокси-сервер, возможно, вы захотите его перезапустить.

Есть ли у вас какие-либо объекты инфраструктуры, которые переписывают куки?