Jump to content
Welcome to our new Citrix community!

Citrix Receiver / Workspace Auth Prompts Netscaler and Storefront Internally


Peter Hartl

Recommended Posts

Hi,

 

I am looking for clarification if it is default behavior. I could not find anything useful.

 

We configure our internal workspace clients at the initial setup to the external netscaler URL. We then get the authentication prompt from the netscaler. After that the receiver/workspace app decides according the beacon configuration to connect to storefront directly, which is then followed by an additional authentication prompt from storefront. I want to get rid of the second auth prompt by storefront. In my opinion it should authenticate with the cached credentials from netscaler at the storefront. All necessary information should be there.

 

Thank you.

Link to comment
Share on other sites

For Storefront to accept credentials from gateway:

On Gateway you must have the single sign on to web setting enabled in the session profile (and potentially a traffic sson policy dependening on version)

On Storefront you must have the storefront enabled from gateway authentication as well

 

There are other factors that can prevent this from working, but that would be a start.

 

Also, unless you need internal users going through gateway for ICA Proxy + Insight, you could route internal users direct to storefront as Carl noted.

 

Configurations such as single unified fqdn, misconfigured base urls, and beacons, or more complex authentication scenarios than what we're assuming can also add complexity. You might need to share more details of your config to narrow down the problem.

Link to comment
Share on other sites

1 hour ago, Rhonda Rowland1709152125 said:

For Storefront to accept credentials from gateway:

On Gateway you must have the single sign on to web setting enabled in the session profile (and potentially a traffic sson policy dependening on version)

On Storefront you must have the storefront enabled from gateway authentication as well

 

There are other factors that can prevent this from working, but that would be a start.

 

Also, unless you need internal users going through gateway for ICA Proxy + Insight, you could route internal users direct to storefront as Carl noted.

 

Configurations such as single unified fqdn, misconfigured base urls, and beacons, or more complex authentication scenarios than what we're assuming can also add complexity. You might need to share more details of your config to narrow down the problem.

 

If the client is externally, SSO and all those features through the netscaler are working without issue. Only if the client is internal and it get's redirected to the storefront the authentication prompt occurs a second time.

 

1 hour ago, Carl Stalhood1709151912 said:

Why not configure internal workspace clients to connect directly to StoreFront instead of going through Gateway?

 

Easy to answer, to have clients which are roaming between external and internal. For example an external location, which has a vpn connection on the primary line to the datacenter and mobile backup without vpn. So the clients are normally connecting internally and if the primary line fails the customer has limited connectivity available through netscaler.

Link to comment
Share on other sites

So for your internal users being routed through gateway, it probably means the internal beacon is "confusing" the situation for the storefront.

The internal beacon is supposed to be an internal URL that only on network/internal users can see.  So that when a StoreFront decides whether you are a gateway user or an internal user, it knows what to do.

 

Your external users going through gatweay, can't resolve the internal beacon and so the storefront treats them as a gateway user; processes credentials from gateway and accepts gateway passthrough.

For  your internal users NOT going through gateway, they will resolve the beacon AND storefront can treat them as a direct storefront connection and prompt for credentials without relying on gateway.

 

The problem is for internal users connecting through Gateway, the internal beacon is working for them and so even though storefront received the request from gateway, it thinks the users should be treated as internal only and prompts them directly instead of relying on gateway passthrough and it tries to route them to a direct/internal ica connection instead of gateway based.

 

If the storefron't gateway connection identifies the source ip of gateway traffic as the vpn vserver VIP (and not a snip or left blank), then this might fix the detection of the internal users also going through gateway, allowing it be treated as a gateway connection.  If not, usually, you'd make the internal beacon a non-resolvable name (but might impact your internal only).  

I would first check the gateway ip filed in the storefront's gateway policy to see if it is blank, vip, or snip (same page as where yo specify the callback address).  

If it is blank, change it to the gateway vip instead. And see if this solves the problem.

If not, we might have to move to internal users going through gateway to their own store that is gateway only to avoid the issue...caused by the conflicting beacon resolution.

 

 

 

 

 

 

 

Link to comment
Share on other sites

17 hours ago, Rhonda Rowland1709152125 said:

So for your internal users being routed through gateway, it probably means the internal beacon is "confusing" the situation for the storefront.

The internal beacon is supposed to be an internal URL that only on network/internal users can see.  So that when a StoreFront decides whether you are a gateway user or an internal user, it knows what to do.

 

It is configured as internal URL only accessible / resolvable by the internal clients.

 

17 hours ago, Rhonda Rowland1709152125 said:

 

Your external users going through gatweay, can't resolve the internal beacon and so the storefront treats them as a gateway user; processes credentials from gateway and accepts gateway passthrough.

 

For  your internal users NOT going through gateway, they will resolve the beacon AND storefront can treat them as a direct storefront connection and prompt for credentials without relying on gateway.

 

The problem is for internal users connecting through Gateway, the internal beacon is working for them and so even though storefront received the request from gateway, it thinks the users should be treated as internal only and prompts them directly instead of relying on gateway passthrough and it tries to route them to a direct/internal ica connection instead of gateway based.

 

Exactly .

 

Quote

 

If the storefron't gateway connection identifies the source ip of gateway traffic as the vpn vserver VIP (and not a snip or left blank), then this might fix the detection of the internal users also going through gateway, allowing it be treated as a gateway connection.  If not, usually, you'd make the internal beacon a non-resolvable name (but might impact your internal only).  

I would first check the gateway ip filed in the storefront's gateway policy to see if it is blank, vip, or snip (same page as where yo specify the callback address).  

If it is blank, change it to the gateway vip instead. And see if this solves the problem.

If not, we might have to move to internal users going through gateway to their own store that is gateway only to avoid the issue...caused by the conflicting beacon resolution.

 

 

I want to keep internal users internally without the netscaler, because it would overload the netscaler license, which is capped by througput.

 

I've tried to set the vip netscaler address, but it did not change anything. Internal users, who setup the client to the netscaler address, get a double auth prompt. One from NS and the other from SF.

 

image.thumb.png.1fd400093a7f9fd863aea18812e8cdec.png

Link to comment
Share on other sites

Just to confirm some assumptions:

1) Are you external gateway users authentication properly and only the internal gateway users are failing?

2) Are you relying on domain authentication only at gateway or something more complex or different authe requirements for external gateway vs. internal gateway? 

3) are you using one session profile for both the internal gateway and external gateway or do you have different profiles in effect ? (There might be some troubleshooting that is needed if different as opposed to one profile for all.)

4) Are all connections internal only and internal gateway web-based? Or are you mixing web and services connections as as there's more than one place where the gateway integration is specified on the storefront side.

 

Assuming none of the above is a factor:

So my recommendation since the internal only users and the internal gateway users are in conflict with the beacon detection.  

 

Option 1: Try to make the internal beacon a non-resolvable name instead of the storefront name and see if this fixes the internal gateway users while not breaking the internal only users.

 

Option 2:  Create a second Store that is configured gateway only. 

You can either do this so that internal only users go to store1 as an internal only store and both internal gateway/external gateway users are directed to Store2 (in gateway only mode).

OR you can do this so that internal only and regular external gateway users keep using store1 (configured for both internal/gateway access), but then route the internal gateway users to store2 that is gateway only. The policy on the gateway could do this by source ip subnet being an internal network.  

The first option is simpler and would solve the problem i believe; but you would need two stores to likely separate the internal only and the internal gateway user scenarios.

 

Does the storefront eventviewer (under Citrix Delivery Service node) have any storefront events that might see if anything else is going on.

 

Otherwise, You might need to summarize the entirety of the storefront's config about gateway to see if there are any errors on the gateway authentication integration, and the gateway settings.  In addition to the session policy to see if there is anything "missing" that would help.

Link to comment
Share on other sites

Sorry about my late answer.

 

Quote

1) Are you external gateway users authentication properly and only the internal gateway users are failing? -

 

Storefront is used internally and only a external gateway is deployed. We configure the internal workspace clients to the external gateway URL, to have roaming capabilities. 

 

Quote

2) Are you relying on domain authentication only at gateway or something more complex or different authe requirements for external gateway vs. internal gateway? -

 

Domain LDAP Auth, Classic Policies on netscaler, nothing special, pretty standard.

 

Quote

3) are you using one session profile for both the internal gateway and external gateway or do you have different profiles in effect ? (There might be some troubleshooting that is needed if different as opposed to one profile for all.) -

 

The external gateway has only two session profiles. One for Receiver and one for Web.

 

Quote

4) Are all connections internal only and internal gateway web-based? Or are you mixing web and services connections as as there's more than one place where the gateway integration is specified on the storefront side. -

 

I am talking about the receiver connections. No web portal connections are used.

 

Quote

Option 1: Try to make the internal beacon a non-resolvable name instead of the storefront name and see if this fixes the internal gateway users while not breaking the internal only users. -

 

If I remove the internal beacon, user gets authenticated to netscaler and the connections get's not redirected to internal and so we have only the authentication on the netscaler (which is okay). There's a registry key for the workspace app, to ignore the beacons, which is the same as your proposal. The outcome is, that the internal clients does not got redirected to the internal storefront and the authentication occurs one time on netscaler and gets forwarded to the storefront. 

 

The issue is, as soon as the workspace client gets configured to the external URL (netscaler), it authenticates to the netscaler. After that storefront delivers the beacon configuration and the workspace clients gets redirected to the internal storefront, because the internal beacon is detected. That generates the second auth prompt from the storefront.

 

Quote

 

Option 2:  Create a second Store that is configured gateway only. 

You can either do this so that internal only users go to store1 as an internal only store and both internal gateway/external gateway users are directed to Store2 (in gateway only mode).

OR you can do this so that internal only and regular external gateway users keep using store1 (configured for both internal/gateway access), but then route the internal gateway users to store2 that is gateway only. The policy on the gateway could do this by source ip subnet being an internal network.  

The first option is simpler and would solve the problem i believe; but you would need two stores to likely separate the internal only and the internal gateway user scenarios. -

 

 

If I do that, we are losing the roaming capatibilities, which are necessary for road warriors or backup.

 

Quote

Does the storefront eventviewer (under Citrix Delivery Service node) have any storefront events that might see if anything else is going on.

 

Nothing there.

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...