Using Kerberos Authentication in a Reverse Proxy Environment

Using Kerberos Authentication in a Reverse Proxy Environment

Legal Notice Copyright 2017 Symantec Corp. All rights reserved. Symantec, the Symantec Logo, the Checkmark Logo, Blue Coat, and the Blue Coat logo are trademarks or registered trademarks of Symantec Corp. or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners. This document is provided for informational purposes only and is not intended as advertising. All warranties relating to the information in this document, either express or implied, are disclaimed to the maximum extent allowed by law. The information in this document is subject to change without notice. THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE. SYMANTEC CORPORATION PRODUCTS, TECHNICAL SERVICES, AND ANY OTHER TECHNICAL DATA REFERENCED IN THIS DOCUMENT ARE SUBJECT TO U.S. EXPORT CONTROL AND SANCTIONS LAWS, REGULATIONS AND REQUIREMENTS, AND MAY BE SUBJECT TO EXPORT OR IMPORT REGULATIONS IN OTHER COUNTRIES. YOU AGREE TO COMPLY STRICTLY WITH THESE LAWS, REGULATIONS AND REQUIREMENTS, AND ACKNOWLEDGE THAT YOU HAVE THE RESPONSIBILITY TO OBTAIN ANY LICENSES, PERMITS OR OTHER APPROVALS THAT MAY BE REQUIRED IN ORDER TO EXPORT, RE-EXPORT, TRANSFER IN COUNTRY OR IMPORT AFTER DELIVERY TO YOU. Symantec Corporation 350 Ellis Street Mountain View, CA 94043 www.symantec.com 8/10/2017

Symantec Blue Coat ProxySG Contents Using Kerberos Authentication in a Reverse Proxy Environment 4 Configure Certificate Authentication with KCD on Reverse Proxy 5 Reverse Proxy Service Configuration 6 Create a Keyring 7 Create a CA-Signed Certificate 8 Import the CA Certificate onto Client Machines 10 Create a CA Certificate List 10 Configure a Reverse Proxy Service 11 Certificate Realm Configuration 13 Create Certificate Realm 14 Construct a User's Full Name with Parser Functions 14 Configure Authorization 16 Specify the Virtual URL for the Certificate Realm 18 Define Authentication Policy for the Certificate Realm 19 IWA Direct Realm Configuration for KCD 21 Integrate the ProxySG Appliance With Your Windows Domain 22 Create an IWA Direct Realm 23 Configure Delegation Rights 25 Define Authentication Policy for the IWA Direct Realm 27 Network Forwarding 30 Create Forwarding Hosts 31 Create Forwarding Policy 31 Verify Authentication Policy 33 Sample CPL Code 34 End-to-End Verification 35 Troubleshooting 36 3

KCD Authentication on Reverse Proxy Using Kerberos Authentication in a Reverse Proxy Environment Kerberos Constrained Delegation (KCD) is a Microsoft extension to Kerberos authentication. KCD allows a trusted service to acquire Kerberos tickets for other users without knowing their passwords. KCD constrains the trusted service to only being able to acquire tickets to a specific set of servers/services. Clients normally use a ticket-granting-ticket (TGT) to get tickets from the Key Distribution Center. In the case of Kerberos Constrained Delegation, the ProxySG gets a service ticket on behalf of the user directly from the Key Distribution Center. The TGT is obtained through authentication, which requires a password, a smart card, or other method of verifying the user's identify. A TGT allows the user to get a service ticket that will authenticate the user to a service. In the scenario covered in this solution, an organization wants to implement a Reverse Proxy where users are authenticated with SSL/TLS certificates on smart cards. These users need to be able to access authenticated content (such as their email) through the proxy. To accomplish this task, the proxy needs to be able to securely send credentials to the Origin Content Server (OCS) so that it knows what content to provide. Here is the workflow using a ProxySG Reverse Proxy that is configured to authenticate with KCD: 1. A user authenticates to the ProxySG using a smart card issued by the organization. 2. The user requests Outlook Web Access (OWA) email through the ProxySG. 3. The ProxySG is configured to authenticate to the OWA server using Kerberos Constrained Delegation. 4. The ProxySG uses IWA Direct to get a Kerberos ticket for the authenticated user to the OWA server. 5. The request is sent to the OWA server with the new Kerberos ticket. 6. OWA authenticates the ticket and responds with the user s email. The goal of this solution is to provide a step by step configuration guide to implement the above mentioned scenario. Proceed to "Configure Certificate Authentication with KCD on Reverse Proxy" on the next page. 4

Symantec Blue Coat ProxySG Configure Certificate Authentication with KCD on Reverse Proxy You must perform the following high-level steps to configure certificate authentication with Kerberos Constrained Delegation (KCD) on a Reverse Proxy: 1. Configure a Reverse Proxy service. This service allows mutual SSL authentication to the ProxySG. 2. Configure a certificate realm and define policy to authenticate users on this realm. 3. Configure an IWA Direct realm and define policy to obtain Kerberos tickets for each web service using Kerberos Constrained Delegation using the IWA Direct realm. 4. Create policy to forward requests from users to each web service. Prerequisites This guide assumes you have: Purchased a ProxySG appliance with a Proxy Edition or Advanced Reverse Proxy license. Followed the Quick Start Guide and Reverse Proxy Addendum (for Reverse Proxy SKUs) to incorporate the ProxySG appliance in your network. Upgraded the SGOS software to 6.7.2.1 or higher. Installed the smart card software on the client workstations accessing the ProxySG. Get Started This guide will step you through the configuration process. The first step, configuring the Reverse Proxy service, requires several preliminary tasks. 5

KCD Authentication on Reverse Proxy Reverse Proxy Service Configuration A Reverse Proxy service allows SSL/TLS mutual authentication to the ProxySG. Before configuring the service, you need to create a keyring for the SSL/TLS server certificate. You may also need to import the CA onto client machines. Create a Keyring 7 Create a CA-Signed Certificate 8 Import the CA Certificate onto Client Machines 10 Create a CA Certificate List 10 Configure a Reverse Proxy Service 11 6

Symantec Blue Coat ProxySG Create a Keyring Keyrings are containers for SSL/TLS certificates on the appliance, and can be used to manage self-signed or CA-signed certificates. Note that this keyring is used for the reverse proxy service listener on the ProxySG. 1. Select Configuration > SSL > Keyrings > Create. 2. For Keyring Name, enter a descriptive name for the keyring. 3. Select Private key visibility, based on your security policy. 4. Leave the key size at 2048 bits. 5. Click OK and Apply to save your changes. 7

KCD Authentication on Reverse Proxy Create a CA-Signed Certificate Self-signed certificates are acceptable during proof-of-concept testing, but they should be replaced with CA-signed certificates before using in a production environment. You will need to generate a CA-signed certificate for your SSL keyring for the server-side authentication part of SSL/TLS. Select Configuration > General > Clock to confirm correct time configuration and NTP settings. Because SSL/TLS certificates include a date and time component, you can avoid problems by configuring an NTP server. Create a Certificate Signing Request One way to obtain a valid CA-signed certificate is to create a certificate signing request (CSR), as described in the steps below. A CSR is the preferred, more secure method, because the private key can be created on the appliance and never has to leave the appliance. (If you obtain the certificate using alternate methods, you can skip this step and import the certificate with its private key.) 1. Edit the keyring created previously. (See "Create a Keyring" on the previous page.) 2. Under Certificate Signing Request, click Create. 3. Fill in the fields as appropriate. Set the Common Name to the single hostname (resolvable via DNS) of the ProxySG. Click OK, then Close, then Apply. Make sure to set the Common Name to the name the client expects to see; it needs to match the virtual URL DNS name in the certificate realm s configuration (Configuration > Authentication > Certificate > Certificate General). 8

Symantec Blue Coat ProxySG 4. Edit the keyring. Data now appears in the Certificate Signing Request. a. Copy this text to the clipboard (including the "Begin" and "End" text). b. Save the text in a file with a name such as "proxysg.csr." c. Click Close. Request & Import a Certificate Contact your preferred certificate signing authority to request a certificate for the CSR you created in the "Create a Certificate Signing Request" section above and provide them with the CSR file you saved above. When the server certificate is available, download the file and import it into your keyring on the ProxySG. 1. Open the Base64 (PEM) certificate in a text editor. 2. Copy the certificate text, including the ---BEGIN CERTIFICATE--- and ---END CERTIFICATE---. 3. Select Configuration > SSL > Keyrings. 4. Select the keyring you created previously and click Edit. The Edit Keyring dialog opens. 9

KCD Authentication on Reverse Proxy 5. Click the Import button in the Certificate section. 6. Paste the ProxySG's certificate you copied in step 2 above. 7. Click Close. Import the CA Certificate onto Client Machines Client machines need to trust the CA certificate that issued the ProxySG's reverse proxy keyring certificate. Import the CA into the browser's trusted root CA store. An Active Directory administrator can do this through Group Policy, which will automatically apply the change for every user. This step is required only if you are using an internal CA. It is not necessary if you used a CSR to get a server certificate from a public, and already trusted, CA. Create a CA Certificate List For the client-side authentication part of SSL/TLS, the client's certificate is validated with the CA Certificate List (CCL) of 10

Symantec Blue Coat ProxySG the reverse proxy configuration. The CA and intermediate certificates used to create the Common Access Card (CAC) certificate must be imported into the CA Certificates tab on the ProxySG. You then need to create a new CA Certificate Lists entry and add the root certificate. Import the Client-Side CA Certificates The authentication certificate on the CAC is often signed by one or more intermediate CAs. You will need to import the entire CA chain, not just the root CA, into the CCL. The certificates must be saved in Base 64 (PEM) format for the following procedure to work. Certificates saved in DER format will not work. 1. Open one of the certificates with a text editor and copy the content. 2. Import the CA certificate onto the ProxySG: a. Select Configuration > SSL > CA Certificates. b. Click Import. c. Type a CA Cert Name. d. Paste the certificate content in the CA Certificate PEM box. e. Click OK. 3. Repeat steps 1 and 2 to import any other intermediate certificates. 4. Click Apply. Create a CA Certificate List 1. Select Configuration > SSL > CA Certificates. 2. Click the CA Certificate Lists tab. 3. Click New. The Create CA Certificate List dialog opens. 4. Enter a CA Cert List Name. 5. Select the root CA certificate and any intermediate CA certificates you imported, and click Add >>. 6. Click OK. 7. Click Apply. Configure a Reverse Proxy Service A Reverse Proxy service can perform SSL mutual authentication to the ProxySG. In mutual SSL authentication, an SSL connection between a client and a server is established only if the client and server validate each other's identity during the SSL handshake. The server and the client must each have their own valid certificate in order to perform SSL mutual authentication. Certificates can be stored in multiple locations. On the client, one such location is a Common Access Card (CAC). The Reverse Proxy service will validate the certificate that the client presents to the ProxySG appliance. 11

KCD Authentication on Reverse Proxy Prerequisite Tasks Before creating an HTTPS Reverse Proxy service, make sure you have completed the following tasks: Created a keyring container for the SSL/TLS certificates on the appliance. See "Create a Keyring" on page 7. Obtained a CA-signed certificate for server-side authentication. One way to do this is to create a Certificate Signing Request (CSR) that can be sent to a Certificate Signing Authority (CA). See "Create a CA-Signed Certificate" on page 8. Imported the client CA certificates and added the trusted root CAs to a CA Certificate List. See "Create a CA Certificate List" on page 10. When these steps are complete, you can configure the HTTPS Reverse Proxy service. Create the HTTPS Proxy Service 1. Select Configuration > Services > Proxy Services. 2. If you have an existing HTTPS service, you should delete it (or add the new service on a different port). 3. Click New Service. The New Service dialog opens. 4. In the Proxy settings section: Name: Reverse Proxy Service Group: Standard (or other group) Proxy: HTTPS Reverse Proxy Keyring: Specify the keyring you previously created. This keyring contains a server certificate that is known / trusted by the client. See "Create a Keyring" on page 7. CCL: Choose the CA Certificate List you previously created. See "Create a CA Certificate List" on page 10. Client mutual authentication will not work if CCL is set to its default setting, All CA Certificates. SSL Protocols: Specify the SSL/TLS protocols that you want to support (Recommendation: Use TLS only). Verify Client: Enabled. Client mutual authentication will not work if Verify Client is not enabled; ProxySG will not request and verify the client's certificate. 5. Click Add to add a listener with the following settings: 6. Click OK. Destination address: Explicit (to listen to any address assigned to the ProxySG) or Destination host (to listen on a single IP address) Port: 443 Action: Intercept 7. Click Apply. 12

Symantec Blue Coat ProxySG Certificate Realm Configuration The objective of the certificate realm is to establish authentication derived from the SSL/TLS mutual authentication performed by the Reverse Proxy service. After creating the certificate realm, you can define policy to authenticate users on this realm. Create Certificate Realm 14 Construct a User's Full Name with Parser Functions 14 Configure Authorization 16 Specify the Virtual URL for the Certificate Realm 18 Define Authentication Policy for the Certificate Realm 19 13

KCD Authentication on Reverse Proxy Create Certificate Realm The objective of the certificate realm is to establish authentication derived from the SSL/TLS mutual authentication performed by the Reverse Proxy service. This realm also defines how to uniquely identify users for Kerberos Constrained Delegation (KCD) authentication. Names that can be used for KCD authentication are: User Principal Name (UPN), for example: john.doe@test.com NetBIOS Name, for example: johndoe LDAP Distinguished Name (DN), for example: CN=john.doe,CN=Users,DC=domain,DC=com 1. Select Configuration > Authentication > Certificate. 2. Click New in the Certificate Realms tab. The Add Certificate Realm dialog opens. 3. Enter a Realm name and click OK. 4. Click Apply. 5. Go to the Certificate Main tab. 6. Username: Enter the substitution that specifies the common name in the subject of the certificate. 7. Full Username: Enter the substitutions used to construct the user's full username. For example, the user principal name (UPN) or LDAP distinguished name (DN). See "Construct a User's Full Name with Parser Functions" below. The username syntax has to match the username syntax on the Key Distribution Center (i.e., Active Directory in the IWA Direct example). If it is not exactly the same syntax, KCD will not work. The Full Username field is what will be used for KCD unless you enable the use of authorization username for KCD authentication via a CLI command. See "Enable Authorization Username for KCD Authentication" on page 17. For government issued CAC certificates, the UPN name can typically be found in the certificate under subjectaltname.othername. 8. Click Apply. Construct a User's Full Name with Parser Functions The following table shows the substitutions that can be used to construct a user's full username. 14

Symantec Blue Coat ProxySG The substitutions used to construct the username use the following parser format: $([attributename=][field][.generalname[.generalnameindex]] [.attribute[.attribute index]]) To see how the parser works, examine the client certificate example below and the resulting substitutions in the table. subject: CN=John,OU=Auth,OU=Waterloo,O=Test subjectaltname: -othername: john.doe@test.com -othername: john.doe@department.test.com -DN: CN=Doe, john,cn=users,dc=internal,dc=cacheflow,dc=com Parser Function Format Example Multiple instances of an attribute/general name results in an attribute/general name list. An individual instance of a multiple valued field is selected using its index (1-based). Works for attribute and general name fields. The subjectaltname and issuer- AltName fields support general name types that can be specified in the substitution. If multiple values of the same general name are found, all values will be substituted in a list. $(<attribute value>) and $(<subjectaltname.general name value>) and $(issuer- AltName.<general name value>) $(<field name>.index#) $(subjectaltname.<general name value>) or $(issueraltname.<general name value>) $(OU) = AuthWaterloo $(OU.2) = Waterloo $(subjectaltname.othername) = john.doe@test.com john.- doe@department.test.com Supported general names types are: othername, email, DNS, dirname, URI, IP, RID A modifier that enables LDAP style expansion of attributes. attribute name= $(OU=subject.OU) = OU=Auth,OU=Waterloo 15

KCD Authentication on Reverse Proxy Parser Function Format Example Text that is not part of a substitution is directly placed into the username. $(any value),text $(OU),o=example becomes AuthWaterloo,o=example Configure Authorization It's only necessary to configure certificate authorization when using group-based authorization and/or if the authorization username is being used for KCD authentication. Using the authorization username for KCD would be necessary if no name existed in the certificate that could be used for KCD authentication. You can perform a search on an LDAP realm to determine the User Principal Name (UPN) based on user attributes such as an employee ID. For example, the Department of Defense identification number, formerly referred to as the Electronic Data Interchange Personal Identifier (EDIPI), is a unique 10-digit number that is associated with personnel and their Common Access Card (CAC). The UPN could be looked up in LDAP with the EDIPI number. Prerequisites SGOS 6.7.2 or higher. The CLI command that enables the use of authorization username for KCD authentication is only available in these versions. (Only required if the UPN isn't in the client certificate. ) An LDAP realm for group lookups (for example, in Microsoft Active Directory) An LDAP search realm for finding the username to use A certificate realm Define the LDAP Search Criteria By performing an LDAP search, the full username value can be uniquely matched to any user attribute in LDAP and then any other attribute of that user (preferably userprincipalname) could be used as the authorization username for KCD. 1. Select Configuration > Authentication > Certificate. 2. Select the Authorization tab. 16

Symantec Blue Coat ProxySG 3. Realm name: Select the certificate realm you created in "Create Certificate Realm" on page 14. 4. Authorization realm name: Select the realm used for group lookups, for example ldap_group_lookup_realm. 5. Search an LDAP server for a user with an attribute matching the substitution: a. Authorization username: Select Determine by search. b. LDAP search realm name: Select your LDAP realm, for example ldap_search_realm. c. Search filter: Construct the search criteria. For example to search for the user name based on the EDIPI, enter (edipi_attribute=$(user)). The Username field value in the Certificate Main tab corresponds to user.name in CPL and the Full Username field value corresponds to user. d. User attribute: Enter an attribute on the entry returned in the LDAP search results that has the value to use as the authorization username. In most cases this is the FQDN of the user entry. For example, enter userprincipalname or distinguishedname. 6. Click Apply. You must specify the distinguishedname user attribute when using group-based authorization with an LDAP authorization realm; the userprincipalname attribute will not work for group lookups. Enable Authorization Username for KCD Authentication If you want Kerberos Constrained Delegation to use the authorization username for authentication, you need to enable this setting in the ProxySG command-line interface. This setting must be used for deployments where the UPN is not included in the client certificates. 17

KCD Authentication on Reverse Proxy This command is available in SGOS 6.7.2 or higher versions. 1. Log in to the ProxySG command-line interface. 2. Enter enable mode and enter your enable password. 3. Enter config mode. 4. Type the following commands in bold (substitute your IWA realm name for realm_name): #(config) security iwa-direct edit-realm realm_name #(config iwa-direct realm_name) kcd-use-authz-name enable Specify the Virtual URL for the Certificate Realm The virtual URL is where client certificate authentication takes place; unauthenticated clients are redirected to this URL. In reverse proxy deployments, the virtual URL often uses the same hostname as the client requests. For certificate authentication to work, it must terminate at the HTTPS Reverse Proxy service that was created earlier. 1. Select Configuration > Authentication > Certificate. 2. Select the certificate realm you created previously, for example, cac_certificate. 3. Go to the Certificate General tab. 18

Symantec Blue Coat ProxySG 4. Set the Virtual URL to the single hostname (resolvable via DNS) of the ProxySG; the URL must include the https:// prefix. The hostname of the virtual URL must match at least the beginning of the subject name of the server certificate if a redirect authentication mode is used. The value you enter for virtual URL must be specified in the certificate Common Name field. See "Create a CA-Signed Certificate" on page 8. 5. Click Apply. Define Authentication Policy for the Certificate Realm Create policy to authenticate users on the certificate realm you previously created. You can create the policy in either Content Policy Language (CPL) or in the Visual Policy Manager (VPM). Create Policy in VPM 1. Launch the Visual Policy Manager on ProxySG. a. Select Configuration > Policy > Visual Policy Manager. b. Click Launch. The Visual Policy Manager window opens. 2. Add a web authentication layer. a. In the VPM window, select Policy > Add Web Authentication Layer. b. Enter a name, such as Web Authentication Layer (cert). c. Click OK. 3. Add a policy rule to authenticate users in the certificate realm you previously created. a. Right-click the Action field and select Set > New > Authenticate. The Add Authenticate Object dialog opens. 19

KCD Authentication on Reverse Proxy b. Name: Enter a name for the object, such as Authentication_cert. c. Realm: Select the name of the certificate realm you previously created, for example, cac_certificate. d. Mode: Select Origin. e. Click OK and OK. The rule for the Web Authentication layer looks similar to the following: 4. Click Install policy. Sample CPL Code The CPL code that corresponds to the above VPM instructions: ;;Client Certificate Authentication <Proxy> authenticate(cac_certificate) authenticate.force(no) authenticate.mode(origin) 20

Symantec Blue Coat ProxySG IWA Direct Realm Configuration for KCD The Integrated Windows Authentication (IWA) realm contains the configuration settings that the ProxySG appliance needs to be able to perform IWA authentication, including how to connect to the Active Directory. Note that you must join the ProxySG appliance to the Windows domain before you can create the IWA Direct realm. You also need to configure delegation rights in Active Directory for the web services behind the Reverse Proxy. You can then create policy to authenticate each web service using Kerberos Constrained Delegation on the IWA Direct realm. Integrate the ProxySG Appliance With Your Windows Domain 22 Create an IWA Direct Realm 23 Configure Delegation Rights 25 Define Authentication Policy for the IWA Direct Realm 27 21

KCD Authentication on Reverse Proxy Integrate the ProxySG Appliance With Your Windows Domain To integrate the ProxySG appliance into your Windows domain, you must complete the following tasks. Synchronize the ProxySG Appliances and DC Clocks The ProxySG cannot join a Windows domain unless its internal clock is in sync with the Domain Controller. To ensure that the ProxySG clocks are synchronized with the Domain Controller clock, use either of the following techniques: Specify the same NTP servers for the ProxySG appliances and the Domain Controller. Configure the ProxySG appliances to use the Domain Controller as the NTP source server. The ProxySG NTP configuration options are located on the Configuration > General > Clock tab. Join the ProxySG to the Windows Domain After you have synchronized the ProxySG appliance s internal clock with the Domain Controller, you can join the appliance to the Windows Domain as follows: 1. From the ProxySG Management Console, select Configuration > Authentication > Windows Domain > Windows Domain. 2. Click New. The Add Windows Domain dialog opens. 3. Enter a Domain name alias and then click OK. 4. Click Apply and then click OK. 5. Select the domain name you created and click Join. 22

Symantec Blue Coat ProxySG 6. In the DNS Domain Name field, enter the DNS name for the Windows Active Directory domain. The ProxySG appliance must be able to resolve the DNS domain name you supply for the Active Directory domain or the appliance will not be able to join the domain. If DNS resolution fails, check your DNS configuration. 7. Enter the primary domain access User Name and Password in the format: username@dnsname. For example: administrator@corpdomain.test.com. 8. Click OK. The appliance displays a message indicating that the domain was successfully joined. 9. Click OK to close the dialog. The value in the State field changes to Joined. Create an IWA Direct Realm IWA Direct is a method for integrating the ProxySG appliance with your Active Directory. It allows you to directly connect 23

KCD Authentication on Reverse Proxy to your AD domains when performing authentication tasks, instead of connecting via an external authentication agent. The Integrated Windows Authentication (IWA) realm contains the configuration settings that the ProxySG appliance needs to be able to perform IWA authentication, including how to connect to the Active Directory. After you join the ProxySG appliance to the Windows domain, you can create the IWA Direct realm as follows: 1. Create the realm: a. Select Configuration > Authentication > IWA > IWA Realms. b. Click New. c. Enter a Realm name. The name can be 32 characters long and composed of alphanumeric characters and underscores. The name must start with a letter. d. In the Active Directory Connection field, select Direct. This option will be grayed out if you have not yet joined the appliance to a Windows domain. e. Click OK to close the dialog. f. To save your settings, click Apply. 2. Select the IWA Servers tab. 3. From the Realm name drop-down list, select the IWA realm you want to configure. 4. Verify that you have configured the realm successfully: 24

Symantec Blue Coat ProxySG a. Click Test Configuration. b. When prompted, enter the username and password of a user in the Windows domain and then click OK. c. The appliance sends an authentication request to the configured server and then displays a message indicating whether the authentication succeeded or failed. If the test failed, go back and make sure you have configured the realm properly. If the test succeeds, the message also displays a list of groups to which the user belongs. 5. Click Apply. Configure Delegation Rights Configure delegation rights in Active Directory for the web services behind the Reverse Proxy. Service Principal Names (SPNs) should already exist for the web services that need to be accessed through the ProxySG. For each web service SPN behind the Reverse Proxy that is being used with Kerberos Constrained Delegation, you must add delegation rights on the ProxySG host in Active Directory. This allows the ProxySG to request service tickets for the user. 25

KCD Authentication on Reverse Proxy 1. On the Domain Controller, select Administrative Tools, and open Active Directory Users and Computers. 2. Under DomainName/Computers, double-click the ProxySG host to display the Properties dialog. a. On the Delegation tab, click Trust this computer for delegation to specified services only. b. Click Use any authentication protocol. c. Click Add; in Add Services, click Users and Computers. d. In the Enter the object names to select (examples) field, enter an SPN to which the system will be 26

Symantec Blue Coat ProxySG trusted to delegate and click OK. e. Repeat steps c and d for each web service SPN. f. Click OK to close the Properties dialog. Define Authentication Policy for the IWA Direct Realm Create policy to authenticate each web service using Kerberos Constrained Delegation on the IWA Direct realm. You can create the policy in either Content Policy Language (CPL) or in the Visual Policy Manager (VPM). Create Policy in VPM 1. Launch the Visual Policy Manager on ProxySG. a. Select Configuration > Policy > Visual Policy Manager. b. Click Launch. The Visual Policy Manager window opens. 2. Add a web authentication layer for Kerberos Constrained Delegation. a. In the VPM window, select Policy > Add Web Authentication Layer. b. Enter a name, such as Web Authentication Layer (KCD). c. Click OK. 3. Create policy that defines the URL destination of the web service. a. Right-click the Destination field and select Set > New > Request URL. The Add Request URL Object dialog opens. b. Enter the URL of the OWA server (or other web service) and click Add, c. Click Close, OK. 4. Add an action to enable KCD in the IWA Direct realm you previously created. a. Right-click the Action field and select Set > New > Kerberos Constrained Delegation. The Add Kerberos Constrained Delegation Object dialog opens. 27

KCD Authentication on Reverse Proxy b. Name: Enter a name for the object, such as KCD. c. Authentication Type: Select origin. d. IWA Realm: Select the name of the IWA direct realm you previously created. e. Service Principal Name: Enter the SPN of the web service. Note that the SPN does not need to be specified if it is the same as the request URL. f. Click OK and OK. The rule for the Web Authentication layer looks similar to the following: 5. For each web service, add a new rule in the Web Authentication Layer (KCD) and specify the URL request destination and KCD policy. Create a web access layer for allowing access to web services. This is necessary because in reverse proxy deployments, the default policy is to deny access to avoid ending up with an open proxy on the Internet. Therefore, you need to create rules in the web access layer to allow access to specific web services. 1. Add a web access layer. a. In the VPM window, select Policy > Add Web Access Layer. b. Enter a name, such as Web Access Layer (OWA). c. Click OK. 2. Add a policy rule to allow access to a web service, such as the OWA server. a. Right-click the Action field and select Allow. b. Right-click the Destination field and select Set > New > Request URL. 28

Symantec Blue Coat ProxySG c. Enter the URL of the OWA server (or other web service) and click Add. d. Click Close, OK. 3. For each web service, add a new rule in the Web Access Layer and specify a policy to allow the service. (Refer to steps 1 and 2 above.) 4. Click Install policy. Add DNS entries to DNS so that these host URLs resolve to the ProxySG. Sample CPL Code The CPL code that corresponds to the above VPM instructions: ;;Kerberos Constrained Delegation: <Proxy> url.domain="acme.server.acme.com" server.authenticate.constrained_delegation(origin,iwa_direct) server.authenticate.constrained_delegation.spn("http/acme.server.acme.com") ;;Authorization: <Proxy> url.domain="acme.server.acme.com" Allow 29

KCD Authentication on Reverse Proxy Network Forwarding Forwarding redirects content requests to IP addresses other than those specified in the requesting URL. Requests from users to each web service have to be forwarded via policy. Before creating the policy, you need to configure a forwarding host for each web service behind the reverse proxy, for example for the Outlook Web Access (OWA) server. Create Forwarding Hosts 31 Create Forwarding Policy 31 Verify Authentication Policy 33 30

Symantec Blue Coat ProxySG Create Forwarding Hosts Configure a forwarding host for each web service behind the Reverse Proxy, for example for the Outlook Web Access (OWA) server. To create a forwarding host for a web service: 1. Select Configuration > Forwarding > Forwarding Hosts. 2. Click New. The Add Forwarding Host dialog opens. 3. Alias: Enter a unique name to identify the forwarding host. The alias will be used in policy. 4. Host: Enter the web service's internal IP address or fully qualified domain name. 5. Type: Choose Server if the forwarding target is a server. If it is a proxy, select Proxy. 6. Ports: Select HTTPS for the protocol to forward, and enter 443 as the port you want to use for forwarding. 7. If you want the ProxySG to verify the OCS server certificate, enable the Verify SSL server certificate option. The OCS certificate needs to be in the CA store of ProxySG or it needs to be signed by a trusted CA. 8. Click OK. 9. Click Apply. Create Forwarding Policy In this procedure, you create policy to forward users' requests to your back-end content server(s). You can create the policy in VPM or CPL. 31

KCD Authentication on Reverse Proxy Create Forwarding Policy Create forwarding layers to forward traffic to the web services behind the Reverse Proxy. This step is necessary if the DNS names that people use to request web services are different than those on the Reverse Proxy side of the ProxySG. 1. Add a forwarding layer to forward traffic to a web service. a. In the VPM window, select Policy > Add Forwarding Layer. b. Enter a name or accept the default. c. Click OK. 2. Add a policy action to forward traffic to a web service, such as the OWA server. a. Right-click the Action field and select Set > New > Select Forwarding. The Add Select Forwarding Object dialog opens. b. Enter a Name for the forwarding object, such as Forwarding_OWA. c. In the Forward to list, select the alias you created for the forwarding host (acme in this example). d. Click Add >>. The alias moves over to the box on the right. e. Click OK. f. Click Close, OK. 32

Symantec Blue Coat ProxySG 3. Create policy that defines the URL destination of the web service. a. Right-click the Destination field and select Set > New > Server URL. The Add Server URL Object dialog opens. b. Enter the URL of the OWA server (or other web service). This is the domain name users will enter to access the web service. c. Click OK. 4. Add a new rule for each web service to be forwarded. 5. Click Install Policy. Sample CPL Code The CPL code that corresponds to the above VPM instructions: ;;Forwarding to OWA: <Forward> server_url.domain="acme.server.acme.com" forward("acme") forward.fail_open(no) Verify Authentication Policy If authentication policy is working properly, you should be able to access a web server through the ProxySG. Note that this is not one of the web servers for which KCD is needed. Assuming you can successfully view web pages on that server, follow the steps below to verify users are being authenticated with the configured policy. 1. Select Statistics > Authentication. 2. Choose the Realm (for example, cac_certificate) or choose <All>. 3. Click Display by user. The user list opens in a new window. 4. Verify users are authenticated. 33

KCD Authentication on Reverse Proxy Sample CPL Code Here is the sample Content Policy Language (CPL) code required for the Kerberos Constrained Delegation certificate authentication solution for Reverse Proxy. ;;Client Certificate Authentication <Proxy> authenticate(cac_certificate) authenticate.force(no) authenticate.mode(origin) ;;Kerberos Constrained Delegation: <Proxy> url.domain="acme.server.acme.com" server.authenticate.constrained_delegation(origin,iwa_direct) server.authenticate.constrained_delegation.spn("http/acme.server.acme.com") ;;Authorization: <Proxy> url.domain="acme.server.acme.com" Allow ;;Forwarding to OWA: <Forward> server_url.domain="acme.server.acme.com" forward("acme") forward.fail_open(no) 34

Symantec Blue Coat ProxySG End-to-End Verification When settings and policies are properly configured as described in this guide, users will be able to use their smart cards (or other authentication method) to access the web services that are behind a ProxySG Reverse Proxy. For example: 1. A user authenticates to the ProxySG using a smart card issued by the organization. 2. The user requests Outlook Web Access (OWA) email, a web service behind the Reverse Proxy which is configured to authenticate to the OWA server using Kerberos Constrained Delegation 3. The ProxySG uses IWA Direct to get a Kerberos ticket for the authenticated user to the OWA server. 4. The email request is sent to the OWA server with the new Kerberos ticket. 5. OWA authenticates the ticket and responds with the user s email. 35

KCD Authentication on Reverse Proxy Troubleshooting If KCD fails, the ProxySG will display an exception page that describes the failure. Because several steps are required to configure KCD correctly, you should double-check that you have properly carried out the instructions in this guide. In some AD environments, it can take up to 30 minutes for changes in AD to be replicated to all the Domain Controllers. If the ProxySG gives an error message that it doesn't have delegation rights, but you are sure you have assigned them, a replication delay might be to blame. You can either wait for replication to happen (in other words, wait a few minutes and try again), or contact your AD administrator and ask how long it should take for the change to replicate. Verify the configuration in two steps: 1. Disable the KCD layer in VPM. Expected result: The user should get an authentication prompt from the OCS. 2. Enable the KCD layer in VPM. Expected result: Transparent authentication to the OCS (no authentication prompt). 36