On Design and Implement Microsoft 365 Services, We need to know how and why to manage domains in Microsoft 365 and this section covers the below topics.

  • Add and configure additional domains
  • Configure user identities for new domain name
  • Configure workloads for new domain name
  • Design domain name configuration
  • Set primary domain name
  • Verify Custom Domain

Add and configure additional domains

When you sign up for Office 365, it includes a default domain name like domainname.onmicrosoft.com. Adding a Domain in Office 365 will help you to have your domain name in your email address instead of that default domain. You need to prove the domain ownership by adding a TXT record on your DNS to add the domain in Microsoft 365.

To add a default domain:

Login to O365 Admin Portal https://portal.office.com/adminportal/home -> Setup -> Domains -> Add a Domain -> enter your domain name -> Verify the domain by creating a TXT record that shows up -> Setup Online Services that you want to use -> Update the DNS records -> Complete the steps.

Tips: To verify the domain, Office 365 will show an option where if domain registered under GoDaddy, Office 365 will verify the domain on your behalf when you login to your GoDaddy account or you can create TXT record that shows up on the domain addition page.

TXT record verification method prompts for a TXT record or an MX record can be created to show the proof of domain ownership.

If you create a MX record, make sure you are ok to receive emails through Microsoft 365 Exchange Online Protection as your email gateway. If you have an existing email gateway in On-Premise and continues to receive the internet emails through the existing system, then do not verify the domain using MX record. Always prefer TXT record to verify the domain.

Configure user identities for new domain name

Microsoft 365 have different Identity models available that you can choose based on your requirement.

Cloud Identity: User Identity management will be only in Office 365 (Azure AD). No On-Premise servers required to manage users. All the objects management, authentication and authorization done only in Cloud (Microsoft 365 Azure AD).

Synchronized Identity: Identities synchronized from on-premises directory to Office 365 (Azure AD) and object management done at On-Premise AD. Passwords Hash can be synced so that users have the same password in on-premises AD and in the cloud Azure AD. On-Premise and Office 365 will have same identity after the Synchronization but Users has to sign in every time when accessing On-Premise and Office 365 application, no single sign on experience.

Federated Identity: Identities synchronized from on-premises directory to Office 365 (Azure AD) and user management done at On-Premise AD. Identities Synced to Azure AD used to enable the Office 365 services by assigning a license. Users always authenticate in on-premise AD to access a Microsoft 365 cloud applications via Federated Authentication (ADFS and ADFS Proxy combination). Federated Authentication provides for Single Sign On experience.

Tips: We can see the current authentication method at Azure AD Portal -> Azure AD Connect.

If you want to change the Authentication method, change it from Azure AD connect configuration. We can see the current authentication method at Azure AD Portal -> Azure AD Connect

Configure workloads for new domain name

When you verify the custom domain, it will provide an option to configure the record required for enabling the workloads\services like Exchange, Skype for Business, Teams, SharePoint\OneDrive and Mobile Device Management for Office 365. We need to plan the services that we are going to be enable for the organization and when enabling, it will show the DNS records that is required for those services. Once the records created in your DNS (Internet), the services enabled for that domain will be verified and the licensed users can access the service.

Tips: Office 365 can register TXT records on your behalf if you sign in to GoDaddy account or you can manually create the TXT records required for services enabled.

Based on the workload selection, Office 365 will prompt you to create the required records. Other Office 365 workloads like Planner, Forms and PowerApps do not require a DNS record.

In addition to the above, we need to know how to enable the services and do the initial configuration for the below Microsoft 365 workloads

  • Windows 10 Enterprise
  • Office 365 (EXO, SPO, OD4B, Teams)
  • Enterprise Mobility + Security

Design domain name configuration

Designing Domain Name includes, adding a custom domain like superhybridcloud.com, sub domain like support.superhybridcloud.com and multiple domains like learnexchangeserver.com, learnHybridCloud.com to your Office 365 Subscription.

We can add up to 900 domains in Microsoft 365 domain settings. However, you need to verify the proof ownership for each domain.

Tips: If you are using Cloud Identity, sub domain additions automatically verified. However, the DNS records should be created for the services enabled for that domain.

If you have a requirement to add a sub domain, do not setup Microsoft to manage your DNS by creating NS records.

If the parent domain is federated identity, sub domains can be added only from the ADFS servers. You need enable the services once the sub domain added from ADFS server.

PowerShell: New-MsolFederatedDomain -DomainName support.superhybridcloud.com

Set primary domain name

If we add multiple domains in Office 365, we have the option to set one domain as Primary Domain.

To Set the Primary Domain:

Login to O365 Admin Portal https://portal.office.com/adminportal/home -> Setup -> Domains -> Select the domain -> Set as Default.

Tips: If we create user objects in Azure AD, the UPN or the email address stamped with the default domain name – domainname.onmicrosoft.com. This is applicable for Cloud Identity only or when the objects created directly in Office 365.

Deploying Windows 10 Enterprise and Intune Setup has a prerequisite to validate the primary domain.

Verify custom domain

If we add an additional domain, it is referred as the custom domain (you need to prove that you are the owner of that domain to Microsoft) and create the DNS records for each Office 365 workloads. Custom domain is nothing but the email addresses that you want on the email addresses for the mailboxes in Microsoft 365.

To Set the Custom Domain, login to O365 Admin Portal https://portal.office.com/adminportal/home -> Setup -> Domains -> Add the domain -> verify the domain by creating the TXT record provided.

Microsoft Exchange Online allow you to create a max of 300 Transport Rules. If for any reason, you have exceed the 300 Transport Rule limit, you will get the below error message when you create the 301 Transport Rule.

What next?

If you approach Microsoft, even if you are an enterprise organization, they will say no to increase the Transport Rule limit. Microsoft will ask you to consolidate the Transport rules and later they may consider your request.

So, how to consolidate?

  • Delete the Transport Rules, which are not in enabled status.
  • Do a cleanup by removing the unwanted Transport Rules by validating whether the transport rules are really in use by viewing the Rule Hits.

(Get-MailDetailTransportRuleReport -TransportRule “Rule Name” -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date)).count

If the count shows as 0 for the above command, you can consider that rule is not in use and can deleted the Rules.

  • Validate the rules and see if any rules can be combined to reduce the Transport Rule number.

Still the numbers are not reducing then show the consolidation details Microsoft Support and they may consider your request.

Mid to enterprise level organization are using Federated Authentication for Office 365 / Azure. Many organization deploys ADFS in a Farm having High availability and few went ahead and deployed ADFS Farms in 2 datacenters. I know few companies deployed ADFS environment deployed in 2 of their own data centers for high availability and in addition a 3rd instance of ADFS Proxy and ADFS server combination (ADFS service name as sts.superhybridcloud.com) with geo load balancing in Azure Cloud (with a writable DC as well in Azure).

Your ADFS deployed like above is fully business continuity plan complaint, users will be able to access Office 365 applications if both ADFS farm in On-Premise datacenter is down.

ADFS federated sign-in authentication with Password Hash Synchronization to Azure AD is good to have option for large enterprises as additional DR. You may have a query why Password Hash Sync is required when ADFS deployed in 3 datacenters and the name says Password Hash Sync to Azure AD which is a SAAS service.

Why you should not worry about Password Hash Sync?

  • In On-Premise, AD stores passwords in the form of a hash value which represents the actual user password.
  • A hash value is a result of a one-way mathematical function. There is no method to revert the result of a one-way function to the plain text version of a password.
  • Password hash cannot be used to sign in to on-premises network.
  • When Password Hash Synchronization enabled, AD has the password stored in a MD4 hash format and DC encrypts the MD4 hash with MD5 hash + Additional Key and send it to AD connect PHS agents. AD Connect PHS agent gets the password in the format of MD5 hash + additional key and it decrypts the MD5 hash using MD5CryptoServiceProvider and the additional key. AD connect PHS agent decrypts the MD5 hash and the it is having the password in MD4 hash.
  • Though the AD Connect PHS Agent decrypts the MD5 hash and the password now available as MD4 hash and no option for the PHS agent to view the clear text password. MD5 hash encryption that was done in AD is only for replicating the MD4 hash to AD Connect server.
  • PHS agent will do many conversions and it results a secured hash (combination of MD4+salt+PBKDF2+HMAC+SHA256) will be synchronized to Azure AD over SSL.

Note: The original MD4 hash is not transmitted to Azure AD. Instead, the SHA256 hash of the original MD4 hash is synchronized. As a result, if the hash stored in Azure AD is obtained, it cannot be used in an on-premises pass-the-hash attack.

Enabling Password Hash Sync:

Changing the configuration in AD connect to enable Password Hash Sync as an Authentication option. Password Hash Sync Agent Sync the SHA256 value every 2 minutes once. We can ensure the Password Hash Sync status enabled by checking the Azure AD connect option in Azure AD Portal.

In addition, you can use the below command to check the password hash sync status.

Hope you are enabling Password Hash Sync as an additional option that you can use in case of any issue with your ADFS infrastructure.

Before looking at handling the terminated employee login and restricting access to company data from Office 365, we need to understand the details about the authentication and Refresh Token and Access Token.

Authentication: when a user access any service that is integrated with Azure AD like Office 365 (EXO) -> EXO will redirect the user Azure AD, Azure AD do the realm discovery -> If the domain is federated, then user will be redirected to federated service like ADFS -> ADFS authenticated the user with Active Directory and return a token -> User will present the token to Azure AD -> Azure AD validates the claims and authentication is successful -> Azure AD provides a Refresh token and a Access Token to user -> Users send the access token to EXO and he will have access to EXO service.

Access Token: Azure AD when identifies the authentication is successful, it provides access token and refresh token pair to user. User will send the access token to respective service like EXO to get access to the services. By default, it will have a time to live value of 1 hour and it cannot be revoked / expired by admin.

Refresh Token: when the access token about to expire after an hour, behind the scene… Refresh token will be send to Azure AD to get a new access token and a new access token \ refresh token pair will be provided to users. User present the new access token to EXO to retain the access. Refresh token are valid for 90 days and can be revoked by admins.

Note: Once the authentication is successful, user will be re prompted to authenticate after a max of 90 days. Refresh and Access token combination can be re used in the back end to access the Office 365 services without re-authentication for 90 days. Password Expiry \ Account Lock out will be identified during the access token refresh\renew interval and user will be prompted to authenticate.

Okay, let’s jump into find options to control terminated employee Sign-In access to Office 365 services

  • Disabling and Resetting User Password – Disabling the account in On-Premise AD / Resetting the password is the first step you will do to stop the user from using Corporate Credential to access the Office 365 Services. These change has to replicate to Azure AD, so that Azure AD restricts the user from sign in using his existing credential or stop him from accessing the company resource because of disabled account. So ensure you keep the Azure AD Connect Sync Cycle to run every 30 minutes once.
  • Revoke the Tokens using PowerShell – Revoke-AzureADUserAllRefreshToken –ObjectID “ID”

This command would revoke all the tokens including the Password based Cookie which we use on OWA.

Optionally / Additionally… we can do the below changes.

  • Disabling Exchange Protocols: Exchange Online will automatically prompt the user to re-authenticate when password changes when accessing Exchange using MAPI, OWA, EWS, POP/IMAP. In addition to that, disable those protocol immediately once the user is terminated.

  • Block the Sign-In in Azure AD: User account can be blocked from Sign in Azure using below command

  • Remote wipe the user mobile device:

Important thing to note: Note: The user will still have access to the Outlook cached mode data on the desktop and if it is on a personal desktop, there is no way to prevent the users from exporting the data to PST.

So, what is the option available for this scenario? Ensure you are allowing access to company data only from company managed (Azure AD Domain Joined) machines. On other side, enable litigation hold to retain the data for ever.

You may want to have a Hybrid Exchange LAB environment to prepare your Microsoft 365 Certification exam. If needed you can follow the instructions below to get your LAB ready in few hours. By the way, it is not free but it won’t cost you much to prepare for your exam.

Below are details of my LAB in Azure that I used to prepare for my Microsoft 365 exam. I’m now an Microsoft 365 Certified Enterprise Administrator Expert certification holder

LAB Requirements:

Azure Trial Subscription: You can easily sign up for Azure Free Trial with 200$ Credits

Office 365 E3 Trial Subscription: You can try Microsoft 365 Trail as well – 30 days free.

Certificate: *.DomainName.com purchased from 3rd Party vendor is required. You can get a wildcard certificate for 40$ Per Year.

Azure Virtual Machines: 4 Virtual Machines (Domain Controller, Exchange 2016, AD Connect Server (Installed on DC), ADFS & ADFS Proxy)

Azure Load Balancer: 2 Load Balancer, One for Exchange (mail.suprehybridcloud.com) & another for STS (sts.superhybridcloud.com)

Azure Storage Account: Create a storage account with LRS type to Keep your Virtual Disk

Azure Virtual Network: Create a Vnet with address space & 2 Subnets (Internal – & (DMZ – Set the DNS Server as

Azure Network Security Group: You can place all the Virtual Machines under this NSG and create the below Inboud Rules to have proper communication between servers.

Step by Step details:

Step 1: Sign Up for Office 365 E3 Trial – To have a clean domain naming options.. choose the required Azure Default domain name for example, superhybridcloud.onmicrosoft.com as default domain if you external email domain is superhybridcloud.com. During the Trial sing up, choose the defaul global admin as admin@superhybridcloud.onmicrosoft.com

Step 2: Login to Portal.azure.com admin@superhybridcloud.onmicrosoft.com and sign up for a Trial Azure Subscription. It will ask for a credit card to verify the proof of Identity.

Step 3: Create a Azure Virtual Network, Address space as with 2 subnets as Internal – & DMZ –

Step 3: Create Network Security Group and apply it the Subnets

Step 4: Create Azure Storage, with LRS as replication type to minimize the cost

Step 5: Create the Domain Controller VM – Domain Control and Promate the machine as DC with the domain name as SHC.com and login to DC. Add the domain superhybridcloud.com as adding UPN suffix in AD Domain and Trust.

Step 6: Create the Exchange Server VM – Join the machine to DC, Install Exchange 2016 and configure the certificate and change the external url as mail.superhybridcloud.com. On DC -> DNS, Create a new zone for superhybridcloud.com and create the A record for mail.superhybridcloud.com and Autodiscover.superhyridcloud.com that points to exhange server IP.

Step 7: Create an Azure LB Instance -> Configure Exchange Server as the back end node, set up monitoring probe for Port 443, Load balancing Rule that points to Exchange Virtual IP

Step 8: Create NSG Rule – Create Inbound allow rule in NSG for mail.superhybridcloud.com

Step 9: Create the external DNS record for mail.superhybridcloud.com that points to Azure LB Public IP and the OWA mail access.

Step 10: Add and verify superhybridcloud.com as additional\custom domain in Office 365

Step 11: AD Connect Setup – Download and Install AD connect in Domain Controller. Do not setup ADFS related configuration. Choose Exchange Hybrid feature only.

Step 12: Create ADFS VM – Install ADFS role and configure it. Adfs service name as sts.superhybridcloud.com

Step 13: Create ADFS Proxy VM – Create the VM in DMZ subnet. Install ADFS Proxy role and configure it. Create a host entry to sts.superhybridcloud.com that points to ADFS server IP.

Step 14: Create an Azure LB Instance -> Configure sts load balancing. Create ADFS Proxy as as the back end node, set up monitoring probe for Port 443, Load balancing Rule that points to ADFS Proxy Virtual IP.

Step 15: Configure ADFS Sign in – Install MSOnline Module in ADFS Follow the steps as shown below.

Leave your command for any additional information about the Exchange LAB setup in Azure. All the best for your exam preparation.

New components\features introduced in Office 365\Exchange Online Protection like Advance Threat Protection and Anti-Phisinging capabilities etc.. Introuduction of these features changes the mail flow architecture. We will discuss the updated Office 365 Mail Flow Architecute here.

Below the updated mail flow architecture reference diagram.

Mail Flow Explanation:

Inbound Mail Flow:

When the MX record pointed to Exchange Online Protection, emails sent to that domain will be routed to EOP. Edge Blocking component will do the Connection filtering -> Anti-Virus & Anti-Malware scanning will be done by Malware Protection -> Transport Rules will be applied to the emails -> Advanced Threat Protection Safe Attachment feature will scan the attachments -> Email will be checked for Anti-Phishing -> Anti-Spam will do the SPAM checking -> Spoof Detection will be done -> Zero hour Auto Purge protection will happen -> ATP safe link Url wrapping will happen and then the mail will be delivered to Office 365 mailbox.

Outbound Mail Flow:

If an Office 365 User sends an Email to Internet, the mail will be scanned for malicious contents and the normal emails will be delivered to Outbound Pool and the delivered to Internet recipient. If any bulk email detection and suspicious email will be routed the High Risk Delivery Pool or Bulk Mail Pool and there is no guarantee that email will be delivered to respective recipient.

Detailed Explanation:

Below architecture shows the complete details of the Exchange Online Protection mail flow architecture

All the components are self-explanatory, leave your commands for any additional information.

Microsoft 365 Certifications

Microsoft announced the New Role Based / Workloads Certification exams in Q4 – 2018. New Microsoft 365 certifications have 2 titles

  • Microsoft 365 Certified: Enterprise Administrator Associate
  • Microsoft 365 Certified: Enterprise Administrator Expert

Enterprise Administrator Associate certification available for below 4 Microsoft 365 workloads and we need to write 2 exams for each workloads. If you complete the 2 exams associated with the respective workloads, you will get the Microsoft 365 Certified: Enterprise Administrator Associate

  • Message Administrator Associate
  • Team Work Administrator Associate
  • Security Administrator Associate
  • Modern Desktop Administrator Associate

Enterprise Administrator Expert certification has 2 exams. We can take any of the above workloads exams + the 2 Enterprise Administrator Expert certification exam to get the Microsoft 365 Certified: Enterprise Administrator Expert Title.

Below table shows the exam details of Microsoft 365 Certified: Enterprise Administrator Associate certification

New Roles Exam
Microsoft 365 Certified: Messaging Administrator Associate
Microsoft 365 Messaging Administrators MS-200: Planning and Configuring a Messaging Platform
MS-201: Implementing a Hybrid and Secure Messaging Platform
Transition Path – MS-202: Microsoft 365 Messaging Administrator Certification Transition (70-345 Completed)
Microsoft 365 Certified: Teamwork Administrator Associate
Microsoft 365 Teamwork Administrators MS-300: Deploying Microsoft 365 Teamwork
MS-301: Deploying SharePoint Server Hybrid
Transition Path – MS-302: Microsoft 365 Teamwork Administrator Certification Transition (70-339 Completed)
Microsoft 365 Certified: Security Administrator Associate
Microsoft 365 Security Administrators MS-500: Microsoft 365 Security Administration
Microsoft 365 Certified: Modern Desktop Administrator Associate
Microsoft 365 Modern Desktop Administrators MD-100: Windows 10
MD-101: Managing Modern Desktops
Transition Path – Completed Exam 70-698 : Installing and Configuring Windows 10 can write MD-101 only

Below table shows the exam details of Microsoft 365 Certified: Enterprise Administrator Expert Title.

Microsoft 365 Certified: Enterprise Administrator Expert

Enterprise Administrator Expert

MS-100: Microsoft 365 Identity and Services
MS-101: Microsoft 365 Mobility and Security

Transition Path – If you have MCSE: Productivity, then completing MS-100 & MS-101 will give you Microsoft 365 Certified Enterprise Administrator Expert certification.

If not, You need to complete any one of the Microsoft Workload Exam + MS-100 & MS-101 to earn the Microsoft 365 Certified Enterprise Administrator Expert certification.

All the best and Good luck with your exams – Super Hybrid Cloud Team.

We will see how the authentication works when accessing Exchange Online Mailbox in Outlook Web Access. Before looking at the OWA authentication flow, we need to understand the Identity Models available in Office 365.

  • Cloud Identities – User accounts provisioned directly in Azure Active Directory using Office 365 Portal or Azure AD PowerShell.
  • Synchronized Identities with password hash – User accounts and the hash of their on-premises Active Directory password is synchronized to azure active directory.
  • Federated Identities – Federation established using ADFS and User accounts synchronized to the Azure Active Directory from On-Premise Active directory.

Federated Identity model is the preferred Identity model for most of the Organization. Federated Identities model uses Active Directory Federation Service technology to establish a federation trust between the Office 365 tenant and the on-premises Active Directory. With the Federated Identity model, when a user tries to access an Office 365 workload, he will get an SAML security token from ADFS, which is handed to Azure AD as proof for being allowed to access the respective workload.

Below diagram explains the authentication flow for Internal OWA client accessing Exchange Online Mailbox.

  1. OWA web client from Internal network tries to access Exchange Online using Outook.office365.com URL, Exchange online redirect the web client to authentication with Azure AD login.microsoftonline.com
  2. OWA client will be redirected to login.microsoftonline.com and login screen appears to enter the credential, once the user enters the user name (user@superhybridcloud.com), Azure AD will check whether the domain is federated or not. In our case it is federated domain, Azure AD will redirect the web client to authenticate with federated identity, which is sts.superhybridcloud.com.
  3. Sts.superhybridcloud.com will resolve to ADFS server available in On-Premise. Windows Integrated Authentication will be configured on ADFS and the authentication will automatically happen in the backend using logged in credential.
  4. ADFS will validate the credential with AD and retrieve the necessary claims related information from AD.
  5. AD validates the credential and provide the requested claims information to ADFS.
  6. ADFS server present a token holding the claims about the user to web client
  7. OWA client will present the received token to Azure AD and authentication will be successful, the web client will be redirected back to outlook.office365.com
  8. Authentication successful and the OWA client will go to Exchange online with successful authentication status and user can access his mailbox in OWA.

Below diagram explains the authentication flow for the Internet OWA client accessing his Exchange Online Mailbox.

If the OWA web client is from internet, all the steps explained above will be applicable. Only difference is, the redirection to STS is through ADFS Proxy or Web Application Proxy servers and also, the web client will be asked to authenticate via Form based authentication page.

Hope you are able to understand the authentication flow for Exchange Online when using Outlook web access. We will see how the outlook authentication works when accessing Exchange Online Mailbox. For any additional clarification, please post your comments.

Before we look at how the Outlook authentication works? we need to understand what is Basic Authentication client and Modern Authentication Clients.

Basic Authentication Clients: Clients or applications that is not a browser-based client that access Office 365 services are Basic authentication clients. Outlook 2013 by default is a basic authentication client and few other clients like EWS clients and EAS clients are Basic authentication clients.

Modern Authentication Clients (OAuth): Modern Authentication uses Active Directory Authentication Library (ADAL) based sign-in for Office clients. ADAL based sign-in supports features like MFA, certificate based authentication and smart card authentication. Outlook 2016 by default is a modern authentication office client, where Outlook 2013 requires an Office update and registry settings modified to act like a Modern Authentication client.

Unlike other authentication method, OAuth provides 2 tokens (Access and Refresh tokens) to the client when it successfully authenticates against Azure Active Directory. Access token is a JSON Web Token (JWT), which is valid for 1 hour and a Refresh token valid for 14 days, if it is continuously accessed it will be valid for 90 days.

Now, we will see how the authentication works on both Basic Authentication client and Modern Authentication client.

  • Basic Authentication

Below diagram explains the authentication for basic authentication client, let us take an Outlook 2013 client or an EWS / Exchange Active Sync client tries to access an Office 365 Mailbox.

  1. Outlook client do an Autodiscover lookup and it know it has to connect outlook.office365.com to access Office 365 Mailbox and initiated the connection to Exchange Online by sending the basic authentication credential over SSL.
  2. Exchange Online sends the details to Azure AD using Proxy Authentication
  3. Azure AD sends the respective endpoint configured for this type of request which is sts.superhybridcloud.com to Exchange Online
  4. Exchange Online will go sts.superhybridcloud.com, which is ADFS Proxy or WAP server in DMZ.
  5. ADFS Proxy or the WAP server proxies the Exchange Online request to ADFS Servers
  6. Active Directory authenticates the request from ADFS
  7. Active Directory sends a logon token along with users information as claims
  8. ADFS server will send the token with claim information to Exchange online
  9. Exchange Online sends the details with Azure AD
  10. Azure AD returns in to Exchange Online in a state where it can be used to authenticate the client and the client are connected.


  • Modern Authentication

Microsoft working on updating all the clients to work like modern authentication, which will use OAuth Authentication. OAuth uses access and refresh tokens to allow access to Office 365 workloads using Azure Active Directory. We will see how it works when we use outlook 2016 to access Exchange Online Mailbox.

  1. Outlook do an Autodiscover lookup and find the Exchange Online Url as outlook.office365.com. Outlook will try to connect outlook.office365.com
  2. Exchange Online redirects the Outlook client to Authentication endpoint in Azure AD (login.microsoftonline.com). Outlook client will use ADAL browser control to reach Azure AD.
  3. Azure AD authentication endpoint will detect the UPN domain is federated and redirect to internal ADFS endpoint.
  4. ADFS require the outlook client to authenticate.
  5. Once the authentication completed, AD will send the user claim information to ADFS.
  6. ADFS server get the user related information as a claim and sent SAML token with claims about the user to Outlook client
  7. Outlook client present that token to Azure AD and after successful authentication, the client will be provided with the access and refresh token.
  8. Outlook client sent the access token to Exchange Online on behalf of user and he will connected to Exchange Online.

Device Management in Azure AD is required to ensure the devices connecting to the cloud services are meeting the Company Security and Compliance Standards. If you have On-Premise Active Directory, computers related to that company are joined to that AD and administrators will have control to those AD joined devices like pushing group policies etc.

Joining a Computer to Azure Active Directory is similar to joining a computer to local active directory. Difference is Azure AD is in Cloud and when joining a machine to Azure AD, it provides additional capabilities like Single Sign On experience when accessing the applications and we can restrict access to those devices based on the Azure AD Join status using Azure Conditional Access.

Device Join to Azure Active Directory are three types:

  • Hybrid Azure AD Join: Device joined to On-Premise Active Directory and Azure Active Directory.
  • Azure AD Join: Device joined directly with Azure AD (not On-Premise AD Domain joined)
  • Azure AD Registered (Workplace Join): Device registered with Azure Active Directly like Windows 10 Personal and Mobile Devices.

During the Azure conditional access validation, all the above devices joined to azure are considered as domain joined devices and the respective settings will be applied.

Hybrid Azure AD Join in Windows 10

Windows 10 Device Registration process explained as

  1. Group Policy pushed to the machine starts the device registration with Azure AD
  2. Windows Device will query AD to get the information about the Azure AD Tenant
  3. Windows Device authenticates itself to Azure AD via ADFS to get a token for device registration
  4. Windows Device generates key pairs used for device registration
  5. Windows Device registers with Azure AD via Azure Device Registration Service.

Below the detailed explanation on how the Hybrid Azure AD Join works

We need to configure few things for Hybrid Azure AD Join to work properly like AD Connect deployment, Group Policy pushing and ADFS Issuance Transformation Rule etc… those prerequisites configuration steps not explained here. We will assume those are already set and will see the flow on how the Azure AD Join working in Windows 10 Machine.

  1. Group policy pushed to Windows 10 clients, which creates a task for the device registration to work and the task will be triggered.
  2. Windows 10 client queries AD (Service Connection Point object) which has the details about the Azure AD tenant to which the client has to connect. Azure AD Connect deployment will create those objects. I have highlighted the path for reference on the diagram.
  3. Azure AD Tenant information like the Azure AD name and the ID will be sent to Windows 10 Client.
  4. A hidden Internet browser is launched and the OAuth code authentication request is sent to Azure AD
  5. Azure AD redirects the client to authenticate with ADFS
  6. Client will reach ADFS by sending the computer account as identity, using Windows Integrated Authentication. Note: If the device is in Internet, then the authentication will fail because the WAP server will have form based authentication and you won’t know the prompt in hidden browser to authenticate.
  7. ADFS validates the computer identity with AD
  8. After the successful authentication, AD send the claim details to ADFS
  9. ADFS send a token along with 3 claims to Windows client, which the device will sent it to Azure AD for successful authentication
  10. Client sends the token along with 3 claims about the device received from ADFS to Azure AD
  11. Azure AD trust the token from ADFS server as it is already integrated and send a final token to Client for Azure Device Registration
  12. Device creates a Private/Public key pair to be used in a certificate-signing request from Azure DRS, to obtain the certificate that the device will use to authenticate to Azure AD later on. In addition, the task generates a second private/public key pair that is later used to bind the Primary Refresh Token (PRT) to the physical device upon authentication.
  13. Task send the Certification Signing Request along with final token received from Azure AD to Azure Device Registration Service.
  14. Azure DRS authorize the token, create a certificate, creates a Device object with its certificate thumbprint and return the certificate to the client.
  15. Client stores the certificate in the User My Store.

If you see above, the device registration is successful. For the Single Sign-On experience in Windows 10, the Primary Refresh Token will be received from Azure AD.

User sign-in to client using his credential, the Cloud Authentication Provider plug-in in windows client authenticates with Azure AD and ADFS, to obtain the Primary Refresh Token. Cloud Authentication Provider knows the Azure AD and ADFS details from the cache available during the Device Registration. Cloud AP plugin will directly send the credential to ADFS and get the SAML token and present it to Azure AD for authentication, Azure AD authenticates it and build a PRT with both User and Device claims and it will return to Window device.

I hope this is informative and you like it. Please comment for any clarification.