Video Screencast Help

Active Directory Authentication for whole group

Created: 20 Feb 2012 • Updated: 24 Feb 2012 | 6 comments
alexovi4's picture
This issue has been solved. See solution.


Can I configure DLP 11.5 to authenticate users from AD group (for example, DLP_ADMIN)?

So, the users in DLP_ADMIN group may changes, but current users can connect to web-console and configure the DLP with appropriate role.

Thank you

Comments 6 CommentsJump to latest comment

pete_4u2002's picture

yes, check this article

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.

alexovi4's picture

Thank you for reply.

My AD intergration is working.

In your message I don't find the information how I can assign a role to the group from AD, not for single user.

Do it possible to assing role to whole group in AD?

pete_4u2002's picture

is this information helpful?

To assign a role:

 Log into the Enforce UI
Go to Administration -> Users -> Users
Select the User in question
Check the box for the appropriate role for that user and save changes

If no roles are set up, you will need to set one up under Administration -> Users -> Roles. Click the Add a Role tab. Then name and define your role.  Save changes when you are finished.

alexovi4's picture

Your information is helpful. Thank.

But I'm searching something another: I don't want to add in web-console every user from DLP_ADMIN (dlp_admin_1, dlp_admin_2, etc) and than add to this users role, I want to assing Role to group DLP_ADMIN.

Keith Reynolds - ExchangeTek's picture

AD integration will not allow you to do this.  It's really for authentication only, not for defining access groups for DLP users.  You will still always need to create the user in DLP.

Now the question becomes, outside of using the GUI itself, how can I use an AD User Group to manage DLP user accounts?  I had a discussion with someone trying to do exactly this.  In theory, you could use several methods outside of DLP to automatically create user records and assign them to a default role.  We're talking about a scheduled job that manages the users through direct database access based on results from an LDAP query.

In most cases, the development effort is probably not worth it when weighed against the effort it takes to manually administer users.  Plus, it opens a whole lot of risk with regards to users being accidentally given access to DLP by nature of them being improperly added to that AD group.  It takes the control of access out of the administrator of the DLP system, and puts it into the hands of whomever administers the AD group.

I'll repeat a theme that I seem to espouse on a lot of my posts: Can it be done?  Most likely.  But should it be done?  There's probably a lot of good reasons why you can't easily do it.