locked
Projection from multiple sources RRS feed

  • Question

  •  

    I apologize if this has been asked before - I didn't find it when I searched.  If so, kindly point me to the other thread.

     

    I have an existing production MIIS system that currently syncs passwords (and not much else) from AD to NT & Novell eDirectory systems.  MV objects are projected when AD user exists.  We are in the middle of migration to AD, so only about 10% of the users currently have AD accounts.  Not all employees have or will have email/network accounts (we are a medical facility, so a lot of clinical folks don't have email or network login accounts), so expecting to be able to project all employees from AD is not realistic.

     

    I am looking to expand the usefulness of MIIS by using it to update information in multiple MAs by importing data from the HR system as a delimited file MA.  One of my primary objectives is to be able to update "department" and "title" from HR system, pushing updated information to NT and eDirectory.  I also want to be able to update user "department" and "title" in another database that is not currently connected to MIIS.

     

    My problem is related to projection.  I guess the main problem is that I don't have any one system that has all objects (all employees, plus contractors, vendors, service accounts, and test accounts that have network IDs).  Since only a few of the total list of employees have AD accounts, not all employees currently have MV objects (obviously) - but there are non-employees that do - projected from AD.

     

    Is it possible to project MV objects from multiple MAs?  Can I project MV objects for all (or some of) my employees from the HR system and flow some attributes authoritatively from there, and also project non-employee accounts from AD?  If so, how do I reconcile them long-term (e.g.MV object created when new employee is hired and projected to MV from HR system, then they are given an AD account later)?  I can use employeeNumber from HR to match employees with their MV objects, but I won't have that for non-employees.

     

    I have considered trying to project all from HR and manually enter employeeNumber in AD to match, but that still wouldn't get the non-employees in to the MV.  I want them in there so we can sync passwords down from AD.

     

    I have also considered manually updating all current employee MV objects with their employeeNumber so they will match when HR MA is brought online, and then initiate procedures so that when new employees are given AD accounts the employeeNumber is a mandatory field.  This has problems as it is a manual process - thus subject to breakdown.

     

    Sorry for the length of the question...Jeff 

    Tuesday, February 5, 2008 12:46 AM

Answers

  • Jeff,

     

    to me, it looks like the biggest challenge you have is the right implementation of a Correlation ID.

    If there is no single data store that contains all objects, you might want to think about creating one (master data store).

    The problem is not only to link the right objects together but also to define the requirements for each account (e.g.: “must have AD account”). You could do this in your master data store. You could also use this store to link the right objects together.

    For example, HR could project objects with a different object type into the metaverse. All HR and AD accounts are provisioned into the master data store.

    For matching objects, the MA of the master store flows the employee ID to the MV object that was projected by ADMA and deprovisions the object that was projected by the HR MA. This way, you convert the object in the HR CS into a pending import that can join to the right metaverse object on the next synchronization run.

    I guess, you get the picture…

    Your master data store is used as “universal” catalog that has information about all identities and it is also in charge of defining the Enterprise roles of your objects.

     

    You are basically on the right track – you need some mechanism that enables you to link the right objects together.

     

     

    Cheers,

    Markus

     

    ///////////////////////////////////////////////////////////////////////
    Markus Vilcinskas

    Technical Writer
    Microsoft Identity Integration Server
    mailto:markvi@microsoft.com.NO_SPAM

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at
    http://www.microsoft.com/info/copyright.htm
    ///////////////////////////////////////////////////////////////////////

     

     

    Wednesday, February 6, 2008 1:27 PM
    Moderator

All replies

  • You can certainly project from multiple sources.

     

    However, the challenge is to flag the objects based on roles.

    One option here would be to stick the non-employees from AD into a specific OU. If this is not possible, you will have to set an attribute on the objects via script – or something like that.

     

    Basically, you need a mechanism to distinguish between objects that are in HR and AD and AD only.

     

    The best implementation option is to flag this on the objects.

     

     

    You should look into the topic of a Correlation ID.  

    This will help you to get a better understanding of this problem space.

     

     

     

    Cheers,

    Markus

     

    ///////////////////////////////////////////////////////////////////////
    Markus Vilcinskas

    Technical Writer
    Microsoft Identity Integration Server
    mailto:markvi@microsoft.com.NO_SPAM

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at
    http://www.microsoft.com/info/copyright.htm
    ///////////////////////////////////////////////////////////////////////

     

    Tuesday, February 5, 2008 6:19 AM
    Moderator
  • Thank you very much for your reply!

     

    I am not concerned at all (at this time) with the non-employees that are in AD.  They will never be in the HR database, so are not part of my current dilemna.  Our current projection criteria is that users are projected in to the MV if they exist in AD.  I want to have the non-employees in the MV as I sync their passwords to the other systems. 

     

    My main concern is in regards to matching up the users projected from the HR database with users that are created later in AD.  FYI, we have 5,000+ employees.

     

    Scenario:

    - Employee does not yet exist in AD, so they are projected from the HR database in to the MV

    - Attributes (employeeNumber, title, department, etc.) flow from HR, through MV, to update the other new database using employeeNumber as the key (both of them have this field).

    - At a later date, the employee above is migrated to AD and is now a candidate for projection in to the MV.

     

    Problem:

    There are no key fields that the new databases and the old databases have in common.  The new ones both use employeeNumber, and the old ones (eDirectory, NT, and AD) are using UserID as the key field.  None of the old directories currently have employeeNumber populated.  I certainly don't want to project another MV object, I want to match to the existing MV object that represents that employee.

     

    ** Note: It is not a key field as it doesn't exist for all users, but 69% of the employees have valid email addresses in the HR database.  I can strip the user part off from in front of "@" and this will match the UserID in the existing databases in almost all cases.  This means I only have to deal with matching the remaining 31%.

     

    Providing that you can project from multiple databases (my main question - you answered above), I could either figure out how to programmatically match the new user in AD to the existing MV object using other attributes such as parts of the name, department, etc. or I could have someone manually enter the employeeNumber in to AD - and use employeeNumber as my first join criteria.  The data in the existing directories is quite stale in many instances, so fields other than name are suspect.

     

    Manually entering the employeeNumber is by definition prone to errors as it is not automated.  I know I need to walk through all of the join, projection, and disconnect scenarios to make sure I cover all the possible combinations, but I haven't taken the time to do that yet.

     

    Are there any larger "big-picture" things or other considerations I should be looking at?  Our long-term plans are to continue expanding the role of MIIS to connect to additional directories.  I feel like I am focusing very narrowly on the new databases I want to add in - but I feel better in that it looks like what I want to do is feasible. 

     

    Any comments are very much welcome!

     

    Thanks in advance...Jeff

    Wednesday, February 6, 2008 12:03 AM
  • Jeff,

     

    to me, it looks like the biggest challenge you have is the right implementation of a Correlation ID.

    If there is no single data store that contains all objects, you might want to think about creating one (master data store).

    The problem is not only to link the right objects together but also to define the requirements for each account (e.g.: “must have AD account”). You could do this in your master data store. You could also use this store to link the right objects together.

    For example, HR could project objects with a different object type into the metaverse. All HR and AD accounts are provisioned into the master data store.

    For matching objects, the MA of the master store flows the employee ID to the MV object that was projected by ADMA and deprovisions the object that was projected by the HR MA. This way, you convert the object in the HR CS into a pending import that can join to the right metaverse object on the next synchronization run.

    I guess, you get the picture…

    Your master data store is used as “universal” catalog that has information about all identities and it is also in charge of defining the Enterprise roles of your objects.

     

    You are basically on the right track – you need some mechanism that enables you to link the right objects together.

     

     

    Cheers,

    Markus

     

    ///////////////////////////////////////////////////////////////////////
    Markus Vilcinskas

    Technical Writer
    Microsoft Identity Integration Server
    mailto:markvi@microsoft.com.NO_SPAM

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at
    http://www.microsoft.com/info/copyright.htm
    ///////////////////////////////////////////////////////////////////////

     

     

    Wednesday, February 6, 2008 1:27 PM
    Moderator
  •  

    Markus -

     

    Thanks again for your assistance!

     

    I am attempting to read up on Correlation ID using the link you provided in your first response, but I am having problems getting to it.  I can follow the link you provided, and it talks about 2 documents.  The second one it talks about is "Design Concepts for Correlating Digital Identities", but there is only one document to download on this page, and it is about Group Provisioning.  I searched that document, and I don't find anything about Correlation ID.

     

    Am I missing something, or is there a problem?

     

    I was able to search TechNet for "Design Concepts for Correlating Digital Identities" and find what I think is the document you talked about at http://technet2.microsoft.com/ILM/en/library/f00eb618-8a38-4c13-ab34-2aaa01e313bd1033.mspx?mfr=true.  I am reading that now.

     

    Thanks...Jeff

    Wednesday, February 6, 2008 4:55 PM
  • Jeff,

     

    yes, there is a problem with the other link I have mentioned.

    We are investigating…

     

    There are basically two versions of our documents available – a downloadable and a “browseable” version.

     

    The link to the page with the downloadable documents is unfortunately not working. Fortunately, you have found the “broseable” version.

     

    Sorry for the inconvenience.

     

    Cheers,

    Markus

     

    ///////////////////////////////////////////////////////////////////////
    Markus Vilcinskas

    Technical Writer
    Microsoft Identity Integration Server
    mailto:markvi@microsoft.com.NO_SPAM

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at
    http://www.microsoft.com/info/copyright.htm
    ///////////////////////////////////////////////////////////////////////

     

    Thursday, February 7, 2008 3:20 AM
    Moderator