Citrix Storefront – Adventures in customization – Dynamically configure authentication based on group membership

Citrix Storefront – Adventures in customization – Dynamically configure authentication based on group membership

/ /
in Blog

Continuing on from my previous post, in XenApp 6.5 and Web Interface we created 2 sites, one with explicit logon (user name and password) set as the authentication method and one set with domain passthrough.  What was configured was an AD group, “ExplicitLogon”, and then Windows Authentication was configured on the IIS sites.  When the user connected to the site, if they were a member of the domain, it would go to a custom aspx script that detected whether the user was a member of ‘ExplicitLogon’ or not.  If they were not a member they went directly to the domain passthrough site.  If they were a member, they would go to the explicit logon site and be prompted again for credentials.  Why is this configuration useful?  Two reasons…

  1. Allows lower level AD accounts to get an opportunity to logon to Citrix with accounts that have elevated permissions.  If your organization enforces ‘non-admin’ accounts for your local computers, then being a part of ExplicitLogon will direct you to the site where you can logon with an elevated account.
  2. Shared accounts that are not allowed access to Citrix applications.  If a shared account is detected as a member of ExplicitLogon it will give the real user a logon prompt where they can logon with their own credentials.

This configuration has served us fairly well for the last few years, but it has a couple drawbacks.

  1. Non-domain joined machines get the ugly ‘prompt’ to enter some form of credentials so the group check can be executed where they will have to enter credentials again (if a member of ExplicitLogon).
  2. Non-domain joined machine may get an error after entering credentials in the initial prompt (if they are NOT a member of ExplicitLogon).  The reason for this, that I can determine (and happens with non-domain joined Macintosh computers), is the browser will pass those AD credentials to the initial group membership check script but not to the next level — the domain passthrough check.

Can we solve the drawbacks with Storefront?

My thoughts are a new workflow that works like this:

1 – Attempt to query group membership with the browser’s “user” first
2- If we’re unable to to find group membership -> proceed to ExplicitLogon page
3 – If we retrieve group membership -> check for ExplicitLogon group
4 – if ‘ExplicitLogon’ group == true -> proceed to ExplicitLogon page
5 – if ‘ExplicitLogon’ group == false -> proceed with domain passthrough

This is the logical structure:



Can I make this happen?  To start I created a store with both ExplicitLogon (User name and password) and Domain pass-through authentication methods enabled.

The server side script to check group membership:

And the technical flow:

And this is what the custom/script.js looks like when we convert the flow to reality:


The results?

User: TEST1

User: TEST2


It works perfectly!  We can now define users to utilize ExplicitLogon via a user group.  And if they are not a member of that user group it will do pass-through authentication.  And even further to that, if they are NOT a member of the domain it will automatically redirect them to the Explicit Logon page!

One Comment

  1. Pingback: Citrix Storefront – Adventures in customization – Dynamically configure features based on group membership – Trentent Tye – Microsoft MVP

Post a Comment

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.