OAuth Communications with Symantec Endpoint Encryption 11.4 and above
Article ID: 240321
Updated On:
Products
Issue/Introduction
Symantec Endpoint Encryption has a very seamless "enrollment" or "configuration" flow where the end users are not required to interact much to get the software setup. The method used in the past is via a windows credential that was included for the server-client authentication--this method has been known as "Windows Authentication".
This method works well as long as the account credentials or account never expires. However; Windows Authentication does have a few limitations such as when the credentials may change, or if the credentials expire. Security Requirements may also require these credentials be rotated. Whenever this happens, a new SEE Client would need to be generated as the previous clients will have the old credentials built in.
These limitations are completely overcome with the new OAuth functionality included with Symantec Endpoint Encryption 11.4.
OAuth, or Open Authentication uses a secure token model in which tokens are used for server-client communications to improve security and ease. All tokens are secured, but HTTPS must be used to ensure security on the wire.
Symantec Endpoint Encryption uses encryption unique keys and tokens for each installation. Each server installation will use a completely unique set of these keys and tokens and so when the SEE 11.4 Client is generated by the Symantec Endpoint Encryption Management Server, these unique objects are taken into account. In this way, only the SEE Clients generated by the specific SEE Management Server are ever allowed to communicate.
Once these communications take place, the tokens then are used to establish the validity. The best part of this new OAuth functionality is that it is fully automatic and there is very little to do once the SEE Client has been deployed. From an administrative perspective, there really is nothing to be configured and should work automatically, saving SEE Administrators time and effort managing the SEE Clients.
With the new OAuth configuration, there are no longer concerns for credential expiration.
This document will discuss the following scenarios as well as go over the steps used to configure OAuth and some of these considerations:
Scenario 1: New Environments just starting with SEE 11.4 (Not using SEE 11.3 or older)
Scenario 2: "Both" Windows Authentication and OAuth are enabled (Using both SEE 11.3 or older as well as SEE 11.4)
Scenario 3: Windows Authentication-Only Configuration
Resolution
In order to begin using the new OAuth functionality, open the SEEMS Configuration Manager. We will go over a few scenarios for you to consider depending on your environment.
Important Note on using OAuth: Although all OAuth tokens are fully encrypted, before you configure OAuth to your environment, it is necessary to configure HTTPS to ensure all traffic is encrypted. Even if not using OAuth, HTTPS should be used for a production environment. HTTP-Only options are available for test purposes only. For this, see the following article:
Table of Contents
Scenario 1: New Environments just starting with SEE 11.4 (Not using SEE 11.3 or older)
Step 1: Configure the SEEMS Configuration Manager
Open the SEEMS Configuration Manager and click on the Web Server tab on the left side. The following screen will be displayed:
You will notice that "Windows" is the default setting, meaning Windows Authentication using windows credentials.
We want to configure this so that only OAuth is configured and will be the only method for SEE Server-client communications. This is recommended over Windows Authentication:
Step 2: Configure the SEE Policy to allow only OAuth.
Now that the SEEMS Configuration Manager allows only OAuth, ensure the policy is also configured to allow OAuth.
Because OAuth is disabled by default in the policy, make sure this is configured prior to installing the SEE Client.
If the SEE Client was generated with OAuth, but the policy is configured as Windows Auth, and the SEE Client checks in with the server, it will try to use Windows Auth going forward, so we want to enable only OAuth in the policy.
In the policy, the Advanced Settings will be displayed, set this value to True:
Step 3: Generate the SEE Client to enable the OAuth feature
When you start the SEE Client Communication creation, you are going to see a screen similar to the following page:
Notice there are two fields above, "Server", which is the old Windows Authentication method and "OAuth Server", which is the new functionality for OAuth. In SEE 11.4 GA, it is required to enter both of these fields during the client-creation process, even if you intend to use only OAuth.
NOTE: In SEE 12 and later, the URL changed for the OAuth server to https://[server.example.com]:[portNumber]/SEEIdentityServer. SEE 11.4 clients can still use the old URL to connect to SEE 12.
For the "Server" field, enter the valid credentials here and then once the client is created you can immediately disable this Windows account, or change the password so that Windows Auth will have no chance of success. This will ensure only OAuth is possible.
Also to note, there is a "Preferred Policy Group" setting on this same page which should be configured so when the client checks in, it will check in to a policy that has OAuth configured. In this example, we have a Preferred Policy Group called "Regular Policies" that is linked to a policy with OAuth enabled. This means when the SEE Client checks in, it will be grouped to this group, which is then associated to a policy that has OAuth configured.
The next item to be aware of during the SEE Client creation wizard is when you arrive at the "Advanced Settings" page--on this page you will see the option for "Enable OAuth for Client-Server Communication".
Change this value from "False" to "True" to enable OAuth (the default is false, or disabled) as shown in the screenshot below:
As mentioned, the advantage of using only OAuth is that you will not need to worry about any of the windows credentials expiring, which could cause communications issues.
Now with the policy configured for OAuth, the SEEMS Configuration Manager is set to OAuth only, and the SEE Client was generated with OAuth, you are ready to install the client on your machines and machines should now start checking in with only OAuth and no further action should be required.
Scenario 2: "Both" Windows Authentication and OAuth are enabled (Using both SEE 11.3 or older as well as SEE 11.4)
If you are currently managing SEE Clients that are on versions 11.3.1 or older, and you would also like to take advantage of the new OAuth feature with 11.4 and above, follow the steps here.
Step 1: Configure the SEEMS Configuration Manager
Open the SEEMS Configuration Manager and click on the Web Server tab on the left side. Under "Authentication Mode", select "Both", meaning both Windows Authentication and OAuth will be allowed:
For this configuration, we need to have separate policies configured so that the 11.4 clients will use the OAuth functionality, and the 11.3.1 and older clients will continue to use Windows Auth until upgraded to version 11.4 or above.
Step 2: Generate the SEE Client to enable the OAuth feature
During the SEE Client creation wizard, when you arrive at the "Advanced Settings" page, you will see the option for "Enable OAuth for Client-Server Communication".
Change the value from "False" to "True" to enable OAuth (the default is false, or disabled) as shown in the following screenshot:
Step 3: Configure the SEE Policy to allow only OAuth.
Now that the SEEMS Configuration Manager allows only OAuth, ensure the policy is also configured to allow OAuth.
Because OAuth is disabled by default in the policy, make sure this is configured prior to installing the SEE Client.
If the SEE Client was generated with OAuth, but the policy is configured as Windows Auth, and the SEE Client checks in with the server, it will try to use Windows Auth going forward, so we want to enable only OAuth in the policy.
In the policy, the Advanced Settings will be displayed, set this value to True:
When you create the SEE Client, make sure you specify the proper policy as mentioned in Scenario 1 that would have OAuth enabled. You can simply modify your existing policy, or create a new one if desired, but the new policy will need to enable the feature as the default is disabled. Once a new policy is created, associate the new Group Policy to the new SEE Policy, and then when you build the client, make sure the SEE Client is generated to match a group that will use OAuth.
When you have the 11.4 clients communicating with the SEE Management Server, as long as these clients are associated with the policy that allows OAuth, these will continue to function using OAuth. All the existing 11.3.1 or older clients will continue to communicate with Windows Authentication as specified. In this hybrid environment, you would need to to leave the option in the SEEMS Configuration Manager to "Both" until all clients are upgraded to 11.4. Once all clients are upgraded to 11.4 and are using OAuth, you can then set this to "OAuth" only, and no further clients will use the Windows Authentication. You can then disable the windows credentials used for the previous clients.
Scenario 3: Windows Authentication-Only Configuration
Windows Authentication is not the recommended method going forward given its limitations and considerations for account security requirements.
OAuth is much more flexible in its use and has none of the limitations that Windows Authentication has. However; if you are not ready to use the OAuth functionality, you need not make any changes. The default configuration in 11.4 GA is to have OAuth disabled by default.
This OAuth setting may not always be the default and at some point, OAuth will become the default parameter, so Symantec Encryption recommends switching to OAuth as soon as it is feasible.
Troubleshooting
If you have configured a client to communicate with OAuth, but the client is not checking in, check the policy associated to the machine checking in. Typically this means OAuth is not enabled in the policy and if Windows Authentication was configured in policy, this means you will need to first check in with Windows Authentication, then switch the policy to use OAuth, and then check in again, and this will then start using OAuth.
For further guidance, please reach out to Symantec Encryption Support.
Additional Information
240649 - Symantec Endpoint Encryption 11.4 Dashboard and Reports
| Keywords |
|
| Symantec Endpoint Encryption OAuth |
Open Authentication Symantec Endpoint Encryption |
| SEE OAuth |
OAuth Symantec Endpoint Encryption |
| SEE Open Authentication |
SEE OAuth |
| SEE Client Creation |
SEE Client Creation OAuth OAuth Symantec Endpoint Encryption Symantec OAuth Encryption |
Feedback
