The BHOLD/FIM integration component introduces a self-service portal to request proposed roles. Proposed roles are those that are not yet activated for a user, still available for the user to request them. The request to activate a role in BHOLD/FIM integration leverages FIM approval workflows. This is a big plus, since FIM Administrators will deal with a familiar interface (FIM Portal) to manage their workflows and requests. In addition to that, all user requests can be found in one place under "Manage My Requests".

In this post, we will discuss what is available out of the box from BHOLD (after installing the integration component) and where to find information about that. We will also discuss how to create a Non-BHOLD approval process for BHOLD role requests.

This post assumes you know how to configure FIM policies including Management Policy Rules, Workflows, and Sets. If you don't, the links below are good introduction to know more about this topic.
Also, the post assumes you have the basic knowledge of creating a BHOLD role and link it to an OU.

Out of the box objects

The FIM Service schema gets extended, and "BHOLD_ROLE" is a new resource type that gets created in FIM Service. When a user submit a request to activate a role, a new "BHOLD_ROLE" objects is created or an existing object is modified.

"BHOLD_ROLE" resource type has attributes bound to it. Some of those attributes will determine the authorization workflow that FIM will execute. Those attributes are highlighted in the image below:

The following links discuss the role approval process in BHOLD FIM Integration. They provide a details on how you can configure approval the BHOLD way.

The above attributes are then used in sets filters. The following sets gets created. They use the above highlighted attributes:
Set's DisplayName
_BHOLD ROLE Management - All roles with approval
_BHOLD ROLE Management - All roles with line management approval
_BHOLD ROLE Management - All roles with role management approval
_BHOLD ROLE Management - All roles with security office approval
_BHOLD ROLE Management - All roles without approval

The following workflows gets created:
Workflow stage
_BHOLD ROLE Management - Line Management ApprovalAuthorization
_BHOLD ROLE Management - Role Management ApprovalAuthorization
_BHOLD ROLE Management - Security Office ApprovalAuthorization
_BHOLD ROLE Management - Without ApprovalAuthorization
BHOLD_ROLE Title GeneratorAuthorization

The following MPRs gets created:
Display Name
Action Type
Grant Right
_BHOLD_ROLE Line Management - ApprovalModifyNoYesNoYesNo
_BHOLD_ROLE Line Management - Without ApprovalModifyNoYesNoNoNo
_BHOLD_ROLE Role Management - ApprovalModifyNoYesNoYesNo
_BHOLD_ROLE Security Office - ApprovalModifyNoYesNoYesNo
BHOLD: Administrators can read and update BHOLD rolesAllNoYesNoNoNo
BHOLD_ROLE Title GeneratorModifyNoYesNoYesNo

The reason I'm showing you all those MPRs and workflows is for you to get a notion of what's going on here. It's the same exact approach we have been using for so long in FIM. The same way you configure a workflow to approve creating a new group, can be used when requesting to activate a role. In the next section, we will discuss how to create a non-BHOLD approval process for BHOLD.

Non-BHOLD Approval Process

First off, you need to do is to group together similar "BHOLD_ROLE" objects in a set. The above sets are useful and can be used, however, we will use different attributes. For the sake of this post, we will use the attribute DisplayName. The set criteria will be (DisplayName starts with "MyRole").

Second, you need to create the approval workflow. For the sake of this example, the approver will be the [//Requestor/Manager]. After the workflow has been created, you will need to modify the XOML to include the BHOLD DLL in the definition. Here's how it needs to look like. If you didn't add this reference to this DLL, the approval process will be triggered, however the role will not be activated in BHOLD.

1.<ns0:SequentialWorkflowActorId="00000000-0000-0000-0000-000000000000"RequestId="00000000-0000-0000-0000-000000000000"    x:Name="SequentialWorkflow"TargetId="00000000-0000-0000-0000-000000000000"WorkflowDefinitionId="00000000-0000-0000-0000-000000000000"........xmlns:ns3="clr-namespace:BHOLD.Workflow.Activities;Assembly=BholdFimActivities, Version=5.0.1992.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
3.       <ns0:ApprovalActivity  ......>
4.              <ns2:ReceiveActivity.WorkflowServiceAttributes>
5.                     <ns2:WorkflowServiceAttributesConfigurationName="Microsoft.ResourceManagement.Workflow.Activities.ApprovalActivity"Name="ApprovalActivity"/>
6.              </ns2:ReceiveActivity.WorkflowServiceAttributes>
7.       </ns0:ApprovalActivity>

Finally, create a request MPR with the following settings.
RequestorAll People
PermissionGrant Permissions is checked
Target Resource Definition Before RequestAll BHOLD_ROLE that starts with MyRole
Target Resource Definition After RequestAll BHOLD_ROLE that starts with MyRole
Resource AttributesbholdRequestItemId; Comment; Subject
AuthZ WorkflowThe one we just created

Next time someone requests a role that starts with "MyRole", FIM will ask approval from the requestor's manager.

Note: You can modify the out of the box workflows. When you do that, make sure the XOML has the BHOLD DLL referenced.

Final Remarks

You can configure approvals for BHOLD in so many different ways. The BHOLD way is discussed here Understanding the role-approval process in BHOLD FIM Integration. It is recommended to use this approach. The Non-BHOLD approach I'm demonstrating here is not a replacement, and I'm not trying to compare the two. FIM is a powerful platform and we can configure it in so many different ways. For example, I can add the manager's approval as an extra step for one of the default BHOLD approval workflows. This way I will end up with two level of approvals, which might meet some clients requirements.

I observed one limitation with BHOLD approvals. It is limited to three type of role approvals (Role Managers, Line Managers, and Security Officers). You can also combine different BHOLD role approvers in the same workflow. For example, your workflow can ask approval from the Line Managers, then ask approval from Role Managers. If your client needs more than three level of approvals, then you will end up short and you will have to find a different way to get your approvers.

A supervisor role is a special role in BHold. It allows users who have this role to view other BHold objects, and if given appropriate permissions, they can modify those objects. In this post, we are interested in two things:
  • How to allow a user with a supervisor role to manage other users' roles?
  • How to allow a user to delegate his supervisor role?
For more information about supervisor role, please visit the following link

Creating a Supervisor Role

When installing BHold Core, a default supervisor role will be created, and linked to all Organizational Units.  You can also create your own supervisor role/s depending on your implementation. The link above has some recommendations from Microsoft regarding Supervisor Roles.
To create supervisor role, you need to login to BHold Core Components, and follow the following steps:
  1. On the left hand side, click on Roles
  2. Click on Add
  1. Fill in the Description, and check the box for supervisor role
As I have mentioned earlier, the default supervisor role can manage all objects, therefore by default it will be linked to this object we are creating.
  1. Click OK

Linking Supervisor Roles to Organizational Units

We would like to allow Ellen (our test user) to manage other users. Right now, using the self-service portal, she can only request roles for herself and view her own roles.

Below are the steps you can take to allow Ellen to manage other users' roles:
  1. Create a new OU under the root "MySupervisorOU"
  1. After the OU has been created, expand Roles, and click Modify
  1. Search for, and add "MyFirstSupervisor" to "MySupervisorOU"
  1. Click Add to proceed
  1. Expand Users, and click Modify to Add Ellen to this OU, which will automatically give her "MyFirstSupervisor"
  1. Lets select the OU/s "MyFirstSupervisor" will manage. For that, I created another OU, called "TheSupervisedOU" and I will add "MyFirstSupervisor" to it

Now, Ellen will see a new tab called "Manage Users", and she should be able to add/revoke roles for those users

Allow users to delegate their supervisor role

Delegation is basically assigning user's role to someone else to perform his/her job. In the example above, we linked "MyFirstSupervisor" to "MySupervisorOU" as an effective role, therefore, Ellen will not be able to delegate it.

For that, we will need to change the link between "MyFirstSupervisor" and "MySupervisorOU" to be proposed. We have to go back to step 3 and 4 above, remove "MyFirstSupervisor", and Add it again. However, this time we will choose it to be proposed.
After you click Add, you should be able to expand the roles, and activate it
 Now, Ellen should be able to go to the self-service portal and delegate the role to someone else. As a result, whoever she delegates the role to, should be able to add/revoke roles for those users in "TheSupervisedOU".


First of all you need to get an account that has the right permissions to create a Lync account in Lync server, then we need to create a windows remote connection to the Lync server, so we can execute PowerShell commends in Lync Management Shell:

SecureString password = new SecureString();
string username = "user";
string str_password = "password";
string lyncserver = "lyncserver.mytestdomain.loc";
string liveIdconnectionUri = "https://" + lyncserver + "/OcsPowershell";

foreach (char x in str_password)

PSCredential credential = new PSCredential(username, password);

WSManConnectionInfo connectionInfo = new WSManConnectionInfo((new Uri(liveIdconnectionUri)), "", credential);

connectionInfo.AuthenticationMechanism = AuthenticationMechanism.Default;

Runspace runspace = System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace(connectionInfo);

PowerShell powershell = PowerShell.Create();

powershell.Runspace = runspace;

After creating the connection, it’s time to execute the command (Enable-CsUser) to create a Lync account:

PSCommand command1 = new PSCommand();
command1.AddParameter("Identity", "MYTESTDOMAIN\\USER");
command1.AddParameter("RegistrarPool", "registrpool.mytestdomain.loc");
command1.AddParameter("SipAddressType", "SamAccountName");
command1.AddParameter("SipDomain", "MYTESTDOMAIN.loc ");
powershell.Commands = command1;




To make sure that the account created in Lync server refer to Lync attributes in the Active Directory for the user.

I hope you get the benefit from this post, please contact me for any question.


Recent Bloggers

  • Website This email address is being protected from spambots. You need JavaScript enabled to view it.
  • This email address is being protected from spambots. You need JavaScript enabled to view it.
  • This email address is being protected from spambots. You need JavaScript enabled to view it.
  • This email address is being protected from spambots. You need JavaScript enabled to view it.
  • This email address is being protected from spambots. You need JavaScript enabled to view it.

User Login