none
Indicating in Active Directory when a connector has been deleted in another Management Agent (SQL)

    Pergunta

  • Hello,

    My current setup in FIM 2010 R2 is using FIM Portal codeless provisioning to create user accounts in Active Directory based on data from a SQL Management Agent. I have not currently configured Delta Tables/Views.

    I have two 'MPR/Set/WF/Sync Rules' configured; one for active accounts and one for deactive accounts

    I was hoping that I was starting to get ready to build this into a production environment but I'm concerned about what happens if a row/object disappears from the SQL View... How can I feed through to Active Directory a change on the user object to help indicate the connected row in SQL has been removed? For example change the objects location or change an attribute...?

    I can change the FIM Sync Object Deletion rule to delete the MV object when the SQL object is deleted/disconnected but are there Sets/Workflows that can be run when the object is about to be deleted from FIM Portal?

    Also... should I be using one Sync Rule with Functions in the Attribute Flow to deal with disabled/deactive accounts or is the arrangement of multiple 'MPR/Set/WF/Sync Rules' a good idea?

    Thanks
    mtwelve

    quarta-feira, 16 de outubro de 2013 09:11

Respostas

Todas as Respostas

  • Hello,

    have a look at this thread, at it deals with exactly the same issue.

    http://social.technet.microsoft.com/Forums/en-US/e5f0efcc-84ba-42f9-928b-a9340928fc47/suspension-of-deleted-accounts?forum=ilm2

    Like described there the best solution is to populate a Attribute isInXX for XX beeing all Management Agents.

    I've done this in nearly all my Solutions, as it also helps finding objects in MV searches.

    Regards
    Peter


    Peter Stapf - Doeres AG - My blog: JustIDM.wordpress.com

    • Marcado como Resposta mtwelve quarta-feira, 16 de outubro de 2013 18:21
    quarta-feira, 16 de outubro de 2013 10:27
  • Thank you for your response; it sound like what I need but could clarify the following:

    In the configuration of the SQL Management Agent I would set an attribute flow to a custom boolean Metaverse attribute.... what would the source of the flow be?

    Do I need another field in my data source or is the flow 'Advanced'?

    Do Attribute Flows configured in the Management Agent conflict with FIM Portal Synchronization Rules?

    quarta-feira, 16 de outubro de 2013 15:13
  • Hello,

    SyncRule flows are evaluated first, after that the MA flows are working, so Last Change Counts.

    You can Archive this Attribute either as SyncRule or AgentFlow, like you want.

    Simple let a String "true" flow as a fixed value to the IsInXX Attribute, in MA it is a advanced flow with constant value.

    Regards
    Peter


    Peter Stapf - Doeres AG - My blog: JustIDM.wordpress.com

    quarta-feira, 16 de outubro de 2013 15:39
  • I'll do some testing but can you confirm that the 'true' value on the Metaverse object will be removed when the object is removed from the Connector Space...?

    It seems strange as I would expect the attribute to stay 'true' until something changes its value...?

    Thanks for your help!

    quarta-feira, 16 de outubro de 2013 18:00
  • Sure the attribute is removed, since it it only contributed by this one MA.
    I used it a lot in my solutions. works perfect, also very good when searching the MV.

    Keep one thing in mind, always rely on the presence of this attribute when checking thinks, not only of the abscence. For example use alway to of this attribute to check the abscence of one:
    Like (IsInAD=true and IsInHR not present).

    Regards
    Peter


    Peter Stapf - Doeres AG - My blog: JustIDM.wordpress.com

    quarta-feira, 16 de outubro de 2013 18:07
  • Excellent! Look forward to testing... would you mind giving your opinion on my setup of having two separate Sync Rules (and associated MPR/SET/WF) to deal with Active users and Disabled users...?

    I'm starting to think I should be building more logic into my Sync Rules...

    quarta-feira, 16 de outubro de 2013 18:21
  • Hello,

    the 2 SyncRules should work, but dont activate the deprovisioning Option in that SyncRule, otherwise the object maybe became deprovisioned and provisioned again. (Not quite sure if this really would happen, just from my understandingof this)

    I've decided to use a depended SyncRule for that in my solution, as the most AttributeFlows are the same for active and inactive users, like FirstName, LastName for example.

    So I create a depended outbound sync to only flow the different attributes, outbound syncrule has higher precedence in that solution to it overwrites flows in the base syncrule.

    Regards
    Peter


    Peter Stapf - Doeres AG - My blog: JustIDM.wordpress.com

    quinta-feira, 17 de outubro de 2013 09:50
  • I have started to test the solution and I'm getting weird results.

    The SQL MA has an Import (to the MV) attribute flow against the custom attribute 'isInSQL'.
    The attribute flow is constant and with the value 'true.
    The MA is set not to recall attributes values for objects disconnected from the MA.

    If I delete the row in SQL and do an Import/Full Sync the object is deleted from the SQL MA.
    However the object in the Metaverse still has all the attributes from the SQL MA including the 'true' against the custom 'isInSQL' attribute..... have I missed some aspect of the configuration?

    Thanks
    m12

    terça-feira, 22 de outubro de 2013 16:28
  • Hello,

    i've tested this again in my VM testlab, even with an SQL MA as SyncRule Flow and direct MA Flow, in both cases it works and the attributes and value are removed from MV but the object is still connected to other systems.

    If you have activated "Do not recall attributes on disconnect" then that is the problem, and attributes remain in mv, which is not a good behavior.

    It is best practice to not activate this option, instead try other solutions to archive your goal.

    Regards
    Peter


    Peter Stapf - Doeres AG - My blog: JustIDM.wordpress.com

    quarta-feira, 23 de outubro de 2013 11:06