Jump to content

Receiver unable to logon after logoff


Mika Sarberg1709156118

Recommended Posts

Posted

Hi everyone,

 

I have run into this issue at a customer where I have setup a new NetScaler Gateway vServer and a new Storefront LB vServer.

 

Everything seems to work fine when a first-time user configures the Receiver manually to point at the external gateway FQDN. User gets logged on and is able to launch published applications.

 

But if the user logs off he cannot log on again. Following error appears "Your apps are not available at this time. Please try again in a few minutes... Cannot contact store".

 

If I use a browser I have no issues at all so it seems isolated to using Receiver. If I try the Activate... option from the browser I get an error saying "Cannot retrieve discovery document".

 

The environment consists of the following:

 

- NetScaler MPX 5500 10.5-58.11 with standard license.

- Storefront 2.6

- XenDesktop 7.6

- SSL Certificate (Global Sign)

           - External FQDN: https://company.com

           - Internal FQDN: https://company.ad.org (added as SAN Name in the SSL Certificate)

 

 

I have configured the NS Gateway with a RADIUS connection for 2-factor auth (SMS token) and since the RADIUS server itself makes an LDAP connection I have not configured any LDAP auth in my NS Gateway. Thus I only got two primary RADIUS authentication policies in place:

 

Receiver policy:

REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver

 

 

Receiver for Web policy:

REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver

 

 

The Session Profile for Receiver has the following config:

 

CLIENT EXPERIENCE:

- Session Time-out: 60

- Clientless Access: Allow

- Clientless Access URL Encoding: Clear

- Plug-in Type: Java

- Single Sign-on to Web Applications: Checked

- Credential Index: Secondary

 

PUBLISHED APPLICATIONS:

- ICA Proxy: On

- Web Interface Address: https://company.ad.org

- Web Interface Address Type: IPv4

- Web Interface Portal Mode: Normal

- Single Sign-on Domain: AD

- Account Services Address: https://company.ad.org

 

 

The Session Profile for Receiver for Web has the following config:

 

CLIENT EXPERIENCE:

- Session Time-out: 60

- Clientless Access: Allow

- Plug-in Type: Windows/MAC OS X

- Single Sign-on to Web Applications: Checked

- Credential Index: Primary

 

PUBLISHED APPLICATIONS:

- ICA Proxy: On

- Web Interface Address: https://company.ad.org/Citrix/StoreWeb

- Web Interface Address Type: IPv4

- Web Interface Portal Mode: Normal

- Single Sign-on Domain: AD

 

 

I've been trying for weeks now to adjust settings in my session profiles and tried different setups using RADIUS and LDAP authentication policies but I always end up in the same rabbit hole where I can log on once but subsequent logons fail.

 

Anyone got any suggestions as to what I am doing wrong or is it possible that this is caused by a bug?

 

If I missed out on important details in my setup just ask and I'll fill in the gaps.

Posted

Additional information that could be of value:

 

Base URL is configured as https://company.ad.org

 

Callback URL is configured as https://company.com

 

Internal beacon point is set to Base URL. External beacon points is set to citrix.com and google.se.

 

Certificate is bound to IIS on both Storefront servers.

 

Internal DNS resolves the base URL to Storefront LB VIP and I have verified that the Netscaler is able to resolve the base URL to Storefront LB VIP as well.

Posted

I have turned on logging for my Receiver and although I don't know what to look for amongst all the output provided, the following lines do look suspicious to me (copied from the Receiver_.log:

 

[2015-10-01 11:30:35.434] [T00000e28] [V6Interfaces.cpp:124]  CSDKLocationAwareness::GetNetworkLocationForStore, storeAddrhttps://company.ad.org/Citrix/store/discovery
[2015-10-01 11:30:35.434] [T00000e28] [NetworkLocation.cpp:321]  intResults.size() = 1
[2015-10-01 11:30:35.434] [T00000e28] [NetworkLocation.cpp:336]  .....Beacons report: check external
[2015-10-01 11:30:35.434] [T00000e28] [NetworkLocation.cpp:351]  extResults.size() = 2
[2015-10-01 11:30:35.434] [T00000e28] [NetworkLocation.cpp:355]  .....Beacons report: outside
[2015-10-01 11:30:35.434] [T00000e28] [NetworkLocation.cpp:262]  Location for store 503972505 is OUTSIDE
[2015-10-01 11:30:35.434] [T00000e28] [NetworkLocation.cpp:282]  Location for url https://company.ad.org/Citrix/store/discovery is OUTSIDE
[2015-10-01 11:30:35.434] [T00000e28] [V6Interfaces.cpp:130]  CSDKLocationAwareness::GetNetworkLocationForStore, network state:2
[2015-10-01 11:30:35.465] [T00002344] [V6Interfaces.cpp:90]  In CSDKSRManager::GetCurrentGatewayForStore
[2015-10-01 11:30:35.465] [T00002344] [V6Interfaces.cpp:102]  GetCurrentGatewayForStore:: Store found - store
[2015-10-01 11:30:35.465] [T00002344] [sRStore.cpp:272]  Gateway selected by user doesn't match any from the store. Using default from store: https://company.com
 
 
It looks to me as if the Storefront suggests that the location of the discovery address, https://company.ad.org/Citrix/Store/discovery, is an external address which it obviously isn't. Although it is true that I am on an external network so it should treat me as an external user but shouldn't the discovery address point to something like https://company.com/Citrix/store/discovery instead?
Posted

Anyone? Suggestions?

 

I've done some further testing and found the following:

 

If I switch to only using LDAP and skip the 2-factor auth all is working as expected. But whenever I configure RADIUS authentication the Receiver issue arises and I am only able to log on the first time when configuring the Receiver. After I log off I am not able to log on again.

 

I have verified the Storefront configuration so its got the Domain + Security Token setting enabled when using 2-factor auth and also the session profile is set to SECONDARY for Credential Index.

 

I've setup 2-factor auth before using MidEye and never seen this issue. I cannot see that I have done things different this time that could cause this.

Posted

I'll just keep posting my own updates and hope that someone will eventually step in and come to my rescue! :)

 

I've done some checking of Receiver logs and the following was found in the SelfService.txt log file. The part in red seems to be a candidate for causing this issue but I have no idea how to fix it. It seems that I should be getting an logon prompt but for some reason I am not getting it. I've searched the forums and Googled it but I cannot find anything about how to set the AllowLogon and Interactive flags it mentions.

 

8/09:05:51 dservice E T100    :  AuthManager Exception in GetResponse(): AuthManager needed to prompt the user for logon to complete the request but it was prevented by the request AuthenticationFlags property. Set the AllowLogon + Interactive flags to allow logon with user prompts.
8/09:05:51 dservice ? T100    :}00:00:08.2772523
8/09:05:51 dservice   T100    :Delivery Services request requires authentication: Unauthorized https://company.ad.org/Citrix/Authentication/auth/v1/token/validate/ <no type> (0 bytes)
8/09:05:51 dservice E T100    :Request failed with HTTP code Unauthorized from service at https://company.ad.org/Citrix/Authentication/auth/v1/token/validate/
8/09:05:51 dservice E T100    :Token Validation request failed with HTTP code Unauthorized from service at https://company.ad.org/Citrix/Authentication/auth/v1/token/validate/
8/09:05:51 dservice E T100    :Failed to obtain user info from provider CredProb=BadCredentials
8/09:05:51 dservice E T100    :Request failed: Credentials error
8/09:05:51 dservice E T100    :   at Dazzle.DeliveryServicesClient.DeliveryServices.DeliveryServicesSet.GetUserInfo(Boolean allowCredUi, String displayName, Uri tokenValidationServiceUrl)
8/09:05:51 dservice E T100    :   at Dazzle.DeliveryServicesClient.Provider.GetUserInfo(Boolean allowCredUi)
8/09:05:51 misc       T100    :No user is loggedon.
8/09:05:51 misc       T100    :Desktop Lock: Desktop Lock Configured: No IsUserAdmin True
8/09:05:51 misc     = T100    :ProcessCommandLine 
8/09:05:51 misc     > T100    :{

 

 

Anyone run into this before?

  • 2 months later...
Posted

Mike,

Did you ever find a solution to this?  I have just run into the same problem.  I have our setup using 1 URL for both internal and external clients (split brain dns).  Externally, everything works with no problems.  Internal is broken with the same symptoms you are describing.  For us, internal users are not prompted for two factor (RSA), externally they are.  From what i can tell the internal users are being directed to the external site for authentication, after they logoff it is trying to use the gateway setup for dual factor and is failing.  If I look in the advanced preferences of the receiver, i only see 1 netscaler gateway listed which is the one for dual factor auth.  I am not sure why yet, maybe something with beacons...  I will keep digging.

  • 2 months later...
Posted

Sounds very familiar to an issue I am seeing, did either of you get a resolution to this? Receiver always works the first time, on the second login I don't even see any authentication occurring on the netscaler gateway log through the monitor on the cli, not had a chance to check the receiver logs get to see what's it is saying, will do tomorrow.

Posted

Wanted to post the solution for us, in case anyone else sees this issue. The beacons on StoreFront were set with the same fqdn for internal and external, so when accessing externally the receiver was getting the wrong information and was unable to connect on any subsequent login after the first one that was successful. I configured a separate hostname internally and it all started working.

Posted

Hi guys and thanks for posting! Sorry for not responding sooner in my own post!

 

I did actually resolve my case after much troubleshooting both by myself and Citrix Support (both NetScaler team and the Receiver team were involved in this).

 

I believe my case is a bit different from yours. After looking into the packets sent from and to NetScaler in Wireshark we found that the NetScaler sent a cookie to the Receiver with a password count of 1 for all failed subsequent logons. This password count should have been 2 (for LDAP and RADIUS 2FA) and this is what caused the issue in my case. This means that the Netscaler only asked for LDAP credentials when it really needed to ask for both LDAP and RADIUS.

 

The solution in this case was to turn off Session Reliability. When we did this all worked fine. I thought it was very strange that it didn't work with SR turned on since I've setup almost identical solutions before and didn't run into this problem. But all according to Citrix Support this was "by design" and it would never work with SR turned on in a case like this.

 

But I was still curious about this and had to see it for myself so we turned on SR again. And guess what... it still works. And now it's been working for about three months.

 

I'd say it was a bug solved by "restarting" SR. :)

  • 1 year later...
Posted

I am seeing this issue with XenApp 7.15, Receiver 4.8, Netscaler 12.x, 2FA

 

Receiver for web works fine. When I add a receiver styore externally using https://myexternmaldomain.company.com (not using the full storename or /discovery), the store adds fine and I am able to launch apps. As soon as I loff, I cannot logon again. Clicking on Logon from Receiver in the start bar does nothing. Refresh apps gives the dreaded 'cannot complete your request'

 

Being able to use Receiver Store will be nice.

 

Can anyone help?

Posted

Ok, here is what I have on the Netscaler.

 

In Netscaler Gateway, I have one vServer, 2 session policies (1 for Native Receiver and one for ReceiverWEB). There is only one Primary Authentication policy set on the vServer (no secondary auth) , which is the RADIUS policy.

 

Receiver for Web works perfectly, I am prompted by the Netscaler for Username and Password, Once I enter that, the next screen prompts for the Token (SecurEnvoy).

 

The credential Index for both Profiles (Receiver and ReceiverWEB) are set to Primary. Changing this to Secondary for Native Receiver did not make a difference. The Native Receiver still not work after logoff.

 

I do not wish to mess with the ReceiverWEB, as it is working.

 

Do you want me to create another vServer and bind the Native Receiver policy to this vServer with Primary Auth as Radius and Secondary Auth as LDAP?

  • 8 months later...
  • 7 months later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...