Authenticating a CAC or SIPR token user to the NetScaler is a two part process that involves using the NetScaler to validate the user certificate and then doing an AD lookup to find the associated sAMAccountName for the Web Interface.  This article assumes that you already have a NetScaler with Access Gateway Enterprise Edition (AGEE) already set up and working to proxy ICA connections with explicit logon credentials.  If you do not yet have that set up check out Bill Hackley’s article to get to that step.  /blogs/2012/04/10/netscaler-for-the-xendesktopxenapp-dummy/ Since the NetScaler will be authenticating the certificates, each issuing DOD authority will need to be added to the NetScaler.  From the NetScaler web admin interface go to SSL->Certificates.

On the right, click the “Install” button at the bottom of the window.
Use the drop down on the “Browse” button for the certificate to switch to browsing your local computer.

Press the “Browse” button again to select the certificate.  Once the certificate is selected and you have entered a name for the entry press “Install.”  Make sure to select the proper certificate format.  This was determined when certificate was exported to a file.

After the certificate is installed the Install Certificate window does not close.  This is to make it easier to add the next one and keep any settings similar.  If the last certificate has been added click “Close.”
The next step is to set up the certificate authentication methods in the AGEE.  Browse to Access Gateway->Policies->Authentication->CERT.  Please note that this is for NetScaler 10.x.  The NetScaler 9.x does not break out the authentication types.  Those are set using a drop down when you create the authentication policy.
Add a new policy.  If on NS 10.x the Authentication Type will be CERT and grayed out.  For 9.x select “CERT” from the Authentication Type drop down box.  Click the “New” button next to the Server box.  Give the authentication server a name and select “SubjectAltName:PrincipalName” in the User Name Field drop down box.  It will be at the very bottom of the list.  Hit “Create” to go back to the Create Authentication Policy window.

Under the Expression section, use the second drop down box for Named Expressions to select “True value” at the bottom of the list.  Click “Add Expression” to add the value to the Expression section.  Click “Create” and then “Close.”

There will now be a CERT authentication policy.

This policy will handle the NetScaler authentication the certificates on the CAC or SIPR token as long as the CAs are added to the virtual server, found later in this article.  Next the AD lookup policy will be created so the sAMAccountName can be found and passed to the Web Interface.  Browse to Access Gateway->Policies->Authentication->CERT.  Again, only the NetScaler 10.x breaks it out this far. Add a new policy.  On NetScaler 9.x set the Authentication Type to LDAP.  Click “New” next to the Server drop down box.  Fill out the AD information.  Make sure to use the correct port for your environment.  The “Retrieve Attributes” button will allow the testing of the connection and prefill the drop down boxes to make selecting the proper attributed easier.  Note that the “Authentication” checkbox is NOT checked.  Click “Create”.

Under the Expression section, use the second drop down box for Named Expressions to select “True value” at the bottom of the list.  Click “Add Expression” to add the value to the Expression section.  Click “Create” and then “Close.”

There will now be an LDAP policy to look up the sAMAccountName.

Now that the necessary authentication and lookup policies have been created it is time to set up the ICA proxy profile.  Browse to Access Gateway->Policies->Session and select the “Profiles” tab.  Click “Add”.  Below are the minimum settings required in the profile.

Here the “SECONDARY” credential index references the secondary authentication policy that will be set on the virtual server later in this article.

The Web Interface site has not been created yet.  Remember the portion at the end of the url, “AGSmartCard” in this example, so it can be used when the site is created.  This example used http, but https can be used as long at the NetScaler trust the certificate in use on the Web Interface server.  The Single Sign-on Domain is the NetBIOS domain name for the AD account.  Click “Create” and then “Close” when done.  Select the “Policies” tab.  Click “Add” to create the new policy.  Make sure to select the newly created Profile in the Request Profile drop down.  Under the Expression section click “Add” (not “Add Expression”).  Match the image below to create an expression that matches non-mobile devices.

Click “OK” and the expression will be added to the list.

Click “Create” and “Close” to add the policy.  Now it is time to add the virtual server that will take advantage of all these new policies to authentication a user.  Browse to Access Gateway->Virtual Servers.  Click “Add”.  After entering a name and entering the VIP (covered in Bill’s article) the certificates will be added.  First select the server certificate for the VIP and click “Add”.  This is the certificate the virtual server will respond with.

Click the “SSL Parameter” button.  Check the “Client Authentication” box near the bottom and select Optional for the Client Certificate.  Note the protocols in use on the left.  In this case it is TLSv1 and SSLv3.  Click “OK” when done.

Hit the Cipher’s button to select the desired ciphers.  They should be valid for the protocols in use.

Back on the Virtual Server window the issuing CAs will now be added.  After selecting one, use the drop down on the “Add” button to add it as a CA Certificate.

The type will show CA Certificate after being added.  Continue to add the remaining issuing CAs and the proper Root CAs.

When done, select the “Authentication” tab.  For the Primary authentication policy, click the “Insert Policy” button and select the CERT policy created earlier.

Click the “Secondary” button and set the LDAP policy created earlier as the secondary policy using the “Insert Policy” button.

The authentication section is now set to have the NetScaler authenticate the user’s certificate and then look up the sAMAccountName in AD.  Click the “Policies” tab.  Click the “Insert Policy” button and add the ICA Proxy policy created earlier.

Select the Published Applications tab.  In the Secure Ticket Authority section click “Add.”  Enter the information for each XenDesktop broker or XenApp server to be used as an STA.  It is not necessary to enter the full path to the ctxsta.dll file, but do specify http or https.

Click “Create” and “Close” to complete the creation of the new virtual server.  At this point the NetScaler is configured but the Web Interface site does not yet exist.  Connect to the Web Interface server and launch the Web Interface Management console.  Right-click the XenApp Web Sites node and select Create Site.

Make sure to match the site name used when creating the Session Profile on the NetScaler.  In this example it was AGSmartCard.  Click “Next”.

Set the point of authentication to the Access Gateway and click “Next”.

Enter the authentication service url.  This FQDN must resolve to the VIP on the AGEE’s virtual server.  The url path is also case sensitive so make sure it matches the example.  The Authentication Options should be set to Smart card.  Click “Next”.

Leave the smart card settings on Prompt users for PIN and click “Next”.

After confirming the site settings click “Next” to initiate the site creation.  When complete leave the “Configure this site now” checkbox checked and click “Next.”  Enter the farm information for your environment.  There is an assumption here that both the XenDesktop and XenApp farms being used are already set up for CAC or SIPR token.   Once all the farm information and settings have been completed the site will appear in the list.  Right-click the site and select “Secure Access”.

Edit the Default access method and set it to Gateway Direct.  Click “Next.”

Enter the FQDN of the VIP on the virtual server and click “Next.”

Click add to specify the XenDesktop broker(s) or XenApp server(s) as Secure Ticket Authorities.  Click “Finish” when done.

When attempting connections if a message is received that the certificate is invalid check out some of the following items:

  1. Certificate is valid (current  and not revoked).
  2. CRLs are available.
  3. User certificate chain is fully trusted on the endpoint (adding of DoD certs to Windows or Firefox)