This article describes how to Integrate Web Interface 5.3 and Access Gateway Enterprise for Pass-through Access.

Requirements

• XenApp and Web Interface servers must be domain members

• XenApp XML service must be running with IIS on the XenApp farm. This is because Kerberos authentication is done by IIS on the Smart Card user’s behalf

• Smart Card middleware is no longer needed to be installed on Web Interface or XenApp servers. This is because this process uses Kerberos for authentication

• Access Gateway Enterprise 9.2 Build 48.6 or later must be used

• Web Interface 5.4 build 51 must be used

• Web Interface must not be installed on a Domain Controller

• XenApp 4.5 and 5.0 have been tested

• XenApp 6.0 requires fix #242752 which is currently available in XA600W2K8R2X64R02, CTX133882 ‑Hotfix Rollup Pack 2 for Citrix XenApp 6 for Microsoft Windows Server 2008 R2 (Included in XenApp 6.5)

• Active Directory domain functional level must be 2003, 2008 or 2008 R2

---

Instructions

Complete the following procedures accordingly:

Active Directory Configuration

Complete the following steps to configure Active Directory:

1. Configure Delegation for XenApp and Web Interface servers.

   Web Interface must delegate http service to all XML servers.

   

2. The XenApp server must delegate http and host service to themselves plus host and http service to all XenApp servers. Each XenApp server must also delegate CIFS and LDAP services to the Domain Controllers. 

   

   Note: The examples of Constrained Delegation, as demonstrated above, are meant to be examples of the minimum configuration required to allow logging on. If a Published Desktop or Published Application uses other resources not on the XenApp server itself (for example, CIFS file shares, SQL, DCOM) additional configuration might be required. Any server hosting that resource must be configured to allow for the XenApp server to access the resource. The correct Service Principal Names (SPN) must be configured for those resources. 

Web Interface Configuration

Complete the following steps to configure web interface:

1. Create a Web Interface site with authentication set to at access gateway. 

   

2. The proper Gateway URL must be entered and resolvable from the Web Interface server in addition to Smart Card being selected.              

   

3. Enable smart card pass-through.

   

4. Reboot the Web Interface.

XenApp Configuration

Complete the following steps to configure XenApp:

1. Set each XenApp server to trust XML requests.

   Note: On XenApp 6.x, this location has changed to the server policy being used.

    

2. Then, when configuring the Web Interface site, ensure that the XenApp servers are defined with their fully qualified domain name, which itself must be resolvable by Web Interface. The fully qualified domain name MUST match its name in Active Directory. Failing to do this causes Kerberos authentication to fail and an Access Denied error page to appear.

   

Access Gateway Configuration

Complete the following to configure Access Gateway:

1. The Access Gateway virtual server must have all necessary CA certificates bound as CA certificates. In case the certificate for the Smart Card has an intermediate authority, both the intermediate and root must be bound separately as CA certificates.

2. Configure the Access Gateway virtual server with client certificate optional.

   Otherwise, the callback from Web Interface FAILS. 

   

3. Configure an authentication policy forcing a client certificate to be presented. If this is not configured, anyone will be able to log on.  

   

4. Depending on Active Directory configuration the profile might need to use the Alternate Subject Name on the Smart Card. This would be the case with DoD CAC Smart cards and also cases where there are multiple CN attributes identifying the user.       

   

   Important! If not using SubjectAltName for the user name field, a Single Sign-On Domain must be configured either on global settings or the session profile.
   The profile does not necessarily have to be configured with group information. However, if configured, Access Gateway performs group extraction based on the criteria chosen for it.

   

5. The most important configuration on Access Gateway Enterprise is the Single Sign-on (SSO) Domain field within the session profile and global setting. A new knob has been introduced on Access Gateway Enterprise where, if a SSO name is entered, the UPN from the Smart Card certificate is split in half. This is very important to understand, and in case of DoD CAC cards, this field must be left blank from both global settings and the session profile. When the field is left blank, Access Gateway forwards the user name in full UPN.

   

   • To control this behavior, there is a new shell command (Note: This is shell command and not CLI command). The name of the variable is wi_sso_split_upn. If non-zero and Single Sign-On domain is not set, UPN splits into username and domain during SSO to Web Interface. If zero, UPN is used for SSO to Web Interface.

   • To change the variable value, if necessary, connect using SSH, type shell, and then type nsapimgr –ys wi_sso_split_upn=1. Note: There should be very few situations where it is necessary to change this value from the default value.

   • In summary, there are four possible scenarios:
     - If SSO domain is entered and this variable is default, UPN is split in half.
     - If SSO domain is entered and this variable is changed to anything other than 0, UPN is split in half.
     - If SSO domain is not entered and this variable is default, UPN is used for SSO with Web Interface.
     - If SSO domain is not entered and this variable is changed to anything other than 0, UPN is split in half.

   • The URL for Web Interface in the Session Profile (or Global Settings) must use SSL. This means that a SSL certificate must be properly installed on the Web Interface server.

Issues Seen During Implementation

During implementation of this configuration on a pure Windows 2008 Environment and Citrix XenApp 5.0 a XenApp hotfix had to be installed. The hotfix addressed an issue where upon launching a published application the connection would be terminated and the DNS Client Service on the XenApp server would terminate. The hotfix that addressed this issue is CTX125414 ‑  Hotfix Rollup Pack 1 for Citrix XenApp 5.0 for Microsoft Windows Server 2008 32-bit Edition, XAE500W2K8R01.

• While attempting to launch a published application Web Interface would report “The resource is no longer available” on the web page. This would prevent an ICA file to be created and the server would log on Event Viewer:
  Site path: C:\inetpub\wwwroot\InternalSmartCard.

  The XML document sent by the Citrix servers could not be processed because it contains invalid XML. This message was reported from the XML Service at address http://xa50.repro2k8.net:80/scripts/wpnbr.dll [com.citrix.xml.NFuseProtocol.RequestLaunchRef]. The specified Citrix XML Service could not be contacted and has been temporarily removed from the list of active services. [Unique Log ID: da4f1ad1]

  To correct this issue the Local Computer policy was adjusted to allow logon locally for Domain Users.

• Smart Card implementation for Gemalto Gemplus Smart Cards requires Gemalto “Classic Client” for Firefox integration on a Red Hat system. This software must be purchased from Gemalto and is not freely available

• DoD CAC Smart Cards in a Linux based operating system can be used with the use of a freely available library called “coolkey”. On an Ubuntu operating system the packages added were: libusb-0.1-4, libpcsclite1, libpcsclite-dev, pcscd, and pcsc-tools (the actual command was “sudo apt-get install libusb-0.1-4 libpcsclite1 libpcsclite-dev pcscd pcsc-tools build-essential autoconf xlibs-dev libccid”)
  Firefox was then configured to load libcoolkeypk11.so under Tools > Options > Advanced > Encryption > Security Devices.

• On a Windows machine if Firefox is intended to be used, additional configuration is needed. Under Tools > Options > Advanced > Encryption > Security Devices a new Device must be loaded. The DLL to be loaded for a GemPlus Smart Card is called gclib.dll and it is usually placed under \Program Files\Gemplus\gemSafe Libraries User\BIN

• While launching a published application the user would start the session, login to the server, but the server would quickly report “Access is denied” before displaying the application. The same user would be able to login through RDP or using an Explicit login to Web Interface. This issue is currently under investigation but to get around the problem the registry DWORD IgnoreRegUserConfigErrors was created under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\.

  

Known Limitations

This configuration causes two PIN prompts from the user if connecting from a non-domain member or if the client machine is a domain member but using Windows Vista or later.

This first condition occurred because the user logged on to Windows and did not log on with the Smart Card. Therefore, the ICA client cannot grab and provide smart card information from Winlogon.

The second condition occurred because of a change in security done by Microsoft on Windows Vista and later. On Windows Vista/7 the behavior of Windows has changed. Upon a smart card logon the mpnotify.exe process is simply not invoked by Winlogon.exe anymore (it is still invoked for username/password logon). The only way we currently know to capture the smart card logon PIN on Vista/7 is to install a credential wrapper. However, this is not something recommended by Microsoft.

This article explains how to configure Smart Card Single Sign-On with Access Gateway Enterprise Edition.

CTX131223 - Enabling Smart Card PIN Pass-Through on Windows Vista or Windows 7 Citrix Session

If this workaround is not applied, a PIN prompt is displayed by the browser.

And a PIN prompt from the XenApp plug-in when launching an application.