Gregor Blaj Posted September 16, 2019 Share Posted September 16, 2019 Hi, I haven't seen anything about the below issue being fixed in newer StoreFront releases, but it seems like a bug to me. 1. Set the GSLBURL for a NetScaler Gateway definition in StoreFront and propagate the changes. 2. Connections from the Gateway, to the original URL (citrix.company.com) and the GSLB URL (site1.company.com), start failing ('Cannot complete your request'). 3. Remove the GSLBURL for the NetScaler Gateway definition. 4. Connections still failing with the same error. 5. Restart services, reset IIS, reboot servers etc... Error still present. 6. Re-create the NetScaler Gateway definition in StoreFront, propagate the changes. 7. Starts working again. I'm not sure why the GSLBURL specified (site1.company.com) didn't work, or what persisted once I reverted the setting, but I'm including the relevant logs below. Has anyone come across this before? StoreFront: 1811 NetScaler: 12.0 60.10 CallBack URL: Blank vServer IP: Blank SSO Domain (Session Profile): Set to domain NETBIOS name. Trusted Domains in SF: Configured, including the above. Other gateways specified in StoreFront: Working the whole time as usual. Error 1: Quote The AG Web Service at: http://localhost/ failed with the following error. This endpoint will be ignored until: 16/09/2019 10:41:15 a.m. Citrix.DeliveryServices.Authentication.CitrixAGBasic.Exceptions.AGCommunicationException, Citrix.DeliveryServices.Authentication.CitrixAGBasic, Version=3.17.0.0, Culture=neutral, PublicKeyToken=null A communication error occurred while attempting to contact the NetScaler Gateway authentication service at http://localhost/. Check that the authentication service is running. at Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.AGClient.GetAccessInfo(String sessionId, String username, String domain) at Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.CitrixAGBasicWebService.GetAccessInfo(String sessionId, String username, String domain) System.Net.WebException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 The request failed with the error message: -- <head><title>Document Moved</title></head> <body><h1>Object Moved</h1>This document may be found <a HREF="http://localhost/Citrix/centralWeb/">here</a></body> --. at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) at Citrix.DeliveryServices.Authentication.CitrixAGBasic.AGAuthService.AuthenticationServiceSoap.GetAccessInformation(String sessionId, String username, String domain) at Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.AGClient.GetAccessInfo(String sessionId, String username, String domain) Error 2: Quote None of the AG callback services responded Error 3: Quote A CitrixAGBasic Login request has failed. Citrix.DeliveryServicesClients.Authentication.AG.AGAuthenticatorException, Citrix.DeliveryServicesClients.Authentication, Version=3.17.0.0, Culture=neutral, PublicKeyToken=null Authenticate encountered an exception. at Citrix.DeliveryServicesClients.Authentication.AG.AGAuthenticator.Authenticate(HttpRequestBase clientRequest, Boolean& passwordSupplied) at Citrix.Web.AuthControllers.Controllers.GatewayAuthController.Login() System.Net.WebException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 The remote server returned an error: (403) Forbidden. Url: https://127.0.0.1/Citrix/centralAuth/CitrixAGBasic/Authenticate ExceptionStatus: ProtocolError ResponseStatus: Forbidden at System.Net.HttpWebRequest.GetResponse() at Citrix.DeliveryServicesClients.Utilities.HttpHelpers.ReceiveResponse(HttpWebRequest req) at Citrix.DeliveryServicesClients.Authentication.TokenIssuingClient.RequestToken(String url, RequestToken requestToken, String primaryToken, String languages, CookieContainer cookieContainer, IEnumerable`1 acceptedResponseTypes, IDictionary`2 additionalHeaders) at Citrix.DeliveryServicesClients.Authentication.AG.AGAuthenticator.Authenticate(HttpRequestBase clientRequest, Boolean& passwordSupplied) Cheers. Link to comment Share on other sites More sharing options...
Vamsi Krishna1709162168 Posted September 18, 2019 Share Posted September 18, 2019 It looks like SSO to the storefront is failing. Please paste the configuration of session profile. Thanks, Vamsi Link to comment Share on other sites More sharing options...
Gregor Blaj Posted September 18, 2019 Author Share Posted September 18, 2019 3 hours ago, Vamsi Krishna Kanduri said: It looks like SSO to the storefront is failing. Please paste the configuration of session profile. Thanks, Vamsi Hi Vamsi, Session Profile config below. I'm not sure why this would be related to the ADC config, if the only changes made are adding an additional URL to StoreFront? add vpn sessionAction ICA-SF-WI -defaultAuthorizationAction ALLOW -SSO ON -icaProxy ON -wihome "https://storefront.domain.com/Citrix/centralWeb" -ntDomain CONTOSO Cheers. Link to comment Share on other sites More sharing options...
Mark Dear Posted October 15, 2019 Share Posted October 15, 2019 Hi Warnox It sounds like you are experiencing a known issue we have discovered and now fixed in current releases of STF. Luckily there is a very simple workaround in the affected versions from 3.9 upwards to the fix release using the Storefront admin console. After having set the Gateway and GSLB URLs via Powershell on your gateway objects then simply unregister the GSLB gateways and then re-register them all to the Stores they are bound to. Alternatively upgrade to a higher release than 1811 as I believe we fixed this in 1903 or higher. Moving to the latest release will definitely contain the bug fix. See the attached screen shot of Configure Remote Access Settings. Please follow all recommendations in this doc I wrote when configuring GSLB within StoreFront. Pay particular attention to the concept of unique callback URLs per gateway and please also set the VIP for each GSLB gateway as this is needed to help StoreFront identify the gateways if they all have the same URL.https://docs.citrix.com/en-us/storefront/current-release/integrate-with-citrix-gateway-and-citrix-adc/configure-two-gateway-urls.html If you have any problems using the feature please contact me and I will assist you further. Regards Mark Link to comment Share on other sites More sharing options...
Gregor Blaj Posted October 15, 2019 Author Share Posted October 15, 2019 7 hours ago, Mark Dear said: Hi Warnox It sounds like you are experiencing a known issue we have discovered and now fixed in current releases of STF. Luckily there is a very simple workaround in the affected versions from 3.9 upwards to the fix release using the Storefront admin console. After having set the Gateway and GSLB URLs via Powershell on your gateway objects then simply unregister the GSLB gateways and then re-register them all to the Stores they are bound to. Alternatively upgrade to a higher release than 1811 as I believe we fixed this in 1903 or higher. Moving to the latest release will definitely contain the bug fix. See the attached screen shot of Configure Remote Access Settings. Please follow all recommendations in this doc I wrote when configuring GSLB within StoreFront. Pay particular attention to the concept of unique callback URLs per gateway and please also set the VIP for each GSLB gateway as this is needed to help StoreFront identify the gateways if they all have the same URL.https://docs.citrix.com/en-us/storefront/current-release/integrate-with-citrix-gateway-and-citrix-adc/configure-two-gateway-urls.html If you have any problems using the feature please contact me and I will assist you further. Regards Mark Hi Mark, Thanks for your reply. I actually set this up in a vanilla lab over the weekend and was able to replicate the issue with even just a single gateway. This was both in 1811 and 1909, so I don't think the bug is resolved in the latest release? Please note that in my setup a callback URL is not required, but I managed to get around the bug with the following steps. 1. Only a single gateway with a gateway URL configured on Netscaler definition in Storefront (GLSB URL, CallBack URL and vServer IP not configured). Everything working. 2. Set GSLB URL, Gateway connections stop working (Cannot Complete Request). 3. Set Callback URL, Gateway connections working again. 4. Remove Callback URL, everything still working. Link to comment Share on other sites More sharing options...
Mark Dear Posted March 13, 2020 Share Posted March 13, 2020 Hi Warnox Using DNS round robin to simulate GSLB while testing StoreFront. This does not simulate or substitute for a real GSLB setup as Receiver for Web is a persistence web app and all HTTP requests for an individual web session should be directed to the same server not randomly distributed between 2 Gateways or 2 StoreFronts. Please do not rely on this method to perform any kind of testing of GSLB gateways with StoreFront as it will cause issues with Receiver for Web. I also understand that you can reproduce this issue with just a single gateway setup. That matches what we already know about the issue and a fix was added back in 1906 which was intended to resolve this. Given your reports and the fact the case is still open this does not seem to be the case. Apologies that the expected fix is not working from 1906 onwards. I have a developer and an escalation engineer (you are already working with him) looking into this case. Here is the min steps needed to reproduce this issue and also to work around it Create a gateway object via the console OR Powershell without a GSLB URL set. Set the GSLB URL via Powershell Issue starts to occur after this.... Unregister the GSLB gateways and then re-register them all to the Stores they are bound to. OR Update the gateway object within StoreFront using the console by changing or adding any of the following.... Set the callback, set the VIP These operations update the gateway model in StoreFront using the console and solve the issue. Cannot complete request should no longer occur after this. To clarify what Gateway config should be used within StoreFront when GSLB is used.... Callback URL is optional except when Smart Access is needed. Then it MUST be used. If Callback URL is to be used it MUST be unique per geo and GSLB gateway and should resolve to the correct VIP. If using a real GSLB setup (not faked....) where multiple gateway objects share the same URL then you MUST set the VIP on each gateway. Using the unique URL to access the gateway may well work without the VIP but when using the GSLB URL (shared by all gateways in the GSLB layer) then it is essential. How can StoreFront determine which gateway the request came from using a URL shared by multiple gateways without the VIP set? VIPs are unique per gateway object and StoreFront falls back to using it if the URL is in use by multiple gateway. This is why I recommended the VIP be set on the call we had. Regards Mark Link to comment Share on other sites More sharing options...
Gregor Blaj Posted March 29, 2020 Author Share Posted March 29, 2020 Thanks Mark, all makes sense. The latest private fix I tested today (30/3/2020) seems to have resolved the issue in 1912 LTSR. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now