Download
1 / 40
400 likes | 1.02k Views
Authentication at WI:Explicit AuthenticationPass-through AuthenticationSmart Card AuthenticationAnonymous AuthenticationKerberos Authentication. Agenda. Support for several authentication methodsSmart cards, client certificates, RSA SecurID, etc.Support for OS and non-OS credentials storesOS
E N D
1. Authentication on XenApp & XenDesktop Lalit Kaushal
Escalation Engineer EMEA
2. Authentication at WI:
Explicit Authentication
Pass-through Authentication
Smart Card Authentication
Anonymous Authentication
Kerberos Authentication Agenda
3. 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. Authentication in XenApp\XenDesktop
4. 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 doesnt 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 clients 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 users Security ID (SID), group membership SIDs, and users rights on the domain.
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 doesnt 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 clients 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 users Security ID (SID), group membership SIDs, and users rights on the domain.
5. In addition to allowing receiving services to check the users identity, Kerberos tickets can be used by Windows services to impersonate the identity of the user. Instead of using the services own identity, a service can use the clients identity in order to access local OS resources (e.g. files). This way, the OS can check access control based on the original callers identity, and not on the services 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 callers original identity. This is called Kerberos delegation (transitive trust). It allows a users 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.In addition to allowing receiving services to check the users identity, Kerberos tickets can be used by Windows services to impersonate the identity of the user. Instead of using the services own identity, a service can use the clients identity in order to access local OS resources (e.g. files). This way, the OS can check access control based on the original callers identity, and not on the services 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 callers original identity. This is called Kerberos delegation (transitive trust). It allows a users 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. All you ever wanted to know about Kerberos: http://technet.microsoft.com/en-us/library/cc772815.aspx
Kerberos in Windows 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 andfor Windows clientsSIDs) 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.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 andfor Windows clientsSIDs) 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.
7. Explicit or Prompt Authentication
8. Username, password and domain
Optionally includes two-factor authentication such as RSA SecurID
Encoded credentials passed to XML service
Explicit or Prompt Authentication 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.
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
10. Explicit Auth in XD 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.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.
12. Pass-through Authentication
13. 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
Pass-Through?
14. 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
Pass-Through Authentication
15. Windows Identity credentials
IWA browser to Web server
Users SIDs sent to XML service
Client handles authentication to ICA server Pass-Through Authentication 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 users 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.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 users 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 Authentication Pass-through authentication allows the online plug-in to access a users 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.Pass-through authentication allows the online plug-in to access a users 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.
18. SmartCard Authentication
19. ATM card is the most common example
You wouldnt use just one factor to protect your money
Multiple factors
Something you know
Your PIN
Something you have
Your card What is Multi-Factor Authentication?
20. Smart Cards
2 Factor Authentication
Something you know
Something you have
Biometrics
Fingerprint readers
Retinal Scan
Facial Recognition
Biopassword
Keystroke dynamics
Proximity What is Multifactor Authentication? 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. 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 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 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthn/security/smart_card_authentication.asp
The basic components of the smart card subsystem are based on PC/SC standards (see the specifications at http://www.pcscworkgroup.com/). 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.
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 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthn/security/smart_card_authentication.asp
The basic components of the smart card subsystem are based on PC/SC standards (see the specifications at http://www.pcscworkgroup.com/). 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.
22. Smart Card Infrastructure 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 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthn/security/smart_card_authentication.asp
The basic components of the smart card subsystem are based on PC/SC standards (see the specifications at http://www.pcscworkgroup.com/). 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.
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 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthn/security/smart_card_authentication.asp
The basic components of the smart card subsystem are based on PC/SC standards (see the specifications at http://www.pcscworkgroup.com/). 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.
23. Smart Card Infrastructure 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 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthn/security/smart_card_authentication.asp
The basic components of the smart card subsystem are based on PC/SC standards (see the specifications at http://www.pcscworkgroup.com/). 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.
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 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthn/security/smart_card_authentication.asp
The basic components of the smart card subsystem are based on PC/SC standards (see the specifications at http://www.pcscworkgroup.com/). 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.
24. 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) (http://go.microsoft.com/fwlink/?LinkId=93352)).
If the authentication is performed using a certificate with a key usage of digital signature, then the pre-authentication data consists of the users 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 users 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 users account object in the active directory, as detailed in Client Certificate Mappings, and uses the users certificate to verify the signature.
11. The KDC validates the users 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 users 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 users 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 TGTs 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)
Users 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 4556. 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 4556. 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 users 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 KDCs signature by the construction of a certification path from the KDCs certificate to a trusted root CA, and then it uses the KDCs 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 users 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 users 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 users 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 (http://go.microsoft.com/fwlink/?LinkID=27175).
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.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) (http://go.microsoft.com/fwlink/?LinkId=93352)).
If the authentication is performed using a certificate with a key usage of digital signature, then the pre-authentication data consists of the users 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 users 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 users account object in the active directory, as detailed in Client Certificate Mappings, and uses the users certificate to verify the signature.
11. The KDC validates the users 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 users 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 users 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 TGTs 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)
Users 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 4556. 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 4556. 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 users 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 KDCs signature by the construction of a certification path from the KDCs certificate to a trusted root CA, and then it uses the KDCs 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 users 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 users 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 users 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 (http://go.microsoft.com/fwlink/?LinkID=27175).
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. Client certificate and PIN credentials
Certificate authentication browser to web server
Users SIDs sent to XML service
Client handles authentication to ICA server Smart Card Authentication IIS performs Certificate authentication (i.e. usingsmart cards) with IE/Firefox to find out the username
The Windows Identity is passed to WI, which then figures out the users SIDs
The users 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 users PIN.
Complicated infrastructure:
Domain Controller
Certificate Authority
Web Interface server with SSL and client certificate mapping enabled
ICA server (XenApp/XenDesktop)
Client deviceIIS performs Certificate authentication (i.e. usingsmart cards) with IE/Firefox to find out the username
The Windows Identity is passed to WI, which then figures out the users SIDs
The users 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 users PIN.
Complicated infrastructure:
Domain Controller
Certificate Authority
Web Interface server with SSL and client certificate mapping enabled
ICA server (XenApp/XenDesktop)
Client device
26.
28. Anonymous Authentication
29. No credentials
XenApp only
Published resources must be explicitly configured for Anonymous authentication Anonymous Authentication
30. Kerberos Authentication
31. 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 Kerberos Authentication Describe Kerberos logon in goldfish:
Before, captured password to do single sign-on
After, uses Kerberos in Windows to do single sign-on
Describe Kerberos logon in goldfish:
Before, captured password to do single sign-on
After, uses Kerberos in Windows to do single sign-on
32.
Kerberos Authentication Support You still need to configure delegation as per the ADFS section of the Web Interface administrators guide pg 163-166
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.
You still need to configure delegation as per the ADFS section of the Web Interface administrators guide pg 163-166
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 You still need to configure delegation as per the ADFS section of the Web Interface administrators guide pg 163-166
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.
You still need to configure delegation as per the ADFS section of the Web Interface administrators guide pg 163-166
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
35. Kerberos Auth in XenDesktop
38. Whitepapers http://www.microsoft.com/windows/server/Technical/security/default.asp
Windows 2000 Kerberos Authentication Microsoft
Windows 2000 Kerberos Interoperability
Authentication Function
http://msdn.microsoft.com/en-us/library/aa374731(v=VS.85).aspx For More Information
39. Recommended related breakout sessions:
SUM509 - Integrating single sign-on and smart card authentication with Access Gateway Enterprise Edition
Session surveys are available online at www.citrixsummit.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 Before you leave
