GlobalProtect - Connect Before Logon

[jwckauman]

Palo Alto’s VPN solution GlobalProtect is configured in Duo as a protected application and in the Palo Alto firewall as a SAML authentication provider. GlobalProtect connects perfectly if the user signs into Windows first and then connects GP. GP doesn’t complete the connection process if the user attempts to connect the VPN BEFORE they sign into Windows. From a process-standpoint, here’s what we are seeing…

1. At the Windows lock screen, the user clicks the GlobalProtect ‘Connect’ option first.
2. GP opens an embedded browser window and prompts the user for their Azure AD account and password, which they enter and click ‘Sign-On’.
3. Duo passes creds to Azure AD for authentication succesfully and that first window closes.
4. A second window opens which is normally where Duo would prompt for MFA. Instead, the user sees nothing but a blank window (GlobalProtect is shown in the title bar).

NOTE: I don’t see anything in the Duo logs to suggest GlobalProtect reached out to Duo so I suspect the issue is with the script/code that makes that connection happen (and shows the Duo MFA prompt). Maybe an issue with the script not being able to run prior to sign-on? What could we do to troubleshoot?

[BabbittJE]

What version of PAN OS are you running? I was on 8.1.14 and Duo authentication was working just fine. After upgrading to 10.1.3, it broke Duo. I have yet to find a solution for our GlobalProtect VPN; one of my technicians is working with Palo Alto to figure out this problem. I wonder if it’s related to the issue you are having.

[jwckauman]

9.1.8. Best I can tell the the hand-off to Duo isn’t happening because we never see Duo being accessed in the Duo logs. In fact, I don’t see anything in the GlobalProtect logs (on the PA) after the initial connection. GlobalProtect does request the credentials (which occur in the browser window), so that tells me the PA is handing GP over to Duo who then sends me to Azure AD for the creds, which are validated sucesfully. So when Duo gets the "1st factor authenticated’ response, it seems like GP is now opening a new browser window to do the Duo 2nd factor, and either the Duo can’t get the message that the 1st factor worked, or can’t somehow request the 2nd factor. But that’s just thoughts based on what i’m seeing. I’m very interested in any findings you have with PA. I also opened a ticket with both Duo and Palo Alto and will share any of my findings as well. Thanks!!

[BabbittJE]

You don’t have browser pop-up disabled, do you? I was wondering if the Duo prompt ever appears for you.

[jwckauman]

Good question about pop-up blockers. I know each browser has it’s own settings with respect to pop-up blocking (Edge blocks by default, but IE doesn’t, right?). Doesn’t GlobalProtect use an embedded browser (whatever that means?) If so, how do you control whether or not that browser will allow pop-ups? That said, given that the configuration works AFTER logon, it makes me think the browser pop-ups are not being blocked (unless that is a user-based policy which isn’t applied BEFORE logon).

[jwckauman]

I noticed something else when testing BEFORE logon. I mentioned that the first ‘browser window’ asks for my Azure AD credentials and seems to complete sucessfully. That window closes and then a 2nd one opens. For a brief second, I see something appear in that window and then disappear. I’ll try to grab a screenshot.

I’ve been looking at the GP logs on our test machine. I’m not sure if I should be looking at the PanGPS Service logs or the PanGPS Agent logs. I’m a bit of a amateur when it comes to all things Palo Alto.

[jwckauman]

Looking at the PanPlapProvider.log file, I think i see where things break down. The log shows several URL requests for https://login.microsoftonline.com/ (which is Azure AD), and then immediately switches the URL to “https://■■■■■■■■■■■■■■■■■■■■■■■■■■■■/frame/frameless/v4/auth?sid=frameless”. That must cause something to happen because GP then switches the URL to “https://■■■■■■■■■■■■■■■■■■■■■■■■■■■/frame/v4/preauth/healthcheck?sid=frameless”. That is the last entry in the log until I exit out the blank window. The logs see that I cancelled the request.

FWIW, in the Palo Alto system logs, i see the SAML Client Redirect but I never get back a SAML Assertion (like I do when I’m connecting AFTER login).

So either the URL that is being passed to Duo Security is incorrect or the response can’t be handled by GlobalProtect correctly?

[jwckauman]

More clues today. On a whim, I switched GlobalProtect to use the traditional prompt (it was using Universal Prompt previously). Now everything works great. So definitely isolated the issue to Universal Prompt. Anyone know anything about how that works? and what is different about it that might prevent it from running before user signs on to Windows?

[scoobydooxp]

Anyone have any updates on this? We are struggling with Palo 10.2, GlobalProtect 6.1 and Duo SAML to get pre-logon working along with the new Duo Verified Push (Universal Prompt required).

[BabbittJE]

I wouldn’t use the pre-logon feature. While I was working on that, I found that I could access the network files without even authenticating! I had a case opened with Palo Alto and they pointed me out that it was the result of the pre-logon feature. I had to change that pronto! Good luck!