Jay Tomlin Sr. Technology Specialist Mgr NA Field Readiness

Jay Tomlin Sr. Technology Specialist Mgr NA Field Readiness
Citrix and ADFS Leverage Active Directory Federation Services in a Presentation Server Environment Thanks also to following Citrites who assisted with the development of this presentation: Ben Walters Michael Bednarek Nick Wise David Halls Andrew Innes Jay Tomlin Sr. Technology Specialist Mgr NA Field Readiness 08 December 2006

Copyright & Disclaimer
Copyright © 2006, Citrix Unpublished work of Citrix. All Rights Reserved. This work is an unpublished work and contains confidential, proprietary, and trade secret information of Citrix. Access to this work is restricted to Citrix employees who have a need to know to perform tasks within the scope of their assignments, or to authorized organizations under a Non-Disclosure Agreement. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability. General Disclaimer This document is not to be construed as a promise by any participating company to develop, deliver, or market a product. Citrix makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Citrix, reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes.

Introduction to Active Directory Federation Services
Agenda Introduction to Active Directory Federation Services Web Interface ADFS Integration Configuration Walk-through Alternative Deployment Scenarios Q&A

Part 1: Introduction to ADFS

What is Federation? A set of standards-based technology & IT processes to facilitate distributed identification, authentication & authorization across boundaries (security, departmental, organizational or platform). Key Idea: Federated Identity Management provides the security infrastructure required in developing connected systems. Define Federation as <stated above> Emphasize Business Process Emphasize the need for access across organization and security boundaries. Talk about challenges within the organization and application of federation inside e.g. Between two forests (when you want to provide select access) Mergers/Acquisition Scenario Organization silos (e.g. separation based on Geography or business function) Users: Fewer passwords, more productivity IT: Centralized, automated, delegated user management Dev: Leveraged, outsourced service infrastructure

EMPLOYEES and your APPLICATIONS REMOTE and VIRTUAL EMPLOYEES
Motivations for Federation SUPPLIERS CUSTOMERS Customer satisfaction & customer intimacy Cost competitiveness Reach, personalization EMPLOYEES and your APPLICATIONS Collaboration Outsourcing Faster business cycles Process automation Value chain REMOTE and VIRTUAL EMPLOYEES PARTNERS Today you have an imperative to extend your business systems (both applications and user management systems) so that they leverage the internet to service your “virtual enterprise.” Extending systems to customers, remote/contract employees, and business partners makes your organization more agile – but at the same time, represents security risks, as well as administrative difficulties. Similarly, there’s also a need to give our internal user population access to resources that sit in other people’s security environments. Employee portals exist largely as an aggregator not only of internal data sources, but of applications from outside our companies, that when combined with our internal IT resources, make a complete system. M&A, joint venture Mobile/global workforce Flexible/temp workforce

Federation Benefits Better Access Experience
Single sign-on across networks & organizational boundaries Increased Security & Simpler Administration Heightened identity assurance No passwords involved Account de-activation is handled by the account partner Account partner can easily be disabled at the organizational level Strong authentication such as user certificates or OTP tokens can be layered on top of federation claim Enterprises today are being asked to extend operational resources to greater numbers of individuals — including partners, suppliers and customers — even as they face the critical need to streamline operations and reduce costs. Many are finding the management of large numbers of external identities difficult and risky, and would like to exploit a trust relationship with a partner, or a third party, as a way of managing identity-related risks

Federation Solution Components
Separates authentication and authorization User is authenticated in their home domain Claims about the users identity are signed and sent to the web server The web server validates incoming claims against its list of account partners Domain A (Account Partner) Domain B (Resource Partner) Federation Service Federation Service Client This deployment is possible when both domains are on the same network, for example when different divisions within a company have their own domain, or when Company A acquires Company B and joins the two companies’ networks. Web Server with ADFS Web Agent

Resource Federation Service Account Federation Service
Federation Libation Account Partner Resource Partner User Principals Resource Federation Service Account Federation Service DMV Bartender Resource Identity assertion

How ADFS works User points to web server
User is redirected to the resource federation server User chooses their home realm User is redirected to their home account federation server for authentication User is redirected back to resource federation server with assertion set Assertion is validated and user is sent back to web server Note: User is not aware of all this complexity. Seamless SSO for the user.

Pseudo Identity Assertion
<SAML> <TimeStamp value=" :31:02GMT" ValidTo=" :31:02"/> <Issuer id="urn:federation:acmecorp"> <Signature>F8/PoUcHh+rx/XfvC0vv0=</Signature> </Issuer> </SAML> Identity assertion generated and digitally signed by the account federation server Additional custom claims can be added easily Timestamp is important—clocks must be synchronized between organizations Resource federation consumes this claim and validates the signature

Federation Process in Detail
User points to web server ADFS Web Agent redirects user to the Resource Partner Federation Service. User selects their home realm from a list of Account Partners Domain A (Account Partner) Domain B (Resource Partner) Federation Service Federation Service 2 Client 1 This deployment is possible when both domains are on the same network, for example when different divisions within a company have their own domain, or when Company A acquires Company B and joins the two companies’ networks. Note: Steps 1 and 2 can be bypassed by using a special URL that sends the user directly to their local federation service with the external application URL in a URL query parameter. For example: Web Server with ADFS Web Agent All connections are HTTPS

Home Realm Discovery The resource partner may have many account partners, so users need to identify which organization they belong to This page can be customized or bypassed altogether by giving users a special URL that includes their realm info User’s choice is remembered as a cookie; next time they would not see the home realm discovery page

User points to web server ADFS Web Agent redirects user to the Resource Partner Federation Service. User selects their home realm from a list of Account Partners User is redirected to their local Federation Service, which authenticates the user and produces an identity claim Client is redirected back to the resource federation server with identity claim set as POST data. Resource Federation Server validates the account claim and then adds a new local identity claim. Domain A (Account Partner) Domain B (Resource Partner) Federation Service Federation Service 3 4 2 Client 1 This deployment is possible when both domains are on the same network, for example when different divisions within a company have their own domain, or when Company A acquires Company B and joins the two companies’ networks. Note: Steps 1 and 2 can be bypassed by using a special URL that sends the user directly to their local federation service with the external application URL in a URL query parameter. For example: Web Server with ADFS Web Agent All connections are HTTPS

Client is redirected back to the web application Return URL with an identity claim now signed by the resource federation server Web server obtains public key from federation service if necessary and verifies digital signature on the claim ADFS Web Agent produces a valid Kerberos token able to access resources on the web server Domain A (Account Partner) Domain B (Resource Partner) Federation Service Federation Service 6 Client 5 7 This deployment is possible when both domains are on the same network, for example when different divisions within a company have their own domain, or when Company A acquires Company B and joins the two companies’ networks. Web Server with ADFS Web Agent All connections are HTTPS

Federation Service Proxy (FS-P)
Federation Service Proxy relays messages to the resource partner federation service Eliminates the need to expose the federation service to the Internet FS-P need not be a domain member FS-P contacts Federation Service via HTTPS with Client Certificate authentication Domain A (Account Partner) DMZ Domain B (Resource Partner) Federation Service Federation Service Proxy Federation Service Client This deployment is possible when both domains are on the same network, for example when different divisions within a company have their own domain, or when Company A acquires Company B and joins the two companies’ networks. Web Server

How to install ADFS on W2K3 R2
Add/Remove Windows Components:

Synchronicity Federation servers at the account partner and resource partner must have their clocks set within 5 minutes of each other For best results, use an Internet time server such as time.nist.gov Different time zones don’t matter

Certificates Everywhere!
Account Partner Account Partner SSL and token-signing certificate + private key Account Partner root certificate Web Server SSL certificate + private key Web Server root certificate Resource Partner SSL and token-signing certificate + private key Resource Partner root certificate FS-P client authentication certificate + private key FS-P client authentication certificate (w/o private key) Client Federation Service Resource Partner Federation Service Proxy Web Server Certificate management is simplified greatly if both organizations use a well-known pubilc commercial CA for all certificates. Federation Services on both sides need to be able to validate CRLs of all certificates, which makes it difficult to use a private certificate authority. Federation Service

Part 2: Web Interface and ADFS

Citrix Announces Federation Interoperability
Citrix extends federation benefits To rich applications (e.g. SAP R/3 client, mainframe emulator) To file shares To web apps inside the firewall Citrix increases federation security Provides greater control over data usage Allows for increased identity assurance Facilitates access logging and auditing across organizations

Only Citrix can Federate to Windows Applications
Identity federation was designed for web applications only The ADFS support in Web Interface bridges the gap between web applications and Windows or host-based applications Citrix uniquely enables federated SSO to Web, Windows and host-based applications

The User’s Experience Click on a link to the ADFS WI site
Icons appear without prompting the user Applications launch without prompting the user

WI ADFS App Enumeration
User points to WI ADFS Web Agent redirects user to the Resource Partner Federation Service. User selects their home realm from a list of Account Partners User is redirected to their local Federation Service, which authenticates the user and produces an identity claim Client is redirected back to the resource federation server with identity claim set as POST data. Resource Federation Server validates the account claim and then adds a new local identity claim. Domain A (Account Partner) Domain B (CPS Domain) Federation Service Federation Service 3 2 4 Client WI 4.5 w/ADFS Web Agent 1 This deployment is possible when both domains are on the same network, for example when different divisions within a company have their own domain, or when Company A acquires Company B and joins the two companies’ networks. Presentation Servers Access Gateway

WI ADFS App Enumeration
Client is redirected back to the WI Return URL with an identity claim now signed by the resource federation server ADFS Web Agent on WI server obtains public key from federation service if necessary and verifies digital signature on the claim ADFS Web Agent produces a valid Kerberos token for the domain B user shadow account, for whom Presentation Server applications have been published WI uses the Kerberos token to authenticate to the CPS XML Service (requires delegation rights). CPS returns a list of applications to Web Interface Domain A (Account Partner) Domain B (CPS Domain) Federation Service Federation Service 6 Client WI 4.5 w/ADFS Web Agent 5 7 8 This deployment is possible when both domains are on the same network, for example when different divisions within a company have their own domain, or when Company A acquires Company B and joins the two companies’ networks. Presentation Servers Access Gateway

Domain A (Account Partner)
WI ADFS App Launch User clicks app icon, CPS Data Collector determines least-busy server Kerberos ticket for shadow account forwarded to XML broker Kerberos ticket forwarded from XML broker to least-busy server in exchange for WI logon ticket WI generates ICA file with logon ticket; also negotiates AG ticket from STA if necessary. WI sends ICA file to user. Client receives ICA file and connects to CPS (through CAG if necessary). WI logon ticket exchanged for Kerberos token at target server Domain A (Account Partner) Domain B (CPS Domain) Federation Service Federation Service Client 12 WI 4.5 w/ADFS Web Agent 9 10 This deployment is possible when both domains are on the same network, for example when different divisions within a company have their own domain, or when Company A acquires Company B and joins the two companies’ networks. 13 Presentation Servers 11 Access Gateway

Requirements WI and Federation servers must be W2K3 R2
CPS 4.5 or 4.0 with hotfix rollup #2 or later Enable “Trust requests sent to the XML Service” Domain functional level must be native Win2K3 Domain Controllers need not be upgraded to R2 Alternate UPN suffix must be added to the resource domain, and shadow accounts must be created using the partner’s UPN suffix Usernames and passwords are not known by the user

Constraints Web Interface server must be a domain member
XML service must be delivered via IIS port sharing Revocation information for all certificates must be accessible by all parties Best practice: Use a commercial CA

Part 3: Configuration Walk-through

Demo Environment DMZ Gemini.ctx (Resource Partner)
CitrixTraining.com (Account Partner) GemFSP.company.com Federation Service Proxy CitrixDC1 Domain Controller CitrixFSA Federation Service GemFSR Federation Service JAYTISA Domain Controller AdfsWI.company.com WI 4.5 ADFS Web Agent Gemini.ctx Member This deployment is possible when both domains are on the same network, for example when different divisions within a company have their own domain, or when Company A acquires Company B and joins the two companies’ networks. As shown here, this deployment works best when both domains are part of a single organization or connected by a private WAN. Kerberos S4U needs to query LDAP to find out its UPN. COLORADO CPS 4.0 STA JOEUSERPC Win2K Client Access.company.com Access Gateway

ADFS MMC Snap-in at the Account Partner (CitrixFSA)
Enable Active Directory as an Account Store Define resource partner (Gemini.ctx) Endpoint URL is the resource partner’s FS or FS-P server

ADFS MMC Snap-in at the Resource Partner (GemFSR)
Enable Active Directory as an Account Store Define CitrixTraining as an Account Partner by importing their Trust Policy file Endpoint URL is the internal URL of the Account Partner’s federation service (CitrixFSA)

ADFS MMC Snap-in at the Resource Partner (GemFSR)
Change to “Resource accounts exist for all users”

Raise Domain Functional Level
Domain functional level at the resource partner must be native Windows 2003 All domain controllers in the domain must be Windows Server 2003 or later

Configure Delegation on the Web Interface servers
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 CPS XML Broker

Configure Delegation on the Presentation servers
Edit the Delegation properties of each Presentation Server computer object in Active Directory Trust this computer for delegation using Kerberos only Add the HOST service for this computer; Add the cifs and ldap services for domain controllers; Add cifs for any file servers users will access This is painful for large farms. Would be nice to have a tool that automates this.

Add a UPN Suffix for each Account Partner
In the Resource Domain, run the Active Directory Domains and Trusts snap-in Select “Active Directory Domains and Trusts” and view Properties Add the account partner’s UPN suffix as an alternate UPN suffix

Create Shadow Accounts for Partner Users
For each account partner user, create a shadow account in the resource partner domain Use the account partner’s UPN suffix Set the password to anything—the user does not need to know it Publish CPS applications to the shadow accounts As the partner hires new people they need to have new shadow accounts created No need to worry about deleting shadow accounts when employees leave the account partner

Create an ADFS-enabled WI site
During the Create Site task, choose to use ADFS integration The ADFS web service refers to the resource partner federation service on the same network as the Presentation Servers Use host names or FQDNs for the XML Broker addresses, no IP addresses

Define Web Interface Site as an Application at the Resource Partner
Define Web Interface as an Application Application URL is the external URL of the WI ADFS Site

Troubleshooting: No applications enumerated
Possible causes: XML Broker is not integrated into IIS Web Interface server is not trusted for delegation XML Broker address is configured as an IP address in WI ADFS Web Agent is installed on CPS, enabled for /Scripts

Part 4: Deployment Scenarios

Minimal CPS Deployment
Domain A (Account Partner) Domain B (Resource Partner) Federation Service Federation Service Presentation Servers Client Web Interface 4.5 ADFS Web Agent This deployment is possible when both domains are on the same network, for example when different divisions within a company have their own domain, or when Company A acquires Company B and joins the two companies’ networks. As shown here, this deployment works best when both domains are part of a single organization or connected by a private WAN.

Federation Service Proxy
Internet Deployment Domain A (Account Partner) DMZ Domain B (Resource Partner) Domain Controller WI 4.5 Federation Service Internet Federation Service Proxy Federation Service Client Note that Access Gateway in this scenario is used for relaying ICA traffic only (Secure Gateway replacement mode) Web Interface 4.5 must be a member of the Resource Partner domain. Kerberos and LDAP traffic must be permitted through the inside firewall. Federation Service Proxy servers need not belong to the domain. Client certificates are used to prove the FSP’s identity to the Federation Service. The Federation Proxy and WI components could be consolidated onto a single server if desired. (Use separate IIS sites.) Presentation Servers Access Gateway

Ports needed by WI and ADFS
CRL Intranet DMZ HTTP :80 Certificate Authority LDAP :389 Kerberos :88 UDP Kerberos :88 TCP Domain Controller HTTPS :443 WI 4.5 Internet HTTPS :443 HTTPS :443 Federation Service Federation Service Proxy Access Gateway Presentation Servers ICA+SSL :443 STA :80 or :443 ICA :1494 CGP :2598 Other ports are needed for NetLogon, GPOs, etc

Partner/Employee shared farm
Employee Domain (Account Partner) DMZ Domain (Resource partner) Partner A (Account Partner) Federation Service Client Federation Service Access Gateway Presentation Servers Partner B (Account Partner) Federation Service Client Client In this example, the WI and Presentation Servers are placed in a DMZ domain that can be accessed by employees on the corporate network as well as partners on the Internet. Multiple account partners may be defined at the DMZ Federation Server. When users first connect, they will be prompted to identify which account organization they belong to, a process called “home realm discovery”. The home realm discovery process can be avoided if necessary by implementing a separate WI+Federation Server pair for each account partner. Web Interface 4.5 Partner C (Account Partner) Federation Service Client Federation Service

Review: Explicit Authentication
A Password 1 password Web Browser WI XML Service B STA & Logon tickets 4 Logon ticket User 2 password C STA & Logon tickets 3 Logon ticket CPS ccticket When a launch request is sent to the XML Service, this is what currently happens: Client of the XML Service sends user’s password to the XML Service to request a launch (NFuse) ticket. XML Service sends the password to the target MPS Server. MPS (ccticket) stores the password, creates a launch ticket to uniquely reference it and sends the ticket back to the XML Service. XML Service passes the launch ticket back to the client of the XML Service. Sometime later, ICA client sends the launch ticket to MPS (CtxGina). CtxGina retrieves the password associated with the launch ticket and uses it to log the user on. I’m adding support for Kerberos authentication to the XML Service and MPS (ccticket). This will replace the need to handle and transmit the user’s password in steps 1 and 2: Client of the XML Service uses SSPI to generate a service ticket and encrypted authenticator (SSPI data) for the XML Service. It sends the SSPI data to the XML Service. The XML Service passes the SSPI data to SSPI to verify the user. It then generates SSPI data for the MPS server and sends it to the MPS server. Alternative deployment: Client of the XML Service generates SSPI data for the MPS server and the XML Service passes it on. MPS (ccticket) passes the SSPI data to SSPI. SSPI authenticates the user and returns a logon token. MPS stores the logon token, creates a launch ticket to uniquely reference it and sends the ticket back to the XML Service. Sometime later, ICA client sends the launch ticket to MPS (CtxGina). MPS (CtxGina) retrieves the logon token associated with the launch ticket and uses it to log the user on. There are a number of possible deployment scenarios in which Kerberos authentication to the XML Service might be used, including the following: Web Interface. User authenticates to WI by typing his password into a Web form. WI uses SSPI to authenticate the user with the XML service and hence MPS. It passes the resulting launch ticket back to the user’s Web browser. Web browser passes the launch ticket to the ICA client. ICA client sends the launch ticket to MPS. The connection may be made via Secure Gateway (SG) but SG doesn’t interfere. If WI is trusted for delegation, the user can authenticate to WI using Integrated Authentication too. ADFS (Microsoft Active Directory Federation Services). ADFS enables users from one organisation to access Web resources in another organisation without having to provide credentials. It does this using SAML and WS-Federation. SAML allows one organization (A) to trust another (B) to authenticate users. Organization B receives an assertion from organization A which says who the user is. ADFS allows users to be mapped onto Windows accounts and impersonated in Web apps. A clear opportunity exits for Citrix to extend this to Windows apps. WI would be configured to use ADFS to impersonate users, and then use SSPI to authenticate the user with the XML service and retrieve a launch ticket. ADFS does not have access to the user’s password so SSPI is required. RSA ClearTrust. Version 5.5 of RSA ClearTrust is able to generate Kerberos tickets for users given just a SecurID passcode. It does this using new Kerberos features in Windows Server 2003 which allow trusted services to generate Kerberos tickets to specified services on a user’s behalf – without requiring access to his Windows password. An XML Service with support for Kerberos authentication would be able to seamlessly integrate with ClearTrust, allowing users access to MPS using just their RSA SecurID token. We should also be able to write our own service which provides the same functionality, which would be good for our customers since ClearTrust is expensive. Note: RSA’s basic product, SecurID Authentication Manager Version 6, provides similar functionality but requires access to Windows passwords. Citrix Web Interface is already adding support for SecurID Authentication Manager Version 6. SAP Portal. The SAP Portal also makes use of the new Windows Server 2003 Kerberos features to enable users to access Windows resources. SAP maintains its own user database and authentication infrastructure. It issues a SAP logon token for users which is valid for a session. When the user accesses a Windows resource (e.g. a Web site running on IIS), it maps the user onto a Windows account and generates an impersonation token which is used to access the resource. SAP doesn’t have access to the user’s Windows password, so SSPI is required. Making the XML Service accept SSPI data would allow it to integrated easily into the SAP portal. References: XML Service Integrated Authentication Engineering Functional Specification (detailed functional spec for my proposed changes), URL TBD Advanced Kerberos Support project home page (my proposed changes come under this project, in the ‘Out of Band Kerberos Authentication’ work package), Active Directory Federation Services: A Path to Federated Identity and Access Management. Kerberos extensions in Windows Server 2003: Exploring S4U Kerberos Extensions in Windows Server 2003, Kerberos Protocol Transition and Constrained Delegation, RSA ClearTrust support for Windows Server 2003 Kerberos extensions, RSA SecurID Version 6 support for Windows, Using SAP Logon Tickets for Single Sign on to Microsoft based web applications. ICA Client Access Gateway CtxGina D STA ticket 5 Logon ticket

WI ADFS sites leverage Kerberos
A ADFS assertion 1 Kerberos data Kerberos Kerberos Web Browser WI XML Service ADFS B STA & Logon tickets 4 Logon ticket User 2 Kerberos data C STA & Logon tickets 3 Logon ticket Kerberos CPS ccticket When a launch request is sent to the XML Service, this is what currently happens: Client of the XML Service sends user’s password to the XML Service to request a launch (NFuse) ticket. XML Service sends the password to the target MPS Server. MPS (ccticket) stores the password, creates a launch ticket to uniquely reference it and sends the ticket back to the XML Service. XML Service passes the launch ticket back to the client of the XML Service. Sometime later, ICA client sends the launch ticket to MPS (CtxGina). CtxGina retrieves the password associated with the launch ticket and uses it to log the user on. I’m adding support for Kerberos authentication to the XML Service and MPS (ccticket). This will replace the need to handle and transmit the user’s password in steps 1 and 2: Client of the XML Service uses SSPI to generate a service ticket and encrypted authenticator (SSPI data) for the XML Service. It sends the SSPI data to the XML Service. The XML Service passes the SSPI data to SSPI to verify the user. It then generates SSPI data for the MPS server and sends it to the MPS server. Alternative deployment: Client of the XML Service generates SSPI data for the MPS server and the XML Service passes it on. MPS (ccticket) passes the SSPI data to SSPI. SSPI authenticates the user and returns a logon token. MPS stores the logon token, creates a launch ticket to uniquely reference it and sends the ticket back to the XML Service. Sometime later, ICA client sends the launch ticket to MPS (CtxGina). MPS (CtxGina) retrieves the logon token associated with the launch ticket and uses it to log the user on. There are a number of possible deployment scenarios in which Kerberos authentication to the XML Service might be used, including the following: Web Interface. User authenticates to WI by typing his password into a Web form. WI uses SSPI to authenticate the user with the XML service and hence MPS. It passes the resulting launch ticket back to the user’s Web browser. Web browser passes the launch ticket to the ICA client. ICA client sends the launch ticket to MPS. The connection may be made via Secure Gateway (SG) but SG doesn’t interfere. If WI is trusted for delegation, the user can authenticate to WI using Integrated Authentication too. ADFS (Microsoft Active Directory Federation Services). ADFS enables users from one organisation to access Web resources in another organisation without having to provide credentials. It does this using SAML and WS-Federation. SAML allows one organization (A) to trust another (B) to authenticate users. Organization B receives an assertion from organization A which says who the user is. ADFS allows users to be mapped onto Windows accounts and impersonated in Web apps. A clear opportunity exits for Citrix to extend this to Windows apps. WI would be configured to use ADFS to impersonate users, and then use SSPI to authenticate the user with the XML service and retrieve a launch ticket. ADFS does not have access to the user’s password so SSPI is required. RSA ClearTrust. Version 5.5 of RSA ClearTrust is able to generate Kerberos tickets for users given just a SecurID passcode. It does this using new Kerberos features in Windows Server 2003 which allow trusted services to generate Kerberos tickets to specified services on a user’s behalf – without requiring access to his Windows password. An XML Service with support for Kerberos authentication would be able to seamlessly integrate with ClearTrust, allowing users access to MPS using just their RSA SecurID token. We should also be able to write our own service which provides the same functionality, which would be good for our customers since ClearTrust is expensive. Note: RSA’s basic product, SecurID Authentication Manager Version 6, provides similar functionality but requires access to Windows passwords. Citrix Web Interface is already adding support for SecurID Authentication Manager Version 6. SAP Portal. The SAP Portal also makes use of the new Windows Server 2003 Kerberos features to enable users to access Windows resources. SAP maintains its own user database and authentication infrastructure. It issues a SAP logon token for users which is valid for a session. When the user accesses a Windows resource (e.g. a Web site running on IIS), it maps the user onto a Windows account and generates an impersonation token which is used to access the resource. SAP doesn’t have access to the user’s Windows password, so SSPI is required. Making the XML Service accept SSPI data would allow it to integrated easily into the SAP portal. References: XML Service Integrated Authentication Engineering Functional Specification (detailed functional spec for my proposed changes), URL TBD Advanced Kerberos Support project home page (my proposed changes come under this project, in the ‘Out of Band Kerberos Authentication’ work package), Active Directory Federation Services: A Path to Federated Identity and Access Management. Kerberos extensions in Windows Server 2003: Exploring S4U Kerberos Extensions in Windows Server 2003, Kerberos Protocol Transition and Constrained Delegation, RSA ClearTrust support for Windows Server 2003 Kerberos extensions, RSA SecurID Version 6 support for Windows, Using SAP Logon Tickets for Single Sign on to Microsoft based web applications. ICA Client Access Gateway CtxGina D STA ticket 5 Logon ticket

Other ways to get a Kerberos token
A IIS Integrated Windows Authentication 1 Kerberos data Kerberos Kerberos Web Browser WI XML Service NTLM B STA & Logon tickets 4 Logon ticket User 2 Kerberos data C STA & Logon tickets 3 Logon ticket Kerberos CPS ccticket When a launch request is sent to the XML Service, this is what currently happens: Client of the XML Service sends user’s password to the XML Service to request a launch (NFuse) ticket. XML Service sends the password to the target MPS Server. MPS (ccticket) stores the password, creates a launch ticket to uniquely reference it and sends the ticket back to the XML Service. XML Service passes the launch ticket back to the client of the XML Service. Sometime later, ICA client sends the launch ticket to MPS (CtxGina). CtxGina retrieves the password associated with the launch ticket and uses it to log the user on. I’m adding support for Kerberos authentication to the XML Service and MPS (ccticket). This will replace the need to handle and transmit the user’s password in steps 1 and 2: Client of the XML Service uses SSPI to generate a service ticket and encrypted authenticator (SSPI data) for the XML Service. It sends the SSPI data to the XML Service. The XML Service passes the SSPI data to SSPI to verify the user. It then generates SSPI data for the MPS server and sends it to the MPS server. Alternative deployment: Client of the XML Service generates SSPI data for the MPS server and the XML Service passes it on. MPS (ccticket) passes the SSPI data to SSPI. SSPI authenticates the user and returns a logon token. MPS stores the logon token, creates a launch ticket to uniquely reference it and sends the ticket back to the XML Service. Sometime later, ICA client sends the launch ticket to MPS (CtxGina). MPS (CtxGina) retrieves the logon token associated with the launch ticket and uses it to log the user on. There are a number of possible deployment scenarios in which Kerberos authentication to the XML Service might be used, including the following: Web Interface. User authenticates to WI by typing his password into a Web form. WI uses SSPI to authenticate the user with the XML service and hence MPS. It passes the resulting launch ticket back to the user’s Web browser. Web browser passes the launch ticket to the ICA client. ICA client sends the launch ticket to MPS. The connection may be made via Secure Gateway (SG) but SG doesn’t interfere. If WI is trusted for delegation, the user can authenticate to WI using Integrated Authentication too. ADFS (Microsoft Active Directory Federation Services). ADFS enables users from one organisation to access Web resources in another organisation without having to provide credentials. It does this using SAML and WS-Federation. SAML allows one organization (A) to trust another (B) to authenticate users. Organization B receives an assertion from organization A which says who the user is. ADFS allows users to be mapped onto Windows accounts and impersonated in Web apps. A clear opportunity exits for Citrix to extend this to Windows apps. WI would be configured to use ADFS to impersonate users, and then use SSPI to authenticate the user with the XML service and retrieve a launch ticket. ADFS does not have access to the user’s password so SSPI is required. RSA ClearTrust. Version 5.5 of RSA ClearTrust is able to generate Kerberos tickets for users given just a SecurID passcode. It does this using new Kerberos features in Windows Server 2003 which allow trusted services to generate Kerberos tickets to specified services on a user’s behalf – without requiring access to his Windows password. An XML Service with support for Kerberos authentication would be able to seamlessly integrate with ClearTrust, allowing users access to MPS using just their RSA SecurID token. We should also be able to write our own service which provides the same functionality, which would be good for our customers since ClearTrust is expensive. Note: RSA’s basic product, SecurID Authentication Manager Version 6, provides similar functionality but requires access to Windows passwords. Citrix Web Interface is already adding support for SecurID Authentication Manager Version 6. SAP Portal. The SAP Portal also makes use of the new Windows Server 2003 Kerberos features to enable users to access Windows resources. SAP maintains its own user database and authentication infrastructure. It issues a SAP logon token for users which is valid for a session. When the user accesses a Windows resource (e.g. a Web site running on IIS), it maps the user onto a Windows account and generates an impersonation token which is used to access the resource. SAP doesn’t have access to the user’s Windows password, so SSPI is required. Making the XML Service accept SSPI data would allow it to integrated easily into the SAP portal. References: XML Service Integrated Authentication Engineering Functional Specification (detailed functional spec for my proposed changes), URL TBD Advanced Kerberos Support project home page (my proposed changes come under this project, in the ‘Out of Band Kerberos Authentication’ work package), Active Directory Federation Services: A Path to Federated Identity and Access Management. Kerberos extensions in Windows Server 2003: Exploring S4U Kerberos Extensions in Windows Server 2003, Kerberos Protocol Transition and Constrained Delegation, RSA ClearTrust support for Windows Server 2003 Kerberos extensions, RSA SecurID Version 6 support for Windows, Using SAP Logon Tickets for Single Sign on to Microsoft based web applications. ICA Client Access Gateway CtxGina D STA ticket 5 Logon ticket

Other ways to get a Kerberos token
A IIS Certificate Mapping 1 Kerberos data Kerberos Kerberos Web Browser WI XML Service Certificate Mapping B STA & Logon tickets 4 Logon ticket User 2 Kerberos data C STA & Logon tickets 3 Logon ticket Kerberos CPS ccticket When a launch request is sent to the XML Service, this is what currently happens: Client of the XML Service sends user’s password to the XML Service to request a launch (NFuse) ticket. XML Service sends the password to the target MPS Server. MPS (ccticket) stores the password, creates a launch ticket to uniquely reference it and sends the ticket back to the XML Service. XML Service passes the launch ticket back to the client of the XML Service. Sometime later, ICA client sends the launch ticket to MPS (CtxGina). CtxGina retrieves the password associated with the launch ticket and uses it to log the user on. I’m adding support for Kerberos authentication to the XML Service and MPS (ccticket). This will replace the need to handle and transmit the user’s password in steps 1 and 2: Client of the XML Service uses SSPI to generate a service ticket and encrypted authenticator (SSPI data) for the XML Service. It sends the SSPI data to the XML Service. The XML Service passes the SSPI data to SSPI to verify the user. It then generates SSPI data for the MPS server and sends it to the MPS server. Alternative deployment: Client of the XML Service generates SSPI data for the MPS server and the XML Service passes it on. MPS (ccticket) passes the SSPI data to SSPI. SSPI authenticates the user and returns a logon token. MPS stores the logon token, creates a launch ticket to uniquely reference it and sends the ticket back to the XML Service. Sometime later, ICA client sends the launch ticket to MPS (CtxGina). MPS (CtxGina) retrieves the logon token associated with the launch ticket and uses it to log the user on. There are a number of possible deployment scenarios in which Kerberos authentication to the XML Service might be used, including the following: Web Interface. User authenticates to WI by typing his password into a Web form. WI uses SSPI to authenticate the user with the XML service and hence MPS. It passes the resulting launch ticket back to the user’s Web browser. Web browser passes the launch ticket to the ICA client. ICA client sends the launch ticket to MPS. The connection may be made via Secure Gateway (SG) but SG doesn’t interfere. If WI is trusted for delegation, the user can authenticate to WI using Integrated Authentication too. ADFS (Microsoft Active Directory Federation Services). ADFS enables users from one organisation to access Web resources in another organisation without having to provide credentials. It does this using SAML and WS-Federation. SAML allows one organization (A) to trust another (B) to authenticate users. Organization B receives an assertion from organization A which says who the user is. ADFS allows users to be mapped onto Windows accounts and impersonated in Web apps. A clear opportunity exits for Citrix to extend this to Windows apps. WI would be configured to use ADFS to impersonate users, and then use SSPI to authenticate the user with the XML service and retrieve a launch ticket. ADFS does not have access to the user’s password so SSPI is required. RSA ClearTrust. Version 5.5 of RSA ClearTrust is able to generate Kerberos tickets for users given just a SecurID passcode. It does this using new Kerberos features in Windows Server 2003 which allow trusted services to generate Kerberos tickets to specified services on a user’s behalf – without requiring access to his Windows password. An XML Service with support for Kerberos authentication would be able to seamlessly integrate with ClearTrust, allowing users access to MPS using just their RSA SecurID token. We should also be able to write our own service which provides the same functionality, which would be good for our customers since ClearTrust is expensive. Note: RSA’s basic product, SecurID Authentication Manager Version 6, provides similar functionality but requires access to Windows passwords. Citrix Web Interface is already adding support for SecurID Authentication Manager Version 6. SAP Portal. The SAP Portal also makes use of the new Windows Server 2003 Kerberos features to enable users to access Windows resources. SAP maintains its own user database and authentication infrastructure. It issues a SAP logon token for users which is valid for a session. When the user accesses a Windows resource (e.g. a Web site running on IIS), it maps the user onto a Windows account and generates an impersonation token which is used to access the resource. SAP doesn’t have access to the user’s Windows password, so SSPI is required. Making the XML Service accept SSPI data would allow it to integrated easily into the SAP portal. References: XML Service Integrated Authentication Engineering Functional Specification (detailed functional spec for my proposed changes), URL TBD Advanced Kerberos Support project home page (my proposed changes come under this project, in the ‘Out of Band Kerberos Authentication’ work package), Active Directory Federation Services: A Path to Federated Identity and Access Management. Kerberos extensions in Windows Server 2003: Exploring S4U Kerberos Extensions in Windows Server 2003, Kerberos Protocol Transition and Constrained Delegation, RSA ClearTrust support for Windows Server 2003 Kerberos extensions, RSA SecurID Version 6 support for Windows, Using SAP Logon Tickets for Single Sign on to Microsoft based web applications. ICA Client Access Gateway CtxGina D STA ticket 5 Logon ticket

RSA Access Manager with Protocol Transition
A RSA Passcode 1 Kerberos data Kerberos Kerberos Web Browser WI XML Service RSA ClearTrust B STA & Logon tickets 4 Logon ticket User 2 Kerberos data C STA & Logon tickets 3 Logon ticket Kerberos CPS ccticket When a launch request is sent to the XML Service, this is what currently happens: Client of the XML Service sends user’s password to the XML Service to request a launch (NFuse) ticket. XML Service sends the password to the target MPS Server. MPS (ccticket) stores the password, creates a launch ticket to uniquely reference it and sends the ticket back to the XML Service. XML Service passes the launch ticket back to the client of the XML Service. Sometime later, ICA client sends the launch ticket to MPS (CtxGina). CtxGina retrieves the password associated with the launch ticket and uses it to log the user on. I’m adding support for Kerberos authentication to the XML Service and MPS (ccticket). This will replace the need to handle and transmit the user’s password in steps 1 and 2: Client of the XML Service uses SSPI to generate a service ticket and encrypted authenticator (SSPI data) for the XML Service. It sends the SSPI data to the XML Service. The XML Service passes the SSPI data to SSPI to verify the user. It then generates SSPI data for the MPS server and sends it to the MPS server. Alternative deployment: Client of the XML Service generates SSPI data for the MPS server and the XML Service passes it on. MPS (ccticket) passes the SSPI data to SSPI. SSPI authenticates the user and returns a logon token. MPS stores the logon token, creates a launch ticket to uniquely reference it and sends the ticket back to the XML Service. Sometime later, ICA client sends the launch ticket to MPS (CtxGina). MPS (CtxGina) retrieves the logon token associated with the launch ticket and uses it to log the user on. There are a number of possible deployment scenarios in which Kerberos authentication to the XML Service might be used, including the following: Web Interface. User authenticates to WI by typing his password into a Web form. WI uses SSPI to authenticate the user with the XML service and hence MPS. It passes the resulting launch ticket back to the user’s Web browser. Web browser passes the launch ticket to the ICA client. ICA client sends the launch ticket to MPS. The connection may be made via Secure Gateway (SG) but SG doesn’t interfere. If WI is trusted for delegation, the user can authenticate to WI using Integrated Authentication too. ADFS (Microsoft Active Directory Federation Services). ADFS enables users from one organisation to access Web resources in another organisation without having to provide credentials. It does this using SAML and WS-Federation. SAML allows one organization (A) to trust another (B) to authenticate users. Organization B receives an assertion from organization A which says who the user is. ADFS allows users to be mapped onto Windows accounts and impersonated in Web apps. A clear opportunity exits for Citrix to extend this to Windows apps. WI would be configured to use ADFS to impersonate users, and then use SSPI to authenticate the user with the XML service and retrieve a launch ticket. ADFS does not have access to the user’s password so SSPI is required. RSA ClearTrust. Version 5.5 of RSA ClearTrust is able to generate Kerberos tickets for users given just a SecurID passcode. It does this using new Kerberos features in Windows Server 2003 which allow trusted services to generate Kerberos tickets to specified services on a user’s behalf – without requiring access to his Windows password. An XML Service with support for Kerberos authentication would be able to seamlessly integrate with ClearTrust, allowing users access to MPS using just their RSA SecurID token. We should also be able to write our own service which provides the same functionality, which would be good for our customers since ClearTrust is expensive. Note: RSA’s basic product, SecurID Authentication Manager Version 6, provides similar functionality but requires access to Windows passwords. Citrix Web Interface is already adding support for SecurID Authentication Manager Version 6. SAP Portal. The SAP Portal also makes use of the new Windows Server 2003 Kerberos features to enable users to access Windows resources. SAP maintains its own user database and authentication infrastructure. It issues a SAP logon token for users which is valid for a session. When the user accesses a Windows resource (e.g. a Web site running on IIS), it maps the user onto a Windows account and generates an impersonation token which is used to access the resource. SAP doesn’t have access to the user’s Windows password, so SSPI is required. Making the XML Service accept SSPI data would allow it to integrated easily into the SAP portal. References: XML Service Integrated Authentication Engineering Functional Specification (detailed functional spec for my proposed changes), URL TBD Advanced Kerberos Support project home page (my proposed changes come under this project, in the ‘Out of Band Kerberos Authentication’ work package), Active Directory Federation Services: A Path to Federated Identity and Access Management. Kerberos extensions in Windows Server 2003: Exploring S4U Kerberos Extensions in Windows Server 2003, Kerberos Protocol Transition and Constrained Delegation, RSA ClearTrust support for Windows Server 2003 Kerberos extensions, RSA SecurID Version 6 support for Windows, Using SAP Logon Tickets for Single Sign on to Microsoft based web applications. ICA Client Access Gateway CtxGina D STA ticket 5 Logon ticket

Ping Identity PingFederate with Protocol Transition
A PING Assertion 1 Kerberos data Kerberos Kerberos Web Browser WI XML Service Ping Federate B STA & Logon tickets 4 Logon ticket User 2 Kerberos data C STA & Logon tickets 3 Logon ticket Kerberos CPS ccticket When a launch request is sent to the XML Service, this is what currently happens: Client of the XML Service sends user’s password to the XML Service to request a launch (NFuse) ticket. XML Service sends the password to the target MPS Server. MPS (ccticket) stores the password, creates a launch ticket to uniquely reference it and sends the ticket back to the XML Service. XML Service passes the launch ticket back to the client of the XML Service. Sometime later, ICA client sends the launch ticket to MPS (CtxGina). CtxGina retrieves the password associated with the launch ticket and uses it to log the user on. I’m adding support for Kerberos authentication to the XML Service and MPS (ccticket). This will replace the need to handle and transmit the user’s password in steps 1 and 2: Client of the XML Service uses SSPI to generate a service ticket and encrypted authenticator (SSPI data) for the XML Service. It sends the SSPI data to the XML Service. The XML Service passes the SSPI data to SSPI to verify the user. It then generates SSPI data for the MPS server and sends it to the MPS server. Alternative deployment: Client of the XML Service generates SSPI data for the MPS server and the XML Service passes it on. MPS (ccticket) passes the SSPI data to SSPI. SSPI authenticates the user and returns a logon token. MPS stores the logon token, creates a launch ticket to uniquely reference it and sends the ticket back to the XML Service. Sometime later, ICA client sends the launch ticket to MPS (CtxGina). MPS (CtxGina) retrieves the logon token associated with the launch ticket and uses it to log the user on. There are a number of possible deployment scenarios in which Kerberos authentication to the XML Service might be used, including the following: Web Interface. User authenticates to WI by typing his password into a Web form. WI uses SSPI to authenticate the user with the XML service and hence MPS. It passes the resulting launch ticket back to the user’s Web browser. Web browser passes the launch ticket to the ICA client. ICA client sends the launch ticket to MPS. The connection may be made via Secure Gateway (SG) but SG doesn’t interfere. If WI is trusted for delegation, the user can authenticate to WI using Integrated Authentication too. ADFS (Microsoft Active Directory Federation Services). ADFS enables users from one organisation to access Web resources in another organisation without having to provide credentials. It does this using SAML and WS-Federation. SAML allows one organization (A) to trust another (B) to authenticate users. Organization B receives an assertion from organization A which says who the user is. ADFS allows users to be mapped onto Windows accounts and impersonated in Web apps. A clear opportunity exits for Citrix to extend this to Windows apps. WI would be configured to use ADFS to impersonate users, and then use SSPI to authenticate the user with the XML service and retrieve a launch ticket. ADFS does not have access to the user’s password so SSPI is required. RSA ClearTrust. Version 5.5 of RSA ClearTrust is able to generate Kerberos tickets for users given just a SecurID passcode. It does this using new Kerberos features in Windows Server 2003 which allow trusted services to generate Kerberos tickets to specified services on a user’s behalf – without requiring access to his Windows password. An XML Service with support for Kerberos authentication would be able to seamlessly integrate with ClearTrust, allowing users access to MPS using just their RSA SecurID token. We should also be able to write our own service which provides the same functionality, which would be good for our customers since ClearTrust is expensive. Note: RSA’s basic product, SecurID Authentication Manager Version 6, provides similar functionality but requires access to Windows passwords. Citrix Web Interface is already adding support for SecurID Authentication Manager Version 6. SAP Portal. The SAP Portal also makes use of the new Windows Server 2003 Kerberos features to enable users to access Windows resources. SAP maintains its own user database and authentication infrastructure. It issues a SAP logon token for users which is valid for a session. When the user accesses a Windows resource (e.g. a Web site running on IIS), it maps the user onto a Windows account and generates an impersonation token which is used to access the resource. SAP doesn’t have access to the user’s Windows password, so SSPI is required. Making the XML Service accept SSPI data would allow it to integrated easily into the SAP portal. References: XML Service Integrated Authentication Engineering Functional Specification (detailed functional spec for my proposed changes), URL TBD Advanced Kerberos Support project home page (my proposed changes come under this project, in the ‘Out of Band Kerberos Authentication’ work package), Active Directory Federation Services: A Path to Federated Identity and Access Management. Kerberos extensions in Windows Server 2003: Exploring S4U Kerberos Extensions in Windows Server 2003, Kerberos Protocol Transition and Constrained Delegation, RSA ClearTrust support for Windows Server 2003 Kerberos extensions, RSA SecurID Version 6 support for Windows, Using SAP Logon Tickets for Single Sign on to Microsoft based web applications. ICA Client Access Gateway CtxGina D STA ticket 5 Logon ticket

Internal Employee SSO Deployment
100% Pure Kerberos Federation servers not required Appsrv.ini changes not required Full ICA client not required Desktop credentials pass-through not required Employee Domain (Resource Partner) Client Presentation Servers Web Interface 4.5 Federated Site With a special sitemgr switch, you can leverage the advanced Kerberos support from the ADFS site type without actually needing the ADFS piece for user authentication. Run sitemgr with the Federated=Yes switch and then disallow anonymous access to your WI site. This triggers Kerberos authentication to IIS, which is delegated on to Presentation Server in the same way. (You still need to configure delegation as per the ADFS section of the administrator’s guide.) sitemgr -c "WIDest=1:/Citrix/Federated,Config=Local, XMLService=COLORADO,XMLSPort=80,Federated=Yes"

Soft Certificate Authentication
Internet DMZ LAN Client Web Interface 4.5 Federated Site with client certificate mapping enabled User has only a browser certificate Web Interface IIS maps certificate to an AD account, generates Kerberos token WI Federated site consumes Kerberos token Presentation Servers If the Federation Service Proxy is set to require client certificates and is able to map client certificates to a domain account, the ADFS web agent can produce a Kerberos ticket for the mapped account and perform Kerberos logins to Presentation Server. The end result is that a user can authenticate to WI using a soft certificate, and then log into CPS without requiring a physical smart card. Note: Requires special switch to install the advanced Kerberos support without requiring Federation Service URL Access Gateway

Third-party strong authentication
Internet DMZ LAN Client Web Interface 4.5 Federated Site with RSA Access Manager Agent (née ClearTrust) User has only an RSA keyfob—they do not know their AD password RSA Access Manager generates Kerberos token for user (protocol transition) WI ADFS consumes Kerberos token RSA has documented this deployment here Presentation Servers When the RSA agent is configured for protocol transition, the user’s RSA authentication is converted into a Kerberos token. From there, the WI site works much like the internal SSO deployment. No federation server is needed on the user side. Access Gateway

Other product integrations
Secure Gateway or Access Gateway can be used to proxy ICA traffic But don’t proxy HTTPS into the LAN Password Manager 4.5 CPS agent functions properly with Kerberos logons (blank password; uses Data Protection API instead) NetScaler can load-balance multiple WI servers, Federation servers, or Federation Proxy servers

High Availability Use Netscaler to load-balance multiple WI servers, Federation Service Proxies, and Federation Services Web Interface is stateful, so persistence is required Federation Service and Federation Service Proxy servers are stateless Endpoint URLs and application URLs can be FQDNs that map to a virtual IP

Federation Service Servers Federation Service Proxy Servers
NetScaler LB VIPs Internet 1 Web Interface 4.5 Servers Client 3 Federation Service Servers 2 Federation Service Proxy Servers Virtual IP Also known as Persistence 1 WI End user URL, Application URL, Return URL SSL Session ID 2 FS-P Federation Service Endpoint URL None required 3 FS Federation Service URL None required

Current Issues and pain points
Web Interface must be a member of the resource domain No ADFS-enabled reverse proxy in Access Gateway, so Web Interface must reside in the DMZ Applications which should be filtered out due to Access Control filters are not filtered out. CPS 4.0 XML Service issue; will be fixed in CPS 4.5 Users are correctly refused access if they try to connect, but the icon should not appear in the application list Delegation must be configured for every Web Interface and Presentation Server, a chore for large farms

Federation Service Proxy
Any Questions? Domain A (Account Partner) DMZ Domain B (Resource Partner) Domain Controller WI 4.5 Federation Service Internet Federation Service Proxy Federation Service Client Presentation Servers Access Gateway

Good Reading/Viewing ADFS TechCenter Troubleshooting Kerberos Delegation Don Schmidt ADFS seminar Web Interface with ADFS Support Admin Guide Web Interface with ADFS Support FAQ RSA Secured Implementation Guide For Portal Servers and Web-Based Applications ADFS Forum on support.citrix.com How to Install Web Interface 4.0 for ADFS on Servers without ADFS (Advanced Kerberos support only)

Jay Tomlin Sr. Technology Specialist Mgr NA Field Readiness

Similar presentations

Presentation on theme: "Jay Tomlin Sr. Technology Specialist Mgr NA Field Readiness"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Jay Tomlin Sr. Technology Specialist Mgr NA Field Readiness

Similar presentations

Presentation on theme: "Jay Tomlin Sr. Technology Specialist Mgr NA Field Readiness"— Presentation transcript:

Similar presentations

About project

Feedback