Organizations typically use Azure AD Join to keep up the connection between their on-prem lively listing and their Workplace 365/Azure cloud occasion, and when doing this, it’s essential that they construct in redundancy with enterprise continuity in thoughts.
Not too long ago our group sought to make two significant modifications to its sync relationship:
- arrange a non-domain-controller AD Join server
- configure the present sync server as a standby for failover within the occasion of issues with the first server
There ought to solely ever be one lively sync server at any given time to function an authority on the info that’s synced from on-prem to the cloud.
It’s attainable to put in AD Join on area controllers, and that’s what we had performed with our preliminary, on-prem AD Join server, Server A. However generally, it’s greatest follow to make use of a devoted server to keep away from conflicts between the 2 roles. It additionally makes it simpler to isolate points as they come up and to carry out upkeep on one service with out affecting the opposite. (Any server that has AD Join put in on it have to be on-prem inside your surroundings.)
So our crew made Serve A the standby and created a brand new server (Server B) and gave it the only real function of being the first AD sync server.
Making the change takes only a few steps, however we discovered it’s essential to be conscious of which server you make modifications to and to export the present sync-server settings to the brand new server. Notice: The servers don’t go into or out of staging mode routinely; this have to be performed manually. Meaning if the lively AD Join server is down for any purpose, somebody must take the secondary server out of staging mode to make it lively.
We arrange Server B with Home windows Server 2019, and joined it to our area, however earlier than putting in AD Join, we exported the settings on Server A utilizing the next steps:
- On Server A, we opened the Microsoft Azure Energetic Listing Join utility and chosen “Configure”.
- We chosen the “View or export the present configuration” choice then “Subsequent”.
- Beneath “Overview Your Resolution” we clicked “Export Settings”, then “Exit”.
- At this level, this system prompted for a “save location” to avoid wasting the .json file to be exported with all of the configuration settings.
After exporting the Server A configuration file, we moved on to configuring Server B, however at this level we didn’t place Server A in standby. That must be performed instantly earlier than making Server B lively to reduce the time there isn’t any lively sync server.
Subsequent, we navigated to Server B, put in AD Join, and began the Azure AD Join wizard. After accepting the licensing settlement, we had been prompted to make use of categorical settings or customized setup. We clicked “Customise”.
We checked “Import synchronization settings,” browsed to the placement of the exported configuration file from Server A, and clicked “Set up”. Importing this file doesn’t routinely make Server B lively; that comes later.
The subsequent display screen was for person sign-in choices, and these are pre-selected based mostly on the configuration of your first AD Join server (Server A in our case). We use the pass-through authentication choice for single sign-on (SSO). (AD Join servers are routinely Passthrough Authentication brokers, however you possibly can have a number of brokers arrange that aren’t AD Join servers. Extra on that later.) We clicked “Subsequent” to maneuver on to the subsequent display screen.
To attach our Azure occasion, we would have liked to provide credentials that belong to the “International Administrator” position in Azure. We entered that and clicked “Subsequent”.
You can be requested to both create a brand new AD account or use an present one. The AD account mainly serves as a service account to question on-prem AD and carry out the sync duties. The better and advisable method is to create a brand new account with each AD Join server to stop points. We selected to have the account auto-generated, so we offered the credentials of an enterprise admin in my area. We clicked “OK” when performed.
The display screen that follows asks to your listing kind on-prem and the Energetic Listing area or forest data to connect with.
We selected “Energetic Listing” as listing kind as a result of we’re a Home windows area store. We offered my forest listing within the type of area.native, and pressed “Subsequent”.
The subsequent display screen confirmed the configuration and offered notes about it, such because the AD recycle bin not being lively and gadget writeback settings. You may return and comply with Microsoft’s advisable configurations after that is full, which is what we did and clicked “Exit” to maneuver on.
As a result of we selected SSO earlier on within the set up, we would have liked to enter area admin credentials to configure AD for that piece. We did and clicked “Subsequent”. Accomplished!
When Server B is configured, Server A may be positioned in staging mode, and Server B taken out of staging mode to make it the lively AD Join Sync Server. Solely one in all these servers ought to be lively at one time to stop sync conflicts.
Examine that the syncing is working
To confirm that syncing is working from the Azure facet, verify with the Azure Energetic Listing admin middle. Navigate Azure Energetic Listing -> Azure AD Join -> Azure AD Join Well being. From there you possibly can entry each “Sync errors” and “Sync providers”, which ought to offer you a good suggestion of the well being of the sync between your on-prem surroundings and your Azure occasion.
If you’re utilizing passthrough authentication, go to the Passthrough Authentication web page (Azure Energetic Listing -> Azure AD Join -> Cross-through authentication). Right here you need to see on the very least the 2 AD Join servers you’ve gotten as brokers, and you’ll add extra, non-AD join brokers by clicking on the “Obtain” button on the high of the web page. In the environment, we now have made all lively area controllers passthrough authentication brokers as properly, so solely these servers have the duty of permitting authentication for SSO.
Copyright © 2022 IDG Communications, Inc.
