User is not forced to reauthenticate in ADFS 2.0 after Sharepoint 2010 session expires - authentication

Question

This case is very much similar to question by Wiktor Zychla, see How to set the timeout properly when federating with the ADFS 2.0
We are experiencing the same behavior, ADFS happily redirects the user back to Sharepoint site and FedAuth cookie is recreated, even though ADFS should prompt for credentials - we want the user to reauthenticate after some period of idle time. Basically it looks like the session is always sliding.
We have disabled persistent cookies, so the FedAuth cookie is removed when session is ended by closing the browser, so the user is forced to reauthenticate after all browser windows are closed and a new session is started, so that works.
As far as I understand the Web SSO lifetime setting in ADFS Snap-in controls the time after which the user should need to re-authenticate on AD FS (enter his credentials again). Tokenlifetime and LogonTokenCacheExpirationWindow together control, when Sharepoint should redirect back to AD FS to in order to renew FedAuth cookie.
Following is a quote from http://msdn.microsoft.com/en-us/library/hh446526.aspx :
To force users to re-enter their credentials whenever they are redirected back to ADFS, you should set the web SSO lifetime in ADFS to be less than or equal to SAMLtokenlifetime minus the value of LogonTokenCacheExpirationWindow.
So, we have done following:
1. Setting the lifetime of SAML token
Add-PSSnapin Microsoft.ADFS.PowerShell
Set-AdfsRelyingPartyTrust –TargetName "[ourrelayingpartytrustreference]" –TokenLifeTime 7
2. Setting LogonTokenCacheExpirationWindow (and disabling persistent cookies)
Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0
$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.LogonTokenCacheExpirationWindow = (New-Timespan -Minutes 1)
$sts.Update()
iisreset
3. Adjusted Web SSO lifetime: 5 minutes in AD FS 2.0 Management console snapin (running Get-ADFSProperties in Powershell correctly returns SsoLifetime: 5)
Thus the expected outcome is:
User starts a fresh new session, requests the web site
Browser is redirected to AD FS, user enter credentials, and browser is redirected back to Sharepoint site, FedAuth cookie is generated
User remains idle for 10 minutes (to make sure that session sliding period has passed)
User requests another page in Sharepoint, browser is redirected to AD FS
Since Web SSO lifetime was 5 minutes, and it was, as in msdn documentation instructs, less than SAMLtokenlifetime minus the value
of LogonTokenCacheExpirationWindow (SAMLtokenlifetime -
LogontokenCacheExpirationWindow = 6 minutes), AD FS prompts the user
for credentials, user enters credentials, and browser is redirected
to Sharepoint page requested and FedAuth cookie is recreated.
Current actual behavior (steps 1-4 similar):
(5.) AD FS does not prompt for credentials, browser is redirected to Sharepoint page and FedAuth cookie is recreated.
So - for us it looks like AD FS session never expires, no matter what we do.
If we create a false configuration of setting LogonTokenCacheExpirationWindow value higher than SAMLtokenlifetime (e.g. LogonTokecacheExpirationWindow = 8 and SAMLtokenlifetime = 7), we get the expected behavior of loop between Sharepoint and AD FS.
We are desperately seeking for a solution to properly expire the session, if user has remained idle for some period of time.
We also tried following configuration change (as per the guidance at 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
No Global.asax changes yet made.
As far as I understand, we have configured everything according to the documentation, however we cannot force the user to reauthenticate. Any help pointing out the error in configuration is appreciated.

Answer 1

Apologies if you have already done this, but be sure you have restarted AD FS after making the websso changes. We did not get our expected results until we restarted the services. Also, if you have a proxy, may want to restart that as well.
Do you have any pieces of infrastructure that are rewriting the cookies?