https://worldofeuc.com logo
Join Slack
Powered by
This message was deleted.
# citrix-netscaler
s
This message was deleted.
b
I typically set it up for USERDOMAIN
👍 1
j
I'm using both sAMACCOUNT and UPN. With 2 policies to connect to my ldaps, one for sAMACCOUNT and one FOR UPN.
c
What are you using for authentication on the Netscaler ? just single factor ldap? if its single factor ldap on your ldap request server you will have server logon name atrribute which is typically samaccoutname with the SSO name blank you can switch these around if u want to login with the UPN (sso name attribute would have to be samaccoutname as SF doesnt like UPN) . You then need to check your session profile look under client experience make sure single sign on to web applications is ticked, under published applications make sure single sign on domain is specified eg c4rm0 (netbios name) , on the storefront store check your trusted domains and pass through from netscaler is ticked as a auth method. You will need to check the Storefront delivery services logs as they are your freind and will narrow down the issue 👍
if you are using federated authentication eg SAML using OKTA or Azure AD with MFA and FAS you dont need to have a SSO domain listed in the session profile under published apps you just need to make sure you enabled FAS on the SF store, fully delegated credentials to the netscaler, have a callback url specified on your ns gw appliance in SF, have trustrequestssenttothexmlserviceport enabled,
e
Thanks, let me try to explain. I have a custom Netscaler build script that build out everything. If I use USERDOMAIN "desktopanywhere" as Trusted Domain, then the SF Load Balancer throws the error "Cannot complete your request". When I use USERDNSDOMAIN "DESKTOPANYWHERE.IO" it works, but easily fixed by adding Persitence = Source IP on the SF Load Balancer. Then SF LB works internally and I can logon successfully, but SSON from NSGW to SF does not work.
c
remove the SSO name attribute in your ldap server you dont need that as its set in the session profile. You got pass through from netscaler ticked as a auth method on the store ?
this
e
Yes, had it working yesterday after changing stuff manually, but today it doesn't after rebuild. I have tested with and without Callback. I removed the SSO name attribute, but same same. My biggest problem is that the Citrix Delivery Services log on the SF servers doesn't show shit
c
check this also on your session profile
e
Yeah
c
strange that looks all good and correct. There was a SSO traffic policy you had to use with newer NetScaler builds as sso from the NS to SF was broken
m
use the FQDN of the domain
not the netbios name
e
Yeah, reason why I went with 12.x - The script has been built by Dave Brett 😉 Just PITA when it doesn't work.
I have tested that, but let me rebuild. So FQDN on both SF and Netscaler
m
yes
e
ok, give me 3 minutes
c
tbh i always add both the fqdn and netbios to trusted domains in storefront
m
that’s what the NS will pass through, you can see it in a aad.debug
c
but always used netbios as sso domain in the session profile
m
I try to use UPN where possible and keep the session profile sso domain blank
but if not I set it to the fqdn. I’m not saying this is the only way to do it but because 98% of these issues are related to DNS/SSL it’s typically a good idea to do fqdn
e
tried both, still the same
Just to check, when using browser I'm hitting the ses_pol_web policy right?
m
yeah
e
Still nothing in SF event log, should I try UPN?
m
I would do UPN unless it’s messed up and doesn’t match your domain
that’s the only reason not to
and in that case you can use a AAA group bound to a policy that just overwrites the SSO domain
if you only have a single domain I’d set storefront to any domain and not have them listed at all
the netscaler is going to handle letting them in, there’s no need to do it there unless you are allowing direct access internally to the same store
c
you can check the session policy hits with nsconmsg -d current -g pol_hits or nsconmsg -d current -g _hits
m
the only reason to list out the domains is so you can use a dropdown menu in storefront to select one and not have to type in the upn or domain\username
c
just make sure you got the session policy for RFW bound to your NS GW Vserver
e
Only this?
m
I think you need to reverse your logon and sso attributes
logon is sam, sso is upn
because the sso needs to contain the domain
e
yeah, so UPN was missing in AD, now it works, but still halt at StoreFront web page. I did set to Trust Domains
m
I take it sotrefront will log you in if you try to log into it direct with upn?
e
Yeah both works, its SAM and UPN as you said
I've blank the policy out, is that correct?
m
yes because it just passes through the domain from the upn
c
hows your hostfile look on your storefront servers you got an entry for the NS GW URL that points to the GW VIP eg gateway.corp.com 192.168.1.12 rather than using DNS to resolve it to the public address. You doing anything like using ssl offload for your storefront LB vserver/VIP if so you will have to take a look at the loopback settings in SF (onusinghttp)
e
Thanks John, I've been playing without Call Back, but will try to add to hosts file and see if that fixes my issues. Rebuilding everything again 😉
c
also did you check that your RFW session policy was bound and was actually getting hit with the nsconmsg commands i posted
e
will test that as well when its back up again
c
hey I didnt see it mentioned in this thread but there a change required once you got to a certain ADC version, had to enable SSO in a Traffic Management policy and bind to the Gateway VIP.
• add vpn trafficAction StoreFront_SSO_trprof http -SSO ON • add vpn trafficPolicy StoreFront_SSO_trpol "HTTP.REQ.METHOD.EQ(post) || HTTP.REQ.METHOD.EQ(get) && false" StoreFront_SSO_trprof • bind vpn vserver YOUR_CITRIX_GATEWAY_vSERVER_NAME -policy StoreFront_SSO_trpol -priority 100 -gotoPriorityExpression END -type REQUEST
e
Thanks Carl, that's with some 13.x version. This fucking crap worked yesterday and today nothing
m
That’s the VDI motto
The amount of times I go to roll out an new image and something is randomly broken and I haven’t changed anything...
(That I remember)
Infrastructure as code is awesome but if the GPO with all your settings randomly disappears during a bad AD replication you’re still screwed
e
Indeed, luckily my MI builds always work and I have control. Netscaler, well that's not my speciality
anyone interested in earning some $$ fixing this and learning Netscaler automation at the same time? I'm loosing my sleep and day work over this crap, ping @Dave Brett
m
I had an idea with VPX where you could just jam a working nsconfig on there before it even boots and then you’re done.
Never got around to testing if it would work
c
@Eric what version of SF?
e
1909.1.0.11 cause the newer in 2009 or 2012 ISO breaks the silent install, never a dull moment
a working nsconfig is my 2nd option, just need to get it working LOL This stuff is for my upcoming Automation Master Class, but there's no time to spend 4 hours configuring a Netscaler. Just need it working 🙂
m
are you still getting a token error? I can do a screen sharing session and have a quick look if you want.
s
you missing a .IO on your STORE URL?
m
lol, that’ll do it
e
Thx Steve, yeah there was a bug with the SF build but this has been resolved. The PITA part is that there’s no logs at all, serms like it passes to SF and then nothing, still SF branding is showing so it does hit it. NS also shows the policy being applied.
I think I just want this working & with Google 2FA as nFactor. So spin up basic NS with license & cert and then dump nsconf via Powershell
s
so you have the FQDN set as the Store URL and your still having problems? and the Citrix Delivery Services eventlog on SF doesn't contain any entries upon failure?
e
Excatly
s
dont think i've ever seen it where SF didn't log an error like that. Can you try putting in the SF IP instead of the DNS name in your session policy... that would remove troubleshooting the LB VIP or multiple SF servers. no firewall, right? that SF has to log something in here...
c
I have seen that error in some recent 1912 deployments but trying to think how it was resolved, the errors did go into that Event Viewer log though.
m
You initially said that SF LB is working if using source IP persistence. What is your loopbackmode set to on SF? And have you tried to add a hosts entry on SF pointing workspace.desktopanywhere.io to 127.0.0.1 ?
👍 1
e
FML, it was the automated StoreFront build script that caused the issue, no clue what, but when building the Store manually using the Wizard everything works 🙂 Thanks all
s
let us know if you figure it out, been having my own pains with SF automation as well.
👍 1
Open in Slack
PreviousNext
Powered by