Join the Appliance to the Windows Domain

You cannot create an (IWA) direct realm until you have joined the appliance to the Windows Domain. See How to join a Windows Domain

NOTE: For information on IWA-Direct's Supported Directory Service Operating Systems. You can refer to the BCAAA Read me, which is posted with the BCAAA version on the Symantec download portal.

(Recommended) Prepare for a Kerberos Deployment

In an IWA Direct realm, Kerberos configuration is minimal because the appliance has its own computer account in Active Directory. Then uses its account password to decrypt service tickets from clients. Therefore, there is no need for you to create a privileged Active Directory account. Or to generate a service principal name (SPN) for the appliance as is required with an IWA BCAAA realm. To ensure that IWA uses the Kerberos protocol rather than downgrading to NTLM. You'll need to make sure that authentication requests are directed to the DNS name of the appliance’s Active Directory computer account name as follows:

1. Create a DNS “A” record for the ProxySG that resolves to the DNS name of the appliance’s Active Directory computer account name. For example, if you have an appliance named ProxySG1. With an IP address x.x.x.x, in the blue9 Active Directory domain at example.com. You can create the following DNS record:
   
   ProxySG1.blue9.example.com     Host (A)     x.x.x.x
    
2. Ensure that client requests are directed to the DNS name for the Edge SWG (Formerly ProxySG) appliance’s Active Directory computer account:
   • Explicit deployments—Configure the client browser explicit proxy settings to point to this DNS name.
   • Transparent deployments—Set the Virtual URL in the realm configuration (on the IWA General tab) to this DNS name. Also, make sure the DNS name for the Edge SWG (Formerly ProxySG) appliance's Active Directory domain is either included in the workstation's list of imputing DNS suffixes. Or explicitly specified as part of IE's local intranet zone. For example, if your AD domain DNS name is blue9.example.com, then you'll add *.blue9.example.com to IE's local intranet zone.

Configure the IWA Direct Realm

The IWA realm contains the configuration settings that the Edge SWG (Formerly ProxySG) appliance needs to be able to perform IWA authentication. Including how to connect to the Active Directory, and which authentication protocols to support.  Also how long before timing out, and where to redirect transparent requests, if applicable.

1. Select Configuration > Authentication > IWA > IWA Realms.
2. Click New.
3. 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.
4. In the Active Directory Connection field, select Direct. This option can be grayed out if you have not yet joined the appliance to a Windows domain as described. 
   
   
    
5. Click "OK" to close the dialog.
6. To save your settings, click Apply.
7. Select the IWA Servers tab.
8. From the Realm name drop-down list, select the IWA realm you created.
9. Specify the type of credentials to accept from the browser or user agent. By default, all credential types are allowed and the Edge SWG (Formerly ProxySG) appliance tries to use Kerberos (the default authentication method for Windows clients). This will automatically downgrade to a different challenge type depending on the browser or user agent capabilities. 
10. (Transparent proxy only) Specify the URL to which to redirect client requests require authentication in the Virtual URL field. For best results, the virtual URL you specify must:
    • Contain a hostname that does not contain any dots (for example, use http://myproxy rather than http://myproxy.example.com. Allowing IE to recognize the URL as part of the intranet zone. Instead of the Internet zone so that the browser automatically return credentials when challenged rather than prompting the user.
    • Resolve to the IP address of the Edge SWG (Formerly ProxySG) appliance. To accomplish the intended functionality, you must add an "A" record to your internal DNS server that associates the virtual URL with the IP address of the Edge SWG (Formerly ProxySG) appliance.
    • (Kerberos only) If you’re using Kerberos, the Virtual URL must be the DNS name of the Edge SWG (Formerly ProxySG) appliance in the Active Directory domain. Typically the DNS name that Active Directory domain prefixed with the Edge SWG (Formerly ProxySG) appliance computer account name. For example, sg.blue9.local. If you do not use the Active Directory DNS name of the Edge SWG (Formerly ProxySG) appliance as the Virtual URL, all authentication transactions are downgraded to NTLM.
11. Click Apply.

Validate the realm configuration

After you create the IWA Direct realm, you can verify that the Edge SWG (Formerly ProxySG) appliance can successfully connect to the Domain Controller and authenticate a user as follows:

1. On the IWA Servers tab, click Test Configuration. 
2. When prompted, enter the user name and password of a user in the Windows domain and then click OK. The appliance sends an authentication request to the configured server and then displays a message indicating whether the authentication that succeeded or failed. If the test fails, 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. 
   
   
    
3. After you create the IWA Direct realm, you can verify that the Edge SWG (Formerly ProxySG) appliance can successfully connect to the Domain Controller and authenticate a user as follows:

(Transparent Proxy Only) Set the virtual URL

1. Select the IWA General tab.
2. Specify the URL to which to redirect client requests that require authentication in the Virtual URL field. For best results, the virtual URL you specify must:
   • Contain a simple hostname that does not contain any dots (for example, use http://myproxy rather than http://myproxy.example.com. This allows IE to recognize the URL as part of the intranet zone rather than the Internet zone so that the browser automatically return credentials when challenged rather than prompting the user.
   • Resolve to the IP address of the Edge SWG (Formerly ProxySG) appliance. To accomplish this configuration, you must add an "A" record to your internal DNS server. This associates the virtual URL with the IP address of the Edge SWG (Formerly ProxySG) appliance.
   • (Kerberos only) If you’re using Kerberos in a non-load balancing IWA direct realm, the Virtual URL must be the DNS name of the Edge SWG (Formerly ProxySG) appliance in the Active Directory domain. Typically this is the DNS name of the Active Directory domain that prefixed with the Edge SWG (Formerly ProxySG) appliance computer account name. For example, sg.blue9.local. If you do not use the Active Directory DNS name of the Edge SWG (Formerly ProxySG) appliance as the Virtual URL. Authentication transactions are downgraded to NTLM.
3. Click Apply.

Create an IWA authentication policy

1. From the VPM, select Policy > Add web authentication layer.
2. Enter a Layer Name or accept the default name and then click OK. The first policy rule displays with default settings.
3. Set the action:
   1. In the Action column of the first row, right-click and then select Set. The Set Action Object dialog displays. Click New and then select one of the following authentication objects:
      • Authenticate—Use this option if you do not need to log user IDs for denied requests. With this option, if the policy causes a request to be denied before the user is authenticated, the user ID associated with the request is not available for access logging. 
      • Force Authenticate—Use this option to ensure that user IDs are available for access logging (including denied requests). 
      • If you plan to create a guest authentication policy, create a combined object that contains the Authenticate object and a Permit Authentication Error object (be sure to select All Except User Credentials Required).
   2. (optional) Specify a Name for the authentication object.
   3. Select the IWA Realm from the drop-down list.
   4. Select the authentication mode from the Mode drop-down list. Although you can select Auto to have the Edge SWG (Formerly ProxySG) appliance automatically choose an authentication mode, it is usually better to make a selection that is appropriate for your deployment as follows:
      • Explicit deployments—Select Proxy or Proxy IP. The Proxy IP mode reduces the load on the network because it uses an IP surrogate to reauthenticate clients that have already successfully authenticated. 
      • Transparent deployments—Select Origin Cookie Redirect. This mode redirects the client to the Virtual URL for authentication and uses a cookie surrogate to reauthenticate clients that have already successfully authenticated. The appliance automatically downgrades to the Origin IP Redirect mode for user agents that don't support cookies.
   5. Click OK to close the Add Authenticate Object or Add Force Authenticate object dialog.
   6. Click OK to close the Set Action Object dialog.
4. (optional) Restrict authentication to a subset of client requests, based on source or destination request attributes. The default settings in the policy rule will cause the Edge SWG (Formerly ProxySG) appliance to authenticate all client requests. You can set the Source and/or Destination columns to restrict authentication to a specified subset of requests. For example:
   1. In the Source or Destination column of the first row, right-click and then select Set. The Set Source Object or Set Destination object dialog displays.
   2. Click New and then select an object that represents the subset of requests you want to authenticate. After you select an object, you are prompted to provide details. For example, if you choose the Client IP Address/Subnet object, you are prompted for an IP address and subnet mask/prefix to which this rule is applied.
      
      Tip: When you first deploy your authentication policy, you may want to limit authentication to the source address of a test workstation or subnet. Allowing you to identify and troubleshoot any configuration issues before rolling the policy out into production.
       
5. (optional) Add additional policy rules to refine your authentication policy. A single web authentication layer rule with the authenticate action is all you need to enable authentication. However, there may be some cases where you want to bypass authentication for certain requests and enable it for others. For example, you may have a certain client, subnet, or URL on which you do not require authentication or you may have some custom applications that do not know how to handle authentication requests. In this case, you would add an additional rule to your web authentication layer policy to instruct the Edge SWG (Formerly ProxySG) appliance how to handle the exceptions. For example:
   1. Click Add Rule. A new row appears in the web authentication layer.
   2. Specify which client requests that this rule applies to by setting the Source or Destination columns. 
   3. Specify what the Edge SWG (Formerly ProxySG) appliance should do with a request that matches the source and/or destination setting you have defined by right-clicking in the Action column of the row, selecting Set.
      • If you want to authenticate requests that match the specified source and/or destination request settings you have defined, click New and select Authenticate and click OK. 
      • If you want to bypass authentication for the matching requests, select Do Not Authenticate and click OK.
6. Arrange the rules according to how you want the Edge SWG (Formerly ProxySG) appliance to enforce them by selecting the rule you want to move and clicking Move up or Move down. The Edge SWG (Formerly ProxySG) appliance evaluates the rules in the order in which they appear in the policy layer. As soon as it finds a rule that matches the request, it to enforce the specified action (in this case, either to authenticate or not authenticate the request). Therefore, you should put more specific rules in front of general rules. For example, if you have two rules in your policy—one that is set to authenticate requests from any source or destination and one that is set to not authenticate requests from a specific subnet—you would put the one that bypasses authentication in front of the general rule that matches all requests. 
7. Install the authentication policy:
   1. Click "Install policy".
   2. Click "OK" to acknowledge that the policy was successfully installed.

(Optional) Create an IWA authorization policy

1. Select Policy > Add Web Access Layer.
2. Enter a Layer Name or accept the default name and then click OK.
3. Specify the user or group to authorize (the source):
   1. In the Source column of the first row, right-click and then select Set. The Set Source Object dialog displays.
   2. Click "New" and then select the type of Active Directory object this rule can authorize:
      • To create a rule for authorizing a group, select Group. The Add Group Object dialog displays.
      • To create a rule for authorizing a user, select User. The Add User Object dialog displays.
   3. Select the IWA realm from the Authentication Realm drop-down list.
   4. Specify the name of the Active Directory user or group that rule can authorize:
      • If you know the name of the Active Directory user or group, enter it in the Group or User field.
      • If you don't know the Active Directory name of the user or group, click Browse and select the group from the IWA Browser.
   5. Click OK to close the Add Group Object or Add User Object dialog.
   6. Click OK to close the Set Source Object dialog.
4. Specify whether to allow or deny requests from the specified user or group:
   1. Right-click the Action column.
   2. Select one of the following options:
      • Allow—Select this option if the default proxy policy for the appliance is set to deny proxy access through the Edge SWG (Formerly ProxySG) appliance. (This is the default in a secure web gateway deployment.)
      • Deny—Select this option of the default proxy policy for the appliance is set to allow proxy transactions. (This is the default in an acceleration deployment.)
        
        Note: If you aren't sure what the default proxy policy is set to on your appliance, go to Configuration > Policy > Policy Options.
5. (Optional) Define any additional parameters that you want this rule to enforce.
6. To create additional authorization rules, repeat Steps 3 through 5.
7. Click "Install policy". 
8. Click OK to acknowledge that the policy was successfully installed.
9. One of the benefits of IWA is that it automatically returns authorization information for a user in response to an authentication request. You do not have to perform any additional configuration to get authorization to work. After successfully authenticating a user, the appliance receives a list of all groups to which the user belongs.