What's New in Microsoft BHOLD Suite SP1
Applies To: Forefront Identity Manager
Microsoft BHOLD Suite Service Pack 1 (SP1) introduces a number of new features that make it even easier to deploy role-based access control (RBAC) in your organization. BHOLD Suite provides more powerful role management as part of the BHOLD Core module. In addition, the functionality of the BHOLD FIM Provisioning module has been replaced by the Access Management Connector, which simplifies configuring data flow between BHOLD and Forefront Identity Manager 2010 R2. BHOLD Suite SP1 also includes changes to the BHOLD Model Generator.
Previously, the BHOLD FIM Provisioning module was responsible for automating role management. In SP1, this feature has been moved to BHOLD Core and significantly improved. BHOLD Core now manages three types of roles:
The following sections describe these roles and how BHOLD Core works with them.
When a new organizational unit (orgunit) is created in BHOLD, BHOLD Core creates a corresponding membership role which is automatically linked to the users who belong to the orgunit. This allows you to link permissions to that role that are appropriate for the members of the orgunit.
For example, when an orgunit named Sales is created, BHOLD Core automatically creates a role named MR-Sales and links it to the Sales orgunit. (The MR- prefix is used to indicate that MR-Sales is a membership role.) You can then link permissions to the MR-Sales role. When users are added to the Sales orgunit, they automatically receive the permissions linked to the MR-Sales role. Conversely, when users are removed from the Sales orgunit, they lose the permissions linked to the MR-Sales role.
It is important to note that users can belong to more than one orgunit, and so receive permissions linked to the membership roles of those orgunits. This makes it easy to manage the permissions of users both according to their placement in your organizational hierarchy and also by their assignment in other groups, as well.
While membership roles are created automatically and linked to their respective orgunits, they can be managed like any other role, and so can be modified, linked, unlinked, and deleted as needed.
BHOLD Core does not enforce uniqueness of orgunit names over time. Consequently, if you rename or delete an orgunit, it is important to rename or delete the corresponding membership role to ensure that it will not be inadvertently assigned to members of a new orgunit that shares the name of an orgunit that no longer exists.
Much like membership roles, personal roles are created when a new user is created in BHOLD. You can then link permissions to that role to provide the individual user access to systems and data that would not be otherwise granted by membership or attribute roles.
For example, when a user named Kim Akers is created, BHOLD Core automatically creates a role named PR-Kim Akers (the PR-prefix indicating a personal role) and links that role to Kim Akers. You might then link a permission to that personal role that gives Kim Akers access to a personal folder on a file server.
Even though BHOLD Core creates and links personal roles automatically, it does not manage them otherwise, and so you can rename, link, unlink, and delete them. As with membership roles, it is important to manage personal role life cycles, so that when a user’s name is changed or the user is removed from BHOLD, the corresponding personal role is renamed or deleted.
Attribute roles provide a method for automatically assigning roles according to categories that users belong to. These categories are assigned to users by means of attributes of the users’ records in BHOLD Core and specified in the Windows registry value B1ManagedAttributeRoles (in HKEY_LOCAL_MACHINE\Software\Wow6432Node\bhold\b1Core). When a user is created or modified in the BHOLD Core database, determines if attributes in the record match the attributes specified in the registry and, if so, creates a new attribute role based on that attribute (if one does not already exist) and links that role to the user. By default, this role is managed by BHOLD so that the user is unlinked from the role if the attribute is changed in the user’s database record, but this feature can be disabled to permit direct management of attribute role links.
For example, if you want to assign roles based on users’ job titles and rank, you could create JobTitle and Rank attributes for the user object. To configure BHOLD Core to create attribute rules for these attributes, you would edit the B1ManagedAttributeRoles registry value to show the names of the attributes that you want BHOLD Core to create roles for and the prefix that is used to distinguish the attribute rule. In the case of the JobTitle and Rank attributes, the registry value could be
JobTitle,JT-;Region,Rgn-;. When a user is added with the JobTitle attribute set to Analyst and the Region attribute set to Eastern, BHOLD Core creates the roles JT-Analyst and Rgn-Eastern, if necessary, and links the new user to those roles. If the user is promoted to Senior Analyst and that new status is recorded in the user’s JobTitle attribute, BHOLD Core unlinks the user from the JT-Analyst role and links the user to the JT-Senior Analyst role.
Access Management Connector
In earlier versions of BHOLD Suite, synchronization of data between BHOLD and FIM was handled by the BHOLD FIM Provisioning module. This module consisted of two Windows services that made use of intermediate SQL database tables. Configuring FIM to work with BHOLD FIM Provisioning required creating management agents (MAs) that accessed these SQL database tables directly.
In BHOLD Suite SP1, the BHOLD FIM Provisioning module has been replaced by the Access Management Connector. The Access Management Connector that allows the BHOLD Core database and FIM to connect directly through one or more MAs, rather than relying on intermediate services and database tables. The new Access Management Connector provides these benefits:
Simpler configuration BHOLD FIM Provisioning in earlier versions of BHOLD Suite required you to create separate SQL Server MAs to manage data flow between the intermediate SQL database tables and the FIM metaverse. Because the Access Management Connector works directly with BHOLD, the number and complexity of the required MAs is significantly reduced. In addition, it is no longer necessary to adjust configuration parameters of the BHOLD FIM Provisioning services to optimize performance.
Improved performance Eliminating the intermediate services of the BHOLD FIM Provisioning module ensures that data flows between BHOLD and the FIM metaverse immediately when the FIM MAs are run. In addition, role management has been moved from BHOLD FIM Provisioning to BHOLD Core, allowing role management to be handled directly within BHOLD without depending on the BHOLD FIM Provisioning services.
Multiple orgunit support The Access Management Connector supports users belonging to more than one organizational unit (orgunit). Users can belong to more than one orgunit in the FIM metaverse; the Access Management Connector allows that multiple orgunit membership to be represented in BHOLD Core.
For an example of a basic deployment of BHOLD Core SP1 with Access Management Connector, see Test Lab Guide: BHOLD Access Management Connector.
BHOLD Model Generator
The user import file for the SP1 version of BHOLD Model Generator has changed: the Description column, which was optional in previous versions, is now mandatory. The following table shows the new requirements.
User file column layout (three- and five-file set)
ID of employee as known by the organization. The value entered as Employee_ID becomes the default alias in BHOLD Core. Important: To ensure that the employee ID matches the default alias in BHOLD Core, specify the employee ID in the format <domain>\<username>, where <domain> is the NetBIOS (short) name of the user’s domain and <username> is the user’s logon name.
BHOLD Model Generator skips any record that does not contain a value in this column.
This column does not have to contain values for all records. Information in this column is not currently used, but the column must be present in the file. Important: The column name must be spelled exactly as shown. Note the nonstandard spelling of the word corporate.
ID of the user’s orgunit. The value for OU_Key_1 must be specified in the orgunit file in the OU_Key column. This column is used as reference between the different files for file import.
This column must contain values for all records.
Description of the user. Typically, this is used to provide the user’s full (given) name.
This column must contain values for all records.
User attributes, for example, Employee_Type and Job_Title.
These extra user attributes that are specific for the organization are created in BHOLD Core and the values for them are set.