Was trying to setup receiver self-service in one of our newer sites and it kept error. (This affects receiver for iOS and Android too by the way, which is how I first came to know of this problem). Had a lot of little configuration errors that needed fixing, but the last one (which is the title of this post) had me stumped for a while.
So without further ado:
- Ensure that there’s a separate session policy for receiver self-service. More importantly:
- Ensure that the expression for the policy includes the case for iOS devices too if you are interested in that (i.e.
REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver || REQ.HTTP.HEADER User-Agent CONTAINS 'CitrixReceiver-iPad' || REQ.HTTP.HEADER User-Agent CONTAINS CFNetwork || REQ.HTTP.HEADER User-Agent CONTAINS Darwin) - Not critical, but as a good practice – ensure that your receiver for web policy and receiver self-service policies have equal priority so there’s one less thing to look at when considering these policies.
- Ensure that the expression for the policy includes the case for iOS devices too if you are interested in that (i.e.
- Ensure that the single-sign on domain in the receiver self-service matches the trusted domains you define in the Citrix Storefront.
- Remember that web authentication uses LDAP as primary & RADIUS as secondary; while self-service authentication uses RADIUS as primary & LDAP as secondary, so double check these are setup accordingly with the correct expression to match web or self-service.
- Ensure that the receiver self-service policy has the SECONDARY credentials ticked for single-sign on.
If the authentication stuff is incorrect you will keep getting prompts that the login is incorrect. Also, the StoreFront logs might contain errors that the user domain isn’t a trusted one etc.
In my case even after doing all this I was getting an error. I was able to successfully login but then would get a message that receiver cannot connect to the store. This had me stumped for a long while until I re-read this Carl Stalhood article (his blog posts are amazing!) and came across this bit:
If you have multiple Gateways, select one of them as the Default appliance. Note: when you point Receiver to a NetScaler Gateway URL for Discovery, after Discovery is complete, the Default appliance selected here is the Gateway that Receiver uses. In other words, Receiver ignores the Gateway you entered during discovery.
That bit in italics was what was messing up my configuration. As part of testing the deployment we had a separate internal gateway, and that was the current default. So when using receiver self-service that internal gateway was being selected and things broke.
A bit more info on the same from this Citrix blog post:
For web browser-based access, the “default appliance” setting has no impact.
For native Receiver access, this setting is downloaded to Receiver on connection to the Store as part of the Store configuration and that Gateway is used thereafter by default.
If all defined Gateways share the same URL via GSLB, then again, this has no impact (Receiver just uses that Gateway definition to see which URL to query). If the Gateways have different FQDNs and you enable them all for a Store, then whichever one is defined as the default will be used by all Receiver clients on first connect. This is problematic if you have two distinct user communities using different FQDNs that you want to aggregate into the same Store (for management simplicity) and they are using Receiver clients. For example, if you have https://myaps.company.com and https://myvdi.company.com and the Gateway selected as the default for the Store is “myapps.” Any user that enters “myvdi” into Receiver during first time setup will be re-routed to “myapps” as soon as they hit StoreFront and be prompted to authenticate again. The cleanest way therefore to deal with multiple Gateway FQDNs and native Receiver clients is via distinct Stores or via distinct StoreFront server groups. Again, fairly specific scenario, but this is another setting that we find is not very well understood by the field.