Nimbostratus
EmployeeOnce APM receives a SAML assertion from an IdP, it should usually finish authentication and the user's session should be in "Allow" state.
Upon the first network request without a cookie, APM creates a session ID and sends it to the client in an "MRHSession" cookie. Upon each subsequent network request, the client should transmit this cookie and to tie the request to the user's session. It sounds like for whatever reason, your login session isn't following this pattern.
To see why, use your browser's dev tools to examine the cookies sent and recieved by your user's browser. It might be that you're using multi-domain mode (when you visit a host with no MRHSession cookie, the APM will redirect you to the "Primary Authentication URI" for login, then redirect back to the original URI and use some HTTP redirect tricks to share the MRHSession cookie between the domains specified in the config). This is where that multi-domain mode is set up:
The problem could also be something else, but in any case looking at the network requests and cookies in your browser dev tools will get you closer to an answer.
NimbostratusThanks Lucas_Thompson . We are using Single Domain. I tried looking at the cookies but there are a lot of cookies involved with Azure AD (EntraID) and it's not obvious which ones are relevant to authentication. It seems to me that the issue as follows:
1- When you first go to our VPN portal hosted by APM, the SAML auth immediately redirects you to login.microsoft.com where you go through Azure MFA.
2- At this point you have a valid auth/session cookie but (I think) it's only valid for login.microsoft.com.
3- When you click on an internal resource withing the portal, the app also redirects you to login.microsoft.com but this time it's rewritten by the portal to: https://'ourvpnportal'.bah.com/f5-w-68747470733a2f2f6c6f67696e2e6d6963726f736f66746f6e6c696e652e636f6d$$/d5fe813e-0caa-432a-b2ac-d555aa91bd1c/saml2. Where the string after f5-w- equates to the hex translation of https://login.microsoft.com.
4- Because login.microsoft.com is hex encoded, the browser cannot use the existing session cookie for authentication and the user must authenticate again but this time will get a cookie that is valid for ourvpnportal.bah.com and doesn't need subsequent authentications.
Does this make sense? Is there a way to somehow use the cookie from step 1 in step 3 so that users don't have to authenticate a second time?
Thanks in advance.