Navigation
- Monitor to verify that StoreFront is UP
- Server Objects
- Service Group
- Virtual Server
- SSL Redirect
- StoreFront Base URL
- Subscriptions/Favorites Replication Load Balancing
Monitor
Note: This is a Perl monitor, which uses the NSIP as the source IP.
- On the left, expand Traffic Management, expand Load Balancing, and click Monitors.
- On the right, click Add.
- Name it StoreFront or similar.
- Change the Type drop-down to STOREFRONT.
- If you will use SSL to communicate with the StoreFront servers, then scroll down, and check the box next to Secure.
- Scroll up, and switch to the Special Parameters tab.
- In the Store Name field, enter the name of your store (e.g. Store).
- The other two checkboxes are not working with StoreFront 2.6. Click Create.
add lb monitor StoreFront STOREFRONT -scriptName nssf.pl -dispatcherIP 127.0.0.1 -dispatcherPort 3013 -secure YES -storename Store
Servers
- On the left, expand Traffic Management, expand Load Balancing, and click Servers.
- On the right, click Add.
- Enter a descriptive server name, usually it matches the actual server name.
- Enter the IP address of the server.
- Enter comments to describe the server. Click Create.
- Continue adding StoreFront servers.
add server SF01 10.2.2.57 add server SF02 10.2.2.58
Service Group
- On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.
- On the right, click Add.
- Give the Service Group a descriptive name (e.g. svcgrp-StoreFront-SSL).
- Change the Protocol to HTTP or SSL. If the protocol is SSL, ensure that StoreFront Monitor has Secure checked.
- Scroll down and click OK.
- On the right, under Advanced, click Members.
- Click where it says No Service Group Member.
- If you did not create server objects, then enter the IP address of a StoreFront Server. If you previously created a server object then change the selection to Server Based and select the server objects.
- Enter 80 or 443 as the port. Then click Create.
- To add more members, click where it says 1 Service Group Member and then click Add. Click Close when done.
- On the right, under Advanced, click Monitors.
- Click where it says No Service Group to Monitor Binding.
- Click the arrow next to Click to select.
- Select your StoreFront monitor, and click OK.
- Then click Bind.
- To verify that the monitor is working, on the left, in the Service Group Members section, click the Service Group Members line.
- Highlight a member, and click Monitor Details.
- The Last Reponse should be Success – Probe succeeded. Click Close twice.
- On the right, under Advanced, click Settings.
- Check the box for Client IP and enter X-Forwarded-For as the Header. Then click OK.
- Then click Done.
add serviceGroup svcgrp-StoreFront-SSL SSL -maxClient 0 -maxReq 0 -cip ENABLED X-Forwarded-For bind serviceGroup svcgrp-StoreFront-SSL SF01 443 bind serviceGroup svcgrp-StoreFront-SSL SF02 443 bind serviceGroup svcgrp-StoreFront-SSL -monitorName StoreFront
- If the Service Group is http and you don’t have certificates installed on your StoreFront servers (aka SSL Offload), then you’ll need to enable loopback in StoreFront:
- In StoreFront 3.5, you enable it in the GUI console.
- In StoreFront 3.0, run the following commands on the StoreFront 3.0 servers as detailed at Citrix Blog Post What’s New in StoreFront 3.0.
& "C:\Program Files\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1" Set-DSLoopback -SiteId 1 -VirtualPath /Citrix/StoreWeb -Loopback OnUsingHttp
Load Balancing Virtual Server
- Create or install a certificate that will be used by the SSL Offload Virtual Server. This certificate must match the DNS name for the load balanced StoreFront servers. For email discovery in Citrix Receiver, the certificate must either be a wildcard (*.corp.local) or have a subject alternative name for discoverReceiver.domain.com (domain.com = email address suffix)
- On the left, under Traffic Management > Load Balancing, click Virtual Servers.
- On the right click Add.
- Name it lbvip-StoreFront-SSL or similar.
- Change the Protocol to SSL.
- Specify a new internal VIP.
- Enter 443 as the Port.
- Click OK.
add lb vserver lbvip-StoreFront-SSL SSL 10.2.2.221 443 -persistenceType SOURCEIP -timeout 60
- On the left, in the Services and Service Groups section, click where it says No Load Balancing Virtual Server ServiceGroup Binding.
- Click the arrow next to Click to select.
- Select your StoreFront Service Group, and click OK.
- Click Bind.
bind lb vserver lbvip-StoreFront-SSL svcgrp-StoreFront-SSL
- Click OK.
- Click where it says No Server Certificate.
- Click the arrow next to Click to select.
- Select the certificate for this StoreFront Load Balancing Virtual Server, and click OK.
- Click Bind.
bind ssl vserver lbvip-StoreFront-SSL -certkeyName WildCorpCom
- On the right, in the Advanced column, click Persistence.
- On the left, in the Persistence section, select SOURCEIP. Do NOT use COOKIEINSERT persistence or Android devices will not function correctly.
- Set the timeout to match the timeout of Receiver for Web.
- The IPv4 Netmask should default to 32 bits.
- Click OK.
- On the right, in the Advanced column, click SSL Parameters.
- If the NetScaler communicates with the StoreFront servers using HTTP (aka SSL Offload), at the top right, check the box next to SSL Redirect. Otherwise the Receiver for Web page will never display.
- Uncheck the box next to SSLv3.
set ssl vserver lbvip-StoreFront-SSL -sslRedirect ENABLED -ssl3 DISABLED
- NetScaler VPX 10.5 build 57 and newer lets you enable TLSv11 and TLSv12. Click OK.
- Perform other normal SSL vServer configuration including: disable SSLv3, bind a Modern Cipher Group, and enable Strict Transport Security.
bind ssl vserver lbvip-StoreFront-SSL -certkeyName MyCert set ssl vserver lbvip-StoreFront-SSL -ssl3 DISABLED -tls11 ENABLED -tls12 ENABLED unbind ssl vserver lbvip-StoreFront-SSL -cipherName ALL bind ssl vserver lbvip-StoreFront-SSL -cipherName Modern bind ssl vserver lbvip-StoreFront-SSL -eccCurveName ALL bind lb vserver lbvip-StoreFront-SSL -policyName insert_STS_header -priority 100 -gotoPriorityExpression END -type RESPONSE
- Then click Done.
SSL Redirect – Down vServer Method
If you created an SSL Offload Virtual Server that only listens on SSL 443, users must enter https:// when navigating to the website. To make it easier for the users, create another load balancing Virtual Server on the same VIP that listens on HTTP 80 and then redirects the user’s browser to reconnect on SSL 443.
This procedure details the Down vServer method of performing an SSL redirect. An alternative is to use the Responder method.
- On the left, under Traffic Management > Load Balancing, click Virtual Servers.
- On the right, find the SSL Virtual Server you’ve already created, right-click it, and click Add. Doing it this way copies some of the data from the already created Virtual Server.
- Change the name to indicate that this new Virtual Server is an SSL Redirect.
- Change the Protocol to HTTP on Port 80.
- The IP Address should already be filled in. It must match the original SSL Virtual Server.
- Click OK.
- Don’t select any services. This vServer must intentionally be marked down so the redirect will take effect. Click Continue.
- On the right, in the Advanced column, click Protection.
- In the Redirect URL field, enter the full URL including https://. For example: https://storefront.company.com/Citrix/StoreWeb. Click OK.
- Click Done.
add lb vserver lbvip-storefront-HTTP-SSLRedirect HTTP 10.2.2.201 80 -redirectURL "https://storefront.corp.com"
- When you view the SSL redirect Virtual Server in the list, it will have a state of DOWN. That’s OK. The Port 80 Virtual Server must be DOWN for the redirect to work.
StoreFront Base URL
- Create a DNS Host record that resolves to the new VIP.
- The DNS name for StoreFront load balancing must be different than the DNS name for NetScaler Gateway. Unless you are following the Single FQDN procedure.
- In the Citrix StoreFront console, right-click Server Group and click Change Base URL.
- Enter the new Base URL in https://storefront.corp.com format. This must match the certificate that is installed on the load balancer. Click OK.
Subscription Replication Load Balancing
If you have multiple StoreFront clusters (separate datacenters), you might want to replicate subscriptions between them. StoreFront subscription replication uses TCP port 808. To provide High Availability for this service, load balance TCP port 808 on the StoreFront servers. See Configure subscription synchronization at Citrix Docs for more information.
- On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.
- On the right, click Add.
- Give the Service Group a descriptive name (e.g. svcgrp-StoreFront-SubRepl).
- Change the Protocol to TCP.
- Scroll down and click OK.
- On the right, under Advanced, click Members.
- Click where it says No Service Group Member.
- In the IP Address field, enter the IP address of a back-end StoreFront server.
- Enter 808 as the port. Then click Create.
- To add more members, on the left, in the Service Group Members section, click where it says 1 Service Group Member.
- Click Add to add a member. Click Close when done.
- On the right, under Advanced, click Monitors.
- Click where it says No Service Group to Monitor Binding.
- Click the arrow next to Click to select.
- Select the tcp monitor, and click OK.
- Then click Bind, and click Done.
add serviceGroup svcgrp-StoreFront-FavRepl TCP bind serviceGroup svcgrp-StoreFront-FavRepl SF01 808 bind serviceGroup svcgrp-StoreFront-FavRepl SF02 808
- On the left, under Traffic Management > Load Balancing, click Virtual Servers.
- On the right click Add.
- Name it lbvip-StoreFront-SubRepl or similar.
- Change the Protocol to TCP.
- Specify the same VIP that you used for SSL Load Balancing of StoreFront.
- Enter 808 as the Port.
- Click Continue.
- Click where it says No Load Balancing Virtual Server ServiceGroup Binding.
- Click the arrow next to Click to select.
- Select your StoreFront Subscription Replication Service Group, and click OK.
- Click Bind.
- Click OK.
- On the right, in the Advanced column, click Persistence.
- Select SOURCEIP persistence.
- Set the timeout to 5 minutes.
- The IPv4 Netmask should default to 32 bits.
- Click OK.
- Then click Done.
add lb vserver lbvip-StoreFront-FavRepl TCP 10.2.2.201 808 -persistenceType SOURCEIP -timeout 5 bind lb vserver lbvip-StoreFront-FavRepl svcgrp-SF-FavRepl
Hi Carl,
Thank you for very detailed and helpful article, truly appreciated. I have one question, we currently have our storefront in the DMZ, what is the real benefit of having it in the DMZ and what feature we will loose if we take it out of DMZ ?
Thank you
I’m not aware of any benefit to putting in the DMZ. StoreFront is usually domain-joined. Remote access to StoreFront is usually reverse proxied through Citrix Gateway.
Hi Carl, thank you very much for the information you’re sharing. I’m moving our Storefront from Server 2012 to Server 2016 (IIS 10) and the IIS Advanced Logging software isn’t an option anymore – seems that it’s built into the new IIS. Your blog covers adding in the X-Forwarded-For header but not the IIS side to see this additional header.
StoreFront also needs the header for its own purposes (e.g. Client IP filtering).
In the absence of the IIS Advanced Logging installer (because of newer IIS) I have run the following based on someone else’s forum response (below). I am using the header name ‘X-Forwarded-For’ on my Netscaler. I assume this is how it’s done now…
Import-Module WebAdministration
Add-WebConfigurationProperty -pspath ‘MACHINE/WEBROOT/APPHOST’ -filter “system.applicationHost/sites/siteDefaults/logFile/customFields” -name “.” -value @{logFieldName=”X-Forwarded-For”;sourceName=”X-Forwarded-For”;sourceType=”RequestHeader”}
Add-WebConfigurationProperty -pspath ‘MACHINE/WEBROOT/APPHOST’ -filter “system.applicationHost/sites/siteDefaults/logFile/customFields” -name “.” -value @{logFieldName=”REMOTEADDRESS”;sourceName=”REMOTEADDRESS”;sourceType=”RequestHeader”}
I forgot to note that I’m using an old version of Storefront. Perhaps the X-Forwarded-For header is part of the newer Storefront software? I’ll find out shortly as I will be putting the latest in our test environment.
Hello Carl, I am using Netscaler Gateway 11.1. The authentication goes well when users entered the correct username and password. But, users are getting “Cannot Complete Request” when the authentication fails instead of “Invalid credential”. Storefront URL is working fine internally without any issue. this is happening only when we use Gateway.
On NetScaler, do “cat /tmp/aaad.debug” to see why auth is succeeding when it shouldn’t.
Are you maybe using Receiver instead of a browser? If Receiver, if the Internal Beacon is reachable, then Receiver will connect directly to StoreFront.
Thanks for the reply Carl. I did “cat /tmp/aaad.debug to capture the authentication events. LDAP send & receive are happened when entered the invalid credentias. But, the Gateway is throwing the error “Cannot complete your request” rather “Invalid credentials” error page. I have attached the logs for your review
ap_user_search_event Received LDAP user search event.
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[371]: ns_ldap _check_result checking LDAP result. Expecting 101 (LDAP_RES_SEARCH_RESULT)
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[375]: ns_ldap _check_result Got result 0. Non-event, continuing
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[339]: receive_ldap_user_search_event Received LDAP user search event.
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[371]: ns_ldap _check_result checking LDAP result. Expecting 101 (LDAP_RES_SEARCH_RESULT)
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[375]: ns_ldap_check_result Got result 0. Non-event, continuing
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[339]: receive_ldap_user_search_event Received LDAP user search event.
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[371]: ns_ldap_check_result checking LDAP result. Expecting 101 (LDAP_RES_SEARCH_RESULT)
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[408]: ns_ldap_check_result ldap_result found expected result LDAP_RES_SEARCH_RESULT
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[351]: receive_ldap_user_search_event received LDAP_OK
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[3452]: unregister_timer releasing timer 247
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[379]: receive_ldap_user_search_event Binding user… 1 entries
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[404]: receive_ldap_user_search_event User DN= <>
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[1260]: build_ldap_group_string group attribute was null
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[487]: receive_ldap_user_search_event For user Gopal, group stringLength 0
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[499]: receive_ldap_user_search_event no group extraction for Gopal
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[505]: receive_ldap_user_search_event AAA_LDAP_FLAGS_NO_AUTH: sending accept
Fri May 12 10:06:06 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[2309]: send_acceptsending accept to kernel for : Gopal
Fri May 12 10:06:09 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[575]: main timer 1firing…
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[774]: process_kernel_socket partition id is 0
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[873]: process_kernel_socket call to authenticate
user :Gopal, vsid :9715
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[3110]: start_cascade_auth starting cascade authentication
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[107]: start_ldap_auth Starting LDAP auth
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[134]: start_ldap_auth attempting to auth Gopal @ 1x.1x.2x.11
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[137]: start_ldap_auth LDAP referrals are OFF
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[138]: start_ldap_auth LDAP referral nesting depth 0
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[684]: continue_ldap_init Connecting to: 1x.1x.2x.11:389
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[3383]: register_timer setting timer 248
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[3452]: unregister_timer releasing timer 248
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[757]: ns_ldap_set_up_socket Server certificate hostname = NULL
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[802]: ns_ldap _set_up_socket Set cert verify level 0
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[805]: ns_ldap_set_up_socket Getting cipher suite global value
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[808]: ns_ldap_set_up_socket Checking non-zero cipher suite
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[817]: ns_ldap_set_up_socket NULL cipher suite. Using default.
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[823]: ns_ldap_set_up_socket Freeing cipher suite value
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[830]: ns_ldap_set_up_socket Done with cipher suite
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[897]: ns_ldap_set_up_socket Sectype: 1
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[3383]: register_timer setting timer 249
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[187]: receive_ldap_bind_event receive ldap bind event
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[371]: ns_ldap_check_result checking LDAP result. Expecting 97 (LDAP_RES_BIND)
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[408]: ns_ldap_check_result ldap_result found expected result LDAP_RES_BIND
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[198]: receive_ldap_bind_event Bind OK
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[3452]: unregister_timer releasing timer 249
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[264]: receive_ldap_bind_event Original slen: 11
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[290]: receive_ldap_bind_event User name: dirty = sanitized =
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[1022]: ns_ldap_search Searching for <> from base <>
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[3383]: register_timer setting timer 250
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[1046]: ns_ldap_search Sent user search query.
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[339]: receive_ldap_user_search_event Received LDAP user search event.
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[371]: ns_ldap_check_result checking LDAP result. Expecting 101 (LDAP_RES_SEARCH_RESULT)
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[375]: ns_ldap_check_result Got result 0. Non-event, continuing
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[339]: receive_ldap_user_search_event Received LDAP user search event.
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[371]: ns_ldap_check_result checking LDAP result. Expecting 101 (LDAP_RES_SEARCH_RESULT)
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[375]: ns_ldap_check_result Got result 0. Non-event, continuing
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[339]: receive_ldap_user_search_event Received LDAP user search event.
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[371]: ns_ldap_check_result checking LDAP result. Expecting 101 (LDAP_RES_SEARCH_RESULT)
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[375]: ns_ldap_check_result Got result 0. Non-event, continuing
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[339]: receive_ldap_user_search_event Received LDAP user search event.
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[371]: ns_ldap_check_result checking LDAP result. Expecting 101 (LDAP_RES_SEARCH_RESULT)
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[375]: ns_ldap_check_result Got result 0. Non-event, continuing
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[339]: receive_ldap_user_search_event Received LDAP user search event.
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[371]: ns_ldap_check_result checking LDAP result. Expecting 101 (LDAP_RES_SEARCH_RESULT)
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_common.c[408]: ns_ldap_check_result ldap_result found expected result LDAP_RES_SEARCH_RESULT
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[351]: receive_ldap_user_search_event received LDAP_OK
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[3452]: unregister_timer releasing timer 250
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[379]: receive_ldap_user_search_event Binding user… 1 entries
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[404]: receive_ldap_user_search_event User DN= <>
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[1260]: build_ldap_group_string group attribute was null
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[487]: receive_ldap_user_search_event For user Gopal, group stringLength 0
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[499]: receive_ldap_user_search_event no group extraction for Gopal
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/ldap_drv.c[505]: receive_ldap_user_search_event AAA_LDAP_FLAGS_NO_AUTH: sending accept
Fri May 12 10:06:27 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[2309]: send_accept sending accept to kernel for : Gopal
Fri May 12 10:06:39 2017
/home/build/rs_111_51_11_RTM/usr.src/netscaler/aaad/naaad.c[575]: main timer 1 firing…
I am not get the Set-DSLoopack command in powershell after importing the PS modules. I am using Storefront 2.6. Please let me know how to get this command in powershell. Thanks.
I believe this feature is only in 3.0 and newer.
Hi Carl,
Awesome work on this site – it’s saved my bacon a number of times.
Just a quick fyi- one screenshot has a discrepancy.
Under step 8 of Load Balancing Virtual Server on this page, the screenshot shows an IP address of 10.2.6.221, however the command for it, and the following screenshots that reference the vip, shows 10.2.2.221.
It through me for a minor loop but I was able to quickly recover.
Thanks again for maintaining this awesome site!
Hi Carl , great one again !!
Quick question, in my environement seems that the Monitor is using the SNIP… but I dont know why but the monitor is indicating “Failure probe failed…”
Any Ideas ? thx
StoreFront monitor? If so, it’s definitely using NSIP. Since NSIP doesn’t have a route to the server, it’s going through the SNIP, but the replies are going back to the NSIP. You might have to switch to a HTTP monitor. Or, implement RNAT.
Just only worries me for the case that one storefront takes more load than other and there is an impact in production environment. And also i wonder if this timeout difference could be the root cause of occasional error message “cannot complete your request ” .
Thanks again
Hi Carl I would like to share with you the results of my lab experiment related with low value sourceip persistence timeout for instance 2min and RFWeb session timeout to 1 h.
I found out that under circumanstances can cause “cannot complete your request error” because of usage CsrfToken. which is session expired coockie. Could be that case ?
Is there any other way to avoid this issue except to increase the sourceip persistence timeout greater than or equal to RFWeb session timeout ?
Thanks in advance.
Why the hesitation to increase the persistence timeout?
Sorry , thought I would try and clarify in more detail.
I have external users and internal users
My Required Time out scenario
External:
Sign in Time Out 2min
Session sign out 8 hours
Internal Users
Sign out Timeout 8 hours
Session Time out 8 Hours
For internal users I am using a load balanced storefront (vrs 3.6) on netscaler (vrs11.1)
External users connect to via the gateway to the same storefront LB Vip
Would you be able to point me in the right direction
Thank you
When you say “Sign In Time Out”, do you mean StoreFront webpage timeout?
NetScaler Gateway has timeouts in the session profile/policy that you can try adjusting. https://docs.citrix.com/en-us/netscaler-gateway/10-1/ng-connect-users-wrapper-con/ng-plugin-config-connection-wrapper-con/ng-plugin-config-timout-settings-overview-con.html
Otherwise, I think the timeout is global to the store so you might have to build separate StoreFront servers for internal and external.
Hi
Thank you for your reply , yes I am talking about the storefront web page sign in time out.I can not see a way around it unless as you mentioned build additional storefront storefront servers, that is a now go
Once again thank you for your reply and helping everybody.
Kind Regards
Craig
Hi Carl , I have a situation whereby my external users need a timeout lets say 2min and my internal users connect via load balanced storefront no time. The question is how do I sent my external users timeout values that they do not affect the internal users. Are all the settings done via netscaler. Storefront 3.6 Netscaler
Is it possible/difficult to customize the Storefront Monitor Perl script to use a SubNetIP (SNIP) instead of the NSIP as source address of the check?
In our setup, we will run into routing trouble (anti-spoof filters) when using the NSIP: the StoreFront servers are in the same subnet as the backend interface of the Netscaler. The NSIP is in the Management subnet. So the StoreFront servers will route the return traffic to their configured (default) gateway and will be dropped by the anti-spoof rules.
So I want to ensure that the Backend SNIP is used as source for the monitoring part…
Great article and it helped me a lot in understanding!
See https://support.citrix.com/article/CTX217712
Hi Carl,
How to setup persistence for Netscaler Virtual server without using load-balancing? I removed few storefront servers from manage members under services for an activity but NS still re-directs connection to those servers though I disabled them under manage members
Did you do a graceful shutdown?
Yes after that it worked. But when i faked it by disabling server from manage servers it still goes to that server. My understanding is it should not route connection unless it’s up
I meant when you disabled the service, did you check the box for Graceful? If so, persistent is honored. If not, persistence is ignored.
Hi Carl,
I have a weird issue with load balancing, or might be not.
I configured LB with HTTP redirect and everything works fine with one minor issue.
When internal user goes to URL http://mycompany.com/ he receives default IIS web page. If user refreshes the page immediately it redirects him to https://mycompany.com/Citrix/StoreWeb/. It is happening in IE only for internal users. Also I noticed that this is happening randomly, some users redirected to https without any issues. Also no issues with accessing https://mycompany.com – I am redirected to https://mycompany.com/Citrix/StoreWeb/ as expected.
What is configured:
– Netscaler 11.0
– 2 StoreFront 3.5 servers in Server Group, propagated changes. Base URL https://mycompany.com. Also web.config copied and it contains redirect enabled to https://mycompany.com/Citrix/StoreWeb/
– Internal DNS record mycompany.com is pointing to Virtual Server Load Balancing SSL (Service group with 2 members)
– HTTP redirect is configured for the same IP with NO members
– Both Virtual Servers have redirected URL pointing to https://mycompany.com/Citrix/StoreWeb/
So I cannot understand why IIS returns the default page. Looks like it is IIS issue, but if I go to http://SF01 or http://SF01 it redirects me to https://mycompany.com/Citrix/StoreWeb/ straight away.
Do you think it’s IIS or just Netscaler/Storefront not configured properly?
Thank you.
http is pointing to a VIP on the NetScaler. If no services are bound to the port 80 VIP then it’s impossible to see the IIS default page.
Do you have a proxy server? Maybe the proxy cached a prior configuration? Or your browser’s cache needs to be cleared.
You can use your browser’s F12 tools > network tab to see what’s happening.
Hi Carl, thank you for reply. You gave me a great hint about cache on proxy, as I tried to clear browser cache and that didn’t help. Today issue just disappeared and everyone is redirected to the correct URL, so I believe it was proxy cache, will talk to networking team later today.
Thank you for all your articles, for your blog and for your replies in Citrix support forum. It is very, very useful and helpful. You are the best! Thank you!
Hi Carl,
I’m facing issues when trying to authenticate with user certificate. I think I have the NetScaler part configured properly, but for some reason the SSO to StoreFront fails. We’re using NS 11.64.34 and SF 3.5.
We’re using UPN as the login attribute and verified that it works if we’re not using the CERT auth. The Cert auth seems to be working just fine when I log in to the NetScaler but the StoreFront SSO responds “Cannot complete your request.” to browser and event IDs 3, 8 and 10 are logged in StoreFront.
The event ID 10 contains the following:
”
The remote server returned an error: (403) Forbidden.
Url: http://127.0.0.1/Citrix/Authentication/CitrixAGBasic/Authenticate
ExceptionStatus: ProtocolError
ResponseStatus: Forbidden”
We’ve also noticed that if I try to reach the store URL with or without the NS LB layer with the proper name:
https://store.my.domain/Citrix/Authentication/Certificate/auth.aspx
The connection is reset by the IIS for some reason (I traced this with NetScaler capture). However if I change the URL for the host name:
https://sfserver.my.domain/Citrix/Authentication/Certificate/auth.aspx
I get a certifcate mismatch error but if I select to continue, the server returns my certificate information properly.
Our internal CA is issuing sha1 certificates and we have tried to disable the TLS1.2 on both NS Gateway and StoreFront LB without any success.
Any ideas?
Do you have callback configured? Does the callback Gateway have client certificates set to Mandatory? If so then you’ll need a separate Callback Gateway that doesn’t have client certs as Mandatory.
Hi, that was exactly the issue. My colleague created a separate GW which resolved the issue. The additional “dummy GW” doesn’t need to be reachable from the external networks so that shouldn’t be a big issue.
One more question 🙂
In the Citrix article https://support.citrix.com/article/CTX139201 it is stated that the /Authentication/Certificate/test.aspx should be available when using the store base url (whether it’s on LB or a DNS alias). I can only connect to the test.aspx with the server name as I described in my original posts.
Any insights on this specific matter?
ps. great blogs and articles, keep up the awesome job!
Hi Carl,
If you have a NetScaler HA pair in both the DMZ and on the internal LAN, and you want to integrate these with the same StoreFront store, how would you suggest to configure the StoreFront base URL?
For example, if you want the StoreFront load balanced URL to be storefront-lb.domain.com; would you add a load balanced virtual server on both NetScaler pairs with a LAN IP (for example 10.x.x.x) which resolves to storefront-lb.domain.com in the DNS? Or would you only configure the VIP on one of the NetScaler pairs, and on the other NetScaler pair add a vserver with an internal 192.168.x.x IP, and then add a DNS A-host to that NetScaler which resolves storefront-lb.domain.com to the 10.x.x.x VIP added on the other NetScaler pair? And finally, editing the HOSTS files on the two StoreFront servers adding each servers own IP-address resolving it to storefront-lb.domain.com.
My Netscaler Gateway in the DMZ is accessed on a different URL than the NetScaler Gateway on the internal NetScalers, and I will obviously configure these when adding the NetScaler Gateway appliances.
Thanks.
Sincerely,
Jimmi
I usually do load balancing on the internal NetScalers and then configure NetScaler Gateway in the DMZ to connect to the internal load balancer. They can be different DNS names.
It seems to be working. Thanks, Carl.
Hi Carl
Is there any specific reason for using X-Forwarded-For?
Can I use cookie insert and not use X-Forwarded-For? Clients are connecting from the same site behind PAT. If I set to source IP will they all go to one StoreFront server?
Thanks
M
See http://docs.citrix.com/en-us/storefront/3/sf-install-standard.html
I’ve seen Cookie Insert deployments not work until they are switched to Source IP persistence.
X-Forwarded-For is a standard for extracting the clients IP address, that is understood by IIS servers. This means that Storefront will be able to see that, and this is very helpfull when it comes to troubleshooting and will be helpfull, for the Helpdesk supporters. Because of this setting, Director will be able to show clients ip adresses, when they are connected through Netscaler Gateway.
I wanted a Dropdown list with the default domain for connection via the web site, and for the receiver without SSO.
I’ve just tested adding a dropdown list with storefront 3.0.1, with citrix docs : https://www.citrix.com/blogs/2014/04/01/adding-a-domain-list-for-receiver-authentication-to-storefront/
It works even better now as you only have to specify domain list, and the drop down list is automatically shown on the web page and receiver.
It should work internally but I don’t think it works through NetScaler Gateway.
Hello Carl, I ran into an issue when load-balancing StoreFront on the 10.5+ NetScaler where you could ping the VIP and even telnet to port 443 successfully, but the StoreFront webpage would just spin and never resolve. It turns out that you need to use the Protocol SSL-Bridged instead of SSL for the Services and the vServer. This fixed the problem.
The problem with SSL_BRIDGE is you can’t insert X-Forwarded-For. If 10.5 build 59, it could be a chiper problem on the services.
Carl, you are THE MAN!
Hi Carl
Sorry for my terrible English
I followed the steps in the article to set the LB, everything works ok when I use the browser to connect.
But, when I use the Citrix Receiver client, I get the following error:
“Your apps are not available at this Time Please try again in a few minutes or contact your helpdesk With information: An error occurred while contacting Store.”
If I configure Citrix Receiver to directly attack to one of the storefront, everything works, but when I try to attack the VIP, no.
I’m running Storefront 2.6, Netscaler VPX 10.5 55.8,nc and Citrix Receiver 4.1 and 4.2.
Any suggestions?
Thank you very much.
This usually means Persistence is not setup correctly. It needs to be Source IP with a timeout of 60 minutes or longer. Or maybe the Base URL was not configured correctly on the StoreFront servers. Try posting your question to discussions.citrix.com where further troubleshooting can be performed.
I think it is well put together and very helpful
Hi Carl,
I’ve seen your posts on the Citrix Forums and I’m getting a lot of nice information from you write-ups here. Great site!
Wondering if you might be able to point me in a direction to investigate why my Storefront Service Group is showing down. I followed your instructions here, except for creating the server, as it already exits for the LDAPS monitor on that server that is reporting up.
I tried checking and unchecking the boxes for Storefront Account Service and Check Backend Services and still not getting green light.
I am running Storefront 2.6
Thanks,
Patrick
Are you saying that LDAPS and StoreFront are the same server? Does that mean you have StoreFront installed on a Domain Controller? I never do that.