none
importing from azure active directory connector gives only few attributes

    Question

  • Hello,

    I have to connect the output of non active directory system to Office365 to provision users. To this end I have installed MIM 2016 and added the azure active directory connector.

    The office365 tenant has pre-existing user accounts. I specified an immutableId for these accounts using powershell. I then was able to import these users.

    The problem is I get only very few attributes in the import, though I selected many for import.

    I would at least expect a value for userprincipalname and the email addresses of the user, but I barely get more than first and lastname. How do I get the agent to import more attributes? Is this a result of those account already existing? If so how do I convert them to "synced" accounts?

    Hope somebody here know the answer.


    Wednesday, July 04, 2018 4:11 PM

Answers

  • I'm going to answer my own question here. For whomever it might be usefull.

    The reason I was seeing little output is how azure/office365 infrastructure seems to work. The agent synchronizes with azure AD and not Office365. Whatever you sync to azureAD is "copied" to office365.

    That might look like the same thing but is not. As values that where already configured on the existing offic365 where not set in the accompanying azure AD of the tenant, like userprincipal name and mail addresses and many more. As soon as I exported those, I could also read them back from azure AD. I just made sure everything matched up with office365 data before export and everything just works.

    In the time working on this I had to do an unrelated adconnect install for a different customer. I noticed that on initial sync the behavior of ADConnect is exactly the same.

    Only one thing still eludes me and that is setting the initial password. Might have to go powershell for that one.

    • Marked as answer by Bart_Z Monday, July 09, 2018 10:31 AM
    Monday, July 09, 2018 10:31 AM

All replies

  • Hi

    first of all, the AAD connector for FIM/MIM is not recommended for new implementations and I would try to avoid using it.

    If you have an onPrem AD but most of the relevant data is in this non AD system, use MIM to transport data to AD and then use AADC, as AADC is more than just a sync. it has some other services around like for SSPR.

    If you dont have an onPrem AD, think about create one only for this purpose an use the method above.

    or

    Use a PowerShell connector in MIM to connect either via the Azure AD PowerShell or MSOL Module or best is directly to Graph API.

    /Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Thursday, July 05, 2018 12:59 PM
  • Hi Peter,

    The customer I'm working for does not have an environment with Active Directory. I could install one as a bridge and have done so many times before. However this customer refuses to allow for that. So I'm stuck not using ADConnect. Things like password or group writeback are not on the customer wishlist

    As an aside, for more advances scenario's I really wish I did not need ADConnect. Most environments already have a FIM/MIM installation, so ADConnect takes another server and extra hardware and host OS licenses as most my customers wish to keep server dedicated to single purposes (and no that does not always make sense). It also introduces an extra possible failure point by definition and requires AD.

    I have used powershell before but that is very slow. The graph agent is still in preview, I belief and I have not yet looked at it. Is it already a viable solution for provisioning?

    Friday, July 06, 2018 8:49 AM
  • Hi,

    understood, was just an option that I thought could maybe possible.

    Since AADC has smaller release cycle regarding new features in Azure AD and is much more than an sync solution I would always preferr AADC in generell.

    You are right the Graph Connector is still preview and the only current thought scenario is for B2B user writeback to onPrem.

    https://docs.microsoft.com/en-us/microsoft-identity-manager/microsoft-identity-manager-2016-connector-graph#scenario-specific-supported-guides

    My intention was you create your own MA either with PS or the ECMA framework to user the GraphAPI.

    So you always connect to the up-to -date API. The MIM AAD connector will not get any updates in the future so I cannot recommend to rely on it for a new solution.

    /Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Friday, July 06, 2018 8:58 AM
  • I'm going to answer my own question here. For whomever it might be usefull.

    The reason I was seeing little output is how azure/office365 infrastructure seems to work. The agent synchronizes with azure AD and not Office365. Whatever you sync to azureAD is "copied" to office365.

    That might look like the same thing but is not. As values that where already configured on the existing offic365 where not set in the accompanying azure AD of the tenant, like userprincipal name and mail addresses and many more. As soon as I exported those, I could also read them back from azure AD. I just made sure everything matched up with office365 data before export and everything just works.

    In the time working on this I had to do an unrelated adconnect install for a different customer. I noticed that on initial sync the behavior of ADConnect is exactly the same.

    Only one thing still eludes me and that is setting the initial password. Might have to go powershell for that one.

    • Marked as answer by Bart_Z Monday, July 09, 2018 10:31 AM
    Monday, July 09, 2018 10:31 AM