Minor updates: 13th o June, 2013, 01.19 CET

This post is the second part of a series of two.

  • So it took some time to write this second blog post, and the reason is that I basically wanted to get a second chance to try my settings on a similar environment, as the one I first encountered. And thanks to a Swiss and a Swedish customer/partner I had the possibilities to re-verify my recommended settings.

  • Assumptions:
  • It is assumed that you have read my original blog post, Troubleshooting Smart Card SSO with Access Gateway Enterprise Edition – Part -1 and that you have completed all steps described in CTX124603 and/or CTX126985, and despite that still can’t get this to work. If you think you done everything right, and that Citrix XenApp just can’t handle it, I recommend you to at least read the IMPORTANT NOTES section further down.

  • Background:
  • This real life scenario include the aggregation of applications from two different farms, a XenApp 5 farm and a XenApp 6 farm, Windows 2003 and Windows 2008 R2. I also had the opportunity to verify this with XenApp 6.5, and I can ensure you all that the challenges are the same.
    One thing to bear in mind is that the access is done from Windows 7 via Netscaler/AGEE, leveraging a XenApp Web Site. I haven’t had the possibility to try any other setup.

    Please note, that this is not a beginners guide, and it assumed that you have some basic knowledge of smartcards, certificates, Netscaler /Access Gateway Enterprise Edition, that root certificates are installed correctly, and that the smartcards and CSP are compatible, functional and assigned correctly amongst other things.

  • Common mistakes and recommended settings:
  • The below tips and tricks mainly relate to XA 6.0/6.5 and Windows 2008/R2.

    Netscaler /Access Gateway Enterprise Edition.
    It is assumed that the processes discussed in the following white papers have been followed: CTX124603 and/or CTX126985.

    • It is also assumed that the path used to point to the STA in AGEE is a FQDN, following this standard “http://my.domain.xyz/Scripts/CTXSta.dll”

    Client End Point.

    • See CTX126985
    • Also, ensure the correct CSP is installed (if needed) smartcard reader drivers etc.

    XML Broker/Controller Port.
    To keep things simple, I would recommend trying to use the same XML port for all XML Brokers in all farms.

    • In my first case, I basically created a policy and configured the XML to listen on port 80 (XA6 farm) as this was the port that the XA5 farm was using as well, instead of port 8080.

    ‘Trust XML Request Sent to this broker’, is a requirement and should be configured for all possible brokers in the farm that might be used in the configuration.

    • The easiest method is to create a XA Policy and apply it to the XenApp brokers/controllers.

    Web Interface.
    Check that the Domain CA certificate is already present on the WI machine and create and install an SSL Web Server Certificate on WI Machine; setup IIS to use https.

    Web Interface – STA.
    A common mistake is also to forget to specify the full path in the correct way; do not forget to add the following: “/scripts/ctxsta.dll”.

    • Furthermore, it is always recommended to use the FQDN of the STA server.

    IIS on Windows 2008 /R2

    • Ensure that the Web Server > Security > IIS Client Certificate Mapping Authentication role service is not installed for the Web Server (IIS) role.
    • At the web server level:
    • Authentication\Active Directory Client Certificate Authentication”=Enable”
    • At the web site level:
    • SSL Settings\Client Certificates\”=Ignore”
    • Authentication\Anonymous Authentication”=Enable”

    IIS /XML sharing.
    If you install IIS after you have installed XenApp (as IIS&XML sharing is a requirement) you are most likely asking for problems. You can try to fix this by following this article (CTX125107); alternatively keep it simple and start from scratch, by installing IIS as part of the XenApp install and not afterwards.

    • In my case, IIS was installed afterwards, and there were two (2) issues, one was that the ctxxmlss was still listening (it should have been unregistered); the second issue was that the XML service for the XA 6.0 Farm was listening on 8080 and not port 80. Just remember, that if you are using anything else than port 80, you might have to specify paths in the following format: HTTP(s)://FQDN:8080/.
    • You also should ensure that you follow the appropriate requirements; see “System Requirements for XenApp 6 for Windows Server 2008 R2” in the reference section below.

    IIS Anonymous (WI & XML).
    Ensure that Anonymous Authentication is Enabled, on both the servers acting WI and XML Broker (if they are not the same server).

    • This is to ensure that the XML Service can accept and respond to requests; otherwise the option “Trust request sent to the XML Service”, which is a requirement, will fail.

    • In my case, IIS Anonymous was unfortunately disabled. And the type of error codes you basically get are the following:
      “Error 30014 Site path: C:\inetpub\wwwroot\Citrix\Smartcard
      An error occurred on the Citrix servers during parsing of the request. This message was
      reported from the XML Service at address http://my.domain.xyz/scripts/CtxIntegrated/wpnbr.dll
      The specified Citrix XML Service could not be contacted and has been temporarily removed from the list of active services. [Unique Log ID: 6ax44xxx]”

    IIS /XML – WIA.
    You also need to ensure that Windows Integrated Authentication is enabled, on the server that is acting as XML(IIS) broker

    • Open IIS Manager, go to Sites> Default Web Site> Citrix>.

    • It might also be possible to set this permission on the “Default Web Site” instead of the WI Site used.

    PTS Specific Steps (NO prompt for PIN on launch).

    On the WI created site, set the following:

    • Authentication point = Access Gateway
    • Authentication Options = Smart Card/Enable Smart Card Pass-Through.


    SPN Record.
    One of the most common problems is that a specific SPN record is missing on the XML(IIS) server/s. According to Microsoft, a SPN is a unique identifier for a service on a network that uses Kerberos authentication.

    • In my case, I had to run “setspn –L Server”, on every XML(IIS) server to verify all the SPN records. Where the Server parameter is basically the NetBIOS computer name of the XML(IIS) Server. The server acting XML(IIS) for the new XenApp 6.0 farm was actually missing its SPN record and I had to create it. The thing to look out for is if you have a record that looks something like this:
    • http/my.domain.xyz
    • If you only see WSMAN, TERMSRV, RestrictedKrbHost and HOST records, you will need to create that SPN record; see the command section below.


    • List SPN records: setspn –L server
    • Create SPN: setspn –a http/FQDN NetBIOSName
    • Report all duplicate SPN Records in Domain: setspn -T * -T foo –X

    Lessons Learned:
    Ensure that you use the FQDN when you create the SPN record, otherwise you might still not get this to function properly. Furthermore SPN records are used for Kerberos and they are not a requirement for IIS; as such they are not created when installing XML(IIS).

    Active Directory Kerberos Delegation – Constrained Delegation.
    The delegations might be possible to optimise further, however the below works for me. It is also assumed that the WI is hosted on a dedicated WI server (otherwise just combine the WI and XML broker delegation requirements as it was 1 server).

    • Web Interface should delegate:
    • HTTP service to all of the XML brokers (might be itself for some designs)
    • XML Broker should delegate:
    • CIFS & LDAP (all Domain Controllers)
    • HOST (all XenApp servers in the same farm)
    • HOST to itself
    • HTTP to itself
    • XenApp should delegate:
    • CIFS & LDAP (all Domain Controllers)
    • HOST to itself
    • HTTP service to all of the XML brokers

    Active Directory Kerberos Delegation – Multiple Farms Scenario.
    If you are going to expand this solution and include more XenApp farms, and/or more XML Brokers, do NOT forget to add a HTTP Delegation (AD Computers and Objects) to those brokers, on the WI Server.

    • Trust this computer for delegation to specified services,
    • Use any authentication Protocol
    • Add: HTTP – FQDN of XML(IIS) servers to be used.
    • In my case, there was a new XenApp 6.0 farm added to the already existing XenApp5.0 farm, however the HTTP delegation for the new XA6.0 Farm’s XML(IIS) was missing.

    Active Directory Kerberos Delegation – Type of Delegation.
    The most interesting and least documented setting is that on the XA servers, you cannot use delegate services, with “Use Kerberos Only”.
    The above basically doesn’t work; you have to set all delegations from XenApp with the following settings:

    • Trust this computer for delegation to specified services, Use any authentication Protocol

    Using Wireshark if you get stuck is always smart, and I would recommend installing it on the XML(IIS) server, and filtering on Kerberos. You will notice that Windows has many various types of Kerberos entries, but in regards to SPN errors, you should look out for KRB5, and in the info field for “KRB Error: KRB5KDC_ERR_BADOPTION NT Status: STATUS_NO_MATCH.”
    If the SPN Record is not created, it will not find it and provide the above error code, if you only use the NetBIOS name when creating the SPN record, instead of the FQDN, you would also get a similar error code as the above.

    Application Launch Failure.
    For both XenApp 6 and XenApp 6.5, there have been some issues with application launches. Basically, when everything is still correctly configured, users are presented with a login request to the application, user name and password, instead of a pin /pin pass-through (see below picture).

    • This is solved now for XA6.0 (part of HRP01), and a similar hotfix will soon be released for XA6.5. There are also other hotfixes for XA6.5 that might be required, like XA650W2K8R2X64015.

    IIS Troubleshooting.
    If you don’t have control over the IIS installation, it might also be good to review the Provider order, in regards to Windows Authentication.

    • Negotiate needs to be first in order, otherwise NTLM will be used.

    I wish to thank the following persons for providing valuable feedback while creating this blog post and verifying my settings, with different setups.

    • Daniel Feller (Lead Architect – WWCS), Holger Fuessler (Architect – EMEA), Mark Strange (Senior Consultant – EMEA).
    • Stephan K. (Swiss Government), Johan G. – (IT Architect – ATEA, Sweden) for trying out my recommended settings.
    • And an extra big thank you to James Gordon (Principal Consultant – EMEA), for digging into some additional information. Without James, this blog post would have taken much longer to create.