smart card single sign on with access gateway enterprise edition

Smart Card Single Sign On with Access Gateway Enterprise EditionNicolas Ogor, Escalation Engineer. 06/10/10

• Introduction of Access Gateway Enterprise Edition.

• What's new in Web Interface 5.3 ?

• Configuration.

• Limitations and solutions.

• Troubleshooting.

Agenda

Introduction to Access Gateway Enterprise Edition

• Combine your traditional IPSec VPN and Secure Gateway into a single appliance.

• Easy to configure with XenApp and XenDesktop.

• Support up to 10,000 concurrent connections.

• Physical and Virtual version available.

What's new in Web Interface 5.3 ?

New enhancements and features in this release

• Pass-through with smart card from the Access Gateway.

• Support for 32-bit color.

• XenApp farm migration.

• Multiple launch prevention.

• Support for Windows Server 2008 R2.

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

User

AGEE

Web Interface

Domain Controller

XenApp

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

User

AGEE

Web Interface

Domain Controller

XenApp

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

User

AGEE

Web Interface

Domain Controller

XenApp

Certificate validation

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

User

AGEE

Web Interface

Domain Controller

XenApp

Citrix AGBasicNo password

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

User

AGEE

Web Interface

Domain Controller

XenApp

Local PTS service

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

User

AGEE

Web Interface

Domain Controller

XenApp

Username and Domain name

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

User

AGEE

Web Interface

Domain Controller

XenApp

S4U

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

User

AGEE

Web Interface

Domain Controller

XenApp

.NET WindowsIdentity class

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

User

AGEE

Web Interface

Domain Controller

XenApp

.NET WindowsIdentity class

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

User

AGEE

Web Interface

Domain Controller

XenApp

XML

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

User

AGEE

Web Interface

Domain Controller

XenApp

Application list

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

User

AGEE

Web Interface

Domain Controller

XenApp

HTTPS

How does the Pass-through work ?

• Web Interface uses the Protocol Transition Service with the User and domain name parameters to obtain an instance of the .NET WindowsIdentity class from the Domain Controller.

• This .NET object represents the user’s logon session. This is used to create a WindowsToken that can authenticate the user.

User

AGEE

Web Interface

Domain Controller

XenApp

HTTPS

Configuration

Certificate Authority

• Install a Certificate Authority in the domain.

• Open MMC-select Certificate Authority and Certificate template.

• Duplicate the Smart card logon template.

• Select your CSP.

Certificate Authority

• Issue the Certificate template created previously to be available for users.

Client computer

• Install your CSP software on your computer.

• Logon to your Certificate Authority.

• Select the Certificate template and CSP vendor.

• The certificate will be installed into the smart card.

XenApp and Web Interface requirements

• XenApp and Web Interface servers must be domain members.

• XenApp XML service must be running with IIS on servers chosen as XML brokers and STA servers

• XenApp version 4.5 and 5 are currently supported.

• Web Interface 5.3 or later must be used.

• Active Directory domain functional level must be 2003 or 2008.

Setup delegation on your domain

•Delegation definition: Some server services require access to a second server.In order to establish a session with the second server, the primary server must be authenticated on behalf of the client's user account and authority level.

Setup delegation on your domain

Setup delegation on your domain

1 - Client provides credentials and domain controller returns a Kerberos TGT to the client.

Setup delegation on your domain

2 - Client uses TGT to request a service ticket to connect to Server 1.

Setup delegation on your domain

3 - Client connects to Server 1 and provides both TGT and service ticket.

Setup delegation on your domain

4 - Server 1 uses the clients TGT to request a service ticket so Server 1 can connect to Server 2 .

Setup delegation on your domain

5 - Server 1 connects to Server 2 using the client’s credentials.

Setup delegation on your domain

• Web Interface must delegate http service to the XML broker.

Setup delegation on your domain

• XML broker must delegate the http service to itself and host services to all XenApp servers in the farm.

Setup delegation on your domain

• Each XenApp server must delegate cifs and ldap services to the Domain Controllers and host services to itself and http services to the XML broker.

Access Gateway configuration

• Create a Virtual Server and associate a server certificate.

• Bind the root certificate as a Root Certificate Authority on the Virtual server.

Access Gateway configuration

• Enable client authentication and client certificate to optional on the Virtual server properties.

Access Gateway configuration

• Create an authentication profile of type certificate.

• Under the User Name field specify the certificate attribute to extract.

Access Gateway configuration

• Create a session profile that will redirect users to the Web Interface after successful authentication.

• Specify the NetBIOS name of your domain for the Single Sign- on domain.

• Bind the session profile to your Virtual server.

Web Interface Site

• Install a server certificate on the Web Server.

• Create a site and specify the path of the Web site.

Web Interface Site

• Set the Authentication to take place at the Access Gateway and select the option “Enable Smart Card-pass-through”.

Web Interface Site

• Once the site is created , you must restart your Web Interface server.

Web Interface Site

• Specify your XML broker.

Web Interface Site

• Finish the Web Interface site configuration and restart the Web Interface server.

Web Interface Site

• Check if the Protocol Transition Service is running.

Web Interface Site

• Configure the Secure Access to go through the Gateway.

Web Interface Site

• Specify the FQDN of your Access Gateway Virtual Server.

Web Interface Site

• Specify the Secure Ticket Authority servers on the Web Interface and AGEE.

Limitations and solutions

PIN prompt when launching a Published Application

• Cause : User receives a Pin prompt when hitting the AGEE Virtual server with the ICA client because the option Client Certificate is On.

PIN prompt when launching a Published Application

• Solution : Create another Virtual server with same IP address, certificate but a different port and with the option Client certificate set to off.

• On Vserver binds the STA server specified on the Web Interface site.

• Create a dummy authentication policy and bind it to the Vserver to avoid users to logon directly to that Virtual server.

PIN prompt when launching a Published Application

• Solution : On the Secure Access Settings of the Web Interface specify the new Virtual Server.

• All HTTP traffic will now go through the VIP on port 443 and ICA proxy traffic through port 444.

Limitations of Kerberos Pass-through Authentication

• Issue: Applications running on XenApp that depend on the NTLM protocol for authentication generate explicit user authentication prompts or fail because the password is never sent over the network.

• Workaround: Configure delegation on the targeted servers to use Kerberos instead of NTLM authentication.

Limitations of Kerberos Pass-through Authentication

• Issue: Kerberos pass-through authentication for applications expires if the XenApp session is left running for a very long time (typically one week) without being disconnected and reconnected.

• Workaround: You have to force user to disconnect after the Kerberos ticket expired.

Troubleshooting

Decrypt traffic between the Web Interface and AGEE

• Install Wireshark tool or other networking sniffer on the Web Interface server.

• Retrieve private keys for the Web Interface certificate and the AGEE virtual server certificate.

• Configure Wireshark SSL preferences to use the Private keys to decrypt traffic. ( http://support.citrix.com/article/CTX116557 )

• Start a trace on the Web Interface server.

Authentication process

1. The client opens a Web browser and enters a URL.

2. The user presents the client certificate to the portal page and clicks Logon.

3. AGEE extracts the username from the certificate.

4. Client sends a GET request to the home page defined on the global SSL VPN settings, or a session profile. This communication is client to VIP.

5. AGEE sends the same GET to the Web Interface page called login.aspx.

6. Web Interface issue a 302 Found message with a redirect to agesso.aspx.

7. Client sends a GET for agesso.aspx to the VIP and the appliance then forward it to Web Interface. 8. Web Interface responds with a 401 Unauthorized message including a header named WWW-Authenticate which should have CitrixAGBasic password_required="No" as its value as well as a ticket ID. 

Authentication process

9. After the 401 unauthorized message, the appliance sends another GET for agesso.aspx including an authorization.

This header includes a hash value of the user name, domain and session ID.

Web Interface responds by a 302 and set the cookie WIAuthID.

Authentication process

10. This now causes the Web Interface to POST to the authentication service URL on its configuration.  

11. If everything succeed the appliance responds with a HTTP 200 message and a SOAP envelope containing the smart access farm name, client IP address, and a success status code.

Authentication process

12. GET request is sent for default.aspx from the client (client to VIP). GET request contains the cookie WIAuthID and the Authorization header which is a Hash of the username and domain.

Authentication process

13. The Web Interface will contact the XML broker to get the application list by sending a Post request to the CtxIntegrated/wpnbr.dll

Authentication process

14. The XML broker will return the published application list for user to the Web Interface.

15. The Web Interface will respond to the GET request in step 12 by a 200 response and the application will be enumerated into the client’s browser.

Authentication process

Check list

• Take a Network trace on the Web Interface.

• Check application Eventviewer on the Web Interface.

• Check your delegation settings on your Active Directory.

• Ensure that the trust XML request option on the XML broker is selected.

• Ensure that the root certificate used to sign the AGEE Virtual server is stored on the Trusted root Certificate store of the Web Interface server.

• Ensure that the Web Interface can resolve the FQDN name of the Virtual server.

Before you leave…

• Recommended related breakout sessions: • SUM502 - XenApp and XenDesktop authentication (Lalit Kaushal)

• Session surveys are available online at www.citrixsynergy.com starting Thursday, 7 October• Provide your feedback and pick up a complimentary gift card at the registration desk

• Download presentations starting Friday, 15 October, from your My Organiser Tool located in your My Synergy Microsite event account