Stupid Citrix Trick #10: Smart Card Confusion

Problem: When using smart cards to log in, some users get an error when launching apps.

Solution: Configure Citrix Workspace to prompt for credentials.

No, Smart Card Confusion is not the hottest nerdcore band in Portland.  It's a problem that Citrix may encounter when multiple smart cards are present in a user's PC.  Before we get to the solution, let's talk about smart cards a bit.

Smart cards have become much more common in corporate and government environments over the past few years, as they are more secure than logging in with a username and password.  The user credential is on a card that looks much like a bank card, and is inserted into a card reader - either built in to the computer, or external, typically a USB device.

When logging in, the user will be prompted for the PIN number, just like a bank card.  Crucially, the user's PIN is not stored in a network database like Active Directory.  Instead, it's kept on the smart card itself.  This is more secure, since there's no password on the server that can be stolen. An intruder would need the card itself and the PIN.

More recently, virtual smart cards have been introduced, which eliminate the need for a physical card.  These smart cards reside on the user's PC in a piece of hardware called a Trusted Computing Module, which is just as secure as a physical card, and also uses a PIN.

Smart card confusion occurs when a user needs to be able to log on with more than one account at different times.  For example, a user may have a virtual smart card for their user account, but a physical smart card to log on as an administrator.  If there are two smart cards present in the system, a user may get this error when launching apps:

If you can see an app in Workspace, you've been granted access, so what does this message mean?  It means that the wrong smart card is being used when logging in, so that the wrong credentials are used to log in to Citrix.

There are only two options for picking the smart card to use with Workspace - always use the default card, or always make the user choose.  Unfortunately this is not configurable using the GUI, but it's very easy to fix it in the registry.  First, navigate to this registry key:

HKLM:\Software\WOW6432Node\Citrix\ICA Client\SSON

SSON stands for Single Sign-on, and it determines how smart cards behave. If the string value "Enable" is set to the test "true", then Workspace will always use the default smart card.  If it's set to "false", as in the picture below, it will always prompt the user for their credentials.

Unfortunately it requires administrator access to change that value.  But it's easily done and will resolve the problem... at least until the next version of Workspace is installed.

Stupid Citrix Trick #9: Deploying A Delivery Group With Powershell

Problem: You're deploying a Delivery Group to a XenApp farm using Powershell.

Solution: NOT AS SIMPLE as you'd expect!

Citrix had done a really good job of integrating Powershell automation into their system.  Anything you can do in the GUI, you can do in Powershell, and I have heard that the system itself uses Powershell to make its changes.  Still, there are a few gotchas here and there that you have to look out for.

One gotcha in particular nearly made me lose my mind.

All I wanted to do was to create a delivery group and publish some applications to it.  Pretty simple, right?  There's a straightforward Powershell function that does just this:

New-BrokerDesktopGroup
-Name $GroupName
-Description $GroupDescription
-DeliveryType DesktopsAndApps
-DesktopKind Shared
-IsRemotePC $false
-SecureIcaRequired $false
-SessionSupport MultiSession
-TimeZone $TimeZone

As you can see from the options we're applying, this group is delivering both desktops and applications and its servers are used by multiple simultaneous sessions - basically an old-school Citrix server.  The information specified is pretty much what you'd need to supply when using the GUI, so you should be able to add some servers and start firing up your apps, right?

Not so fast, buckaroo.  If you published applications to that delivery group, no one would ever see them, and that's because you have to create another object, a Broker Entitlement Policy Rule.  Here's what the code looks like:

New-BrokerAppEntitlementPolicyRule

-Name $GroupName

-DesktopGroupUid $GroupUid

-Enabled $true

-ExcludedUserFilterEnabled $false

-IncludedUserFilterEnabled $false

-LeasingBehavior Allowed

-SessionReconnection Always

The $GroupName and $GroupUid are for the group you just created, natch. We're naming the rule the same as the group; you can name it something else if you prefer.

I'm not really sure why this rule is required.  It's created silently when using the GUI, so why couldn't it be automatically configured when the DeliveryType is "DesktopsAndApps" or "AppsOnly"?  I suspect it's because that XenApp 7 grew out of the XenDesktop product, not from XenApp 6.5 (at least that's my understanding).  Support for publishing apps was more or less bolted on, and some of the joints are still visible.

In addition, and more aggravating, the documentation for New-BrokerDesktopGroup does not tell you that there's another step before you can publish apps.  If you don't create it, everything will look as though it's configured properly but the apps will not be visible.

Let me know in the comments if this helped you. 'Til next time...