This message was deleted.

New IP's for new vServers mate, GSLB is just doing the name resolution

Got it.. thought that, Andy... just crafting the plan now. Good weekend to you, sir!

Have you thought about using Nfactor ? i did our migration to our new MFA solution OKTA (saml) using Nfactor so could run both existing and new MFA solution together on the existing NS GW vserver. Basically as 1st factor i have a username only loginschema that uses a advanced ldap group extraction policy to get the group membership of user. The next factor looks at the group memberships using AAA.USER.IS_MEMBER_OF and no_auth polices and if user is member of AD group "MFA1" they get the old MFA solution using ldap/radius with a dual factor loginschema but if they are a member of the AD group "MFA2" they get spun off to the idp (OKTA) using the saml policy. I used AAA groups and separate session polices/profile which was bound to the AAA group to point to the FAS enabled storefront store for the saml users

That's a good shout, John. The customer is very keen to keep both totally sperate as they are looking to move to a new url and minimize risk... that said, I never thought of this option so I'll keep it in mind 🙂

Ping Matt @John Gallacher - we have nfactor configs for this all over the place :-)

@c4rm0 @James Kindon @John Gallacher Are there blogs or more sources of info for this type of setup? We are about to be in the position of supporting LDAP/Radius with Duo and moving to Azure AD and Azure MFA

Deyda has a good walkthrough here: https://www.deyda.net/index.php/en/2020/04/02/saml-authentication-between-citrix-microsoft-with-azure-mfa/

i got a nfactor blog that does saml using okta and ldap for vip users on a single GW same type of concepts https://c4rm0.wordpress.com/netscaler-nfactor-authentication/

Thanks guys.

the easiest method i found is to have a username only login schema as first factor that collects the AD group memberships, next factor looks at those group memberships with no_auth , next factor depends on group memberships eg user is member of AzureADmfa next factor = spun off to azuread policy label which has the azuread advanced saml policy bound with nologinschema, if this user is member of radiusmfa next factor = dual auth login schema with ldap policy bound and cred index set and next factor radius with nologinschema and a then finally a traffic policy to pass through the AD creds to SF thats how i did ours. The options with nfactor in un limitless atm i got 3 different types of mfa solutions on my NS GW Azure mfa using saml , okta using radius, netscaler natve otp users get different MFA solutions based off AD groups