During a new setup for a customer we were using the latest build from Storefront 2.6 and latest NS build 10.5 (53) to ensure that there are no bugs and so on.
The pre-existing Storefront was setup using regular HTTP (Not recommended) but it should work just fine.
After setting up Netscaler against Storefront and adding different policies everything looked to be working fine.
Well almost… Receiver for web worked as it should we managed to authenticate and start applications as they should. But! when using Citrix Receiver (latest version) we stumbled across something funny.
After starting Citrix Receiver and entering username and password the “enter URL” dialog window popped up again
annoying….
So I did as every IT-guy does, I enabled logging of Receiver and checked the logs on Storefront and doublechecking on different clients and checked that the store actually was saved in the registry.
Since my first things was that Receiver wasn’t able to store info in registry
NOTE: Citrix Receiver stores info under HKEY_CURRENT_USER
That worked as it should, then I enabled logging on Citrix Receiver and saw trough the logs there.
This is done by adding a couple of registry settings under HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixAuthManager
SDKTracingEnabled = true
TracingEnabled = true
HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrix
dword, ReceiverVerboseTracingEnabled = 1
The logs are generated under %AppData%LocalCitrix
but no luck there as well, everything looked as it should be, but still no luck. After that I got some tips from some colleagues that I should enable HTTPS since it was the last logical chooise
and voila! then Citrix Receiver worked as it should.
This is actually by design. Default settings for Recevier doesn’t permit adding un-secure stores, it requires HTTPS. This has been the case since version 4 was released as far as I know. This article shows how this can be overridden: http://itsolutionsdirect.com/configuring-citrix-storefront-for-http-access/650/
Hi Geir, know it can be overided with the registry setting. But since the store was proxied with a netscaler it should throw a error message of some sort, I tried the registry setting but no change and on other platforms it worked fine. And I know it has worked before 🙂
I have made it a habit to use HTTPS on Storefront no matter what, since I have experienced problems using Receiver on mobile devices if HTTPS has not been enabled. Dunno why, though…. Since the Storefront server “never” is exposed to the public, a self-signed certificate would normally suffice. Most mid to larger companies now have their own internal CA, and can provide the certificate, and it only requires installing the root certificate on the Netscaler. That would also reduce the risk for man-in-the-middle attacks on the LAN, sniffing out passwords in packets destined for the Storefront server.
Fully aware of this, it is not that I don’t agree with you. Just find it a bit odd that I don’t get any error messages of such and that logs don’t say anything that I’m running on HTTP.
And by the way, if I already have someone man-in-the-middle it not much of a hassle to use sslstrip and arpspoof to buypass the certificate 😉
Marius, were they running LB VIP on port 80? And everything started working when you switched LB to SSL? Or did you have to go SSL on the actual Storefront servers also? Just curious, storing others experiences for possible issues in the future….
No LB involved in this scenario, just plain gateway backend to Storefront which was running HTTP. So After switching to HTTPS on Storefront it worked fine.