First published on TechNet on Mar 12, 2018
Greetings and salutations fellow Internet travelers! Michael Hildebrand here...as some of you might recall, I used to pen quite a few posts here, but a while back, I changed roles within Microsoft and 'Hilde - PFE' was no longer. Since leaving the ranks of PFE, I've spent the last couple of years focused on enterprise mobility and security technologies. Recently, I was chatting with the fine folks who keep the wheels on this blog when I asked "Hey – how about a series of guest-posts from me?" They said if I paid them $5, I could get some air-time, so here we are. My intentions are simple - through a series of posts, I'll provide high-level discussion/context around the modern Microsoft mobility and security platform to "paint you a picture" (or a Visio) of where we are today then I'll move on to 'the doing.' I'll discuss how to transform from 'on-prem' to 'hybrid-enabled' to 'hybrid-excited.' I'll start that journey off in this post by establishing the foundation - hybrid identity – then, in subsequent posts, I'll work through enabling additional services that address common enterprise scenarios. Along the way, I'll provide job aids, tips and traps from the field. It continues to be a very exciting time in IT and I look forward to chatting with you once more. Let's roll. Azure AD – Identity for the cloud era The hub of Microsoft's modern productivity platform is identity; it is the control point for productivity, access control and security. Azure Active Directory (AAD) is Microsoft's identity service for the cloud-enabled org. If you want more depth (or a refresher) about what Azure Active Directory is, there's no shortage of content out there. I'll be lazy and just recommend a read of my prior post about "Azure AD for the old-school AD Admin." It's from two years ago – which makes it about 2x older in 'cloud years' – and as such, it suffers a bit from 'blog decay' on some specifics (UIs and then-current capabilities), but the concepts are still accurate. So, go give that a read and then come on back … I'll wait right here for you.
The Clouds, they are a-changin' As an "evergreen" cloud service, AAD sees continuous updates/improvements in the service and capability set. Service updates roll out approximately every month – so, we're at around 36 +/- AAD service updates since my Jan 2015 article. To stay on top of AAD updates, changes and news, the EMS blog ( Link ) is always a good first stop. If you like "Release Notes" style content, starting last September (2017), the 'What's new in AAD' archive is available - https://docs.microsoft.com/en-us/azure/active-directory/whats-new . Recently, a change to the AAD Portal homepage added a filterable 'What's new in Azure AD' section – Also, the O365 Message Center has a category for "Identity Management Service" messages: An Ambitious Plan Here's the plan for this post, this series and some details about my "current state" environment:
Now let's get down to brass tacks. For the rest of this post, I'll focus on considerations, planning and pre-reqs for getting Azure AD Connect up and running and then I'll walk through the setup and configuration of AD and AAD Connect to integrate an on-prem AD forest with an on-line AAD tenant.
NOTE – As with most blogs, this isn't official, sanctioned Microsoft guidance. This is information based on my experiences; your mileage may vary. Overall AAD Connect Planning Microsoft has done a lot of work to gather/list pre-reqs for AAD Connect. Save yourself some avoidable heartburn; go read them … ALL of them:
AAD Connect has two install options to consider – Express and Custom: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-select-...
Consider AAD Connect 'Automatic Upgrade' to keep AAD Connect up-to-date automatically:
AAD Connect uses a service account model to sync objects/attributes between AD and AAD. There are two service accounts needed on-prem (one for the sync service/DB and one for AD access) - and one service account needed in AAD.
Service account details:
TIP - The username of this account is derived from the AAD Connect server name
TIP – This account won't be seen anywhere in AD; it's only part of AAD and the sync system. You can see it in the configuration pages of the Synchronization Service Manager tool - screen snip below.
TIP - The ID can also be seen in the AAD portal 'Users' section.
Planning on-prem sync filtering
You can limit what users, groups, contacts and devices are sync'd between on-prem AD and Azure AD. This is known as 'filtering' and can be done based on forest, domain, OU or even object attribute values. Also, for a pilot or PoC, you can filter only the members of a single AD group.
TIP – Thoroughly plan/test a sync filtering strategy to understand what will/won't sync. In prod, do it once; do it right.
Read this link for more information/details about sync filtering:
Points to consider:
TIP – Group-filtered sync isn't supported for production implementations
UPNs and email addresses – should they be the same?
In a word, yes. The best experience for your users (seamless SSO with minimal login prompts or pop-ups/sign in errors, etc.) will be achieved when the on-prem UPN matches the AAD UPN, as well as the primary email address (and SIP address for overall consistency). This assumes there is an on-prem UPN suffix in AD that matches the publicly routable domain that your org owns (i.e. ... @microsoft.com ).
"Ok, but is it required ?" No, but over time, it will make lives better with less confused users who make fewer helpdesk calls and are happier with IT.
Points to consider:
AAD Connect – Install and configuration I basically break this phase up into three sections:
TIP - You can enable SSPR/pwd writeback without enabling password hash sync; you can offer your users self-service password reset even if you're not ready to sync passwords to Azure AD.
TIP – You don't select the specific domains/OUs you want to sync here; that's done in a later step
TIP – In the long red box above, you see I have a UPN suffix in AD that matches a verified custom domain name that I registered in my AAD; this is due to the pre-work that I mentioned in the UPN section above.
TIP - If you haven't verified a custom domain, you'll see an option to 'Continue without any verified domains' (i.e. for a test or PoC environment)
Repeated TIP – Thoroughly plan/test a sync filtering strategy to understand what will/won't sync. In prod, do it once; do it right.
TIP – As mentioned above in the sync planning section, recall that as/if new OUs/subOUs are created, they might be sync'd to AAD automatically.
Here's how to adjust your sync settings to control new OU sync:
The checkbox "state" in this UI indicates if new OUs will sync or not:
TIP – Recapping:
TIP – Even though the UI states this will synchronize all users and devices , that isn't really what happens. This option will sync all users, groups, contacts and Win 10 computer accounts "within the scope of any filtering you defined."
On the "Optional features" screen, verify all "Optional features" except Password synchronization are blank and click Next.
TIP - Subsequent delta synchronizations occur approx. every 30 min (and every 2 min the password hash sync process runs, if you've enabled it); previous versions.
TIP - You can easily trigger a sync via PowerShell at any time. I use a quick one-liner straight from the 'Run' dialog box on my AAD Connect server after making on-prem AD changes that I want to sync right away:
powershell –ExecutionPolicy Bypass Start-AdSyncSyncCycle
TIP – To avoid surprises with Automatic Upgrade of AAD Connect, now is a good time to review/verify the state of it for your AAD Connect via PowerShell:
HOMEWORK – Go school yourself about AAD Connect Health – I think you'll like it
If you're a visual person, like me, here's where we are on our plan: Ok folks, there you have it … a brief refresher on AAD as the ID hub of our modern productivity and security platform, a sizeable collection of "points to consider" when planning AD sync and then a walk-through of setting up AAD Connect to hybrid-enable a sample Active Directory forest. Hopefully, that level of detail was helpful. Tune in next time when I'll continue the march towards 'hybrid-excited.' Cheers! "Welcome back, (Hilde) Kotter" P.S. Did anyone catch how the title of this post pays homage to the awesome movie "Remo Williams: The Adventure Begins"?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.