BHOLD SP1 Core Portal Role Management for Dummies

I’ve had the rare luxury of time in learning BHOLD SP1 for a customer recently and I thought I’d share the basics of what I’ve learned about the product. There’s very little in the way of information in the public realm about BHOLD SP1, particularly as Microsoft have made significant changes to the database schema for Service Pack 1 of BHOLD, so I thought I’d share some learnings.

Beware, this is a ‘BHOLD for Dummies’ scenario where all you might like to do is develop a quick scenario to show off BHOLD’s capabilities in role management. This blog incorporates the following key technologies:

1. BHOLD Core Portal
2. FIM Metaverse with 4 Management Agents (1 x AD DS, 2 x BHOLD, 1 x FIM Portal)
3. Active Directory (AD DS)

Essentially, what I’m attempting to demo to a customer is the ability to quickly provide users access to applications using the BHOLD Core Portal without performing any permissions, group or OU membership changes in AD DS. The key scenario is being able to show how the BHOLD Core Portal can use its powerful role management capability to affect change into a group in the FIM Metaverse. After a group is updated and available with membership in the FIM Metaverse, it can then be turned into whatever a customer wants using code. BHOLD is essentially performing a task whereby it imports Active Directory Users, and an Organisational Structure (SQL, AD DS or 3^rd party connector) to generate ‘role based access’ to applications and permissions in the form of a FIM Metaverse group membership. That’s all it does essentially, it’s very powerful but at the same time very simple.

I’ve setup my demo to achieve the basic scenario:

The above represents a scenario whereby I import both Users and a basic AD DS OU (flat) structure into the BHOLD database so I can quickly get started in demonstrating working with BHOLD OUs. I’ve seen other scenarios whereby others have used a SQL database to generate either a user and/or a sample BHOLD OU structure. For the purposes of simplicity (this is for dummies right!), I’ve kept it to only FIM, AD DS and BHOLD.

So boiling it down: Users and OUs go in, group membership comes out!

Part 1: Bring your Users and OUs from AD DS into the FIM Metaverse.

If you’d really like to cheat, get a FIM R2 SP1 platform installed and then run the ‘Quickstart’ PowerShell command which will essentially install an AD and FIM Management Agent and configure it for a Self Service Password Reset (SSPR) scenario. It’s very easy and the QuickStart source code comes with the FIM R2 SP1 media – you can find how to get this scenario working by following this link: http://technet.microsoft.com/en-us/library/jj134276(v=ws.10).aspx

For reference, my AD DS and FIM Management Agents are configured very simply like the following:

I’m cheating a bit here, because BHOLD actually needs a minimum of two attributes to get a working BHOLD OU working in the BHOLD database ‘B1’:

1. Display Name (I’m sourcing from an OU’s name attribute)
2. Company (I hard-code this with a string ‘value’ of simply ‘Kloud’). I’m using a FIM Portal Sync Rule to get the flat string value ‘Kloud’ into the Organization Metaverse object (not in the screenshot).

After this is setup, there should be a populated ‘Person’ and ‘Organization’ Metaverse entry similar to the following:

Person:

Organization:

Eagle eye observers will note I’m actually not bringing across any correlation between the ‘Person’ and the ‘Organization’ ie. that ‘Michael Pearn’ belongs to ‘Identity Management’ at all because essentially it doesn’t really matter for our demo.

It just means it will add one more step whereby I have to add person: ‘Brendan Carius’ to a BHOLD OU called ‘Management’. We’re just sourcing BHOLD OUs from somewhere that’s not SQL. Keeping it really, really simple. Also, AD DS OUs are limited in that a user is generally only a member of one AD DS OU at a time (not including the parent hierarchy). A user however can be made a member of multiple BHOLD OUs so this is why I’ve purposefully kept AD DS OU import ‘flat’ and not bring across user membership.

So run an AD DS Management Agent import, confirm that both a basic Person and Organizational objects exist in the Metaverse and have attributes similar to the above.

Step 2: Create BHOLD Management Agents and Provisioning Code

This step will consist of two major tasks:

1. Create a Metaverse Project Extension to provision ‘Persons’ and ‘Organizations’ to the BHOLD connector space ready for export to the BHOLD database
2. Create the BHOLD Management Agents (using the BHOLD Access Connector MA template, installed by the BHOLD SP1 Access Connector MSI installation)

Substep A:

Create a basic Metaverse extension with the Microsoft LAB provided code and compile it in Visual Studio 2012 (http://technet.microsoft.com/en-us/library/jj853089(v=ws.10).aspx). Update the code to reflect your Management Agent names in your FIM Sync engine.

Substep B:

1. Create the two BHOLD Management Agents (1 for OUs, 1 for Users and Groups) and configure them with the following attribute mappings:

BHOLD Org Unit Management Agent

• Select only the ‘OrganizationalUnit’ part of the BHOLD MA:
  

• OUs ‘go in’ to the BHOLD database:
  

BHOLD User Management Agent:

• Select both the ‘Group’ and ‘User’ Object Types
  

• Users go in, Group memberships come out!
  

2. At the end of this step, you should have 4 Management Agents configured like this:

The last part will be to create some ‘Export’ run profiles for each of the Management Agents. Then run an AD DS MA ‘Full Import’ and ‘Full Sync’ cycle and you should have some pending exports in both of your BHOLD MAs. Run an export of these MAs and you should now have some users and BHOLD OUs created in the BHOLD Core portal.

Step 3: Confirm Users and BHOLD OUs are created in the BHOLD Core Portal

Time now for a basic sanity check to ensure that you have BHOLD Users and OUs to play with. Open up the BHOLD Core Portal on your BHOLD server.

1. Login to BHOLD core website –> click ‘Model’ –> Click ‘Users’. Click the magnifying glass search button:

2. Login to BHOLD core website, click ‘Model’ –> Click ‘Organizational Units’. Click the magnifying glass search button:

OK, it’s looking good. The BHOLD OUs have a very flat hierarchy (ie. all OUs have a parent BHOLD ‘root’ OU which is the very ‘top of the tree’). This could be solved easily into a more complex hierarchy of multiple levels but for this demo not necessary (plus others have documented how this can be achieved). The next part will be to create a basic ‘BHOLD application’ with some permission ‘groups’ which we’ll export back to our FIM Metaverse as group memberships.

For reference, each time a new BHOLD OU is created, an ‘MR Role’ is automatically created with the OU. Also, each time a ‘BHOLD user’ is created, a ‘PR Role’ is automatically created with that user. Both ‘MR Roles’ and ‘PR Roles’ can be found under: Model à Roles:

Step 4: Create BHOLD Applications & Permissions

For this scenario, every time a new BHOLD OU is created (either manually or from an import from the FIM Metaverse) it will automatically create an ‘MR Role’ for that OU. This is the key bit for our demo – we’re going to make life simple and use this automatically created role to assign a ‘BHOLD application’ and a ‘BHOLD permission’ to that role and therefore assigns users to that application permission.

Substep A: Create your BHOLD application:

1. Create a new application by clicking ‘Model’ à ‘Applications’:
   

I used data values of Protocol = SOAP and Object type = User.bholdDefAlias, as I found that would create me a BHOLD account with the correct ‘Alias’ type (more on this later).

2. Click ‘OK’ when complete.

Substep B: Create a BHOLD Permission:

This essentially represents a FIM Metaverse Group as you assign users (via BHOLD OUs and Roles) to Applications via a BHOLD Permission object.

1. Click ‘Modify’ next to the ‘Permissions’ entry when you’re in the ‘Application’ settings (in my case my ‘O365 Production’ Application):

2.  Create a basic label for the Permission (this essentially becomes your FIM Metaverse Group Name). My Permission name in this example is ‘B2 License’:

3. Click ‘Add’ when the Permission object is completed. The default values for Maximum number of roles = 0 and Maximum Number of users = 0 represents an unlimited value.

4.  You can confirm that there are now Permission objects assigned to that Application by checking: ‘Model’ –> ‘Permissions’ then filtering on that Application using the drop down box and ‘magnifying glass’ icon (in my case ‘O365 Production’):

Substep C: Assigning the Permission to the MR Role

I’m going to now link the Application, Permission and MR Role Objects to tie my user ‘Brendan Carius’ (who is a member of the ‘Management MR Role’).

1. Confirm the user ‘Brendan Carius’ is a member of the MR Role object. Click ‘Model’ –> ‘Roles’ –> MR-<name>
2. Click ‘Modify’ then add in a user (or a dozen!) to that MR Role object.
3. Confirm a user appears in the list for the MR object:

   

4. Now we will assign that MR Role object to the Permission ‘B2 License’. Open up the ‘Model’ –> ‘Permission’ –> e.g. B2 License:

5. Under Roles click ‘Modify’, then add in the MR role from Step 3. I’m adding in the ‘MR Management’ role to this Permission object:

6. Confirm the value has been added successfully at the top of the screen:

7.  You can now confirm that due to the test user (my user ‘brendan.carius’) being a member of the MR Role ‘Management’ object now has the ‘Permission’ object to that application in his profile. Confirm by browsing ‘Model’ –> ‘Users’ –> < Test User> then under the ‘Permission’ there should be the example added in:

8.  Confirm that user now has been automatically created into an Account in the BHOLD section. Browse ‘Model’ –> ‘Accounts’ and the alias for the user should match their ‘sAMAccountName’ from Active Directory.

This seemed to be the key essential element missing from my previous failings with BHOLD SP1, if the account does not appear in the ‘Accounts’ section, then the ‘Permissions Object’ will not flow membership to the ‘FIM Group Metaverse object’:

9.  Now run an Import Run profile on the BHOLD Users Management Agent and then a Full Sync, and in the FIM Metaverse Search, that user should now be represented in both the FIM Groups called ‘B1 License’ and ‘B2 License’:

10.  Checking the membership of both the ‘B1 License’ and ‘B2 License’ groups in the Metaverse should now reveal Brendan Carius to be a member:

11.  Well, step 11 is up to you! Write code to then use that membership to create either groups in AD DS directly or straight to a third party application over an extensible Management Agent (ECMA 2.0, 2.2 or Powershell).

This is just a ‘quick and dirty’ intro to BHOLD to help demystify some of the terminology and use of the BHOLD Core Portal.  I’ll be blogging about more advanced scenarios and techniques in weeks and months to come.  Good luck!