08-02-2022 10:38 AM
We have been able to configure the ADMIN UI to use SAML auth on the primary firewall to leverage MFA. The problem is the secondary firewall has a different URL, of course, to access it. We tried creating a second ADMIN UI, but you cannot assign a separate authentication profile to the two different management interfaces in a HA configuration. Has anyone had a workaround for this?
09-27-2022 05:41 AM
I got it escalated to PA product development. When you use prelogin using a machine certificate authentication and SAML for user authentication, the SAML page on the firewall is what's causing the issue. We also are using a Windows OCSP responder to validate the certificate from a Windows server 2019 CA server. What development came back with was it is an issue with TLS 1.2. They believe that TLS 1.3 will have support for checking for certificate OID. There is no ability to check OID of the certificate in TLS1.2. If you have both user and machine certificates on the endpoint from the same CA, the embedded browser will prompt for a user certificate even though you are already authenticated. the workaround is to create a subordinate CA and only issue machine certificates from that CA. I found that if I used the public IP on the untrust side of the firewall and created a loopback interface using a nonroutable IP address and port 444, the issue didn't happen. You then need to nat to the untrust that loopback on 444 to port 443. GP will only function on 443. The gotcha here is you cant use IPsec and have to use SSL VPN at the cost of about 20% or better on the performance. The more people that go to their account rep and create a request for enhancement, the more attention this will get. So far they said only 4 people have reported the issue. I see this as something more and more people are going to want to do.
09-27-2022 02:34 AM
Hi Carleton - did you ever get around this issue?
Cheers.
09-27-2022 05:23 AM
I managed to resolve this by adding multiple entries in the Azure SAML Identifer and reply-urls within the azure application SSO properties.
09-27-2022 05:41 AM
I got it escalated to PA product development. When you use prelogin using a machine certificate authentication and SAML for user authentication, the SAML page on the firewall is what's causing the issue. We also are using a Windows OCSP responder to validate the certificate from a Windows server 2019 CA server. What development came back with was it is an issue with TLS 1.2. They believe that TLS 1.3 will have support for checking for certificate OID. There is no ability to check OID of the certificate in TLS1.2. If you have both user and machine certificates on the endpoint from the same CA, the embedded browser will prompt for a user certificate even though you are already authenticated. the workaround is to create a subordinate CA and only issue machine certificates from that CA. I found that if I used the public IP on the untrust side of the firewall and created a loopback interface using a nonroutable IP address and port 444, the issue didn't happen. You then need to nat to the untrust that loopback on 444 to port 443. GP will only function on 443. The gotcha here is you cant use IPsec and have to use SSL VPN at the cost of about 20% or better on the performance. The more people that go to their account rep and create a request for enhancement, the more attention this will get. So far they said only 4 people have reported the issue. I see this as something more and more people are going to want to do.
09-27-2022 05:43 AM
One other thing. If you have user certs that are not used from the same CA and you delete them, the issue goes away too.
09-27-2022 05:52 AM
I replied to the wrong thread, sorry. Yes we got this resolved by using a singe Enterprise app for both firelwalls
09-27-2022 06:35 AM
In the basic SAML Config, you add both firewalls as shown below
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
