Sign in
 
HomeLibraryWikiLearnGalleryDownloadsSupportForumsBlogs
Resources for IT Professionals >
> 
> 
> 
FIM populating strange accountName values to AD

Answered FIM populating strange accountName values to AD

  • Wednesday, February 06, 2013 9:20 PM
     
      Has Code
    Sign In to Vote
    0

    I seem to be missing the mark on passing the correct accountname value to AD from FIM.

    Within the FIM MA I've configured an attribute Flow for Person=> 

    Data source attribute: AccountName (direct-import) -> Metaverse attribute: accountName

    (This correlates the Direct import from FIM Portal to the Metaverse, right?)

    The accountname is defined in the sync rule to map to sAMAccountName.

    All looks well in the FIM CS if I look at the object, it retains the value I entered: JohnDoe.

    In the MV, the accountName Value is still: JohnDoe. In the connectors Tab on the person object within that MV object property GUI, the DN which is identified as 4b27ac09-4fbc-4045-b304-464731dcc1f0 (projection-rule) shows this same accountName JohnDoe, yet if I look at the object with the DN of the form 'CN=John Doe, OU....' to be provisioned to AD (provisioning-rules), that sAMAccountName value is some random string of charaters.  Other attribute values look good. 

    AND...this random string populates the pre-Windows 2000 AD logon field, HOW DO I PASS THE USER LOGON NAME THAT IS NON-PRE WINDOWS 2000? This is the top User logon name field in the ADUC console, above the pre-win 2000 field.

     

All Replies

  • Wednesday, February 06, 2013 9:33 PM
    Moderator
     
     
    Sign In to Vote
    1

    Can you provide a sample of this random value?

    The Pre-Win2k Logon Name is the sAMAccountName attribute.

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

     
  • Thursday, February 07, 2013 6:52 AM
     
     
    Sign In to Vote
    1

    This usually happens when you don't populate the sAMAccountName attribute in the AD MA, are you absolutely sure you're populating it during provisioning or have an export flow to AD (based on the above it seems it should be MV.accountName -> CS.sAMAccountName)? Running a "preview" sync is really helpful see what's going on and which attributes are populated when - for example I've seen a scenario where an attribute was populated during provisioning, and then cleared by the flow rule (source value was empty, and export nulls checkbox was selected)... so the end result was that the value ended up being empty.

    The non-prewin2k attribute is the userPrincipalName and it's syntax is <UserID>@<UPNSuffix>, in ADUC the value is split and you see the <UserID> as a seperate field, and the <UPNSuffix> as a drop-down next to it.

    Piotr

     
  • Thursday, February 07, 2013 1:48 PM
     
     Answered
    Sign In to Vote
    1

    Go to Metaverse Designer and for the person attributes click on the sAMAccountName and check for Attribute Flow Precedence, make it Equal even though there may be only one Management Agent listed there.

    in the FIM MA

    in addition to Data source attribute: AccountName (direct-import) -> Metaverse attribute: accountName

    add this as well Data source attribute: AccountName (direct-import) <- Metaverse attribute: accountName

    Regards Furqan Asghar

    • Marked As Answer by Osho27 Thursday, February 07, 2013 4:10 PM
    •  
     
  • Thursday, February 07, 2013 2:09 PM
     
     
    Sign In to Vote
    0

    yes the value is $M72000-742EB8F1V9BQ

    what attribute should i populate to give a value to the AD W2K8R2 logon value?

     
  • Thursday, February 07, 2013 2:54 PM
     
     
    Sign In to Vote
    1

    its a good practice and I usually populate both the

    i. sAMAccountName (Syntax: AccountName)

    ii. userPrincipalName (Syntax: AccountName + "@contoso.com")

    Regards Furqan Asghar

     
  • Thursday, February 07, 2013 4:13 PM
     
     
    Sign In to Vote
    0

    The issue turned out to be precedence for the accountName attribute.  AD's attribute was listed first, FIM, second.  I set them equal and tested again, the value appeared correctly.  I'll add the direct-export AccountName <- MV accountName flow and modify the sync rule to pass userPrincipalName too. Thanks!

     
  • Thursday, February 07, 2013 4:33 PM
    Moderator
     
     
    Sign In to Vote
    0

    yes the value is $M72000-742EB8F1V9BQ

    what attribute should i populate to give a value to the AD W2K8R2 logon value?


    As you discovered, that is an auto generated value when you don't supply a value.

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

     
  • Thursday, February 07, 2013 4:33 PM
    Moderator
     
     
    Sign In to Vote
    0

    Go to Metaverse Designer and for the person attributes click on the sAMAccountName and check for Attribute Flow Precedence, make it Equal even though there may be only one Management Agent listed there.

    in the FIM MA

    in addition to Data source attribute: AccountName (direct-import) -> Metaverse attribute: accountName

    add this as well Data source attribute: AccountName (direct-import) <- Metaverse attribute: accountName

    Regards Furqan Asghar


    The second (export) flow is not necessary.

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

     
  • Thursday, February 07, 2013 4:34 PM
    Moderator
     
     
    Sign In to Vote
    0

    The issue turned out to be precedence for the accountName attribute.  AD's attribute was listed first, FIM, second.  I set them equal and tested again, the value appeared correctly.  I'll add the direct-export AccountName <- MV accountName flow and modify the sync rule to pass userPrincipalName too. Thanks!


    You shouldn't need the equal precedence or the export flow.

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

     
  • Thursday, February 07, 2013 4:45 PM
     
     
    Sign In to Vote
    0

    Thanks Brian

    You are absolutely right it shouldnt be necessary. Having said that, It made me realize Osho must have an export flow set as well in the FIM MA (as AD was already set as Precedent), that would make precedence an issue.

    If the (export) flow is removed the precedence wouldnt be an issue at all,

    So thats the best thing to do, isnt it?

    As per my habbit, I usually declare both the import and export flows on all attributes when I implement a project and then make all of the attributes equal precedence, Makes life much simpler :)

    Regards Furqan Asghar


     
  • Thursday, February 07, 2013 4:52 PM
    Moderator
     
     
    Sign In to Vote
    0

    As per my habbit, I usually declare both the import and export flows on all attributes when I implement a project and then make all of the attributes equal precedence, Makes life much simpler :)

    Regards Furqan Asghar



    That change the behavior of the product and isn't really something I would recommend anyone do.

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

     
  • Thursday, February 07, 2013 5:42 PM
     
     
    Sign In to Vote
    0

    As per my habbit, I usually declare both the import and export flows on all attributes when I implement a project and then make all of the attributes equal precedence, Makes life much simpler :)


    That change the behavior of the product and isn't really something I would recommend anyone do.


    Exactly, and also the equal precedence will be removed from the product (per the list of deprecated features) going forward. So I'd also say to try and live without it :).
     
  • Friday, February 08, 2013 3:36 AM
     
     
    Sign In to Vote
    0

    Thanks for the Article Piotr.

    I Hope, Microsoft Knows what it is doing. As it was always handy to have equal precedence.

    And you are right I should start living without it

    Regards Furqan Asghar