none
DN notation error RRS feed

  • Question

  • We have a proof-of-concept install of Microsoft Identity Manager 2016 SP1 up and running on server 2012 R2.  The domain, too, is a test domain on 2K12R2.

    We've been having trouble getting users to provision from the MIM portal to the Sync service and therefore into Active Directory.

    We're down to a problem with deploying distinguished name data.  According to the guide we followed, the Outbound Sync policy is supposed to include:

    +("cn=",displayName,",ou=OurOU,dc=testdomain.dc=local")

    As an initial outbound flow

    But it's erroring.  In the sync service, a sync fails for each user, with the same error:

    Microsoft.MetadirectoryServices.ProvisioningBySyncRuleException: DN"+("cn=",displayName,",ou=OurOU,dc=testdomain.dc=local")" is not valid

    I'm thinking that the displayName is the issue.  Everthing else is static, while that's variable.  But I can't find any LDAP or Active Directory documentation that tells me how to configure a variable input like that.

    Thoughts?  Source for me to work on this?  Maybe I need something that I'm missing.

    Feedback greatly appreciated.

    Monday, December 11, 2017 9:15 PM

Answers

  • There are many steps to making this work and you are skipping some of them.

    UserPrincipalName is an AD Attribute and it is not selected by default. You need to select it in the AD MA

    Then,

    Export as follows

    AccountName+"@PLSTEST.com" ==> UserPrincipalName


    Nosh Mernacaj, Identity Management Specialist

    • Marked as answer by Rob J Vargas Friday, December 15, 2017 8:24 PM
    Thursday, December 14, 2017 11:18 PM

All replies

  • DN Format is supposed to be,

    cn=displayName,ou=OurOU,dc=testdomain.dc=local

    No commans before and after displayName.

    Also careful using DisplayName as CN, because you may end up with duplicates\collisions.


    Nosh Mernacaj, Identity Management Specialist

    • Proposed as answer by Nosh Mernacaj Monday, December 11, 2017 10:27 PM
    Monday, December 11, 2017 10:27 PM
  • Rob-

    I think the problem is the + sign. I think that's supposed to indicate concatenation. You could use a custom expression and put "CN="+displayName+",OU=OurOU,DC=testdomain,DC=local" in it. Incidentally I would wrap your displayName in the EscapeDNComponent() function in case there's an illegal character in there.


    Thanks,
    Brian

    Consulting | Blog | AD Book

    Monday, December 11, 2017 11:08 PM
    Moderator
  • Thank you, Nosh. The notation was changed. I get the same error, just showing the dn format you suggested now, instead of what I posted in my question.

    displayName, I hope you understand, is coming from a user created in the Microsoft Identity Manager portal.  It's a discrete field we want to fill in when creating new users.  We might change that to get filled in automatically (it's first name, last name, which is separately filled in).

    Tuesday, December 12, 2017 3:26 PM
  • Please show me how you are bulding the DN, and send me a screen shot of the error.

    I know what displayName is but you understand that it is not unique, which can create issues if you come with 2 users with same displayName (in the same ou) DN has to be unique.

    I know you said this is Proof of concept, but for future references.


    Nosh Mernacaj, Identity Management Specialist


    Tuesday, December 12, 2017 3:28 PM
  • Brian:

    Still struggling, but the error changed when I tried your syntax.

    For the moment, I'm leaving this question in unanswered status, but expect the new error will direct me elsewhere.  Once I confirm, I'll likely mark your response.

    Tuesday, December 12, 2017 5:51 PM
  • Brian:

    Still struggling, but the error changed when I tried your syntax.

    For the moment, I'm leaving this question in unanswered status, but expect the new error will direct me elsewhere.  Once I confirm, I'll likely mark your response.


    What's the new error?

    Thanks,
    Brian

    Consulting | Blog | AD Book

    Tuesday, December 12, 2017 5:53 PM
    Moderator
  • OK, so the new error is based on Brian's suggestion.  I get:

    Microsoft.MetadirectoryServices.ProvisioningBySyncRuleException: An object with DN "cn="+displayName+",OU=MIMUsers,DC=PLSTEST,DC=com" already exists in management agent "ADMA".

    I get this for both of the two test users I created in the MIM portal.  But the users do not show up in ADUC.  I have done this (in the order presented):

    • Run Full Import on the MIM MA.
    • Run Full Sync on MIM MA
    • Run Full Import on the AD MA
    • Run Full Sync on the AD MA
    • Stopped the Forefront Identity Manager service.
    • Stopped the Forefront Identity Manager Sychronization service
    • Started the Forefront Identity Manager service
    • Started the Forefront Identity Manager Synchronization service
    • Run Full Sync on MIM MA

    I can see both users when I do a Metaverse Search using the Sync Service Manager.  Neither one references the ADMA in their properties (although I don't think that's the problem).

    My suspicion is that the dn I'm asking your help with is (now) being taken literally, not as having a variable "displayName" to be set by each respective Metaverse object.

    I've tried looking up how to configure input variables into distinguished name notation, but only get results for using CSV's in PowerShell scripts.

    I think I'm going to repeat this question in an AD forum.  See if they understand what I need and what I'm lacking.  I still welcome feedback here, though.
    • Edited by Rob J Vargas Tuesday, December 12, 2017 6:50 PM Added info.
    Tuesday, December 12, 2017 6:48 PM
  • If it's literally including "displayName" then something is not right still. Without seeing the sync rule it's hard to say. It should be taking that from the displayName Metaverse attribute value.

    Thanks,
    Brian


    Thanks,
    Brian

    Consulting | Blog | AD Book

    Tuesday, December 12, 2017 7:03 PM
    Moderator
  • The error indicates a duplicate account with the same DN.
    You don't need to ask the AD Forum, just show as how the DN is build, we can easily identity the issue.

    As mentioned before, the DN has to be like this "cn=displayName,OU=MIMUsers,DC=PLSTEST,DC=com"

    Not "cn="+displayName+",OU=MIMUsers,DC=PLSTEST,DC=com". Compare the two and you will see the difference.


    Nosh Mernacaj, Identity Management Specialist

    Tuesday, December 12, 2017 10:14 PM
  • Thank you all.  Turns out I was using the wrong field source.  I think.  The dn notation that succeeded was:

    "CN="+accountName+",OU=MIMUsers,DC=PLSTEST,DC=COM"⇒dn

    The resource that I used to generate that notation in the first place had me manually generate the string.

    Concatenation is built right into the attribute flow screen in MIM.  That, plus a different resource, which I'll plug now:  The Microsoft Identity Manager 2016 Handbook, used accountName, where the other resource told me to use displayName.

    I'm still not getting the users provisioned into A.D.  I suspect I'm missing an attribute flow to make it happen.  But I only just got past this error, so I haven't done any additional troubleshooting of my own just yet.

    At least now the new users in MIM have an ERE.

    Wednesday, December 13, 2017 11:00 PM
  • Rob,

    Sorry, but there is no such a thing as the wrong field for CN. You use whatever the requirement is and there is no set rules of what that should be. 

    The answer was given to you, including me telling you not to use displayName because it is not unique.  Please read the guide here, for what you are trying to do.

    https://technet.microsoft.com/en-us/library/ff686263(v=ws.10).aspx


    Nosh Mernacaj, Identity Management Specialist

    Thursday, December 14, 2017 2:17 PM
  • Nosh:

    If it was the source of errors in synchronizations, then it was wrong, even if was valid within dn syntax.  Changing to accountName cleared the error, although something still isn't "finishing" the synchronization.

    No errors that I can find, but the user still isn't searchable in AD, nor listed in the destination OU per the above dn.  Here's the outbound attribute flow as copied from the outbound synchronization rule:

    Initial flow:

    <export-flow allows-null="false"><src><attr>accountName</attr></src><dest>dn</dest><scoping></scoping><fn id="+" isCustomExpression="false"><arg>"CN="</arg><arg>accountName</arg><arg>",OU=MIMUsers,DC=PLSTEST,DC=COM"</arg></fn></export-flow>
    ------------------------------------------------------------
    <export-flow allows-null="false"><src>512</src><dest>userAccountControl</dest><scoping></scoping></export-flow>
    ------------------------------------------------------------
    <export-flow allows-null="false"><src>PassW0rd</src><dest>unicodePwd</dest><scoping></scoping></export-flow>
    ------------------------------------------------------------

    Since this is only for POC, I don't consider any of that to be confidential.

    Now for persistent:

    <export-flow allows-null="false"><src><attr>accountName</attr></src><dest>sAMAccountName</dest><scoping></scoping></export-flow>
    ------------------------------------------------------------
    <export-flow allows-null="false"><src><attr>displayName</attr></src><dest>displayName</dest><scoping></scoping></export-flow>
    ------------------------------------------------------------
    <export-flow allows-null="false"><src><attr>employeeType</attr></src><dest>employeeType</dest><scoping></scoping></export-flow>
    ------------------------------------------------------------
    <export-flow allows-null="false"><src><attr>firstName</attr></src><dest>givenName</dest><scoping></scoping></export-flow>
    ------------------------------------------------------------
    <export-flow allows-null="false"><src><attr>lastName</attr></src><dest>sn</dest><scoping></scoping></export-flow>
    ------------------------------------------------------------

    I thought briefly that flowing accountName to SAMAccountName was the problem, but I've tried synchronization with and without that attribute flow, restarting the Forefront service AND the Forefront Synchronization service after each.  No change.  The users created in MIM show the sync rule in their ERL.  But they remain in pending status.

    Therein, I think, lies the key to what I'm missing.

    Thursday, December 14, 2017 4:59 PM
  • you are missing required attribute userPrincipalname usually something like this. AccountName@DomainName.com


    Nosh Mernacaj, Identity Management Specialist


    Thursday, December 14, 2017 5:10 PM
  • You appear correct, Nosh.  Although that didn't appear to be what was halting the account provisioning.  ADMA just needed to do an export.

    Upon doing an ADMA Export, the accounts show up in A.D.  But the username appears randomized.  For example, one user, I called him Alan Harkin.  I see him in AD now, in the correct OU.  But in the account tab there's no entry for User Logon Name, and the Pre-Windows 2000 has an apparently randomized name: $A91000-FVH2QR78IP7A.

    I don't see that attribute as an option in the MIM portal.  So... a missing attribute flow?

    Thursday, December 14, 2017 10:19 PM
  • When you look at the Active Directory Users and computer, you see friendly names.

    The Pre-Windows 2000 is called UserPrincipalName in the AD Schema.

    Set UserPrincipalName = accountName@domainName. accountName + "@"+ domainName. That is what is getting randomize, because you are leaving it blank.

    Export is needed, but please follow the guide. We are assuming you are doing something. Nothing happens magically. :)


    Nosh Mernacaj, Identity Management Specialist


    Thursday, December 14, 2017 10:26 PM
  • I don't see an option for UserPrincipalName.  Not for source nor for destination.
    Thursday, December 14, 2017 10:39 PM
  • There are many steps to making this work and you are skipping some of them.

    UserPrincipalName is an AD Attribute and it is not selected by default. You need to select it in the AD MA

    Then,

    Export as follows

    AccountName+"@PLSTEST.com" ==> UserPrincipalName


    Nosh Mernacaj, Identity Management Specialist

    • Marked as answer by Rob J Vargas Friday, December 15, 2017 8:24 PM
    Thursday, December 14, 2017 11:18 PM
  • There are many steps to making this work and you are skipping some of them.

    ...

    Then,

    Export as follows

    AccountName+"@PLSTEST.com" ==> UserPrincipalName


    Nosh Mernacaj, Identity Management Specialist

    I don't know where I'm skipping this.  I followed the installation guide at https://docs.microsoft.com/en-us/microsoft-identity-manager/install-mim-sync-ad-service#create-the-ad-management-agent

    There was no mention of UserPrincipalName there.

    I'll add it now.

    • Marked as answer by Rob J Vargas Friday, December 15, 2017 8:24 PM
    • Unmarked as answer by Rob J Vargas Friday, December 15, 2017 8:24 PM
    Friday, December 15, 2017 5:23 PM
  • I don't know about this guide, and there are definitely gaps in these guides, but you also said above, "ADMA just needed to do an export." Which is the equivalent of saying, I need to turn the computer on before I can send an email. :)


    Nosh Mernacaj, Identity Management Specialist

    Friday, December 15, 2017 8:05 PM
  • Nosh, thank you for your help.  I think I'm done at this point.  You'll get credit for the answer, but I didn't come here to be lectured.
    Friday, December 15, 2017 8:23 PM