Forum Discussion
CapU_117493
Nimbostratus
NimbostratusSharepoint error - Your session could not be established
Hello,
Our SSO for Sharepoint doesn't work anymore. The behavior is: When user trys to log in, no matter of credentials (even left blank) the users gets error: Your session could not be established. The session reference number: 57d6b19a Invalid Session ID. Your session may have expired. Thank you for using BIG-IP.
The APM log reveals: \N: Session deleted due to user logout request. right after the login attempt We are using NTMLv1. And Sharepoint iApp v 2010 Here is an extract from our log: Feb 13 11:36:24 br437f5 notice tmm2[9350]: 01490544:5: 2a5f63b5: Received client info - Type: IE Version: 9 Platform: Win7 CPU: WOW64 UI Mode: Full Javascript Support: 1 ActiveX Support: 1 Plugin Support: 0 Feb 13 11:36:24 br437f5 notice tmm2[9350]: 01490500:5: 2a5f63b5: New session from client IP 204.239.152.212 (ST=British Columbia/CC=CA/C=NA) at VIP 10.11.0.23 Listener /Common/MSSP2013_Int_vs (Reputation=Unknown) Feb 13 11:36:28 br437f5 notice tmm2[9350]: 01490501:5: 2a5f63b5: Session deleted due to user logout request. Feb 13 11:36:49 br437f5 debug websso.0[9532]: 014d0001:7: Expire thread: TGTlist:0 TGTMap:0 UCClist:0 UCCmap:0 Feb 13 11:36:49 br437f5 debug websso.2[9746]: 014d0001:7: Expire thread: TGTlist:0 TGTMap:0 UCClist:0 UCCmap:0 Feb 13 11:36:49 br437f5 debug websso.1[9594]: 014d0001:7: Expire thread: TGTlist:0 TGTMap:0 UCClist:0 UCCmap:0 Feb 13 11:36:53 br437f5 debug websso.3[9856]: 014d0001:7: Expire thread: TGTlist:0 TGTMap:0 UCClist:0 UCCmap:0
Hi CapU,
Which browser version are you using? Does it happen on all browsers?
thanks
CapU_117493Yes, it happens on all browsers
Are you using Multi-domain Single Sign-On (SSO)? If so, I wonder if it might be this bug: https://support.f5.com/kb/en-us/solutions/public/14000/900/sol14958.html
You should be able to check the temporary files in the browser for the APM cookies for the old session.
- CapU_117493
Yes, we do have Multi-Domain, we tried the workaround in that link but it didn't make any difference.
Using Fiddler I can notice an odd date for the cookie expiry date (1970). Here is an example: if (get_cookie("F5_PWS") == "1") { document.cookie = "F5_PWS=0; path=/; expires=Fri, 01-Jan-1970 00:00:01 GMT"; var pwsClassId = "7E73BE8F-FD87-44EC-8E22-023D5FF960FF"; InsertActivexControl(pwsClassId, {"command": "exit"} ); } else if (get_cookie("F5_GPO") == "1") { document.cookie = "F5_GPO=0; path=/; expires=Fri, 01-Jan-1970 00:00:01 GMT"; var gpoClassId = "8F6AFB67-F834-4227-94A7-A51377E0678E"; InsertActivexControl(gpoClassId, {"GroupPolicyRollback": "TRUE"} );
Where would that time come from? My time on the F5 it's correct, same on the Sharepoint servers Is that the problem that the session is already expired?
I think APM sends cookies with that date that it immediately wants the browser to delete. I see the MRHSHint cookie doing that in a working APM environment, anyway.
You should probably open a case with F5 support on this (unless anyone else chimes in with the answer). Sounds like APM's having a problem.
- CapU_117493
I logged a case with F5
-
The cookie expiry date of 1970 is a standard date for terminating the session - so that is normal.
-
We discovered the Access Policy applied to the Sharepoint VIP was being processed at all. The F5 tech couldn't find a reason why is not processes. He recommended we should do a fail over to the standby unit.
We'll do this today
DannyG_34437Cirrus
And???
-
