none
Wrong domain address when synchronizing from on premise AD

    Question

  • Hello,

    I wonder if someone can help us with the following problem:

    After the synchronization the new created users from our local AD to Azure AD, the users are being synced with wrong domain address, the one which is created by default from the Azure side (domain.onmicrosoft.com). So we have to edit each new synchronized user manually in order to change his domain.

    Please note that the desired Domain is marked as "Default" in the Domain settings section in Azure.

    so instead of synchronizing to : user@domain.com

    it's synchronizing to : user@domain.onmicrosoft.com

    Microsoft Support told me that it's realted to the Proxy Addresses of the users. All users in our AD have the following addresses:

    - userAlias@domain.lan (alias to connect to office 365)

    - user@domain.com

    - user@domain.lan

    For further clarity to our infra:

    - AD is on premise, which being synchronized through "Azure AD Connect".

    - Exchange Server is on Premise.

    There is DNS Warning by the default domain because we dont't want insert our Exchange MX in the Online Exchange, which I think we should not because our emails should go through our DNS Host.

    I'm sure that I have misunderstood something about the connection between local AD and Azure AD or a little misconfiguration at the beginning have been done.

    Tuesday, April 4, 2017 8:52 AM

Answers

  • Yes, it is related to the proxyAddress as support says. On-prem you can add multiple aliases and approved domains to your users. (Through the "Domains and Trusts" console if I remember correctly.) But the one you have as default will be the one matching up during sync to Azure AD. So if your users have @domain.lan as the default, and that is not verified in AAD/O365 you will get the @onmicrosoft.com instead.

    As you have already discovered you can change this manually, but changing the default alias of the users should also work. (Change it to the one verified in O365.)

    Whether you keep your Exchange on-prem or not (or maintain a hybrid setup) you should verify the domain in O365. Verifying the domain does not require you to change the SMTP flow. Having O365 send and receive on that specific domain name requires configuration changes, but in a hybrid setup you can configure Exchange as to whether you want inbound/outbound to always flow through your servers or not.

    • Marked as answer by Schreibati Friday, April 7, 2017 11:53 AM
    Tuesday, April 4, 2017 10:04 AM
    • Marked as answer by Schreibati Friday, April 7, 2017 11:53 AM
    Tuesday, April 4, 2017 10:11 AM

All replies

  • Yes, it is related to the proxyAddress as support says. On-prem you can add multiple aliases and approved domains to your users. (Through the "Domains and Trusts" console if I remember correctly.) But the one you have as default will be the one matching up during sync to Azure AD. So if your users have @domain.lan as the default, and that is not verified in AAD/O365 you will get the @onmicrosoft.com instead.

    As you have already discovered you can change this manually, but changing the default alias of the users should also work. (Change it to the one verified in O365.)

    Whether you keep your Exchange on-prem or not (or maintain a hybrid setup) you should verify the domain in O365. Verifying the domain does not require you to change the SMTP flow. Having O365 send and receive on that specific domain name requires configuration changes, but in a hybrid setup you can configure Exchange as to whether you want inbound/outbound to always flow through your servers or not.

    • Marked as answer by Schreibati Friday, April 7, 2017 11:53 AM
    Tuesday, April 4, 2017 10:04 AM
    • Marked as answer by Schreibati Friday, April 7, 2017 11:53 AM
    Tuesday, April 4, 2017 10:11 AM
  • Thank you for the informations! They fixed our problems with Azure AD!
    • Marked as answer by Schreibati Friday, April 7, 2017 11:53 AM
    • Unmarked as answer by Schreibati Friday, April 7, 2017 11:53 AM
    Friday, April 7, 2017 11:52 AM
  • can you describe what had been done in the AZURE AD  in order the solve the problem?  
    Wednesday, June 20, 2018 12:58 PM
  • @Ofer A HaMoked - Meanwhile I would suggest you to create new thread in the Azure AD Forums and elaborate what exactly you are trying to achieve and issue you are facing. 
    Sunday, June 24, 2018 8:10 PM
    Moderator