Gateway certificate error when switching to SAML authentication

[rbhoward]

I am testing changing our authentication for GlobalProtect from AD LDAP on premises servers to using Azure AD saml. I have the authentication working fine at the portal; the system logs show successful authentication. But then I get  "Could not verify the server certificate of the gateway." on the client. The GlobalProtect logs on the firewall show the successful connection to the portal, but nothing at all on the gateway. There are no errors at all in the firewall logs, and I don't see anything more than the above error in the collected client logs.

I am testing this on a pa220 that has been working using LDAP. The portal and gateway are on the same interface and using the same certificate, a wildcard from Godaddy. If I swap the authentication profile back to the LDAP one and change nothing else, it works again.

Any ideas?

[rbhoward]

I got some time to dig further into the client logs yesterday and found that the certificate mismatch is because the client receives the IP address for the gateway rather than the FQDN that is defined in the portal. When the client retrieves the gateway information, does it get it from somewhere other than the agent configs on the portal?

[Adrian_Jensen · Accepted solution]

The client gets the Gateway information from the Portal agent config under the External tab. You can specify the gateways by FQDN or IP in the configuration. Something to look at might be the certificate attributes. If you are using SAML for the Portal auth then you need the portal FQDN in the certificate, if the Gateway then the gateway FQDN. If you use the same certificate for both then you need both names. The certificate should include a SAN section (certificate Subject Alternative Name) with all the FQDNs listed. Likewise, the matching FQDNs should be listed in the Azure SAML config for the IDP Identifier, Reply URL, and Sign on URL fields. 

[rbhoward]

Thank you for your response. I had those things correct, but in double checking them to make sure of that, I saw that the problem was username format. I had multiple agent configs in the portal, but they were looking for domain\username format while the SAML was providing username@domain. A final default agent config that hasn't been used in years was configured with IP. Now I just need to figure out usernames, etc.