When I'm adding a custom policy label in to my nfactor that displays eula, authentication to StoreFront breaks, even that the loginschema bound to the policy label doesn't do anything for the authentication. I just get the error "A CitrixAGBasic Login request has failed." in StoreFront (The remote server returned an error: (403) Forbidden.). What could cause this?

What auth are you using? Is the EULA being shown before or after auth? A packet trace of the auth request to StoreFront should give you some hints too. I have set this up before and it worked, I didn't take very detailed notes but have a link to the Citrix doco here and a note "If configuring EULA as per Citrix Docs, need to add a true/NO_AUTHN pol as first label, then link to EULA label"

just LDAP

So I understand the flow correctly. User opens the web page, is presented with the EULA/NoAuth first step. They accept, proceed to the next LDAP Auth, correctly authenticate, and it passes them to StoreFront which errors? The error you are getting indicates maybe that the StoreFront callback is erroring out. Can you see an event in the StoreFront event or IIS logs? What does “cat /tmp/aaad.debug” show? Or “tail -f /var/log/ns.log | grep SSLVPN”? Watch both while performing a login that fails and that succeeds.

first ldap auth, then the eula

So, it looks like NetScaler is not keeping the primary login through the second NoAuth. I would start with the policies on the NetScaler and make sure the Attribute number lines up in LDAP and the policy. Also, try changing the attribute to 15 instead of 1. In the LDAP policy, Advanced, set the attribute 15 to the attribute you want (sAMAccountName or email, etc.) and then in the gateway policy set the primary to 15. I've seen low attribute numbers inexplicably overwritten by a later policy in nFactor.

I have done that.. I added the username in to ldap attribute (1 = samaccountname, 2 = userprincipalname) and then used traffic policy on Gateway to enforce that but still seeing that issue

It passes a tokenized auth to the StoreFront, so somewhere in that transfer the environment is failing. Try moving the attributes to a higher number. like 6 and 7 instead of 1 and 2.

I think I tried using END in the goto, but that didn't have any effect

And if it doesn't work, run the cat and tail commands to see what is being seen and delivered to StoreFront.

didn't help

Is StoreFront delegating the authentication fully to Gateway? Open two SSH sessions. In one go to the shell and use "cat /tmp/aaad.debug" and in the other “tail -f /var/log/ns.log | grep SSLVPN” Observe one that fails with the EULA and one that passes without and see what is different.

as for now we're not fully delegating... this is a prep step for Entra ID / SAML auth enrollment

Yep, good next step.

just a stupid issue, should be just a walk in the park, but no.

Please share if you find the problem, and if you would like assistance, I can probably make arrangements for someone to assist. We are in Oklahoma City doing an event at the March Madness games tomorrow, so I am probably going to be slow responding from here on out.

password field is blank in the network trace

It sounds like it. And you can see the password if you remove the second NoAuth?

nope, it actually didn't hit that URL at all

Interesting. Narrowing it down. Have a good evening!

I am using EULA and it works on latest NS 13.1 and SF 2402 CU3. First page is only username with EULA tick then I can do next authentication.

yeah, it has worked for me pretty much everywhere, but now there's some hiccup... opened a support case

@Kari Ruissalo (WyW) did you get it working, or is the support case still open?

still pending