none
Syncing to existing AD account applied but the DN not changed as expected. RRS feed

  • Question

  • We have a strange use case.

    Employees can move from being Internal to External type and vice versa. The HR dept allocates a different set of employeeIDs for each type. So the SAME PERSON can be employed as an External with employeeID E123 and then remployed as an Internal employee and be given an employeeID I123. Fortunately they are not employed at the same time with both employeeIds. There is a change over period which can be anywhere between a few hours and a few months. We use employeeID as the Sync Rule Join/Provision match criteria.

    What I am trying to get FIM to do is to re-use the existing AD account/mailbox/home directory created for the user when he first joined company as an External.

    The method I took is this: ( we get informed in advance by HR of this 'rare' situation )

    1. set up an HR feed connector filter so that the OLD terminated record is filtered out.

    2. After the External has his contract terminated and before he gets re-employed as an Internal, edit the AD account and Portal account changing the employeeID value to the new employeeID.

    3. Import the AD and FIMMA changes into FIM.

    4. With new HR feed data run the Full import/Full sync of HR feed.

    This sort of works, the AD and Portal attributes are fine. Just one problem, the AD dn attribute isnt being set according to the the Outbound Sync rule.

    When a user has his contract terminated (status = terminated) he gets his AD account moved to the "Deleted Users" OU.The DN is set depending on the status. I had hoped that the new HR feed with active status would then reset the DN and rename the AD account and move him into the "User Accounts" OU at synchronization time, but it dont!

    When I look at the Metaverse object and inspect the connectors, I see that the AD connector is a projection into the MV and the HR feed is a Join. Most AD connectors are usually created and should have a DN built by provisioning rules. In this situation we have a pre-existing account with its existing DN. Whenever I try to force a full sync on this object with a preview, , the sync rule gets applied ok, but the DN doesnt change. It ought to because it is a function based on a status value.

    What am I doing wrong in trying to handle this unusual case with FIM.

    Thursday, July 5, 2012 8:53 AM

Answers

  • Just a clarification about the "Also make sure that your flow rule for the DN is not set as "initial flow only"

    When using declarative provisioning to AD and you want to support renames of DN you need to have TWO attribute flows for AD.

    One with the initial flwo only flag set to support the create in external system setting and then one without the initial flow only to support renames of the dn.

    Friday, July 6, 2012 6:49 AM

All replies

  • Is there an ID value that doesn't change for a person depending on whether they are internal or external?  If the number after the E/I is consistent and unique, perhaps you could import that value and use it to join with a rule extension for your join.  Just a thought.

    As to your provisioning/rename problem, are you using a metaverse extension for provisioning, or codeless provisioning configured in the portal?  I'm assuming portal-based sync rules based on your description.  Check your MPRs to ensure that the sync rule for terminated users is being removed based on set transition.  Also make sure that your flow rule for the DN is not set as "initial flow only".  Those would be the first places I would look for the source of the trouble.

    Chris

    Thursday, July 5, 2012 1:07 PM
  • Hi,

    Depends on how you are provisioning but does your provisioning code deals when you find connectors for the "person" object type if you are provisioning classically.

     ConnectedMA thisMA;
                 switch (mventry.ObjectType)
                 {
                         CSEntry csentry = thisMA.Connectors.StartNewConnector("user");
                                         case "person":
                         thisMA = mventry.ConnectedMAs["External ADMA"];
                        if (thisMA.Connectors.Count == 0)
                        {
                         string rdn = "cn=" + MVEntry["accountName"].Value;
                         csentry.DN = thisMA.EscapeDNComponent(rdn).Concat(ACTIVE_ROOT_CONTAINER);
                        //Set up initial flow
                        csentry["unicodePwd"].Value = "abc$12345"; 
                        csentry["userPrincipalName"].Value = mventry["email"].Value;
                        csentry["pwdLastSet"].Value = 0; 
    
                        csentry.CommitNewConnector();
    
                        }
                        else if(thisMA.Connectors.Count==1)
                        { 
                            CSEntry csentry = thisMA.Connectors.ByIndex[0];
    
                             if (MVEntry["status"].Value="something") 
    DN = thisMA.EscapeDNComponent(rdn).Concat(ACTIVE_ROOT_CONTAINER); else DN = thisMA.EscapeDNComponent(rdn).Concat(DISABLED_ROOT_CONTAINER); if (!csentry.DN.ToString().ToLower().Equals(DN)) { csentry.DN = DN; } else { csentry.Deprovision(); } } break; default: break; }


    • Edited by bhavesh001 Thursday, July 5, 2012 4:32 PM typo
    Thursday, July 5, 2012 4:31 PM
  • Just a clarification about the "Also make sure that your flow rule for the DN is not set as "initial flow only"

    When using declarative provisioning to AD and you want to support renames of DN you need to have TWO attribute flows for AD.

    One with the initial flwo only flag set to support the create in external system setting and then one without the initial flow only to support renames of the dn.

    Friday, July 6, 2012 6:49 AM