Netscaler 2-Factor using DUO OAuth not validating tokens

[ThinkingVirtually]

Recently DUO and NetScaler now offer OAuth using 14.1 since DUO not supporting IFRAME anymore. I was able to configure it on our gateway using DUO instructions, but after approving the 2-factor it tries to send you back to gateway where it fails. 

https://duo.com/docs/netscaler-web#migration-from-duo-authentication-proxy-solutions-to-duo-oauth

Error message:

Error trying to validate Access Token. Please contact your administrator

Any help would be a plus!!

 

 

Edited October 10 by ThinkingVirtually
added url

[ThinkingVirtually]

I was able to get pass this part by removing the symbol "\" in the authorize URL. This only happens when you are building it manually through the GUI. If you are using the command line, then just copy the URL from the documentation. 

[Sasi Tzdaka]

Hi

we have the same issue

we check he "\" in the authorize URL but it is config ok.

you have any idea?

[rms]

I am having the same issue.
Push is verified on the DUO side. It redirects back to my NetScaler Gateway VIP /oauth/login?state=--stateinfo-- but takes a long time to timeout before giving the error "Error trying to validate Access Token. Please contact your administrator"

ns.log shows the error as with the full url and stateinfo
AAA Client Handler: Found extended error code 1310727, ReqType 16386 request

Were you able to resolve this?

[DanielRuiz]

I’m experiencing the same issue. I managed to get it working on another set of NetScalers, but it’s not functioning on a new deployment.

On the new pair, when I go to the NetScaler Gateway site, I authenticate using LDAPS credentials and get redirected to DUO Universal. However, it eventually times out with the error message:
"Error trying to validate Access Token. Please contact your administrator."

When I check the logs using tail -f ns.log | grep -v CMD_EXEC under /var/log, I see the following message:
"AAA Client Handler: Found extended error code 1310727, ReqType 16386."

Has anyone encountered this issue and found a solution? Any insights would be appreciated.

 

 

[DanielRuiz]

Hi everyone,

I resolved the issue caused by traffic not reaching StoreFront properly.

Here’s what I did:

1. Removed the nFactor Configuration: Version 14.1 has a peculiar nFactor GUI, which seems very finicky / buggy

2. Deleted the Duo Web Advanced Authentication Action and Policy.

3. Created a New Session Policy: This policy directed traffic to a dummy (bogus) StoreFront server.

4. Recreated the Duo Web Advanced Authentication Action and Policy.

5. Created a New nFactor Profile: I connected the nFactor flows to LDAPS and the newly created Duo Web advanced authentication action and policy.

6. Tested Authentication: Verified successful authentication, which redirected to the dummy StoreFront server, confirming traffic was attempting to reach StoreFront.

7. Created a New SSL Profile: Applied this to the NetScaler Gateway.

8. Updated the StoreFront Session Policy: Adjusted it to route traffic to the correct StoreFront servers.

I’ll publish a detailed blog post about this process soon at https://danielruiz.net. Stay tuned!

[ThinkingVirtually]

Hey,

They just released a new configuration for this setup. You can watch it on demand. Its more detail than the first session.

 

Edited November 22 by ThinkingVirtually

[rms]

I resolved my issue.

On the lab NetScaler that I was testing on the default backend SSL profile was limited to TLS 1.0 from some previous testing. Once I re-enabled TLS 1.2 all was good. Presumably the backend profile dictates the TLS protocol and cipher suites that are used for the token verification cryptography.

 

Edited November 22 by rms

[DanielRuiz]

I documented the setup and put it on my blog.  I hope it helps someone.  https://danielruiz.net/2024/11/22/netscaler-14-1-oauth-with-duo-universal-prompt-and-no-citrix-federated-authentication-service-fas/