Originally posted by Lucian Franghiu on his blog over at clouduccino.com, #clouduccino.


Time flies when you’re connecting to Azure AD. Late last month Microsoft announced that Azure AD Connect is now generally available. At the time of writing this, the synchronisation app itself still isn’t the default sync standard for Azure and obtaining the installer requires a quick Google. Since I’m deploying it for a client, I thought I’d run through the install process for future reference.

AADConnect provides allot of new functionality like for example this new fandangled ADDS password sync. In this scenario I’m keeping federation services, so ADFS will be deployed, which is more aligned with the previous or most common enterprise identity design.

This is going to be a long blog post with allot of screen shots (you’re welcome) on how to deploy Azure AD Connect. I’ll be going though the wizard process which will follow the automated process to deploy AADConnect, ADFS and ADFS WAP servers- pretty cool indeed.

At the moment AADConnect still isn’t the standard synchronisation service for Office 365 or Azure AD and requires download from the Microsoft Download Centre. To begin with, I’ve downloaded the AADConnect installer from this location.

I’ll keep the feedback between screenshots short and sweet, so to follow along with the installer, begin here…

Lets begin

My environment that I’m deploying AADConnect, ADFS and ADFS WAP in is Azure compute. There is a dedicated instance for AADConnect, there is two ADFS servers (load balanced), two ADFS WAP servers (load balanced) and two domain controllers in an availability group. These have been already provisioned.

Step 1 – Download the client – again available from here.

2015-07-19-AAD-Install-001

Step 2 – Launch the wizard

2015-07-19-AAD-Install-002

Step 3 – Tick “I agree” and Continue

2015-07-19-AAD-Install-003

Step 4 -Select Customize to run a custom install

2015-07-19-AAD-Install-004

Step 5 – Select the required components. In this scenario I will be deploying with an existing service account which I’ll enter.

2015-07-19-AAD-Install-005

Step 6 – I’ve entered the service account for AADConnect. I’ve named it service_aadconnect in the ADDS environment I’m deploying this solution in. Then I hit install to deploy the AAD pre-requisite components on the AADConnect server.

2015-07-19-AAD-Install-006

Step 7 – Installation components run through complete. Once completed, continue on.

2015-07-19-AAD-Install-007

Step 8 – Select the user sign-in option. I want to use Federation with ADFS in this scenario.

2015-07-19-AAD-Install-008

Step 9 – Enter the Azure AD account that will be used in AADConnect to sync objects. This account needs to have global admin rights in the tenant and Office 365.

2015-07-19-AAD-Install-009

Step 10 – Select the on-premises Active Directory forest and add the directory to AADConnect. Enter in a service account or admin account with enterprise admin credentials here.

2015-07-19-AAD-Install-010

Step 11 – Once AADC has the on-premises ADDS added, continue to next.

2015-07-19-AAD-Install-011

Step 12 – Select the means of which ADDS users will be synced to AAD. There are numerous options here through selecting a single set of credentials and unique attributes is best practice. I’ve elected to use the objectGUID and UPN as my two unique identifiers. Later in the sync service additional attributes will be selected as well, thought these two are the primary means.

2015-07-19-AAD-Install-012

Step 13 – Originally I had elected to sync only users that were members of a security group to AAD. Screenshot below highlights this. However, even with members added to the group, it didn’t quite like that and I changed it back to synchronise all users but made sure it was only my desired organisational units in ADDS.

2015-07-19-AAD-Install-013

Step 14 – In this example I added the group it, ensured it was found and continued via next.

2015-07-19-AAD-Install-014

Step 15 – Here I got an error in that Get-ADUser was not able to be run. This was because I did not have Azure AD Powershell installed on the AADC server. To resolve this I downloaded AAD Powershell module and installed on the AADC server. AADC Powershell is available via a direct download from the following link. In addition, the Online Services sign-in assistant is a requirement as well. This can be downloaded from the following link.

2015-07-19-AAD-Install-018

Step 16 – Once filtering is completed, there are a number of options to select in terms of what features we would like to have in AADC. These include write back from AAD to on-premises ADDS. A great use case would be Intune deployed and allowing for registered cloud managed devices to be synced back to on-premises ADDS. To enable this- select Device write back. There are some pre-requisites though. Follow this link and review the Device write back (preview) section.

2015-07-19-AAD-Install-020

Step 17 – Select where write back functionality is to be allowed to write back to on-premises ADDS. This will be the on-premises ADDS forest.

2015-07-19-AAD-Install-019

Step 18 – We previously selected ADFS federated users in step 8 as our method of user sign in. To configure ADFS, select the external SSL certificate used to secure the site. I have chosen to use a wildcard SSL as I can re-use in Exchange Online later.

2015-07-19-AAD-Install-022

Step 19 – Once the SSL is validated, enter in the site name for ADFS. Microsoft generally use the subdomain of sts or “secure token signing” abbreviation. However, anything from adfs, fs, or whatever subdomain or service you would like is fine here.

2015-07-19-AAD-Install-023

Step 20 – Add in the two ADFS servers that are going to authenticate users. These are domain joined servers that are configured in a load balanced pair. In my example these are hosted in Azure compute in a cloud service and availability set with an Azure internal load balancer configured in front.

2015-07-19-AAD-Install-024

Step 21 – Once both servers are added in and verified, continue to next.

2015-07-19-AAD-Install-025

Step 22 – Next add in the two ADFS WAP servers. Again these are hosted in Azure compute in my example. These are two non-domain joined servers in a cloud service and availability set in a controlled or DMZ subnet. I’ve installed the Windows Role > Remote > Web application proxy already on my two servers though with no config, as shown in the below screenshot. However, AADC wizard will override this and compete the config for me.

2015-07-19-AAD-Install-026

Step 23 – The following step requires a service account to establish the proxy trust. This needs to be an enterprise admin from the on-premises ADDS environment.

2015-07-19-AAD-Install-027

Step 24 – Either a group managed service account (gMSA) or a domain user service account can be used. This account will run the service on the ADFS servers. Use in GMSA is easier to mange from a password management perspective. However gMSA requires Windows Server 2012 R2 domain controllers.

2015-07-19-AAD-Install-028

Step 25 – In this scenario I’ve simply used a service account and made sure its a local admin on each of the ADFS servers. I’ve also through local security policies allowed the account to logon locally, logon as a service and logon as a batch job.

2015-07-19-AAD-Install-029

Step 26 – Complete the ADFS service credential input and run the configuration process. This pre-checks all the components prior to running and config as well for any final errors or issues.

2015-07-19-AAD-Install-030

Step 27 – Once the configuration has finalised: AADS, ADFS and the ADFS WAP servers are configured and ready… not quite.

2015-07-19-AAD-Install-032

Post install configuration

Once the wizard is finalised, there was a few other components I needed to run to get the servers up and running. These steps included:

  • Configuring the sts.domain.com site in the ADFS WAP. The AADC wizard only provisioned the service and completed the trust with ADFS. The wizard didn’t actually add the site, though that was a 2min job.
  • In ADFS I had to setup the customised branding as the AADC wizard only provisioned the basic site.
  • In my scenario I changed the filter type from sync’ing users based on security group to rather sync all user and group objects and then filter by OU. By default the wizard configures the AADConnect sync service to sync every object in ADDS via the root OU.

Pro-tip when deploying ADFS

ADFS heavily relies on ADDS. Thats a blinding flash of the obvious. What I mean by that is that on-premises ADDS management and maintenance needs to be up to date and infrastructure well maintained. ADDS sites and services sites that are incorrectly configured, orphaned or dead domain controllers that were global catalogues that haven’t been cleaned up, all contribute to ADFS inability to authenticate users. Should there by any of the above poor management and maintenance of ADDS you’ll likely experience the following error:

ADFS error

I’ll be putting together a detailed blog post on how to resolve that should you run into it.

Summary

The AADConnect wizard does a nice streamlined job of configuring the federated identity components that normally requires quite a bit of manual process. It’s a good step forward and with the new options around write back functionality opens up to different configuration prospects.

Enjoy and leave any feedback in the comments below on your experiences deploying AADC.

Thank you,

by-lucian-handwritten-v1

 

 


Originally posted by Lucian Franghiu on his blog over at clouduccino.com, #clouduccino.

 

Category:
Azure Infrastructure, Identity and Access Management
Tags:
, , ,

Join the conversation! 33 Comments

  1. Great article!

    Perhaps a silly question, but if I had an infrastructure that was in Azure and I wanted to synchronise a VM that was my DC with the Azure AD – can this tool run from within my cloud infrastructure? Or does it only work externally?

    Reply
    • Hi Peter,

      Theres no silly questions here. Just sharing knowledge.

      AADC can be provisioned in say Azure, not a problem.
      What you’ll need is domain controllers (yes with an ‘S’) and connectivity to your on-premises infrastructure.
      Site to site VPN can be leveraged initially, though long term it’s best to connect with guaranteed SLA: hence Express Route.

      Thanks,
      Lucian

      Reply
  2. Hello. You said in step 13 that it did not like members within a security group. What error did you get? I did the same thing, but it is not syncing at all, so I’m wondering if this is the issue.

    Thank you.

    Ken

    Reply
    • Hi Ken,

      I would disable that and not use it at all.
      You can limit what users sync by OU in ADDS.
      For me, when I disabled that rule, all was syncing.
      I haven’t had a chance to look into it in more detail at this time, but hopefully this advice gets you out of a bind.

      Thank you,
      Lucian

      Reply
  3. Thanks for the reply. I read elsewhere that you can only do via groups if you have the ADDC installed on a DC. I had it on a member server. They said that in the next update, it will work on a member server.

    Reply
  4. Lucian,

    Thanks for the post. I have a quick question. We are about to start deploying the Office 365 and trying to find the best way (I should say “the ideal for us” since the best doesn’t exist :-)) to deploy the single sign-on solution.

    My question is if I deploy ADConnect in “Password synchronization” mode with no ADFS and no ADFS proxy can I still have the single sign-on?

    To put it simple if the users come in the morning, turn on their workstations connect to our network authenticate to AD then if they open the Outlook to connect to Exchange in Office 365 do they still have to enter ID/Password or that is passed on from the Windows/Network Authentication? Same for Skype for Business/SharePoint/etc in Office365

    Multumesc 🙂
    Cristian

    Reply
    • Hey Cristian,

      In a short answer: ADFS is required (or equivalent- say something like OKTA) for SSO.

      Password sync is a great option for smaller deployments or when you dont really need or care about SSO.
      To get true SSO, authentication needs something like ADFS whereby your internal users authenticate against your internal ADDS through Windows Integrated / pass through auth.
      When you use password sync, the auth process authenticates against an external ADDS (Azure AD) and because of that you don’t get SSO.

      Some Office clients like Outlook 2010, SfB or Lync can save passwords- kind of half way SSO there.
      However, any web services like SharePoint Online would need authentication.

      You’re most welcome,
      Lucian

      Reply
  5. Thanks for the answer. It burst my bubble 🙂 but oh well…it looks like ADFS it is.

    Cheers
    Cristian

    Reply
  6. Hi Lucian,

    Many thanks for all your posts.

    Would it be possible to be integrate AAD Connect with Azure Application Proxy instead of a ADFS WAP Proxy as we do not want to build and maintain a DMZ environment with servers in the cloud?
    Many thanks in advance for your answer.

    Regards
    RD

    Reply
    • Hey Ronald,

      I would say if you’re hosting AADConnect, DC’s and ADFS servers in Azure, using the Azure App Proxy in theory could work.
      You would need AAD Premium licensing which is an additional cost.
      I’d look at it as to whether the cost of upgrading to AAD Premium is less than running say two standard A1 servers which would suffice for your ADFS proxies.
      On the other hand, if you are not running ADFS (and don’t want SSO) just simply password sync to Azure, then a couple DC’s and a AADConnect server would in theory be fine with Azure App Proxy.

      If you go ahead and implement it successfully, it would be great to hear the results.
      So shoot back some feedback on here or email me direct.

      Cheers,
      Lucian

      Reply
  7. Hi

    Any chance you can point me in the right direction for teh steps used to create the sts site in WAP as part of your post configuration steps?

    Thank You

    Reply
  8. Hi Lucian,

    Great article!!! I will like to check whether is the step “Configuring the sts.domain.com site in the ADFS WAP. The AADC wizard only provisioned the service and completed the trust with ADFS.” required only if we need to support application which uses”pass-through, ADFS authentication or client certificate authentication” as per mentioned on http://blogs.msdn.com/b/spses/archive/2015/03/19/configuring-microsoft-web-application-proxy-server-for-inbound-hybrid-topology-with-office-365-and-microsoft-sharepoint-server-2013-part7.aspx?

    Many Thanks
    Nick

    Reply
  9. Hi Lucian,
    Azure ad connect have adfs component inbuilt. Still we required adfs server and adfs wap for single sign on?

    Reply
    • Morning Raj,

      AADConnect has the ability to partially configure/provision the AD FS 3.0 config for you.
      However, you still do need AD FS servers and AD FS WAP’s as well.

      Cheers,
      Lucian

      Reply
  10. hi lucian
    are you able to provide bit more info on how to,
    – Configuring the sts.domain.com site in the ADFS WAP. The AADC wizard only provisioned the service and completed the trust with ADFS. The wizard didn’t actually add the site, though that was a 2min job.
    – In ADFS I had to setup the customised branding as the AADC wizard only provisioned the basic site.
    thanks,

    Reply
    • Hi Shaun, head to the bottom of this TechNet page and it will have the process on how to configure the WAP: https://technet.microsoft.com/en-au/library/dn383662.aspx.

      Ensure you have TCP 80,443 and 49443 open between your DMZ WAP servers and your AD FS 3.0 servers.
      Ensure your public AD FS cert is deployed on your WAP servers.
      Run through the setup process outlined in the article.
      Should work straight away.

      Cheers mate,
      Lucian

      Reply
  11. Hi,
    I’ve ran through your guid, but am getting an error when using AD Connect to configure AD Connect – I hit an error “No such host”, the wap is in a DMZ. Both 80 & 443 are open in both directions, is there something else that’s needed?

    Thanks

    Reply
  12. thanks Lucian for the link, when you said about the custom branding, you were referring to modifying adfs3 landing page using powershell isn’t it?

    wanted to clarify something, when deploying aad connect it will give you the option to either password sync OR federate, so when linking up our domain to office 365 if we pick federate option will it automatically sync users and create them in the cloud as well (so user can be assigned with a license)? my understanding is federate will point auth back to customer and passsync will sync AD users / passwords to the cloud. will selecting federate achieve both?
    cheers, shaun

    Reply
  13. Hi Shaun,

    You have two options: sync password hashes to Azure AD and then Azure will do the authentication for your client; or chose federate and you have to configure AD FS farm.
    Depending on the size of the client, it’s usually best to go with AD FS as you have a single username/password credential for on-prem and the cloud.
    This makes it very easy for users!
    Oh and you can only have one or the other, not both options.

    Branding is done via powershell, thats correct.
    Some details here: https://technet.microsoft.com/en-au/library/dn280950.aspx
    (I was on this page today re a AD FS 2.0 to 3.0 transition i’m currently doing)

    Cheers!

    Reply
  14. thanks lucian, with federation if users only exist in onprem AD, how can we assign office 365 licensees? because this is usually done via office 365 admin portal and users has to exist in there.
    shaun.

    Reply
    • Hey Shaun,

      A federated user still needs AADConnect to sync user and groups to the cloud.
      In that instance, as soon as AADC is configured, i would guesstimate roughly 80-90% of all of those attributes are read only in the cloud.
      So AADC syncs all of that user and group data from on-premises.
      (for Exchange Online you’ll also need Exchange Hybrid deployed to manage email attributes)

      You would be able to assign licenses through the Office 365 portal, but, there are some FIM + powershell goodies that can be done to automate that process.
      I’m not sure if anyone’s posted that on our blog before, but, if its something you’d want to look into, contact our account managers to discuss a possible consulting engagement where Kloud could assist.

      Cheers,
      Lucian

      Reply
  15. Lucian,

    Thanks for your help previously.

    I have a quick question for you since you mentioned FIM (now MIM). I’m looking at setting up MIM with my Office 365 tenant. I have all the licenses (EMS, etc.) Does the MIM connector replace AADConnect? I haven’t found much documentation yet on doing an “upgrade” from AADC -> MIM environment, but I want to make sure I don’t end up breaking AADC or just synchronization in general.

    Any help you can give is greatly appreciated!

    Thank you.

    Ken

    Reply
  16. Hi Ken,

    AADC would still be there to run the sync process to WAAD.
    So that would not be changed and therefore should easy your worry about breaking it.
    Where FIM/MIM comes into play is that it would sit along side and then take over the sync process management of AADC.
    The sync service on AADC is stopped and disabled, then, FIM/MIM integrates with AADC (seperate server- keep them both seperate!) and FIM/MIM triggers sync requests which then AADC still completes.
    Theres some complexity around FIM/MIM in this scenario.

    Depending on what you’re trying to achive, automated user provisioning or automated license assignment, I would get someone in for the FIM/MIM piece so your existing hybrid identity isn’t compromised at all.

    Hope that helps!?
    -Lucian

    Reply
  17. thanks lucian for the information ..
    i just wanted to confirm that aad connect will create user accounts in office 365 when using the federation mode. (and not have to use old dirsync as well for that task)
    plan is to use powershell to bulk assign license after. and extensionattribute to filter, to limit objects syncing to o365 via aad connect.
    cheers, shaun

    Reply
  18. Shaun, thats exactly right. AADConnect is the new version of DirSync. So it will sync your on-premises objects to Office 365. You dont need DirSync + AADC, just AADC.
    Cheers

    Reply
  19. Hi Lucian,
    Thank you for this great article.
    Do you know if AADConnect can be used to established relationship between Exchange Online and an AD Domain for migration to Exchange On Premise?
    Thank you

    Reply
    • Hi Jean Luc,
      AADC can only be used to sync on-premises directory with Azure AD.
      Migrating from cloud back to on-prem requires a more manual approach.
      The solution isnt designed to move away from it as easily as it is to move to.
      Cheers,
      Lucian

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: