1. Authentication on XenApp & XenDesktop
Lalit Kaushal
Escalation Engineer EMEA

2. Agenda Authentication at WI: Kerberos Authentication
Explicit Authentication
Pass-through Authentication
Smart Card Authentication
Anonymous Authentication
Kerberos Authentication

3. Authentication in XenApp\XenDesktop
Support for several authentication methods
Smart cards, client certificates, RSA SecurID, etc.
Support for OS and non-OS credentials stores
OS: Active Directory and eDirectory
Non-OS: LDAP, RADIUS, 3rd party authentication methods.
Leverage Authentication methods supported by Windows:
Smartcard support
Client certificates support
Custom 3rd party authentication mechanisms through GINA extensions.
Leverage Windows authentication to flow the OS identity tokens between Access Infrastructure services
Example: flowing Kerberos tickets between ICA client and XA server.

4. Kerberos Key Distribution Centre (KDC) AS TGS 1 2 3 4
Authentication Service (AS) - Authenticates a client logon and issues a Ticket Granting Ticket (TGT) for future authentication. 2
Ticket Granting Service (TGS): It grants tickets to TGT holding clients for a specific application server or resource.
I am Bob, I need Ticket to get Ticket (TGT) 3
Ticket Granting Ticket (TGT): This ticket is received from the Authentication Service (SA) that contains the client’s Privilege Attribute Certificate (PAC). 4
Ticket: This ticket is received from the TGS that provides authentication for a specific application server or resource.
Here’s TGT – Can you decrypt it with your password hash
Here’s my TGT – Can you give me Service Ticket
Here’s your Service Ticket
The Kerberos Authentication protocol uses 2 types of A-ID: A generic A-ID called the Ticket Granting Ticket (TGT). This is obtained when the user initially authenticates to the KDC (Kerberos Authentication Service). Another, a per-service A-ID, is issued each time the user wants to access a specific network service; the user presents its generic A-ID (the TGT) to the Kerberos server (KDC), and she receives a service-specific A-ID called a Service Ticket. A Service Ticket is only valid for the service it is intended for.
In Windows, Kerberos scales better than its NTLM predecessor because a service that receives an ST ticket doesn’t need to check with the KDC whether the ticket is authentic. All ST tickets are encrypted by the KDC with a key that only the receiver can decrypt.
In order to access Windows services, Kerberos ST tickets (A-IDs) are passed in a variety of Windows protocols between clients and servers: For example, Kerberos tickets are passed in the SMB/CIFS (file access) protocol when accessing Windows shares, in the RPC/COM+ protocol, in HTTP (between IE and IIS only).
Authentication Service (AS): This service runs on the Key Distribution Center (KDC) server. It authenticates a client logon and issues a Ticket Granting Ticket (TGT) for future authentication.
Ticket Granting Service (TGS): This service runs on the KDC server. It grants tickets to TGT holding clients for a specific application server or resource.
Ticket Granting Ticket (TGT): This ticket is received from the Authentication Service (SA) that contains the client’s Privilege Attribute Certificate (PAC).
Ticket: This ticket is received from the TGS that provides authentication for a specific application server or resource.
Session Key: This is the derived value used strictly for the immediate session between a client and a resource.
Privilege Attribute Certificate (PAC): This is strictly used in Windows 2003 Kerberos authentication. Contains information such as the user’s Security ID (SID), group membership SIDs, and users’ rights on the domain.
Here’s my Service Ticket, Auth. me
Client\Server session

5. Kerberos Delegation
In addition to allowing receiving services to check the user’s identity, Kerberos tickets can be used by Windows services to impersonate the identity of the user. Instead of using the service’s own identity, a service can use the client’s identity in order to access local OS resources (e.g. files). This way, the OS can check access control based on the original caller’s identity, and not on the service’s making the access. This is very useful for services whose purpose is to mediate access to resources (e.g. web, file, mail services). Windows even allows a service which impersonated a user to access other network services with the caller’s original identity. This is called Kerberos delegation (transitive trust). It allows a user’s original identity (Kerberos ticket) to flow across more than one hop, and can be used as the basis for granting or denying access to local OS resources at each hop.
Many of the services needed in the Access Infrastructure can benefit greatly from these OS features. This way, Access Infrastructure services do not need to store, handle and transmit users’ credentials between hops. They instead leverage the OS secure mechanisms for communicating identity information between interacting services, and can also benefit from the strong and secure auditing provided by the OS.

6. Kerberos in Windows
All you ever wanted to know about Kerberos:
The Authentication Service Exchange
1. Kerberos authentication service request (KRB_AS_REQ)
The client contacts the Key Distribution Center's authentication service for a short-lived ticket (a message containing the client's identity and—for Windows clients—SIDs) called a ticket-granting ticket (TGT). This happens at logon.
2. Kerberos authentication service response (KRB_AS_REP)
The authentication service (AS) constructs the TGT and creates a session key the client can use to encrypt communication with the ticket-granting service (TGS). The TGT has a limited lifetime. At the point that the client has received the TGT, the client has not been granted access to any resources, even to resources on the local computer.
Why use a TGT? Could the AS simply issue a ticket for the target server? Yes, but if the AS issued tickets directly, the user would have to enter a password for every new server/service connection. Issuing a TGT with a short lifespan (typically 10 hours) gives the user a valid ticket for the ticket-granting service, which in turn issues target-server tickets. The TGT's main benefit is that the user only has to enter a password once, at logon.
The Ticket-Granting Service Exchange
3. Kerberos ticket-granting service request (KRB_TGS_REQ)
The client wants access to local and network resources. To gain access, the client sends a request to the TGS for a ticket for the local computer or some network server or service. This ticket is referred to as the service ticket or session ticket. To get the ticket, the client presents the TGT, an authenticator, and the name of the target server (the Server Principal Name or SPN).
4. Kerberos ticket-granting service response (KRB_TGS_REP)
The TGS examines the TGT and the authenticator. If these are acceptable, the TGS creates a service ticket. The client's identity is taken from the TGT and copied to the service ticket. Then the ticket is sent to the client.
Note
The TGS cannot determine if the user will be able to get access to the target server. It simply returns a valid ticket. Authentication does not imply authorization.
The Client/Server Exchange
5. Kerberos application server request (KRB_AP_REQ)
After the client has the service ticket, the client sends the ticket and a new authenticator to the target server, requesting access. The server will decrypt the ticket, validate the authenticator, and for Windows services, create an access token for the user based on the SIDs in the ticket.
6. Kerberos application server response (optional) (KRB_AP_REP)
Optionally, the client might request that the target server verify its own identity. This is called mutual authentication. If mutual authentication is requested, the target server will take the client computer's timestamp from the authenticator, encrypt it with the session key the TGS provided for client-target server messages, and send it to the client.

7. Explicit or Prompt Authentication

8. Explicit or Prompt Authentication
Username, password and domain
Optionally includes two-factor authentication such as RSA SecurID
Encoded credentials passed to XML service
User types in their username and password (possibly including domain and passcode)
Credentials can be in either DOMAIN\Username, UPN or both formats.
Admin can provide the user with choices for the domain field
Pass the username and password (CTX encoded) to the XML Service
Receive a ticket from the XML Service, which is placed in the ICA files generated at launch and redeemed by the ICA server.

9. Explicit Auth in XenApp
Get svc ticket
Client DC
Authenticate & get TGT
Winlogon
pwd
auth
pwd
XML Broker
SSOn WI
pwd
IMA / DDC
pwd
pwd
WI ticket
WI ticket IE
WI ticket in .ica file
XenApp
Winlogon
WI ticket
pwd
ICA Client Engine
WI ticket
TS / wsxica
Svc ticket
Servers (File Server, Exchange, …)

10. Servers (File Server, Exchange, …)
Explicit Auth in XD
Get svc ticket
Client DC
Authenticate & get TGT
Winlogon
pwd
auth
pwd
DDC
SSOn WI
pwd
IMA / DDC
pwd
pwd
WI ticket
pwd
WI ticket IE
WI ticket in .ica file
WI ticket
VDA
1. Winlogon gives password to authenticate to against DC to get TGT.
2. As part of the Single-Signon , SSONSVr takes the users's passwd.
3. IE pass pwd --> WI --<> psswd --> IMA\DDC --> authenticate to DC.IMA also stores psswd in memory and return WI Ticket
4. WI include the WI ticket into the ica file and forward it to client.
5 IE pass the WI ticket to Desktop toolbar and later forward it to ICA Client Engine.
6. ICA Client engine pass the WI ticket to VDA
7. VDA --> sends ticket to DDC to validate the ticket and to perform some other checks related to previous sessions, etc. If WI ticket successfully authenticates then IMA return the psswd and clear locally cached psswd
8. VDA send psswd to Winlogon and Winlogon perform the normal logon process by contacting the DC and gets the Service ticket.
9. At this stage if you need connection to other backend server like Outlook, then VDA will use the psswd to request TGT\Svc ticket for Outlook.
Desktop Toolbar
Winlogon
WI ticket
pwd
ICA Client Engine
WI ticket
VDA
Svc ticket
Servers (File Server, Exchange, …)

11. Troubleshooting Explicit
Diagnostic/Tracing (CDF)
MF_DLL_CtxGina (PortICA GINA) for smart card SSON
MF_DLL_Ctxauth
MF_DLL_Ctxnotif
MF_DLL_Wsxica
MF_Service_CtxXmlSS
MF_XMLRelay_Wpnbr
Debugging
Capture Network traffic
Study behaviour of any 3rd party authentication system, if exist
Additional info
Use CDF tool
Isolate XML
Event Logs messages

12. Pass-through Authentication

13. Presentation Title Goes Here
Insert Version Number Here
Pass-Through?
Pass-Through Session:
Connecting from within one session to another session on another server
2 servers
2 clients
2 sessions
Pass-Through Authentication\SSON (Single Sign On):
Passing the user credential into the session
© 2003 Citrix Systems, Inc.—All rights reserved.

14. Pass-Through Authentication
Presentation Title Goes Here
Insert Version Number Here
Pass-Through Authentication
Pass-through Authentication
Users can authenticate using the credentials they provided when they logged on to their physical Windows desktop.
Users do not need to re-enter their credentials and their resource set appears automatically.
Additionally, you can use Kerberos integrated Windows authentication to connect to server farms
If you specify the Kerberos authentication option and Kerberos fails, pass- through authentication also fails and users cannot log on
© 2003 Citrix Systems, Inc.—All rights reserved.

15. Pass-Through Authentication
Windows Identity credentials
IWA browser to Web server
User’s SIDs sent to XML service
Client handles authentication to ICA server
IIS performs IWA (integrated windows authentication) with IE/Firefox, normally just to find out the username, sometimes to get a Kerberos ticket
WI figures out the user’s SIDs from the Windows Identity received from IIS and sends them to the XML service
When a launch is initiated, the generated ICA file contains no authentication information, but instead sets the value UserLocalUserAndPassword to true.
UseSSPIOnly is also set to true if Kerberos authentication is enforced.

16. Pass-Through Authentication9 10 10 8 9
Pass-through authentication allows the online plug-in to access a user’s local Windows user name, password, and domain information and pass it to the XenApp server. This means that users are not prompted to log on to XenApp separately.
Phase 1: Client to WI
The user navigates to the Web Interface URL.
Note: IIS (Web Interface) use integrated Windows authentication to authenticate the user (depending on the environment either NTLM or Kerberos is used by IIS). For more information please see Microsoft Integrated Windows Authentication
Phase 2: WI to XML Broker
Web Interface create an XML request containing the user's individual and group SIDs and forwards the list of SIDs to the XML Broker.
Note: Till this step WI knows the user's domain and username, but not the password. Also, Web Interface contacts only one XML Broker server at a time. If XML Service load balancing is enabled, WI sends XML requests to all the listed servers in a round-robin fashion. If XML Service load balancing is not enabled, WI use the first server in the list. If the XML server cannot be contacted, it is removed from the list for BypassDuration minutes (60 by default). Note that an XML server that is alive but reporting errors is not considered a failed server and is not removed from the list. This can happen, for example, when the XML Service is busy or not responding properly.
Phase 3: XML Broker returns applications list
The IMA service on the XML Broker queries the Local Host Cache in order to determine the user's application set.
Note: XML Broker does not perform user authentication at this point, as the user's password is still not known.
The list of applications is returned via XML to Web Interface.
Phase 4: ZDC sends Least loaded server address
When user click on an application, WI sends request to XML Broker for the IP address for the XenApp Server to direct the user.
XML Broker (using IMA) queries ZDC for the least loaded server hosting the requested application.
ZDC calculates the least-loaded server and address of this server is provided to WI and written to the ICA file.
Note: ZDC checks several conditions before giving back the server address e.g. if user has disconnected session, any load-evaluator assigned to requested application, policy for Zone preference (ignored in case of reconnecting user to disconnected session), etc.
ICA file is then sent to the ICA Client.
Note: With WI 4.5 onwards, in some cases an ICO launch script is returned instead of an ICA file.
This ticket is then used by the client authenticate with the ICA stack e.g. XenApp.
XenApp server authenticates the user against the domain controller. Additionally, the credentials supplied by the SSONSVR.EXE executable running on the client can also be used for authentication by the member server (password or a Kerberos ticket). If ssonsvr.exe is not working properly then the user will be prompted for credentials. 5 2 4
1-3 4 6 6 7 7 9 10

17. Troubleshooting Pass-Through
Diagnostic/Tracing (CDF)
MF_DLL_CtxGina (PortICA GINA) for smart card SSON
MF_DLL_Ctxauth
MF_DLL_Ctxnotif
MF_DLL_Wsxica
MF_Service_CtxXmlSS
MF_XMLRelay_Wpnbr
Debugging
Capture Network traffic
Verify SSONSVR is running
Additional info
Use CDF Control tool
Verify if Explicit\Prompt authentication works
Follow CTX368624

18. SmartCard Authentication

19. What is Multi-Factor Authentication?
Presentation Title Goes Here
Insert Version Number Here
What is Multi-Factor Authentication?
ATM card is the most common example
You wouldn’t use just one factor to protect your money
Multiple factors
Something you know
Your PIN
Something you have
Your card
© 2003 Citrix Systems, Inc.—All rights reserved.

20. What is Multifactor Authentication?
Smart Cards
2 – Factor Authentication
Something you know
Something you have
Biometrics
Fingerprint readers
Retinal Scan
Facial Recognition
Biopassword
Keystroke dynamics
Proximity
Multifactor authentication (MFA) is a security system in which more than one form of authentication is implemented to verify the authenticity of a transaction.
In contrast, single factor authentication (SFA) involves only a user ID and password.
In two-factor authentication, the user provides dual means of identification, one of which is typically a physical token, such as a card, and the other of which is typically something memorized, such as a security code.
Additional authentication methods that can be used in MFA include biometric verification such as finger-scanning, iris recognition, facial recognition and voice ID. In addition to these methods, smart cards and other electronic devices can be used along with the traditional user ID and password.

21. Smart Card Infrastructure
User Applications
Microsoft Architecture
DLL’s
Resource
Manager
Smart card
Subsystem
Microsoft Architecture is being discussed since majority of our customers are using Microsoft platforms and Microsoft has a PC/SC solution.
The graphic has 3 distinct sections:
User Apps
Smart Card Subsystem
Hardware
From
The basic components of the smart card subsystem are based on PC/SC standards (see the specifications at These basic components include:
A resource manager that uses a Windows application programming interface (API).
A user interface (UI) that works with the resource manager.
Several base service providers that provide access to specific services. In contrast to the resource manager's Windows API, service providers use a COM interface model to provide smart card services.
Drivers
Hardware

22. Smart Card Infrastructure
Cards
Credit card–sized devices
Introduce to Windows by using a vendor-supplied installation program
Installs service provider that registers its interfaces with the Resource Manager
Reader
Attach to peripheral interfaces, e.g. PS/2, PCMCIA and USB
Microsoft Architecture is being discussed since majority of our customers are using Microsoft platforms and Microsoft has a PC/SC solution.
The graphic has 3 distinct sections:
User Apps
Smart Card Subsystem
Hardware
From
The basic components of the smart card subsystem are based on PC/SC standards (see the specifications at These basic components include:
A resource manager that uses a Windows application programming interface (API).
A user interface (UI) that works with the resource manager.
Several base service providers that provide access to specific services. In contrast to the resource manager's Windows API, service providers use a COM interface model to provide smart card services.
Hardware

23. Smart Card Infrastructure
Service Providers
Provide cryptographic services e.g. key generation, digital signature, bulk encryption—through CryptoAPI
Two categories: cryptographic (CSP) & non-cryptographic
CSPs can be software-only (like MS Base CSP) or hardware-based - cryptographic engine resides on a smart card (SCCP)
Resource Manager
Manage & control all application access
Provide a virtual direct connection to the requested smart card
Device Drivers
Maps functionality to native services that infrastructure provide
Communicates card insertion\removal events to Resource Manager
Provides data communications capabilities to and from the card
DLL’s
Microsoft Architecture is being discussed since majority of our customers are using Microsoft platforms and Microsoft has a PC/SC solution.
The graphic has 3 distinct sections:
User Apps
Smart Card Subsystem
Hardware
From
The basic components of the smart card subsystem are based on PC/SC standards (see the specifications at These basic components include:
A resource manager that uses a Windows application programming interface (API).
A user interface (UI) that works with the resource manager.
Several base service providers that provide access to specific services. In contrast to the resource manager's Windows API, service providers use a COM interface model to provide smart card services.
Resource
Manager
Smart card
Subsystem
Drivers

24. Windows logon – Smart Card
Flow sequence:
1. WinLogon requests the logon UI credential information.
Asynchronously, smart card resource manager starts. The smart card credential provider:
a. Gets credential information, a list of known credentials or none, or that Windows detected a smart card reader.
b. Gets a list of smart card readers (uses WinSCard API) and the list of smart cards inserted in each of them.
c. Enumerates each card to check if a logon certificate (signing) controlled by Group Policy is present. If the certificate is present, the smart card credential provider copies it into a temporary secure cache on the terminal.
d. Notifies the logon UI that it has new credentials.
2. The logon UI requests the new credentials from the smart card credential provider. As a response, the smart card credential provider provides to the logon UI each logon certificate for which a corresponding logon tile is displayed. The user selects a smart card-based logon certificate tile, and Windows displays a PIN dialog box.
3. The user enters the PIN and clicks Go. The smart card credential provider encrypts the PIN.
4. The credential provider that resides in the LogonUI process (system) collects the PIN. As part of packaging credentials in the smart card credential provider, the data is packaged in a KERB_CERTIFICATE_LOGON structure (defined in CredentialProviders.h). The main contents of the KERB_CERTIFICATE_LOGON structure are smart card PIN, cspdata (contains reader name, container name, etc), User Name and Domain Name. User Name is required if the logon domain is not in the same forest, because it enables a certificate to be mapped to multiple user accounts.
5. The credential provider now wraps the data (such as encrypted PIN, container name, reader name, and card Key Spec) and is sent back to LogonUI.
6. Data from Logon UI is now presented by Winlogon for LSALogonUser.
7. LSA calls Kerberos Authentication Package (Kerberos SSP) to create a Kerberos Authentication Service Request (KRB_AS_REQ) containing a pre-authenticator (as specified in RFC 4556: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (
If the authentication is performed using a certificate with a key usage of digital signature, then the pre-authentication data consists of the user’s public certificate, and the certificate is digitally signed with the corresponding private key.
If the authentication is with a certificate with a key usage of key encipherment, then the pre-authentication data consists of the user’s public certificate, and the certificate is encrypted with the corresponding private key.
8. To sign the request digitally (as per RFC 4556), a call is made to the corresponding CSP for a private key operation. Because the private key in this case is stored in a smart card, the smart card sub-system is called, and the necessary operation is completed. The result is sent back to the Kerberos SSP.
9. The Kerberos SSP sends an authentication request (as per RFC 4556) to the Key Distribution Center (KDC) service that runs on a domain controller, to request a Ticket Granting Ticket (TGT).
10. The KDC finds the user’s account object in the active directory, as detailed in Client Certificate Mappings, and uses the user’s certificate to verify the signature.
11. The KDC validates the user’s certificate (time, path, and revocation status) to ensure that the certificate is from a trusted source. The KDC uses CryptoAPI (CAPI2) to build a certification path from the user’s certificate to a Root CA certificate that resides in the root store on the domain controller. The KDC then uses CryptoAPI (CAPI2) to verify the digital signature on the authenticator that was included as signed data in the pre-authentication data fields. The domain controller verifies the signature and uses the public key from the user’s certificate to prove that the request originated from the owner of the private key that corresponds to the public key. The KDC also verifies that the issuer is trusted and appears in the NTAUTH certificate store.
12. The KDC service retrieves user account information from Active Directory. The KDC constructs a TGT based on the user account information that it retrieves from Active Directory. The TGT includes the user's security identifier (SID), the SIDs for universal and global domain groups to which the user belongs, and (in a multi-domain environment) the SIDs for any universal groups of which the user is a member. The TGT’s authorization data fields include the list of SIDs.
13. The domain controller returns the TGT to the client as part of the KRB_AS_REP response.
Notes
· The KRB_AS_REP packet consists of:
· Privilege attribute certificate (PAC)
· User’s security identifier (SID)
· SIDs of any groups of which the user is a member
· A request for Ticket Granting Service (TGS)
· Pre-authentication data
The response is as per RFC TGT is encrypted with the master key of the KDC, and the session key is encrypted with a temporary key. This temporary key is derived based on RFC Using CAPI2 APIs, the temporary key is decrypted. As part of the decryption process, if the private key for the same happens to be on a smart card, then the call is made back to the smart card subsystem using the specified Cryptographic Service Provider to extract the certificate corresponding to the user’s public key. (Programmatic calls include CryptAcquireContext, CryptSetProvParam with the PIN, CryptgetUserKey, CryptGetKeyParam for the certificate.). After the temporary key is obtained, the \ Kerberos SSP decrypts the session key.
14. The client validates the reply from the KDC (time, path and revocation status). It first verifies the KDC’s signature by the construction of a certification path from the KDC’s certificate to a trusted root CA, and then it uses the KDC’s public key to verify the reply signature.
15. Now that a TGT has been obtained, the client obtains a Service Ticket to the local computer in order to log on to the computer.
16. On success, LSA stores the tickets and returns success to the LSALogonUser. On this success message, user profile, Group Policy, and other actions are performed.
17. Once the user profile is loaded, CertPropSvc picks up this event, reads the certificates from the card (including the root certificates), and then populates them into the user’s certificate store (MYSTORE).
18. CSP to smart card resource manager communication happens on LRPC Channel.
19. On successful authentication, certificates will be propagated to the user’s store (MYSTORE) asynchronously by the Certificate Propagation Service (CertPropSvc).
20. When the card is removed, certificates in the temporary secure cache store are removed. The Certificates are no longer available for logon, but they will remain the user’s certificate store (MYSTORE).
Note
A SID is a security identifier that is created for each user or group, at the time a user account or a group account is created within either the local security accounts database on Windows NT or higher computers, or within Active Directory. The SID never changes, even if the user or group account is renamed.
For more information about Kerberos, see How the Kerberos Version 5 Authentication Protocol Works (
By default, the KDC verifies that the client's certificate contains the smartcard client authentication EKU szOID_KP_SMARTCARD_LOGON. However, there is a policy that allows the KDC not to require the SC-LOGON EKU (SCLogonEKUNotRequired – See Windows Vista Group Policy Settings). SC-LOGON EKU is not required for account mappings that are based on the public key.

25. Smart Card Authentication
Client certificate and PIN credentials
Certificate authentication browser to web server
User’s SIDs sent to XML service
Client handles authentication to ICA server
IIS performs Certificate authentication (i.e. using smart cards) with IE/Firefox to find out the username
The Windows Identity is passed to WI, which then figures out the user’s SIDs
The user’s SIDs are passed to the XML service
When a launch is initiated, the generated ICA file contains no authentication information, but instead sets the value DisableCtrlAltDel to Off
This forces the XenApp server to supply the “Press Ctrl+Alt+Del” GINA dialog, which then recognises the smart card over the virtual channel
The user has to enter their PIN, unless a full ICA Client with credentials capture enabled is present
The pass-through variant requires users to log onto their local machine with their smart card credentials. IWA is completed as in the plain pass-through flow, and both UseLocalUserAndPassword and DisableCtrlAltDel are set appropriately in the ICA file. The ICA session does not prompt for the user’s PIN.
Complicated infrastructure:
Domain Controller
Certificate Authority
Web Interface server with SSL and client certificate mapping enabled
ICA server (XenApp/XenDesktop)
Client device

26. Smart Card Core Subsystem Architecture
End-Point (e.g. XP)
XD/XA Host
Wfica32.exe
(ICA Client Engine)
Winlogon.exe
PC/SC API
VDSCardN DLL
Winword.exe
PC/SC API
SCardHook DLL
PC/SC API
WinSCard DLL (MS)
SCardHook DLL
CtxSvcHost.exe
(CtxSmartCardSvc DLL)
SCardSvc.exe (MS)
User Mode
Kernel Mode
VC User Mode API (Pica/WTS)
SC Reader Driver
User Mode
Kernel Mode
ICA Stack
PC/SC (WinSCard) API
Remoted over ICA protocol
(ICA Smart Card VC Protocol)
SC Reader
Remote calls: SCardEstablishContext, SCardConnect, SCardTransmit…

27. Troubleshooting Smart Card
Diagnostic/Tracing (CDF)
MF_DLL_CtxGina (PortICA GINA) for smart card SSON
MF_Hook_SmartCard
PE_Service_CtxSmartCardSvc
PE_Service_CtxSvcHost (just load CtxSmartCardSvc.dll)
PE_Library_GvchBase
PE_Library_CtxCppBase
Debugging
Debug user process loading SCardHook.dll
Debug CtxSvcHost.exe (instance with CtxSmartCardSvc.dll loaded)
Debug Wfica32.exe and vdscardN.dll on client side
Additional info
Use Remote CDF tool
Verify Citrix Smart Card Service is running
Restart Citrix Smart Card Service

28. Anonymous Authentication

29. Anonymous Authentication
No credentials
XenApp only
Published resources must be explicitly configured for Anonymous authentication

30. Kerberos Authentication

31. Kerberos Authentication
Presentation Title Goes Here
Insert Version Number Here
Kerberos Authentication
Using Kerberos for Authentication
Users can use Kerberos for Explicit\Prompt or Pass-through Authentication.
More secure - No password crosses the wire – even encrypted
Works with any client logon method
Password, smart card, biometrics, etc…
Describe Kerberos logon in goldfish:
Before, captured password to do single sign-on
After, uses Kerberos in Windows to do single sign-on
© 2003 Citrix Systems, Inc.—All rights reserved.

32. Kerberos Authentication Support
Configure Delegation on Web Interface Server
Edit the Delegation properties of each WI computer object in Active Directory
Trust this computer for delegation using any authentication protocol
Add the http service for each XenApp XML Broker
You still need to configure delegation as per the ADFS section of the Web Interface administrator’s guide pg
To trust the server running the Web Interface for delegation
1. In the MMC Active Directory Users and Computers snap-in View menu,
enable Advanced Features.
2. In the Computers folder under the domain name, select the server running
the Web Interface.
3. On the Action menu, click Properties.
4. On the Delegation tab, click Trust this computer for delegation to
specified services only and Use any authentication protocol, and then
click Add.
5. On the Add Services screen, click Users or Computers.
6. On the Select Users or Computers screen, type the name of the server
running the XML Service in the Enter the object names to select text box,
and then click OK.
7. Select the http service type from the list and then click OK.
8. On the Delegation tab, verify the http service type for the server running
Presentation Server appears in the Services to which this account can
present delegated credentials list, and then click OK.

33. Kerberos Authentication Support
Configure Delegation on XenApp (XML) Server
Edit the Delegation properties of each XenApp Server computer object in Active Directory
Trust this computer for delegation using Kerberos only
Add the HOST service for this computer running the XML service
You still need to configure delegation as per the ADFS section of the Web Interface administrator’s guide pg
To trust the server running the XML Service for delegation
1. In the Computers folder under the MMC Active Directory Users and
Computers snap-in, select the name of the server running the XML Service
that the Web Interface is configured to contact.
2. On the Action menu, click Properties.
3. On the Delegation tab, click Trust this computer for delegation to
specified services only and Use Kerberos only, and then click Add.
4. On the Add Services screen, click Users or Computers.
5. On the Select Users or Computers screen, type the name of the server
running the XML Service in the Enter the object names to select text box,
and then click OK.
6. Select the HOST service type from the list and then click OK.
7. On the Delegation tab, verify the HOST service type for the server running
the XML Service appears in the Services to which this account can
present delegated credentials list, and then click OK.

34. Kerberos Auth in XenApp
Get svc ticket
Get svc ticket
Client DC
Authenticate & get TGT
Get svc ticket
Winlogon
pwd
pwd XA
SSOn WI
SIDs
IMA ok
Launch ref
Launch ref IE
Svc ticket
Launch ref in .ica file
Launch ref
Winlogon
Svc ticket
ICA Client Engine
Launch ref & svc ticket (through Kerberos VC)
TS / wsxica
Svc ticket
Servers (File Server, Exchange, …)

35. Kerberos Auth in XenDesktop
Get svc ticket
Client DC
Authenticate & get TGT
Authenticate & get TGT
Get svc ticket
Winlogon
pwd
pwd
DDC
SSOn
pwd WI
Get pwd
SID
IMA / DDC ok
Launch ref
Launch ref IE
Svc ticket
Launch ref in .ica file
VDA
Launch ref
Desktop Toolbar
Winlogon
Launch ref
pwd
ICA Client Engine
Launch ref, pwd
VDA
Svc ticket
Servers (File Server, Exchange, …)

36. Troubleshooting Kerberos
Diagnostic/Tracing (CDF)
MF_DLL_CtxAuth
MF_DLL_CtxKerbProvider
MF_DLL_Cutildll
MF_Library_CtxSSPI
Debugging
Debug Winlogon process
Debug Wfica32.exe on client side
Analysis Network trace for Kerberos related packets
Additional info
Use CDF Control
Verify Service Principal Name (SPN)
Verify Configuration CTX121918

37. Recap Explicit\Prompt Authentication
Negotiate on Authentication protocol at MS layer.
Smartcard Authentication
XenDesktop and XenApp has similar architecture
New Citrix services for Cert Enumeration, SC removal policy, etc
Pass-through Authentication
Credential capturing (SSONSVR) or Kerberos Ticket
Kerberos Authentication
No Back-end NTLM support. Credential prompt

38. Authentication Function
For More Information
Whitepapers default.asp
Windows 2000 Kerberos Authentication Microsoft
Windows 2000 Kerberos Interoperability
Authentication Function

39. Before you leave… Recommended related breakout sessions:
SUM509 - Integrating single sign-on and smart card authentication with Access Gateway Enterprise Edition
Session surveys are available online at 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