cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
The Adventure Begins: Plan and Establish Hybrid Identity with Azure AD Connect (Microsoft Enterprise Mobility and Security)
By
BrandonWilson
Published Sep 20 2018 07:46 AM 4,254 Views
BrandonWilson
Microsoft
‎Sep 20 2018 07:46 AM

The Adventure Begins: Plan and Establish Hybrid Identity with Azure AD Connect (Microsoft Enterprise Mobility and S...

‎Sep 20 2018 07:46 AM

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:

  • I'm starting out with an on-prem, single AD forest w/ two domains (contoso.lab and corp.contoso.lab)
    • Basically, the blue rounded-corner box in the Visio picture above:
  • In this post, I'm going to establish a hybrid identity system, and bridge on-prem AD to an AAD tenant via Azure AD Connect (AAD Connect)
    • Choose password hash for the authentication method
      • This enables password hash sync from AD to AAD
    • Filter the sync system to limit what gets sync'd from AD to AAD
    • Prepare AD for eventual registration of Domain-Joined Windows PCs from AD to AAD
  • In subsequent posts, I'll build on this foundation, covering topics such as custom branding for the cloud services, self-service password reset, device registration, Conditional Access and who knows what other EMS topics.
    • I'll be assigning homework, too, lest yee not fall asleep
  • I'll end up with an integrated, hybrid platform for secure productivity and management
  • These are pretty bold ambitions – but we'll get there, and the beauty of the cloud services model is that "getting there" isn't nearly as hard as that list makes it seem.

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.

  • If you already have AAD Connect up and running, KUDOS! Read-on, though, as you might find some helpful tips or details you weren't aware of or didn't consider.

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-...

  • The Express install of Azure AD Connect can get you hybrid-enabled in around 4 clicks. It's easy and simple - but not very flexible. Express setup requires an Enterprise Admin credential to perform all of the AD changes and you don't have a lot of control over those changes (i.e. naming service accounts, where in AD they go, which OUs get permissions changes, etc).

     

  • The Custom install of Azure AD Connect provides more flexibility, such as allowing you to pre-create the service accounts (per your AD naming/location standards) as well as assign scoped AD permissions as part of the pre-work before installing AAD Connect.

Consider AAD Connect 'Automatic Upgrade' to keep AAD Connect up-to-date automatically:

Service accounts

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:

  • Sync service account - this is for the sync service and database
  • AD access service account - this is a Domain User in the AD directory(ies) you want to sync.
    • An ordinary, low-privilege Domain User AD account with read access to AD is all that is needed for AAD Connect to sync AD to AAD for basic activities.
    • There are notable exceptions that require elevated permissions and two I'll cover here are password hash sync and password writeback (for self-service password reset/account unlock)
    TIP - Create your AD access service account in AD and assign any custom permissions to it BEFORE you install AAD Connect. TIP - This account itself doesn't need to sync to AAD and can/should reside in a 'Service Account' OU, with your other service accounts, filtered from sync. TIP – Make sure you secure, manage and audit this service account, as with any service account.
  • AAD cloud access account
    • This is a limited, cloud-only account in Azure AD, created by the AADC install process, which sets a long, complex password that is set to not expire.

    TIP - The username of this account is derived from the AAD Connect server name

    • For example, my AAD Connect server is named "CORP-AADC01" so the AAD service account ID will be something like "Sync_CORP-AADC01_1@mycorp.onmicrosoft.com"

    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.

    • The Synchronization Service Manager tool is sometimes used for advanced sync settings and is out of scope for this article; I strongly urge you to not wander around in there.

    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:

  • Not everything in AD is sync'd, even if you don't filter –
    • For example, DNS zones don't get sync'd. GPOs don't get sync'd. Objects with the "isCriticalSystemObject" attribute equal to "true" won't sync – so many sensitive AD objects won't sync (i.e. Domain Admins group in AD)
    • However, unless filtered, some objects may sync that you don't need/want in AAD (i.e. the DNS Admins group in AD, your service account OU, etc.)
  • Any OU that has/will have Windows 10 PCs that you want to register/sync to AAD (called 'Hybrid Azure AD Join') should be selected for sync, as Azure AD Connect plays a part in sync'ing Win 10 PCs to Azure.
    • Azure AD Connect does not play a part in sync'ing pre-Win 10 PCs; they can sync/register in AAD on their own (after you install an update/MSI to those OSes), regardless of their OU being targeted or not
    • We'll get into the weeds of Hybrid Azure AD Join, AAD Join and Azure Device Registration Service in a later post
  • For a pilot, you can simplify what gets sync'd by selecting a single group in AD to sync
    • Use a "flat" Global Security group in AD; any nested groups within it won't sync
    • If you also setup OU filtering, be sure the target group and its members (users, Windows 10 PCs, etc.) are all in OUs that are in-scope for sync – OU filtering is evaluated before the group filter.
    • You can't browse for the group via the wizard – you need to type in the group name or DN attribute (the 'resolve' button will verify it, though)
    • The UI option to filter by group only appears in the initial setup of AAD Connect. If you don't select it during the first run, it won't show up in the UI in subsequent runs of the tool.

    TIP – Group-filtered sync isn't supported for production implementations

  • New OUs/subOUs that are created after you've setup your sync filtering in AAD Connect may be sync'd by default. If so, this may be an unwelcome surprise.
    • I'll cover more on this later in the AAD Connect configuration section

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:

  • Recall the pre-requisites doc/link – it lists a line-item to add any custom domain(s); go through the process to add and 'verify' your public domain names (called 'custom' domains in O365/AAD) before setting up AAD Connect. There is a step during AAD Connect setup that will poll on-prem AD for UPN suffixes and AAD for matching verified custom domains. This is visible in my step-by-step later.
  • To avoid additional work and potential issues, it is strongly recommended that you address UPN/ID issues BEFORE you install AAD Connect

AAD Connect – Install and configuration I basically break this phase up into three sections:

  1. AAD Connect server setup/tools install
  2. On-prem AD config
  3. Initial sync config
  4. AAD Connect server setup and Tools Install
    1. On my AAD Connect server (these steps are for a WS 2012 R2 x64 instance – again, read all the AAD Connect pre-reqs from the link above; your specific steps may vary):
      1. Disable IE Enhanced Security Config and enable Cookies in the IE browser settings
      2. Install the RSAT AD tools – via Server Manager or PowerShell <from elevated PoSh>
        1. Add-WindowsFeature RSAT-AD-Powershell
      3. Download and update to WMF 5.0 then install AAD PowerShell v1
          1. Reboot
        2. Open elevated PowerShell and run Install-Module -Name PowerShellGet -Force
        3. From same PowerShell console, run Install-Module -Name MSOnline
      4. Download AAD Connect (AzureADConnect.msi) and install it on the target AAD Connect server
        1. https://www.microsoft.com/en-us/download/details.aspx?id=47594
      5. As soon as the install completes, the AAD Connect configuration wizard will auto-initiate – don't run through it; exit/close out of the tool/wizard.
      6. The AAD Connect setup installs the sync service and several pre-reqs, and copies some PowerShell scripts/functions locally
  5. On-prem AD config
    1. Prepare on-prem AD for Azure AD integration (I'll also initialize AD for Azure AD Device Registration Service – AzDRS)
      1. Use PowerShell to establish the Service Connection Point (SCP) object and associated attributes in AD - More info
      1. This process creates an object in on-prem AD with pointers to the associated on-line AAD tenant name and GUID – this information is used by several AD <-> AAD integrations such as AAD device registration, device write-back, etc.
        1. For example, this information is used by Windows domain-joined PCs to "find" the connected AAD tenant and register there (aka "Hybrid Azure AD Join.")
      2. From the AAD Connect server:
        1. Run a PowerShell window as an Enterprise Admin account (this process needs to create a container in the Configuration partition in the AD forest):
        2. Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1" <press enter>
        3. Initialize-ADSyncDomainJoinedComputerSync <press enter>
        4. PowerShell will prompt for AdConnectorAccount : enter the AD access service account and press enter
          1. The format is "domain\ID" - CORP\SRV-AADC
        5. A logon box will pop-up; enter the AzureADCredentials
          1. This should be a Global Admin ID from Azure AD
          2. The format is upn-style - admin@woodgroove.onmicrosoft.com
      3. Verified results:

  1. Review/verify/edit the AD access service account has permissions for the desired Azure AD services/features (see above Service Accounts section)
    1. Remember, password hash sync and self-service password reset (SSPR) each require unique manual permissions edits in AD
      1. This is a commonly missed step or not done correctly

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.

  1. Initial Sync config
    Let's take a breath, pause and recap: AAD Connect is installed and several on-prem decisions and configurations have been completed (sync filtering decisions, service accounts created, custom permissions assigned, 'Service Connection Point' container created and verified in AD, etc.).
    1. Next, I establish the core AD > Azure AD sync configuration and start actually sync'ing objects to AAD.
      1. From the AAD Connect server, launch the AAD Connect tool/wizard, agree to the license terms checkbox and click 'Continue.'
      2. We're doing 'Customize' (vs 'Express') for the reasons mentioned above (i.e. more flexibility in creating/naming/locating the service accounts)

      1. On the "Install required components" screen, leave all boxes blank – AAD Connect will setup the sync service and a 'virtual' service account on the AAD Connect server. This ID and password are system-managed and won't require any on-going management. Click 'Install.'

      1. Next, select the User sign-in/authentication method. My thinking has evolved over time on this aspect. I started out favoring federation with ADFS and on-prem passwords/auth, then I moved on to "Pass-through authentication" (PTA) and on-prem passwords/auth (I still really like PTA if there's a need to keep password hashes on-prem).
        However, now I've seen the light and "Password Synchronization" is my preferred choice. This is by far, the simplest solution and I'm comfortable w/ the security of password hash sync/storage. This is usually referred to as 'password hash sync' or PHS since AAD Connect takes the on-prem password hash value, processes it with additional hashing, then syncs that value to AAD. Also, with PHS, I get more complete coverage from the AAD Identity Protection capability and Azure-cloud levels of high-availability. Here's a great blog about the auth choices and decision: Sam D's auth choice blog .
        1. Also select the check box to "Enable single sign-on"

      1. On the "Connect to Azure AD" screen, enter an Azure AD global admin account (which isn't saved; it's only used during setup). Use a cloud-only ID from the tenant – i.e. admin@mycorp.onmicrosoft.com . This sets up the Azure AD tenant for sync and creates the AAD cloud access service account mentioned above in the service accounts section.

  1. On the "Connect your directories" screen, select/verify the target AD forest(s) and click "Add Directory" then select to "Use existing AD account." Enter the AD access service account credentials (from the above service accounts section) and click OK, then click Next.

TIP – You don't select the specific domains/OUs you want to sync here; that's done in a later step

  1. Review/select the Azure AD sign-in configuration - hopefully keeping the default which sets the on-prem UPN value as the login ID for Azure AD.

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)

  1. On the "Domain and OU filtering" screen, select "Sync selected domains and OUs" and select the domains/OUs to sync - or select "Sync all domains and OUs" if that's how you want to roll.
    1. Remember, even if an entire forest/domain is selected, not everything in the domain will sync.

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:

  1. If you DO NOT want subsequent new sub OUs to sync (my personal preference), clear all the check marks then click the deepest level, specific OU boxes you want to sync. The parent domain and OU box(es) will flip to solid gray, without a checkmark
    1. In this state:
      1. Only the selected OUs under CORPORATE will sync (white box with black checkmark)
      2. New OUs created anywhere will not sync

    1. If you DO want subsequent new sub OUs to sync, click the parent domain/OU box so it has a black checkmark (all sub-OUs will also get checked). Now, de -select the sub OU box(es) you don't want to sync, leaving the desired OUs checked. The parent OU box will turn gray with a black checkmark.
      1. In this state:
        1. The selected OUs under CORPORATE will sync (white box with black checkmark).
        2. New sub OUs created under the corp.contoso.lab domain and/or the CORPORATE OU will sync
    2. You can also configure a mixed state:
      1. In this state:
        1. New sub OUs created directly under corp.contoso.lab will not sync (gray box without black checkmark)
        2. The selected OUs under CORPORATE will sync (white box with black checkmark).
        3. New sub OUs created under the CORPORATE OU will sync (gray box with black checkmark)
        Example:
  • New 'Sync-Test-OU' was created in AD.
  • The new 'Sync-Test-OU' was added to sync filtering without making any changes to AAD Connect

TIP – Recapping:

  • White box without checkmark – won't sync
  • White box with black checkmark – will sync
  • Gray box without checkmark – new sub OUs won't sync
  • Gray box with black checkmark – new sub OUs will sync
  1. Review the unique identifier page for the sync configuration – the default is fine for my setup. Click Next.
  2. On the "Filter users and devices" screen, choose 'Synchronize all users and devices'

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."

  1. If you decided earlier that you want to use group filtering for sync (i.e. for a PoC), you choose 'Synchronize selected' here and enter the group name or DN and click 'resolve' to verify it.
    1. If you don't see this screen or if you are considering this, review the above details about group filtering – it is a common area of confusion and unexpected results/behavior.

On the "Optional features" screen, verify all "Optional features" except Password synchronization are blank and click Next.

  • The "Password synchronization" option is checked and grayed out due to the earlier selection of "Password synchronization" for User sign-in.

  1. On the "Enable single sign-on" screen, click 'Enter credentials' then enter Domain Admin credentials for the domain(s) where your SSSO users reside (don't be confused like I was when the pop-up asked for "Forest Credentials" – it's asking for a Domain Admin ID).
  2. Click OK. Then click Next.
    1. This step creates a computer account called "AZUREADSSOACC" and puts it in the built-in COMPUTERS container in the target domain(s).
    2. Don't pre-create this account – let AAD Connect do it, as it populates some specific attributes/values for this computer account.
      1. You can move the computer account to an OU of your choice and I'd recommend you configure it for protection from accidental deletion (right-click > properties > object tab).
  3. On the "Ready to configure" page, verify the 'Start the synchronization process…' option is checked (default) and click 'Install.' Click Exit after the 'Configuration complete' page displays.
  4. Review the Application Event Log on the AAD Connect server for related events.
  5. Sign in/refresh the Azure/AAD portal
    1. Verify sync by looking for your targeted on-prem objects in AAD and review the Azure AD Connect section of the Azure/AAD portal for successful sync messages.
      1. On-prem users sync'd are listed with a 'SOURCE' of 'Windows Server AD'
      2. On-prem groups sync'd are listed with a 'Membership type' of 'Synced'

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:

Get-ADSyncAutoUpgrade

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"?

0 Likes
Like
Version history
Last update:
‎Sep 05 2019 05:02 AM
Updated by:
Labels