An interesting take on the Replay MA idea came to me that I want to share today.
So far the published use cases for this idea have been restricted to the ‘replaying’ of the FIM Service MA alone – such as dealing with ‘skipped-not-precedent’ issues and the like. This post is about a different more topical scenario – specifically the need to manage Office 365 licence allocations based on AD group membership. In this case, the customer wants to manage allocations based on group membership managed through a (non-FIM) 3rd party tool … and FIM Synchronisation (via the AAD connector) is being tasked the job of translating membership changes to license allocation changes for Office 365.
The problem with this is two-fold:
- The API for assigning licenses works on the basis of what licenses do you NOT want a user to get (a topic for another day); and
- The delta is on the GROUP object when you actually need a delta on the USER (member) objects.
Solution? Simple … replay the delta import of your source ADDS MA, and map the member user objects to your FIM Metaverse to ‘touch’ these MV objects and trigger your export attribute flow to AAD/Office 365. There you have it … a kind of freebie version of the traditional ‘Auxiliary MA’ idea from MIIS/ILM days.
Enjoy!
IdM for Real 
Nice! I need to take a proper look at your replay MA TEC presentation. It sounds very cool. I use the old OCG “reflector MA” pattern a lot – a SQL MA that is a view of the MV. I solved a very similar scenario to what you describe using this approach. I synchronised groups into the MV from each forest, built a reflector MA that basically PIVOTs the group membership from each group in each forest into a view where each row is the user – the UPN (anchor) and then a BIT column for each license, e.g.
uPN,eXO,sPO,rMS (etc.)
paulw@msresource365.com,0,1,1…
I synchronised this into a multi-valued license attribute and used the PowerShell connector to talk AAD PS to do the license assignment. It was a fun solution. It made me realise attribute-value assignment is by far the best way of doing this and groups suck, but it was still fun! 🙂
Yes Paul have done the same thing myself – now no need to export to some external store just to import again – the replay MA gives the same result with just an XSLT applied to the delta import drop file (transform generates LDIF import file). Check it out!
Doh – missed your point there (blame the glass of red!) – your import is from a MV view as per the old MIIS group populator. Replay is more efficient because you have a ready made delta in rapid time.
Just a quick update on this.
In order to establish a join I added an IAF for the ADDS MA to write each user DN to the (indexed) MV.person.uid property. The ADDS Replay MA join could then be set up on CS.group.member = MV.person.uid. The important point here is that without the replay MA any delta to group membership would not translate into a delta for the affected user(s).
I’m using this idea on a solution right now, and plan to post more detail about this in a separate blog, but importantly in order to get this working for an ADDS MA I’ve had to write a variation of the scripts and stylesheets that are found on the http://www.thefimteam.com/ community site – this is because the schema for the FIM MA and ADDS MA are quite different.
However, rather than have a different set of components for each type of MA I would rather have a common one which handles the variations for ease of use and maintainability – so I won’t post the files I’m using right at the moment until I’ve had a chance to develop and refine them. In the meantime, if anyone needs to get hold of something that works for an ADDS MA then let me know.
OK – I’ve finally uploaded the 2 XSLT files you need to for this to https://unifysolutions.jira.com/wiki/pages/viewpage.action?pageId=16875654. This allows you to set up an ADDS Replay MA to derive user.memberOf from group.Member in your ADDS MA, You will need to set up a Replay MA as you would for the FIM MA, but instead you do it from your ADDS MA instead, and you use the 2 new XSLTs instead of the 2 corresponding FIM ones. I’m using this right now to drive O365 licensing via membership of targeted AD groups – why don’t you too?