Two-Factor Authentication and OID (Single Sign-On) Configuration for Symantec Endpoint Encryption Web Console (SEE)

Products

PGP Command Line PGP Encryption Suite PGP Key Management Server PGP Key Mgmt Client Access and CLI API PGP SDK Desktop Email Encryption Drive Encryption Encryption Management Server Endpoint Encryption File Share Encryption Gateway Email Encryption

Issue/Introduction

Symantec Endpoint Encryption uses a web console in order to manage Groups, Policies, and Helpdesk operations, such as obtaining recovery tokens.

In order to make using the web console more seamless, you can use Open ID (OID)

Configure Symantec Endpoint Encryption with a third-party Identity Provider (IdP), such as Siteminder that uses the OpenID Connect protocol and allow administrators to log into the SEE Management Console with OpenID Connect-based secure single-sign-on authentication (without the need to authenticate additional username and passwords).

Environment

Symantec Endpoint Encryption 12.0 and above.

Resolution

Each user who is allowed to be authenticated to the SEE Application for OID must also be configured on the OID's template page.
This is the page where the SEE Application is configured for your OID. The users must also have the authentication for this to work.
Ensure that you have performed the required configurations on an Identity Provider (IdP) portal before configuring this page.
Ensure that HTTPS is enabled for communication. OpenID Connect feature for the SEE Management Console is supported only when the communication protocol is set to HTTPS.

Configuration required on the Open ID Connect Provider Configuration page:

Open the SEE Configuration Manager on the computer in which the Symantec Endpoint Encryption Management Server is installed.
Click Advanced Settings and click Authentication from the left navigation pane.
Select the Enable OpenID Connect checkbox.
Enter the Discovery URL and click the Discover button.

The following data is displayed:
Issuer, Authority, Authorization Endpoint, Token Endpoint, UserInfo Endpoint, JWKS URI, and End Session Endpoint.

The End Session Endpoint field is optional and if the value is not displayed automatically, then it can be left blank.
Enter the following in Required Scopes:

openid,profile,email.

To add more scope values, enter them separated by commas.
Enter Client ID and Client Secret that were provided by the IdP administrator.
Enter the domain name that needs to be searched to get the user attribute in User Lookup Domain Names. To add more than one domain name, enter them separated by commas.
Enter the Identity Claim value that was provided by the IdP administrator from the ID Token or the UserInfo Endpoint attribute.

For example, email. If you want to use nested claims such as, address:{street_address}, then while using street_address for Identity Claim, use the format: address.street_address.
Enter the user attribute value in Mapping Attribute that was provided by the Active Directory (AD) administrator. You may use the AD Explorer tool for retrieving the user attribute value.

NOTE: The Identity Claim and the Mapping Attribute values must match, which is a 1:1 relationship. For example, if the Identity Claim email value is user1@example.com and the Mapping Attribute user mail value in the Active Directory is user2@example.com, then the authentication will fail. Both values must be the same for this to work.
Click Save.

Reset IIS after successfully saving the changes (via admin command line, you can run "iisreset" for these changes to take effect.

Troubleshooting

Scenario 1: Discovery URL is not working and does not populate the details.

Solution: Make sure you are using the proper URL here. Copy and paste, rather than type the URL in.
This is a link that you would obtain from your own OID solution, such as Siteminder.

SEE does not use "oauth-authorization-server" for the discovery URL. Make sure it is using "openid-configuration".

For Okta an example may look like the below URL:

https://OKTA-FQDN-HOST-HERE/.well-known/openid-configuration

________________________________________________________________________________________

Scenario 2: Error 400 one redirect URI
When clicking the Single Sign-On button, the page is getting redirected to the wrong page and does not go to the SEE Management Server.

Solution: Check on your OID in your logging to see what the proper URL should be for the SEE Management Server, and make sure this URL is actually being used.

In the SEEMS Configuration Manager, you can check the "Redirect URL" to what it should resolve to.

For example, the following will be displayed for the host "host.example.com", for the redirect URL:

https://host.example.com/webconsole/api/account/oidccallback

________________________________________________________________________________________

Scenario 3: I've configured everything correctly, but still, the changes are not taking effect.
Solution: Make sure you restart IIS after making any changes within the OID configuration. OID affects the webserver in significant ways that require the website to be restarted.
Use "iisreset" as administrator for ease.

"Make sure to restart IIS after modifying authentication settings."

________________________________________________________________________________________

Scenario 4: Everything is configured properly in SEEMS, but it looks like the authentication is failing to recognize me as a valid user at login.

Solution: Check to see if your OID solution has "Zones" enabled.

For example, if you login as an internal user, the system you are accessing the authentication may be from an IP that is not allowed in the OID "Zone".
Work with your OID expert to ensure the machines you are accessing, are allowed within the zones that will enable authentication.

________________________________________________________________________________________

Scenario 5: Unable to login with error about claims and mapped user attributes.
When you click on the "Single Sign-On" button, this will authenticate the current user to the OID solution.
The OID solution in turn will have the user prove their identity. A "Push" request may be provided, and once this is done, the user is authenticated.
At the end of this, the user is then allowed to authenticate. In this case, an error occurs:

"Either the claims are not present or the mapped user-identity attribute value is empty in the IDP."

Solution: If you are seeing this error, check the SEEMS Configuration Manager and look at the "Identity Claim" value.
If this is using a custom claim, try using "email" instead. The "email" attribute is a standard claim that will typically always resolve the user account: