Tips on setting up Active Directory Authentication Data Loss Prevention
Last Updated April 20, 2018
Contains tips on setting up and troubleshooting problems with Active Directory authentication in Symantec Data Loss Prevention (DLP)
The following are some items to verify when setting up Active Directory authentication for DLP:
1) Realm names must always be capitalized
When configuring your domains for AD authentication in DLP it's very important that all domain names be capitalized. This applies for domain (realm) names entered on the System Settings page in the DLP UI and also for domains listed in the KRB5.INI file.
2) Include the file name when specifying the path to the KRB5.INI or KRB5.CONF file.
It is necessary to include the name of the file when specifying its location in the System Settings page of the DLP UI. Failure to do so may result in login issues with all all users, including the DLP Administrator account.
3) Domain user names entered for login must match the user names defined in DLP.
When setting up Active Directory authentication you need to make sure that domain user names match what has been created in the Users section of the DLP UI. Also remember that DLP user names are case-sensitive even if Active Directory is not.
For example, in DLP you can define two apparently identical user names; Jsmith and jsmith. The difference is only in the case of the first letter, but DLP considers them to be unique since the user names are case-sensitive. Both names, if entered, would authenticate against a domain user name jsmith. However, if the DLP user is created as JSMITH and you attempt a login as jsmith you will get a login failure message.
4) Users must be part of a role in DLP to be able to login
It is not sufficient to create a user in Vontu that matches an existing domain user. The user must also be assigned to a role within Vontu, otherwise you will be unable to login.
5) After configuring DLP for Active Directory authentication, restart the Vontu Manager Service.
(For example: On Linux with DLP version 9, this is done with the command "service VontuManager restart". On Windows, do restart the service from the task manager.)
6) Try using /etc/krb5.conf if Enforce is a Linux machine. Check C:\Windows\krb5.ini if Windows machine.
When the Enforce server is Linux, the machine may try to use the file /etc/krb5.conf instead of the krb5.ini file in the /opt/Vontu/Protect/config directory. Try editing that file and specifying it (full path + filename) in the Enforce interface. (You may also wish to rename the krb5 file in the config directory so it cannot accidentally be used.).
For same reason, if the Enforce server is Windows, a previous copy of krb5.ini exist in C:\Windows. Try editing that file and specifying it (full path + filename) in the Enforce interface.
7) Use the "kinit" utility to test
In version 9, see the Administrator's Guide (chapter 2) for more information on using the "kinit" utility to test, as well as how to configure the system for Active Directory integration. This utility will help diagnose whether authorization is successful or not. Unless kinit shows a successful authentication, you are not likely to be able to log in from the Enforce interface.
8) In Windows, configure Vontu services to depend on Oracle services
If Vontu services come online before all the Oracle database services, AD logins might not work until the Vontu services are manually restarted. In this case, it is recommended to set the “Vontu Manager” service to have a dependency on the “Oracleservice[username]” service (usually OracleserviceProtect).
9) Check port connectivity
For the authentication process to succeed, UDP port 88 must be open between the Enforce server and the KDC (domain controller). Note that testing with kinit will not reveal this problem, because kinit is able to function over TCP port 88, whereas the Enforce server must use UDP port 88.
Imported Document ID: TECH220609
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe