This message was deleted.

So you get that just opening in g storefront? Not when trying to open a resource? Did you add the second domain to the allowable domains? Do you have a two way trust.

Hi @Rob Zylowski. 1. Error only occurs passing thru to Storefront from ADC. SAML isn't configured for direct login to Storefront. 2. We have not gotten to app enumeration yet, as it fails when getting to storefront. 3. Allowable domains on storefront (if I am on the same page as you) is set to Allow all domains. 4. The trust is a one way trust where "test.blah" trusts blah.com

Is you nameid the upn? Do you have Fully Delegate credential checked

Yeah, saw that. Thank you Sir. Unfortunately same result.

Maybe I get this wrong but Netscaler get the username as user@blah.com and storefront needs the username as user@blah.local? So you need to change - after authentication - the realm/suffix/domain of the user. This should be possible by using a traffic policy at the level of the Gateway or within a login schema if using a next factor.

@Jon Falgout so just to get the facts straight; 1. Users are like Marion explained above "user@blah.com" and the @blah.com is the upn suffix for the users in the user domain 2. StoreFront servers are located in @test.blah? Often the issue is that in the user-side the user principal name which is on the user authentication (for instance Azure AD) matches the users email address, not the on-premise UPN. Not sure if this is the case for you? Anyway, you need to connect the SAML identity with the on-premise identity, which you can achieve using for example: 1. On the NetScaler AAA, use the SAML authentication as the first factor followed by second factor, which is an LDAP action that uses the "mail" attribute as the login attribute and stores the users on-premise UPN to NS attribute1 (or sth else) 2. Apply a Traffic policy to the GW vServer that sets the user name as the NS attribute 1 This way the users identity is connected and should pass on to the StoreFront in "undestandable form". Ofc to gain SSO you'll need FAS, PKI, etc... but this is how I've resolved this issue in several cases. I might have understood your problem incorrectly though.

Thanks Guys! Users are user@blah.com . The only thing on test.blah are the storefront servers, sf1.test.blah, sf2.test.blah. Forgot to mention we are using PingOne as the iDP not sure if that makes a difference. Interesting ideas about the next factor. Will look into that today.

So you're able to log in to the StoreFront using the @blah.com user?

Directly and using ldap/radius via ADC.

Ok, then using nFactor might solve that for you if you already have FAS in place

I'll give it a shot. Re FAS, does it work in a one way trust? I read that it required two way, but not sure if that's true? Thanks!

You FAS is in the user domain?

It would be, but VDA would be in test.blah

🤯

lol

So a "resource domain:

Thanks Kari!