World of EUC

we are using LDAP for the first authentication source and RADIUS (Duo) for the second.  I followed through Carl's blog, and aside from applying a scheme to put the password and passcode fields on the same screen (we are not doing that currently), our config seems to match.

<https://www.carlstalhood.com/citrix-gateway-radius-authentication/>

Well....it seems to be related to binding an authentication policy that has an expression "AAA.LOGIN.USERNAME.CONTAINS("<http://domainexample.com|domainexample.com>")

when the expression is just "true" it works fine.  When we bind an expression to try parsing the username for the domain (to send it to a different LDAP action specific to that user's domain) it breaks.

the goal was to have two different authentication policies, each looking for a different domain string, pointing to a different LDAP server/action, and allow for users in our child domain to authenticate alongside the parent domain.  We didn't have an issue doing this with classic expressions.

This nfactor config is really hard for me to wrap my mind around for some reason.

in which policy do you have the expression with the aaa.login.username.contains("somedomain") ?
It can only work on radius (as you said this is you secondary authentication cause before netscaler does not know the username). But I am not even sure if it would work on radius. maybe you have to user aaa.user.domain (something like this)

I've got a setup where users are directed based on the domain part of the UPN, if this is what you are trying to do?
add authentication Policy pol_LDAPS_xxxx.local -rule "AAA.LOGIN.USERNAME.SET_TEXT_MODE(IGNORECASE).CONTAINS(\"xxxx.local\")" -action auth_LDAPS_xxxx.local

image.png

This was the initial setup - EULA presented first, then policy labels and policies to check which domain they belonged to, with an extra step to prompt for MFA depending on AD group membership in one domain

Thanks for that <@ULNLQFMB8> - yes, I am trying to do basically that, but I'm leaning towards an issue with my expression, which obviously differs from yours.  Even the presence of a single authentication policy with the formatting of my expression breaks Receiver being able to add a store/account or an existing Receiver/WA from communicating with the gateway properly (it doesn't even get to the point of displaying a logon prompt).  Just throws a server error.  Reverting to a LDAP authentication policy using "true" fixes it immediately.  I will do some testing using an expression like yours, appreciate the details.

We ended up getting the LDAP &gt; RADIUS policies to work by just using "true" in the expression - not ideal, but it basically mirrors the config of cascading authentication we had using classic expressions.  This child domain is actually scheduled to be consolidated into the parent domain in about a month, so I figured it was best to not chase our tails on this right now and just make it work.

I have a feeling the part we are missing is the "noauth" type policy that precedes all the other steps in the nfactor flow.  From what I've gathered reading docs and various blogs, it seems like that step is key for being able to parse the username to check for domain strings.  Our expression was pretty similar to Daniel's, with exception to the string forcing it to disregard case sensitivity.