Working on a FIM implementation for a customer, I needed to bulk create and update a number of related Sets and MPRs which granted permissions to users. I could have performed this task a number of ways:
- Manually create and update all objects
- Scripted in PowerShell using FIM Automation
- Scripted using the Lithnet FIM/MIM Service PowerShell Module
I’ve been successfully using the Lithnet FIM/MIM Service PowerShell Module in a number of scripts to query and bulk create objects in the FIM Service which has greatly improved the quality and simplicity of my PowerShell scripts compared to using the FIM Automation module. What I hadn’t used to date was the ability in the Lithnet module to use the Configuration Management features within FIM, so I thought I’d set myself a challenge to come upto speed with this feature and determine if it was a quicker method than using FIM Automation. I knew it was going to be quicker using the Lithnet module but since I needed to do some research and testing compared to knowing how to tackle it using FIM Automation, I needed to be 100% convinced.
This blog assumes a very good working knowledge of the Microsoft Forefront Identity Manager product, now known as Microsoft Identity Manager. If you haven’t used the Lithnet module yet, what are you waiting for! Ryan Newington has developed and released to the community this PowerShell module which cuts the amount of scripting required to manage FIM configuration and objects within the FIM Service. Using the Configuration Management features was a perfect set of functions I needed for my scenario which I will now describe.
Scenario
For this customer, they had a delegated permissions model where each of their 13 agencies had administrators that were able to manage a fixed set of user attributes just for their own users. Users from other agencies were not visible within their view within the FIM Portal, and to support this model, each agency has linked FIM Set and MPR objects to give this delegated administration. My customer engagement was to update this existing FIM implementation to add custom telephone-based attributes against each user, and create a new phone object type. The existing permissions needed to be updated to include the new telephony attributes, and new permissions were required for the phone objects linked to each agency. This customer had 13 agencies and the beauty was the naming convention the FIM solution had for Sets and MPRs, with the names of the common objects being the same with only the agency name being different. For example, each agency administrator Set object was called ‘_Agency (<agency>) Administrators’. This was the same for MPRs, so my task was made easier as I just need to develop a templated XML configuration file which I could easily update per agency. Follow me so far?
What I liked about the Configuration Management feature was the ability to easily reference other objects without needing to separately query the FIM Service to return an ‘ObjectID’ which you can then supply to your configuration. The Lithnet module takes care of the referencing.
The Lithnet module is located here, and the quickest way to learn about this Configuration Management feature is to read the Lithnet documentation here, and as suggested watch the recording from FIM contributor Ike Ugochuku and download his sample XML configuration here which is a great starting point – here.
Required Actions
For my scenario, I needed to perform the following:
- Create a Set object to group all phone objects for each agency
- Create a permissions-granting MPR object giving each agency Modify permissions to one attribute for phone objects, a ‘visibility’ boolean attribute. You’ll notice in the XML configuration below, the Set created above is referenced, showing the power of this Lithnet module
- Create a permissions-granting MPR object giving each agency Read permissions to all attributes for phone objects
- Update an existing permissions-granted MPR object giving each agency Modify permissions to one attribute for user objects, against the ‘visibility’ attribute
- Update an existing permissions-granted MPR object giving each agency Read permissions to the new phone related attributes for user objects
- Update an existing permissions-granted MPR object removing the Modify permissions for user self-service which has been assigned in error some time ago
Using the -Preview switch against a configuration XML file (sample listed below) for the first agency, a preview can be tested before applying.
On a second agency with some of the updates already applied, I performed a preview. It shows all objects exist and which individual change would be applied.
As a test against the second agency, I changed resource operation from ‘Add Update’ to ‘Add’. When attempting the preview again, it showed it is creating the Sets even though they already exist. This is not ideal for verification, so I changed it back to ‘Add Update’ which I recommend using.
Removing ‘Preview’ and committing the change against the first agency shows what is changed and committed to FIM.
Validating the changes with a preview once applied to confirm all changes had been committed.
Although I could have been smarter to script the process for the remaining agencies, I did a search-and-replace of the agency name in the configuration XML file, saved it and re-ran the import.
Last step was to check the FIM Service requests to confirm they have been completed.
My sample XML configuration file for an agency change is located here.
Tips
Some simple recommended tips based on my use of this Configuration Management feature:
- ID is a required tag even if you don’t use it as a reference within your XML configuration file
- When creating FIM objects, use the XML tag ‘Add Update’ so that the Preview function can be used to validate the changes you have performed. If you leave it as ‘Add’, the Preview will simply report that the object ‘would’ be created if executed, rather than query and check that the objects exists and no update is required
- Case sensitivity of the XML tags as mentioned by Ike in his video. I didn’t test changing the case as the sample XML configuration files were working configuration
So how long did it all take?
My goal was to make the changes into production against the 13 agencies after successfully testing the FIM configuration in a test environment. After watching Ike’s video and reading Ryan’s wiki, it took about 15 minutes to customise the sample XML files and update the configuration in the production FIM instance for all 13 agencies. A huge time saving. Other colleagues have started using this functionality both for speed of implementation and consistency in configuration, and my colleague Darren Robinson has also saved a great deal of effort as detailed in his blog here.
What scenarios have you performed with this functionality? Let us know in the comments below.
Comments are closed.