Someone here mentioned the AAA Profile authenticat...
# citrix-netscaler
k
Someone here mentioned the AAA Profile authentication domain -field? (Was it you @Jan Tytgat?)... I have a small problem. I have a "landing page" (sth like landing.company.com) which contains links to different systems (like system1.company.com, system2.company.com,..). The user can connect directly to one of the systems, but some use the landing page to connect to multiple ones. Before they are allowed to go to any of these pages, they're required to authenticate on NetScaler GW (auth.company.com, this one is using SAML/Entra ID). The problem is that when they authenticate on the landing.company.com page (using the auth.company.com), they need to re-authenticate when going to system1.company.com. I tried setting the AAA domain setting to "company.com", but that didn't seem to help. Should it?
j
Assuming the authentication level for both system1 and system2 is the same, setting the AAA cookie domain to company.com should be enough.
k
that's the case
j
you might need to validate your traffic policies and session profile
k
Firefox didn't show the NSC_TMAS cookie domain, I'll check it with a chromium
j
AAA cookie domain is only to control AAA behavior
it's the session profile + traffic policy that control SSO to backend
k
yeah... seems that even if I change the domain on the AAA AuthN Profile, I'm still getting landing.company.com as the domain for NSC_TMAS cookie
j
Cookie persistency enabled
?
k
nno?
the one under AAA Global
let me try that one
j
never use AAA Global šŸ˜„
k
session policy then?
j
So you have authentication host set to auth.company.com and Authentication domain set to company.com right?
šŸ‘ 1
Only thing I can think of is that SAML auth overrides the authentication domain logic
as you need an enterprise application in Entra ID with a callback URL
but that should be auth.company.com in that case
k
the persistent cookie didn't help
j
the persistent cookie was just a question to make sure it wasn't set šŸ˜‰
k
oh, ok
j
do you have a plain AD available ?
you might want to check againt plain AD if it works (or even local auth)
just to make sure that SAML isn't causing this discrepancy
k
ok, I think you might be on to something
šŸ‘ 1
but the thing is that I have only added the GW in the LB vServer in authentication, so once traffic hits the LB VS, one could assume the NetScaler would check the cookie validity and pass the user through
however the NSC_TMAS cookie is written to the subdomain, so it doesn't seem to work
j
So you have a GW with a auth profile to send auth traffic to AAA VS
šŸ‘ 1
And you have an LB with authentication enabled, also with a authprofile to send it to auth.company.com
k
image.png
I just have the GW object mapped to the LB VS and its FQDN
no authn profile
should I have that too or even replace some bits with that
j
Use an authentication profile on the LB as well (should be different than the auth profile on the gw), but with the same auth level.
Both profiles as such have: • Auth host: auth.conpany.com • Auth Domain : company.com • Auth level: 10 • Aaa server: the AAA VS
k
Oh... I'm using same hostname for GW and AAA
my AAA is non-addressable
so in this sense my GW is "auth.company.com"
("also")
j
and why do you do this on GW?
are you doing ICA proxy at all?
k
the use-case started off with ICA proxy
but as things evolved, the customer has leveraged the existing setup for the GW auth for other purposes too
j
i'd suggest switching the fqdn for gw to something more generic
k
it is generic, I'm not dropping real hostnames here šŸ™‚
j
yeah yeah, you know what I mean
šŸ˜›
but even as such, that should work
k
yeah... it might be I would need to add a completely new authn profile and bind that one to the gw server to get that domain -thing applied
seems there are things that require some forceful pushing of the buttons to get piped through
like... if you enter a metadata url to SAML/OAuth Server and try to get rid of that, you need to rebuild the whole thing...