Skip to Content
Author's profile photo Matt Pollicove

Using VDS to display ROLE Validity

As has become my habit, I’ll start this entry off with a quote:

“Impossible” is a word that humans use far too often.” – Seven of Nine

A few weeks ago there was a thread on the IDM forum that asked about using the Virtual Directory Server (VDS) to display a user, their roles and most importantly, the expiration of those roles.

I thought that this was not possible to accomplish and stated so in the discussion thread, but it’s been nagging at me, as has the idea of doing some writing about VDS, which I’ve had a love/hate relationship since it was the MaXware Virtual Directory. I’ve often called it part of the “black magic” of IDM, but really, once you get your arms around it. It’s not that bad. So I started playing around with it a bit and was able to come up with a configuration that works.

With that being said, we’ll stop for one more quote and then be about it…

“The difficult we do immediately. The impossible takes a little longer.” – Motto of the US Army Corps of Engineers.

Before we begin, a couple of notes:

  • I designed this around SAP IDM 7.2 SP8 / VDS SP8
  • My IDM instance is using SQL Server 2008, so if you’re running this against an IDM based on Oracle there might be a couple of changes to be made.

To start, load up the VDS front end and Select File / New and then Database from the Group column and Generic Database from the Template column. Click OK. Fill out the Parameters and you should have something that looks like:

database template.png

I’d like to point out a couple of things here:

  1. Note that if you’re running VDS on a server with Active Directory, Open LDAP, any other LDAP or VDS running on Port 389, you’ll wind up with errors later on. Use another port. 1389 is one of my standbys, but usually stuff in the 7000 range is good too. Even though you might be thinking, it’s DEV/LAB/SANDBOX and it doesn’t matter, trust me it does. You’ll be going to production and things will not be working. This is the first thing to check. Do yourself a favor and check with your Network Admins early so that they can assign you a good block of ports for VDS operations.
  2. Note in the database connection string that we are using mxmc_oper. In order for this configuration to work, you must use the OPER account. I could probably find a way to make it work under mxmc_rt, but it would require a ton or so of custom coding, and that’s not really my style.
  3. For whatever reason I never changed the Display name value, use whatever makes you happy.

After you click OK, you’ll be prompted to save your configuration.  Give it a valid file name and save the file in the default location.

Now, take a look at the Data sources node, and dive down past Singles to the Database node (Note this will be different if you changed #3 above) and click on the Database tab. Click the Get Get database schema button, find the idmv_link_ext view and select OK and for testing purposes add mcValidTo is not null to the Additional filter field. When you’re all done, hit Apply.

database node.png

So what does this do, anyway? It tells us to look in the specified scope (idmv_link_ext) view within the identity store database which holds assignment information and to only include those entries where the mcValidTo column is not populated. This is good for troubleshooting since it will show only entries with Roles that have expiration dates (I seldom use them in my projects somehow, so this was helpful to me, your mileage may vary.) You should also notice a constant for the database connection (%$const.MX_DS_DATABASE% and a JDBC Driver populated (depends on what database you are using)

Now, pop over to the Data source attributes tab. Go down to the Default database parameters section and select Define… When the window appears, scroll down in the Available Attributes column and highlight mcThisMSKEYVALUE and click Add attribute. Make sure that the Attribute types is set to CN=.

The screen should look like this:

define parameters.png

If it does, go ahead, click OK. Congratulations, you just set up the parameters that are passed to VDS for defining the virtual LDAP DN.

Now go down a little bit in the VDS tree and find the Rules Node, expand the node and click on the FullAccess node and choose the Search Operation tab.

Rules node.png

This will allow us to set the Access controls on the Virtual Directory. Note that you can set up a virtually unlimited number of access rules, but we’re only interested in the default rules. Set it up the way I’ve specified here. You’ll have to enter these one at a time.  Make sure that you double check your spelling! This could result in some issues later on. 🙂


If you want, feel free to set this up for the FullReadAccess rule as well.Incidentally, what we’ve done here is set up a listing of all the attributes that can be viewed when this configuration is accessed by an LDAP browser or other LDAP enabled application.

Now we need to map the FullAccess rule to a user. To do this, go to User groups and expand the Authenticated node and double click on the admin user that is there, click on the Reset button to define a password.password set.png

We’re nearing the finish line now. It’s time to construct the virtual tree and it’s pretty easy for our purposes, just use the default that you see in the example, which uses one static node (O=db) and one Dynamic node (*)

When this all done, start (or update if the configuration is already running for some reason) your configuration using the controls on the top of the screen. Now take a look in the LDAP browser and drill down (make sure you’ve filled in the credentials you set up before) and take a look. You should see something like this:

ldap browser.png

If you’ve done everything correctly, you should see some results. I threw this together fairly quickly and tested it but there could be a couple of holes.  If there’s any issues, let me know and I will update the entry.

As time permits, I’ll look into expanding this example to demonstrate more functionality, some of the things I’m thinking about are:

  • Adding access rules
  • Changing the Virtual Tree structure
  • Writing back to the Identity store
  • Changing the mapping of attributes

I might not do all of these using this particular example, but I would like to show this functionality. If there are other things you’re interested in achieving with VDS, let me know and I’ll try to write on it.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.