O365 AD Connector?

Copper Contributor

I have inherited a hybrid O365/On-Prem solution with my company.

 

What we have is a local only Active Directory and O365 subscriptions, this means that users currently have one password to logon to the network here and another for their emails etc... 

 

I want to setup the AD connector so that these details are sync'd.

 

My initial question is what will happen if I setup the AD connector today? I would assume that all my local AD accounts, groups etc... will be copied to my O365 however there will be duplicates i.e. JSmith has an AD account and an O365 subscription usernames will be the same. 

 

Any help much appreciated. 

15 Replies

Hi!

I guess what you mean its separated right now and not hybrid (connected) yet..

 

What you wanna do is setup the ADConnect and probably filter byOU (most common) which objects you wanna sync..You can then only sync the users/groups you want, also test things out..

 

You have to add the Office 365 UPN to the users you are syncing! Many AD's today have a UPN of user1@company.local or such..If you have company.com as a domain in office 365, (your 365 users have a mail of user1@company.com for example) company.com must be added as a UPN in AD and set on the users which to be synced ( Same UPN)

 

Regarding the accounts that exists in your Office 365 tenant today, they can be merged with the accounts in AD.

If UPN's and proxyaddress is matching the 2 users will do a soft match and not end up duplicated

 

Read more here:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-existing-tenan...

Hi, Ad connect is made of 3 component, Monitoring,ADSF and Sync services which will ONLY help you do INTEGRATE your on premise AD and Azure AD to SYNC and monitor ONLY the users that you select and pls not to assume that all your local AD accounts, groups etc... will be copied to my O365 ... 2 good hints, is to just make sure those users are routable UPN names and that your SYNC is a one way Traffic...... Another good suggestion I have for you is that, since ADSF is a component of AD Connect I will enable it during the setup of AD connect, because if you decide in the near future to have a ful blown SSO then all you will only need to DO, is to setup ADSF Farm and Trust using Powershell between your On premise AD and Azure AD. Good Luck

Hi Paul,

 

Whatever you do, do not take installing and configuring Azure AD Connect lightly!  I know (from experience, unfortunately) that one wrong checkbox can ruin your weekend, and possibly much longer than that.  You'll want to involve any other admins that run Microsoft services at your company, too, as once that sync is made there is no going back and it can greatly affect any and all Microsoft services in your environment.  

 

Make sure you understand all your options around hybrid O365 identities before you decide how to set up your environment.  Additionally, make sure you review how Azure AD Connect will "match" your existing user accounts and check for duplicates - this is another one of those things that you can't undo once it is set.  And make sure that your user accounts actually meet all the requirements before going too far down that road.

 

Best of luck!

Absolutely correct about reading up on the topic! If done right, this is pretty straightforward and not that complex! Troubleshooting a faulty setup however, could very much be :)
Although, you’re a little harch! The sync can very much be undone

Adam
what do you mean by "hybrid"? that typically means that accounts are created on-prem and sent to O365 and the only way to do this is with Azure AD Connect. It may already be setup.
Hi Adam,

There are some scenarios that are easier to undo than others, certainly, but there are others that require potentially destructive changes to break the sync. Setting up hybrid identities should never be something an administrator just decides to do on a whim because the application itself is easy to install.
He should set up adfs from the adconnect if not using it at all right now! Also I recommend using pass-through auto and seamless sso instead of ADFS! Works for “most” scenarios!
Yes! Read up on the procedure! That’s what I wrote :)
Also in this case the scenario was that he wanted to sync his AD and match the users in O365! My point of view was out of that perspective, Nothing else
Cheers / Adam

No the UPN's are all set to the local domain i.e. %USERNAME%.DOMAIN.LOCAL

No the UPN's are all set to the local domain i.e. %USERNAME%.DOMAIN.LOCAL

If you don't want to have new/duplicate users, this would be the first thing you need to adjust prior to a migration.

 


Quadrotech - Management, Reporting and Migration for Office 365 and Exchange

So in order to test I am going to filter out all OU's except a test OU. 

 

Am I right in saying that so long as the UPN and ProxyAddress match that of the O365 object then the accounts will be merged?

 

People have mentioned one-way sync, how and where can I check that my connection is in fact one-way only?

Hi Paul,

 

Good call - a small test OU or pilot group is a great idea for this.

 

Rather than using the express install wizard, you probably will want to go through the custom installation instead.  Have a read through all of the options in the custom install wizard before deciding, of course, but by going through the custom install you'll have control over which OU's to sync (or just use a pilot group), and whether any write-back (two way sync) features are enabled.

 

Something worth noting from my previous experience that may not be apparent from reading all this documentation is that the account in your on-prem Active Directory will become the master account, which means that the on-prem account's details will overwrite any information that may have been set in the cloud identity - so it's not really what I consider a true "merge".  In your testing you might want to make sure you check all of the proxy addresses before and after an account is synced to see if there could be any potential interruption to mail flow for users.  For instance, if your on-prem account has only the primary SMTP address in it's proxy addresses, but your cloud account has multiple proxy addresses, then when those accounts are synced only the primary SMTP address will remain and all those other proxy addresses will be removed.  This also means that you may have to adjust provisioning processes if you had some of that user information being updated in the cloud rather than on-prem, many of the settings will only be able to be managed from your on-prem directory at that point.

 

Another thing to remember is that when an account in the cloud is synced to an on-prem object, it's always synced to that object.  The guid of the on-prem object is encoded and written to the cloud object forming a permanent link between the two objects.  It is really hard to unlink those accounts at that point, so just be cautious and test as many scenarios as you can before syncing your whole directory.  You might want to also check out the troubleshooting guide to see how you can view exactly what attributes are being written and where in your testing.  

Hello Paul, 

Let me know if you still have any queries.