none
Stop certain users from exporting to the MIM Portal? RRS feed

  • Question

  • I think I already know this answer.  But, I figured I would see if anyone has done this before. 

    I have a bunch of users synced to the metaverse from another domain.  I am only using their usernames to send to a database via a SQL MA for use in a workflow that queries that DB.  I do not want them to clutter the portal.  There are over 50,000 of them.  I initially tried using a custom object type which does keep them from syncing to the portal due to no mapping.  But, that didn't work because I need all usernames from multiple sources to go to that SQL DB.  You cannot have connector space objects connected to multiple MV object types.  Is there any way to keep certain users from exporting to the portal?

    Thanks.


    Mike Leach | http://blogs.catapultsystems.com/mleach/default.aspx


    Wednesday, March 20, 2019 7:46 PM

Answers

  • Hey Leo.

    My solution to this was to flow the 3 "extra sources" they want accountname creation checked against to a custom object type "Epic_person".  But, what remained to be an issue was the already existing usernames in their local AD.  I created a second ADMA that flows just the accountnames into that custom object type (instead of person) and join/project there.  This keeps those customs from going out to the portal.  Only this custom object type flows out to the "Unique Values" username DB.  Then, the workflow (T4FIM) checks against that when creating the accountname, finds a unique accountname for that user, and then writes that to the DB.  That new accountname is then imported and synced to Epic_person.  This way, an accountname is never re-used.....even if it gets deleted from AD.     


    Mike Leach | http://blogs.catapultsystems.com/mleach/default.aspx

    • Proposed as answer by Leo Erlandsson Thursday, March 28, 2019 1:17 PM
    • Marked as answer by Mike H Leach Monday, April 1, 2019 5:56 PM
    Thursday, March 28, 2019 1:07 PM

All replies

  • Hi,

    No, not supported unfortunately, and no workaround that I know of.

    You cannot have a Rules Etension on the FIMMA/MIMMA.

    Br,

    Leo


    Did my post help? Please use "Mark as answer" or "Propose as answer". Thank you!

    Thursday, March 21, 2019 7:56 AM
  • Hey Leo.  Thanks.  I figured as much.  So, the only way that I know of to keep objects out of the portal is to use a custom object type without the 1:1 mapping.  I thought of another possible solution to my issue last night.  Is it possible to have 2 Management Agents connected to the same SQL data source?  Then, have each custom object type syncing with the Connector Space on their own MA?  This way, any overlaps of usernames will be taken care of in the data source.

    Mike Leach | http://blogs.catapultsystems.com/mleach/default.aspx

    Thursday, March 21, 2019 12:37 PM
  • Hi,

    Yeah, sure, you can connect 2 MAs to the same SQL Data Source. Could be a solution to your problem!

    Br,

    Leo


    Did my post help? Please use "Mark as answer" or "Propose as answer". Thank you!

    Thursday, March 21, 2019 1:05 PM
  • Well, this 2 MA method didn't seem to work out either.  They kept stepping on each other's toes and caused a bit of a circle of CS staging and deleting.  So, I'm going to try flowing all usernames into a single custom object type and the only having that object type syncing to that CS.

    Mike Leach | http://blogs.catapultsystems.com/mleach/default.aspx

    Friday, March 22, 2019 5:59 PM
  • Hi,

    Ok, interesting. Please keep us updated.

    Br,

    Leo


    Did my post help? Please use "Mark as answer" or "Propose as answer". Thank you!

    Thursday, March 28, 2019 11:14 AM
  • Hey Leo.

    My solution to this was to flow the 3 "extra sources" they want accountname creation checked against to a custom object type "Epic_person".  But, what remained to be an issue was the already existing usernames in their local AD.  I created a second ADMA that flows just the accountnames into that custom object type (instead of person) and join/project there.  This keeps those customs from going out to the portal.  Only this custom object type flows out to the "Unique Values" username DB.  Then, the workflow (T4FIM) checks against that when creating the accountname, finds a unique accountname for that user, and then writes that to the DB.  That new accountname is then imported and synced to Epic_person.  This way, an accountname is never re-used.....even if it gets deleted from AD.     


    Mike Leach | http://blogs.catapultsystems.com/mleach/default.aspx

    • Proposed as answer by Leo Erlandsson Thursday, March 28, 2019 1:17 PM
    • Marked as answer by Mike H Leach Monday, April 1, 2019 5:56 PM
    Thursday, March 28, 2019 1:07 PM