Jump to content
Welcome to our new Citrix community!

Redirect to different StoreFront


Recommended Posts

Hello,

I have taken over an existing environment and haven't been able to figure out how the StoreFront/NS integration is setup.

So when various users (or IT) login we are sent to a different Storefront that is basically called "DEV"

However, regular user are sent to another StoreFront that we can call "PROD"

If I look in the NS there are 2 different Citrix Gateways or "Virtual Servers" one this point to PROD and the other to DEV.

I'm assuming there is some "group" I have to be in to get sent to the "DEV" site while not in the group sent to the PROD site?

Where should I be looking to figure out how to send different users to the different sites?

 

Thanks in advance for your help.

Link to comment
Share on other sites

Option 1:  separate vpn vservers

If they separate vpn vservers, then they may be using all users on vpn 1 goes to store 1 (prod) and all users on vpn 2 goes to store 2 (dev). This is done by bind a session policy to vpn1 (for prod) and a separate one to vpn 2 for dev (session policies control the storefront destination).

 

Option 2: by user group (as sam mentioned):

Session policies can be bound to vpn vservers, aaa groups (and aaa users, but groups are easier).

If you have one vpn vserver, but have created two separate session policies at the group level:

produsers get session_pol_gotoprod

devusers get session_pol_gotodev

 

Then when users authentication to the single vpn vserver (vpn1), we do a group extraction and their group membership determins which policy applies (prod) or (dev).

You can also use group filters in the advanced engine.

 

If users only ever do one role, then the group-based policies are easy.

If one user can do either prod or dev, then separating based on which vpn you hit (gateway1 vs gateway2) would determine when you are doing prod vs dev.

 

Super high level examples....

Example 1:

vpn_vsrv_gateway1 (prod)

    - session_pol_gotoprod

vpn_vsrv_gateway2 (dev)

    -session_pol_gotodev

 

Example 2a (one vpn vserver with group bindings).

- Note: group extraction is based on how the ldap policy is defined and you create group names on ADC that matches AD groups.

- Depending on classic vs. advanced engine a lot of considerations around policies and priorities come into play. This is just the basics.

 

vpn_vsrv_gateway1 (all environments)

  - <no vpn policy; or session details blank>

 

AAA Group: ProdUsers (or other group Name)

    - session_pol_gotoprod (storefront details)

 

AAA Group: DevUsers (or other group Name)

    - session_pol_gotodev (storefront details)

 

Example 2b (one vpn vserver, with policies based on group...but using the advanced group filters at the vserver level instead of group bindings)

- The advanced policy engine can filter policies by group membership after authentication.  

- Different group names can be used; if nested group extraction is required, then authentication policy must enable nested groups....

 

vpn_vsrv_gateway1 (all environments)

     session_pol_gotoprod  (with storefront prod details):  aaa.user.is_member_of("ProdUsers")                

     session_poL_gotodev   (with storefront dev details):   aaa.user.is_member_of("DevUsrs")

 

In this case, the policies are bound to the vpn vserver (instead of the aaa group), but policy applies based on user group membership.

If a user is a member of both groups, priority would determine which one is more important and wins.

 

-------------

For your current config, do the following:

 

## 1) see session policy(ies) bound to vpn vserver(s)...

show vpn vserver <vpnprod name>

show vpn vserver <vpndev name>

 

## 2) see what AAA groups if any are on system

show aaa group

 

## 3) Then for each group, see if any group level policies are bound

show aaa group <groupname>

 

This will let you see if you have group level policies in addition to the vpn vserver policies.

In GUI, go to Gateway > virtual servers to view the "policies" section and review the session policies in use on the virtual server(s).

Then Gateway, has a section for AAA Groups and AAA users where you can see them as well.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

17 minutes ago, Sam Jacobs said:

Look under AAA Groups ... there should be a special session policy bound for users in that AD group that overrides the default session policy.

Sorry, I am not too knowledgeable about the Netscalers.

I do see the attached policies but I'm not seeing anything that tells me what site they will go to as they have the same settings.

 

 

SessionPolicies.png

Link to comment
Share on other sites

I found an AAA group but the policies didn't tell me much.

Also, I was not able to find that group in our AD.

 

 

We have a couple of gateways but the image below seems to encompass both Prod and Dev

Other than the StoreFront URL I'm not seeing any other settings differences.

 

 

GatewayPolicies.png

Link to comment
Share on other sites

Yeah, there are 2 different StoreFront URL's on the same gateway but I need to send some users to DEV and the rest to Prod.

For some reason the production site was setup with "auto" launching application icons (XA only).

If you are a user with say 10 icons, all 10 icons start automatically which of course is an issue for those with multiple icons. (most users only have one icon).

 

Most of IT are set to DEV which does not have auto launch.

I need to figure out how to switch a user from Prod to Dev so they can test and I'm assuming that would be adding the testing user to a group then removing them when they are done?

I did find a "AAA" group but there is no match AD group for that so I'm not sure what that is used for.

 

Thanks

Link to comment
Share on other sites

16 hours ago, Tim Hadlock said:

Yeah, there are 2 different StoreFront URL's on the same gateway but I need to send some users to DEV and the rest to Prod.

For some reason the production site was setup with "auto" launching application icons (XA only).

If you are a user with say 10 icons, all 10 icons start automatically which of course is an issue for those with multiple icons. (most users only have one icon).

 

Most of IT are set to DEV which does not have auto launch.

I need to figure out how to switch a user from Prod to Dev so they can test and I'm assuming that would be adding the testing user to a group then removing them when they are done?

I did find a "AAA" group but there is no match AD group for that so I'm not sure what that is used for.

 

Thanks

 

 

OK, so I "think" I found an AAA group but I can't seem to find it in Active Directory.

I'm assuming by default all users are sent to the Prod StoreFront URL and somewhere there is a group or something sending IT users to the Dev site.

This is the only AAA group I was able to find.

AAA_Group.png

AAA_SessionPolicies.png

Link to comment
Share on other sites

Policy/group extraction explanation first; followed by what you can do to change this regardless...

 

[a] Policy/group extraction explanations (in brief; this can be complicated but hopefully this helps you out)

Usually, when policies are managed per AAA group, group extraction is used.

Meaning, user accounts belong to a group in AD "DevUsers" for example.

The ADC, then just defines the AAA Group named "DevUsers" (same exact name as AD; be sure actual group name and not display name). Then on the ADC you don't have to create users, put in groups.  During authentication, the ldap policy extracts the groups and the ADC compares group list from LDAP against its own list of AAA Groups and user receives policies based on the groups on the ADC (which match the AD group).

 

However, if the person who set this up isn't using group extraction, they could have created aaa users on the ADC. Put those users into a AAA group on the ADC and bound policies to the group.  Then the "group membership" is goverened by the adc local group settings.

 

To see if they created users into groups:

show ns runningconfig | grep <aaagroup name> -i

And you should see if the group was created and which individual accounts were bound.

 

OR if they did a 3rd option.

 

The other way groups can be assigned is during either authentication or authorization policies an "authentication" group or an "authorization" group can be specified.

In this case (depending on which policy does it), the user completes a condition (like authentication or authorization) and a group membership is imposed on the user.

This would then treat the user as a member of the group specified, but not require the user to be actually bound to the group (or use the group extraction method).

 

By searching the running config for any reference to the group name you identified, you can narrow down how this might be occurring.

 

---

Finally, if a user is a member of multiple groups - then policy priority would determine which session policy wins.

 

If there are policies at both group level AND at vpn vserver level, then precedence is a little more complicated:

1) if still using the classic engine, the priority is the sole determining factor of whether the group settings or the vpn vserver policy wins (and which group wins).  Highest priority wins regardless of bind point; in the event of ties (priorities the same), user overrides group (meaning user wins).  Group overrides vpn vserver (group wins), etc... .  Highest priority means priorty 10 is MORE IMPORTANT/WINS over priority 100.  There's a little more if you have conflicting groups.

2) If using the ADVANCED/DEFAULT policy engine, then priorities work within bind points and group overrides vpn vserver (without having to think about it too much).

Classic policies: ns_true

Advanced policies: true  

 

AND your screenshots above indicate you are likely using advanced policy engine.

 

 

[b] what might help you achieve your new results

(backup config / test first....as this is an incomplete view of what your current config is actually dependent on; so be cautious.)

1) If you want to create a NEW group in AD, put your AD users into the AD group.  

2) Create the AAA Group on the ADC (netscaler) with the same name as the AD group you just created.

3) Bind the policy you want to the AAA group with a high priority like 10 to override any other group memberships or conflicts.

4) Be sure the LDAP policy is retrieving the member_of criteria

Then your users should get the new value when they log on.

 

If you need these users to use prod on vpn1 and dev on vpn2, don't bind the policy to the AAA group, but bind the policy to the vpn vserver and use the 

aaa.user.is_member_of("<NEWGROUPNAME>") 

to override and make this policy more important than others (requires advanced engine though)

 

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...