"Connection Reset" and "No Subject in AuthnRequest": Troubleshooting GlobalProtect SAML Authentication Failures

• The customer encountered issues with setting up SAML authentication on their GlobalProtect VPN. They were unable to reach the SAML login page, resulting in failed authentication attempts. The client device could successfully connect to the IdP server, but the connection terminated with a "reset by peer" error, hinting at a potential network or configuration issue. This led to a "No Subject in AuthnRequest" message from the IdP.

• A user machine running Global Protect
• Global Protect gateway running PANOS software
• SAML IDP as per the customer environment

• Decoding the SAML request from the .har file from the user's  browser shows the following data:

<samlp:AuthnRequest

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

AssertionConsumerServiceURL="https://xyz-gw.com:443/SAML20/SP/ACS"

Destination="https://abc.auth.securid.com/saml-fe/sso/vpnBackup"

ID="_625cc2b19554fd8b54d5460c05161662"

IssueInstant="2025-04-21T17:27:58Z"

ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

Version="2.0">

<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://xyz-gw.com:443/SAML20/SP

</saml:Issuer>

• SAML response highlighted the status message "No subject in AuthnRequest" as seen by the IDP provider in their log messages

<saml2p:Response

xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"

Destination="https://xyz-gw.com:443/SAML20/SP/ACS" ID="_cc99a4fb2ce8bd5a" InResponseTo="_625cc2b19554fd8b54d5460c05161662"

IssueInstant="2025-04-21T17:28:01.851Z" Version="2.0">

<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://abc.auth.securid.com/saml-fe/sso/vpnBackup

</saml2:Issuer>

<saml2p:Status>

<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">

<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal"/>

</saml2p:StatusCode>

<saml2p:StatusMessage>No Subject in AuthnRequest</saml2p:StatusMessage>

</saml2p:Status>

</saml2p:Response>

• In the above example, RSA SecurID acts as the Identity Provider (IdP), though it's important to remember that the IdP can vary depending on a customer's environment. The GlobalProtect Gateway is serving as the Service Provider (SP).

• This is an error response from the IdP (RSA SecurID/abc) to the SP (xyz-gw). The core of the issue is that the IdP rejected the authentication request because it didn't specify the user credentials (Subject) it wanted to authenticate.

• This behavior from the IdP is incompatible with a standard SP-initiated browser SSO flow. In such a flow, the SP can't include a specific user identity in the <Subject> of the initial AuthnRequest because it simply doesn't know who the user is yet. 

• The user provides their credentials on the IdP's login page after being redirected. The IdP's error message, "No Subject in AuthnRequest," clearly indicates it's expecting this information upfront, which isn't how SP-initiated SSO typically works.

• The StatusMessage>No Subject in AuthnRequest</StatusMessage> directly explains why the Identity Provider (IdP) couldn't identify the user: the authentication request sent by the Service Provider (SP) didn't include the necessary user credentials, known as the "Subject."

• This error points to a potential configuration issue in the SAML implementation. In a typical SP-initiated browser SSO flow, the user's browser is first redirected by the SP to the IdP with a SAML Authentication Request (AuthnRequest). User credentials are not part of this initial request; they're provided later on the IdP's login page.

• It appears the IdP might be configured for IdP-initiated browser SSO, where the user begins their authentication journey directly from the IdP's portal. In that scenario, the IdP already has the user's credentials before sending a SAML assertion to the SP. The error suggests the IdP is incorrectly expecting the user's "Subject" within the initial AuthnRequest from the SP, which isn't how SP-initiated flows work.

Steps to Resolve the Issue :

To successfully implement SP-initiated SAML authentication, follow these steps:

1. Ask the customer to contact the IdP (abc.auth.securid.com).
2. Explain your setup: Clarify that you are implementing SP-initiated browser SSO, where the user is initially unknown to the SP.
3. Provide the full context: Share the SAML AuthnRequest and the Response that contained the "No Subject in AuthnRequest" error.
4. Verify IdP configuration: Ask the IdP to check the configuration for your SP's Entity ID (https://xyz-gw.com:443/SAML20/SP) associated with their endpoint (https://abc.auth.securid.com/saml-fe/sso/vpnBackup).
5. Confirm endpoint intent: Specifically, ask them to confirm if that endpoint is indeed intended for SP-initiated browser SSO and whether the requirement for a <Subject> element within the AuthnRequest can be removed or adjusted for this configuration.

• Additional details regarding the SAML workflow can be found in the document below : 
  Introduction to SAML