Authentication failure post pOTP

[ffainelli]

I am getting an authentication failure after sending the correct OTP challenge that OKTA verify produced, is this something you have seen before:

---
[INFO] portal-userauthcookie: empty
[INFO] global protect login
err: login request failed. status code: 512, text:

var respStatus = "Error";
var respMsg = "Authentication failure: Invalid username or password";
thisForm.inputStr.value = "";

I can provide additional logs if necessary. When I do open a browser to the VPN URL gateway, it does redirect me to the page after successful authentication so something must have been working somehow.

[dlenski]

1. Are you using openconnect v8.00 or v8.01 as I recommended to you in How to connect when only okta auth is used dlenski/openconnect#116 (comment)? (Some of the pre-release versions had a bug in which the cookie/password may not be passed in properly.)

2. The script is telling you that it's failing to generate a portal-userauthcookie. If you login "manually" via the browser ("open a browser to the VPN URL gateway") and get to the page after successful authentication… can you verify that a valid portal-userauthcookie is indeed set by that page?

[ffainelli]

1. Are you using openconnect v8.00 or v8.01 as I recommended to you in [dlenski/openconnect#116 (comment)](https://github.com/dlenski/openconnect/issues/116#issuecomment-453875098)? (Some of the pre-release versions had a bug in which the cookie/password may not be passed in properly.)

I am using openconnect 8.01.

2. The script is telling you that it's failing to generate a `portal-userauthcookie`. If you login "manually" via the browser ("open a browser to the VPN URL gateway") and get to the page after successful authentication… can you verify that a valid `portal-userauthcookie` _is indeed set by that page_?

Assuming I used firefox -> Shift F9 to have storage, I only saw two PHPSESSID cookies, one with / as a path and the other one with /global-protect/ as the path.

gp-okta.py also seems to confirm there is no portal-userauthcookie:

<portal-userauthcookie>empty</portal-userauthcookie> <portal-prelogonuserauthcookie>empty</portal-prelogonuserauthcookie>

There does appear to be a:

<scep-cert-auth-cookie>XXXX</scep-cert-auth-cookie>

[dlenski]

There does appear to be a:
<scep-cert-auth-cookie>XXXX</scep-cert-auth-cookie>

I haven't seen this one before, but what if you try logging connecting via the command line with

$ echo "THAT_COOKIE_STRING" | \
  openconnect --prot=gp --passwd-on-stdin -u \
    USERNAME VPN.SERVER.COM/portal:scep-cert-auth-cookie

[ffainelli]

There does appear to be a:
<scep-cert-auth-cookie>XXXX</scep-cert-auth-cookie>

I haven't seen this one before, but what if you try logging connecting via the command line with

$ echo "THAT_COOKIE_STRING" | \
  openconnect --prot=gp --passwd-on-stdin -u \
    USERNAME VPN.SERVER.COM/portal:scep-cert-auth-cookie

It returns the following:

`Got HTTP response: HTTP/1.1 512 Custom error
Unexpected 512 result from server
SAML login is required via POST to this URL:

`

[ffainelli]

Here are some possibly relevant sections of the getconfig response:

        <authentication-modifier>
                <none/>
        </authentication-modifier>
        <authentication-override>
                <accept-cookie>no</accept-cookie>
                <generate-cookie>no</generate-cookie>
                <cookie-encrypt-decrypt-cert></cookie-encrypt-decrypt-cert>
        </authentication-override>
        <use-sso>yes</use-sso>
                <ip-address></ip-address>
                <host></host>
...
</exclusion>
        </hip-collection>
        <agent-config>
        <save-user-credentials>1</save-user-credentials>
        <portal-2fa>no</portal-2fa>
        <internal-gateway-2fa>no</internal-gateway-2fa>
        <auto-discovery-external-gateway-2fa>no</auto-discovery-external-gateway-2fa>
        <manual-only-gateway-2fa>no</manual-only-gateway-2fa>
<client-upgrade>prompt</client-upgrade>
<logout-remove-sso>yes</logout-remove-sso>
<krb-auth-fail-fallback>yes</krb-auth-fail-fallback>
<retry-tunnel>30</retry-tunnel>
<retry-timeout>5</retry-timeout>
<enforce-globalprotect>no</enforce-globalprotect>
<captive-portal-exception-timeout>0</captive-portal-exception-timeout>
<traffic-blocking-notification-delay>15</traffic-blocking-notification-delay>
<display-traffic-blocking-notification-msg>yes</display-traffic-blocking-notification-msg>
<traffic-blocking-notification-msg>&lt;div style=&quot;font-family:'Helvetica Neue';&quot;&gt;&lt;h1 style=&quot;color:red;text-align:center; margin: 0; font-size: 30px;&quot;&gt;Notice&lt;/h1&gt;&lt;p style=&quot;margin: 0;font-size: 15px; line-height: 1.2em;&quot;&gt;To access the network, you must first connect to GlobalProtect.&lt;/p&gt;&lt;/div&gt;</traffic-blocking-notification-msg>
<allow-traffic-blocking-notification-dismissal>yes</allow-traffic-blocking-notification-dismissal>
<display-captive-portal-detection-msg>no</display-captive-portal-detection-msg>
<captive-portal-detection-msg>&lt;div style=&quot;font-family:'Helvetica Neue';&quot;&gt;&lt;h1 style=&quot;color:red;text-align:center; margin: 0; font-size: 30px;&quot;&gt;Captive Portal Detected&lt;/h1&gt;&lt;p style=&quot;margin: 0; font-size: 15px; line-height: 1.2em;&quot;&gt;GlobalProtect has temporarily permitted network access for you to connect to the Internet. Follow instructions from your internet provider.&lt;/p&gt;&lt;p style=&quot;margin: 0; font-size: 15px; line-height: 1.2em;&quot;&gt;If you let the connection time out, open GlobalProtect and click Connect to try again.&lt;/p&gt;&lt;/div&gt;</captive-portal-detection-msg>
<certificate-store-lookup>user-and-machine</certificate-store-lookup>
<scep-certificate-renewal-period>7</scep-certificate-renewal-period>
<ext-key-usage-oid-for-client-cert></ext-key-usage-oid-for-client-cert>
<retain-connection-smartcard-removal>yes</retain-connection-smartcard-removal>
<rediscover-network>yes</rediscover-network>
<resubmit-host-info>yes</resubmit-host-info>
<can-continue-if-portal-cert-invalid>yes</can-continue-if-portal-cert-invalid>
<user-switch-tunnel-rename-timeout>0</user-switch-tunnel-rename-timeout>
<pre-logon-tunnel-rename-timeout>-1</pre-logon-tunnel-rename-timeout>
<show-system-tray-notifications>no</show-system-tray-notifications>
<max-internal-gateway-connection-attempts>0</max-internal-gateway-connection-attempts>
<portal-timeout>5</portal-timeout>
<connect-timeout>5</connect-timeout>
<receive-timeout>30</receive-timeout>
<enforce-dns>yes</enforce-dns>
<flush-dns>no</flush-dns>
<proxy-multiple-autodetect>no</proxy-multiple-autodetect>
<use-proxy>yes</use-proxy>
<wsc-autodetect>yes</wsc-autodetect>
<mfa-enabled>no</mfa-enabled>
<mfa-listening-port>4501</mfa-listening-port>
<mfa-trusted-host-list/>
<mfa-notification-msg>You have attempted to access a protected resource that requires additional authentication. Proceed to authenticate at</mfa-notification-msg>
<ipv6-preferred>yes</ipv6-preferred>

        </agent-config>
<user-email>first.lastname@company.com</user-email>
<portal-userauthcookie>empty</portal-userauthcookie>
<portal-prelogonuserauthcookie>empty</portal-prelogonuserauthcookie>
<scep-cert-auth-cookie>XXXXX</scep-cert-auth-cookie>
</policy>

[dlenski]

Ah, this is the portal getconfig request. Is there no <gateways> section in it!?

The <scep-cert-auth-cookie> value in the portal response is meaningless, or at least not useful for authentication to the gateway.

[ffainelli]

There is a gateway section with multiple gatewaya defined, I took that part out because it contains host names etc. If you want a full dump that is obfuscated, I can paste that tomorrow.

…

[arthepsy]

@ffainelli, full dump would definitely help.

[ffainelli]

@arthepsy I have a couple of different behaviors, with your repository as of 2adb621 ("Debug HTTP headers.") I get the following behavior:

https://gist.github.com/ffainelli/c5d0d9035b5823b20022e8c66f72e302

with @nicklan and his fork as of a7e61aa ("Pass conf where needed"), I get the following behavior:

• cannot get the certificate: https://gist.github.com/17c8d2fde9ab9bf5ffe0cfb6a7eff618
• forcing the certificate to be read from file after obtaining it from the portal: https://gist.github.com/4b99798a74a03d2b7e42bf89613c657a

[ffainelli]

Do these logs help in any way?

[yeluolei]

I have the same problem here.

[openbrian]

I'm also getting this issue.

<portal-userauthcookie>empty</portal-userauthcookie>

[openbrian]

You can get your VPN admin to enable the cookie by following these instructions https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000boODCAY