custom deprovisioning for FIM users
hello everybody,
i have 2 management agents: AD and FIM
i am provisioning users from AD into metaverse then exporting them to the FIM portal.
I want when a user is deleted from Active Directory, to keep the FIM user in the FIM portal but rename its display name to prepend the "Deleted_" string to it.
How can i do such a thing knowing that i cannot run deprovisioning rules on the FIM MA.
thanks
MM
MM
May 10th, 2011 4:16pm
You could have a workflow in FIM do something like that. Have an attribute flow from AD to portal and when it is removed, the portal would then not have a value which would then no longer be present.
The removal of the AD attribute value in the portal can have the user move into a set which would trigger an MPR and the workflow which would trigger the addition of the string using function evaluator.
If you're using declarative rules then you could simply have a workflow activity the runs after the sync rule is removed and the entry in AD slated for deprovisioning.
Thanks
B
Free Windows Admin Tool Kit Click here and download it now
May 10th, 2011 4:19pm
You could have a workflow in FIM do something like that. Have an attribute flow from AD to portal and when it is removed, the portal would then not have a value which would then no longer be present.
The removal of the AD attribute value in the portal can have the user move into a set which would trigger an MPR and the workflow which would trigger the addition of the string using function evaluator.
If you're using declarative rules then you could simply have a workflow activity the runs after the sync rule is removed and the entry in AD slated for deprovisioning.
Thanks
B
May 10th, 2011 4:21pm
but initially all my attributes flow from AD, so if this attribute will no longer exist then all other attributes will no longer exist. i have enabled "do not recall attributes" on MA of AD to keep the attributes even when the AD object no longer exists.MM
Free Windows Admin Tool Kit Click here and download it now
May 10th, 2011 11:48pm
but initially all my attributes flow from AD, so if this attribute will no longer exist then all other attributes will no longer exist. i have enabled "do not recall attributes" on MA of AD to keep the attributes even when the AD object no longer exists.MM
May 10th, 2011 11:48pm
Hi There,
You can get around the disappearing attribute by using inbound attribute flows from FIM as well which are of lower precedence for the ones in AD. That way you can turn the attribute recall functionality back on as it can cause major headaches down the road
if you're dealing with new datasources and have made their data of lesser precedence.
This would allow you to do the method I suggested. The data that AD populated in FIM would fill in the gaps from AD (even though the data in FIM originally came from AD) save for the "flag" attribute you're using to detect whether or not AD is present.
Thanks
B
Free Windows Admin Tool Kit Click here and download it now
May 11th, 2011 1:06am
I guess it all depends how you have your object deletion and FIM MA deprovisioning rules configured.
In my play environment, which has users from AD provisioned to FIM Portal, I have it configured so that if a user is disconnected from all connectors except FIM, it deletes the MV object and deletes the FIM Portal object.
However, in your environment it sounds like your object will stay in the metaverse and stay in the FIM Portal after the AD object no longer exists.
I think you'll find the following might be slightly inaccurate:
Have an attribute flow from AD to portal and when it is removed, the portal would then not have a value which would then no longer be present.
If recall attributes for the AD MA is turned on, the above becomes moot because the contributed value from AD will still exist in the metaverse (honestly not sure how this works in regards to precedence as I have never used it).. however,
in a system that has only two MA's (AD and FIM), I would wonder why you're using this option in the first place. As pointed out below, just because a contributing MA is disconnected from the MV, it should not clear the attributes in the FIM Portal, only in
the Metaverse.
If you wanted your attributes to still appear in the metaverse, you could have some import attribute flow rules in the FIM MA for those attributes - and by selecting them as having secondary precedence to Active Directory, it would ensure that the FIM
MA only contributed them when the AD object is disconnected. This would mean you could turn the recall attributes option off, and your MV objects would be preserved. But really, it's not even necessary to have values assigned to your MV objects.
If recall attributes for the AD MA is not turned on, then what happens is that when the object disconnects, it clears the "inAD" value from the metaverse. Because that value is cleared from the metaverse and so it would not flow back out
to FIM. For example if my "inAD" was true and it had previously flowed out to the FIM Portal, it would still be set to true in the FIM Portal. Using direct flows, I know of no way to flow a null.
The normal approach to this would be to have a constant value of 'false' importing back in from the FIM MA with secondary precedence - such as when the AD object disconnects, the new value of 'false' from the FIM MA imports into the metaverse and then
the EAF flows it out to FIM Portal... but we can't do advanced (constant) flows in the FIM MA.
To solve your original problem, I would have:
1) A metaverse attribute called inAD of string type. Create a corresponding FIM Portal schema value
2) A declarative (Portal) IAF from AD to the MV inAD value flowing a constant string 'true'.
3) An EAF (in the MA) for MV.inAD->Portal.inAD
4) An IAF (in the MA) for Portal.displayName->MV.inAD (displayName could be any other attribute.. the idea here is that we can't flow a constant so we have to improvise)
5) Ensure precedence on the inAD attribute has AD as #1, FIM Portal as #2
6) Create a set called "Users not in AD". Criteria for entry is that the inAD portal attribute is not equal to 'true'
7) Create an new workflow called "Change non-AD display name" that evaluates a function to change displayName in the portal to "DELETED" + displayName (if you've setup the flow rules as per my recommendation above, the MV displayName attribute will
also update)
7) Create an MPR for your "Users not in AD" set which fires the "Change non-AD display name" workflow
Hope that's clear enough.
- Ross Currie
May 11th, 2011 1:11am
thanks all will try this and let you knowMM
Free Windows Admin Tool Kit Click here and download it now
May 11th, 2011 1:58am