Building an LDAP/AD Group Membership Report in Guardium

 by John Haldeman, Practice Lead


Guardium Entitlement Reports are a useful feature that help you determine what privileges have been assigned in your databases. It's primary value is in helping you create standardized reporting for entitlements based on the database catalog information in each database without you having to create custom scripts.

This being said, that's all Guardium does - query the database catalogs of the databases you register and shows you that information. Certain database types, MS SQL Server for instance, may obscure who the end user that has a certain privilege is because the database catalog just has a listing for the groups assigned, not the users in those groups. An example is show in figure 1. A role for a MS SQL Server database is shown to be assigned to a WINDOWS_GROUP. Invariably, the next question becomes: who is in that Windows group, and can I see that information in the same report set and environment I am getting delivered to me anyway rather than having to look up the information in my corporate directory server separately.

Figure 1: A Guardium Entitlement Report showing a role assigned to two groups: TESTDIR\testgroup1 and TESTDIR\testgroup2 - Who are the users in those groups?

Building a report on that group membership is what this post is all about. You should be warned though: Guardium is not very good at this. In this post you will see mechanisms to try and help make this happen but keep in mind that these mechanisms were not originally designed to fulfill this specific use case. So, it may start to feel a little awkward in making this happen.

Guardium V10 - Micro Tips #1 - RHEL 6

by John Haldeman, Practice Lead

Everyone by now knows that Guardium V10 has been released. It's an exciting release with a lot of features. I expect to see a lot presented and written on the big features like the new UI, file activity monitoring, query rewrite, and new vulnerability assessment data sources, etc. in the next few months. What I want to take some time to do on this blog is talk about the little features that might not get a lot of attention but can make a difference in the everyday lives of Guardium administrators and practitioners like me. I'll be calling those Micro Tips, and this is the first one.

Since I have just finished deploying a virtual machine in my lab environment for V10, let's talk about the operating system and virtualization (btw, if you want a step by step guide for the installation of Guardium V10 and some things that have changed since V9, this blog post is a great resource. One particularly nice thing is that the imaging process is now completely unattended - no waiting to enter passwords half way through the install process. That is a great decision.)

Guardium V10 got an upgrade in it's OS from RHEL 5 to RHEL 6 (RHEL 6.5 to be exact). Since you never really get to touch the underlying operating system, this might be transparent and not matter to you. That being said, it does actually make a difference for some using VMWare deployments using newer types of virtual adapters. If you want to use paravirtual SCSI adapaters (as described here) and VMXNET3 type virtual network adapters (as described here), you should now be able to do that a lot more easily. Those drivers were included in RHEL6, but not RHEL5 by default.

Note, in the case of VMXNET3 adapters, you could enable them in the past with some awkward additional steps, but now since it is running on RHEL6, it *should* come packaged with a VMXNET3 driver and work out the gate.

Note that I have not confirmed this - my current lab environment doesn't have those options. Theoretically the Guradium organization could have taken the drivers out, but I don't see why they would. I will try and confirm they are in there and update this post.