Forum Discussion
Juergen_Mang
MVP
MVPAPM: Basic SSO is failing now and then
I have a strange issue and opened a case after lot of debugging, but I want to also ask you. I hope I am not the first and only one with this problem.
I have a virtual server with an APM profile and a basic sso profile attached. Login and SSO works the most of the time without problems. But now and then the basic auth sso is failing. I investigated in this issue by writing an iRule to log the username/password combination at various stages: session.logon.last.password, session.sso.token.last.password and the password extracted from the basic auth header that was inserted by websso.
On functional requests all three username/password combinations are identically. On a request with failing SSO the session.logon.last.password and session.sso.token.last.password are identical, but the password extracted from the basic auth header is different.
Has anyone stumbled across a similar problem? I Have not found anything related here, in the F5 KB or in the BugTracker.
Fallout1984Cirrocumulus
Hmm... If it looks like the password's getting corrupted at some point, you could assign it to a variable and then retrieve and set it later if needed. We had to do that in an APM setup used for VDI, where the password was (if I remember correctly) getting corrupted at the DUO step. It was several years ago, but I have an old APM flow diagram that shows it. Anyway, just putting that out there as a possible technique to try if applicable.
Hamishis the basic auth header from the browser changing? If so, is the endpoint the browser is talking to always the same? Or are there two different VIP's and the browser has the wrong password saved for one of them?
Juergen_Mangis the basic auth header from the browser changing?
The browser does not submit a basic auth header, only the MRH session cookie.
If it looks like the password's getting corrupted at some point, you could assign it to a variable
The password variables inside the APM session are correct. I log it on each request, but the authorization header inserted by the sso profile is sometimes incorrect.
Thanks for your replies.