Data Loss Prevention

I have potentially hundreds of users that need to access the DLP enforce server (for system administration, managing incidents, etc). It looks like the only way to add users/roles is to add them manually. Is there a quicker way of doing this? Perhaps by using groups instead of users?

I don't think you can use AD integration with the administrator users. Your best bet might be to create a user for each type of admin and distribute the same credentials to each user of the same type. Although that kinda kills auditing. Have you checked the user/admin guide for information?

You have to create a role that has adminstrative rights then you create the user in the DLP system and assign them the role.

I haven't found a way to leverage AD groups for security -- > Example being create a group in AD called DLP Admins and then assign the DLP Admins group to the Admin role in DLP.

Would be interested to find this out

I was able to implement AD integration. So you first need to set up the krb5.conf file (for linux) and then add each user manually and assign roles to them (tedious process). Unfortunately, this does not scale well for hundreds/thousands of potential users that will be using my system (I want to allow content owner to respond to an incident and remediate it).

At the minimum, I want to to do this using groups so that I assign roles to members of a group and don't have to add each user manually. As a bonus, I would like to have members of an OU prepopulated into the DLP system into a limited role.

Sounds like you might have to write a script to edit the krb5.conf file based on a [scheduled?] AD query. That would add the credentials automatically and scale well.

Which version of DLP are you using?

Here's a site with some info about AD querying in Python...it doesn't look as complicated as I originally thought but I'm no scripting expert so what do I know?

http://tgolden.sc.sabren.com/python/active_directory.html
http://tgolden.sc.sabren.com/python/ad_cookbook.html

And for VB

http://msdn.microsoft.com/en-us/library/w4y82e8a%28v=vs.71%29.aspx
http://www.vbdotnetheaven.com/uploadfile/ecabral/adandnetinvb11112005020216am/adandnetinvb.aspx

Once you nail a query to print all the users according to group, then you should be able to do some fancy formatting to make the krb5.conf file happy.

Hopefully these will help and hopefully it'll be less tedious to do than adding all your users manually =]

~xlloyd.

krb5.conf is actually used to define the domain name and domain controller host. I've been trying to find a config file where Vontu stores users. I couldn't find it. This makes me think it's probably stored in the oracle db. Checking that now...

I'm using version 10.5 for Linux.

ooooh darn >_<

There's a table in the database which stores the user info.  You could write a script to auto-load a large list of users directly to the user tables.  There are several though, so it's going to take you some development work.  We have done this successfully for a client of ours faced with the same issue.

I would challenge this a little bit though with regards to why you need so many users in the system. 

~Keith

Yep, just realized that the users are stored in the db.

>> I would challenge this a little bit though with regards to why you need so many users in the system.

When an incident is found I want to auto cut a ticket to the team that owns this data (pulling information from file share attributes) and give them access to view and respond to the incident.

Depending on what types of data you're looking for, you certainly want to consider PCI compliance with regards to what those users are going to be able to see.  Obviously, giving someone access to view incidents with Credit Card data has implications to your company with regards to that issue.  If that's the case here, you'll want to vett this with your Audit team.  You run the risk of granting someone access that you didn't mean to if you systemize this.

You're also going to need to default that new user to a specific role, so you'll want to create the proper filtering in that role so that they only see the incidents that you want them to see (mark a Custom Attribute in the system for the incident that the role filters on, etc).  Automatically generating or editing a role is probably going to be far too difficult, so be sure that's defined up front.

Good luck with it...I'd be interested to hear how it works out.  Where we did this before was to just do one-off batch loads of users, so it was a little less involved.