Windows 10 – Hybrid Azure Active Directory Join for Federated Domains

What is ADFS?

Active Directory Federation Services (ADFS) provides a secure mechanism to authenticate users, accessing applications (often in the cloud), using Active Directory credentials when Windows Integrated Authentication (WIA) is not possible.

Not so long ago ADFS was considered the go-to option when needing to authenticate Domain users accessing Office 365 services. With the introduction of Azure Authentication technologies ADFS struggles to sell itself with newer adoptions of Office 365. That being said, there are still specific use case for deploying ADFS and it certainly isn’t going anywhere soon – Microsoft added some new feature to the ADFS Role in Server 2019:-

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/whats-new-active-directory-federation-services-windows-server

Some organisations may be starting their Office 365 journey with an established ADFS infrastructure. That’s cool. Microsoft recognizes that some of us use ADFS and fully support this option when there is a requirement to register Domain Joined devices in Azure.

Why Enable Hybrid Azure Active Directory Join?

One of the most understated features of Azure Active Directory is Conditional Access. I only want my users accessing their data if they meet a certain criteria. e.g. They are on a trusted corporate device, using Multi Factor Authentication (MFA) on a personal device and/or using an approved client app. More info on Conditional Access here:-

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview

It would be a tall order to expect my users to use MFA every time they access an Office 365 service from their work computer so I might want to relax some of my Conditional Access policies if the connection is coming from a Domain Joined device. There is an expectation that we already have a good deal of control and security on Domain Joined devices..right?

What does Hybrid Join actually do?

For Conditional Access to evaluate that the connection to Office 365 is coming from a Domain Joined device, we have to register these devices in Azure Active Directory – effectively allowing a trust to be formed in Azure Active Directory with the Domain Joined device. Once the Domain Joined device is “Registered” in Azure Active Directory, we can leverage Conditional Access policies.

Hybrid Azure AD Joined Devices

Azure Active Directory Connect

Starting with Azure AD (Active Directory) Connect 1.1.819.0 Microsoft made it really easy to instigate Azure Device Registration for those of us using ADFS. The wizard automatically updates the Service Connection Point (SCP) in our on-premises Active Directory and also creates the required ADFS Claims Rules.

Pre-Requisites for configuring Hybrid Join for a Federated Domain using Azure AD Connect:-

  • Windows Server 2012 R2 with AD FS
  • Azure AD Connect version 1.1.819.0 or higher.
  • Domain and Forest Functional Level 2008R2 or higher (On lower versions, the user may not get a Primary Refresh Token during Windows logon due to LSA issues)
  • Windows 10 devices 1607 or higher

Detailed pre-requisite information can be found at:-

https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-plan

If you love a challenge, or are unable to use Azure AD Connect to configure the Hybrid, you can manually setup the environment, SCP and issuance of claims. More info can be found at:-

https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-manual

Client Considerations

Once you have completed the AADConnect Wizard, steps shown later, ALL Domain Joined, Windows 10 clients, will automatically hybrid join Azure AD at device startup or user login. You may want to limit which devices get hybrid Joined during your POC or initial roll-out phase.

You can control this behavior by using either a GPO or SCCM Client Setting.

Group Policy

The following GPO allows you to control Device Registration: Register domain-joined computers as devices.

  1. Open Group Policy Management.
  2. Create a new or edit an existing policy for Device Registration
  3. Go to Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsDevice Registration.
  4. Right-click Register domain-joined computers as devices, and then select Edit *
  5. Select one of the following settings, and then select Apply:
    • Disabled: To prevent automatic device registration.
    • Enabled: To enable automatic device registration.
  6. Select OK.
Group Policy setting for Windows 10 Device Registration

*This Group Policy template has been renamed from earlier versions of the Group Policy Management console. If you’re using an earlier version of the console, go to Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration > Register domain joined computer as device.

SCCM Client Setting

  1. Open Configuration Manager, select Administration, and then go to Client Settings.
  2. Open the properties for Default Client Settings and select Cloud Services.
  3. Under Device Settings, select one of the following settings for Automatically register new Windows 10 domain joined devices with Azure Active Directory:
    • No: To prevent automatic device registration.
    • Yes: To enable automatic device registration.
  4. Select OK.
SCCM Client Setting for Windows 10 Device Registration

You may also wish to consider updating your golden image to avoid an unexpected device registration in Azure AD. This can occur if there is a delay in your devices applying the a GPO or SCCM Client Setting.

Client Firewall Configurations

Me: “Do you use a Proxy Server?”
You: “Yes Ben”
Me: “Ok… listen very carefully”

Windows 10 Device Registration occurs either at Computer Startup or User Logon. Both use the SYSTEM context to attempt a device registration in Azure. The SYSTEM has permissions to authenticate against Azure AD because it will have (hopefully) been issued an Access Token by ADFS. Most environments use an explicit Proxy or PAC file to configure USER access to the internet via the Proxy Server. Often, the device is overlooked. If you don’t already allow the Device to connect to the internet in the SYSTEM context, you will need to make some changes.

What URLS do my Devices need to connect to?

  • https://enterpriseregistration.windows.net
  • https://login.microsoftonline.com
  • https://device.login.microsoftonline.com
  • Your organization’s STS (federated domain/s)

Source: https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-federated-domains

Microsoft provide a Web Service for Office 365 URLs and IPs. Go and see what CIDR and IP’s you need to allow for your device to access the above URLS:-

https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-service

*IMPORTANT* The CIDR that isn’t listed in the Web Service XML, and most definitely is required is:-

CIDR 40.64.0.0/13 (enterpriseregistration.windows.net)

Running the Azure AD Connect Configuration Wizard

You will require:-

  • Azure AD Global Administrator credentials
  • Enterprise Administrator credentials for your forest/s
  • ADFS Administrator credentials

1 . Open Azure AD Connect and click Configure

Click “Configure”

2 . Select Configure Device Options and click Next

Select “Configure Device Options”

3 . Read the Overview and click Next

Read the Overview

4 . Enter the Credentials of an Azure AD Global Administrator and click Next

Enter Azure AD Global Administrator Credentials

5 . On the Device Options page, ensure Configure Hybrid Azure AD Join is selected and click Next

Choose “Configure Hybrid Azure AD Join”

6 . Select the Forest/s to configure, choose the ADFS Server, Add Enterprise Admin credentials for the Forest/s and click Next

Configure the Service Connection Point

7 . Choose which devices you want to support for Hybrid Azure AD Join and click Next (we are only looking at Windows 10 devices in this post)

Choose “Windows 10 o later domain-joined devices”

8 . Enter the Credentials of an ADFS Administrator and click Next

9 . Review the changes that are about to be made and click Configure

Review the changes before completing the configuration wizard

10 . Configuration Complete, click Exit

Configuration Complete

Review changes made by the Azure AD Connect Wizard

The Azure AD Connect wizard will have made two changes:-

  1. Your Active Directory Configuration will have a new Services Connection Point configured
  2. ADFS will have new Claims Trusts configured

Verify the Service Connection Point (SCP)

The SCP will tell devices which Azure AD tenant to go and attempt to register on. Connect to your Configuration Naming Context using ADSI EDIT, you will see some new configuration objects

New Configuration Objects

Clicking on the properties of the object CN=62a0ff2e-97b9-4513-943f-0d221bd30080 and navigate to the keywords attribute. The two attributes will be unique to your configuration:-

  • azureaADid Your Azure AD Tenant ID
  • azureADName Your Azure AD Tenant Domain Name
Verify the SCP has been created

Verify the Claims Trusts

Your Domain Joined Windows 10 Devices rely on ADFS to authenticate to Azure AD in a Federated Domain. Devices will authenticate to get an access token to register against the Azure Active Directory Device Registration Service (Azure DRS).

When you’re using AD FS, either adfs/services/trust/13/windowstransport or adfs/services/trust/2005/windowstransport must be enabled. If you’re using the Web Authentication Proxy, also ensure that this endpoint is published through the proxy. You can see what endpoints are enabled through the AD FS management console under Service > Endpoints.

Source: Microsoft

The following claims must exist in the token passed to Azure AD during Device Registration:-

  1. http://schemas.microsoft.com/ws/2012/01/accounttype
  2. http://schemas.microsoft.com/identity/claims/onpremobjectguid
  3. http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid
  4. http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid (If you have more than one verified domain)
  5. http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID (If you already issue an ImmutableID claim e.g. Alternate Login ID)

1 . http://schemas.microsoft.com/ws/2012/01/accounttype

@RuleName = “Issue account type for domain-joined computers”
c:[
Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”,
Value =~ “-515$”,
Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”
]
=> issue(
Type = “http://schemas.microsoft.com/ws/2012/01/accounttype”,
Value = “DJ”
);

2 . http://schemas.microsoft.com/identity/claims/onpremobjectguid

@RuleName = “Issue object GUID for domain-joined computers”
c1:[
Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”,
Value =~ “-515$”,
Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”
]
&&
c2:[
Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”,
Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”
]
=> issue(
store = “Active Directory”,
types = (“http://schemas.microsoft.com/identity/claims/onpremobjectguid”),
query = “;objectguid;{0}”,
param = c2.Value
);

3 . http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid

@RuleName = “Issue objectSID for domain-joined computers”
c1:[
Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”,
Value =~ “-515$”,
Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”
]
&&
c2:[
Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid”,
Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”
]
=> issue(claim = c2);

4 . http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid

@RuleName = “Issue account type with the value User when its not a computer”
NOT EXISTS(
[
Type == “http://schemas.microsoft.com/ws/2012/01/accounttype”,
Value == “DJ”
]
)
=> add(
Type = “http://schemas.microsoft.com/ws/2012/01/accounttype”,
Value = “User”
);
@RuleName = “Capture UPN when AccountType is User and issue the IssuerID”
c1:[
Type == “http://schemas.xmlsoap.org/claims/UPN”
]
&&
c2:[
Type == “http://schemas.microsoft.com/ws/2012/01/accounttype”,
Value == “User”
]
=> issue(
Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid”,
Value = regexreplace(
c1.Value,
“.+@(?.+)”,
“http://${domain}/adfs/services/trust/”
)
);
@RuleName = “Issue issuerID for domain-joined computers”
c:[
Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”,
Value =~ “-515$”,
Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”
]
=> issue(
Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid”,
Value = “http://<
verified-Domain-Name>/adfs/services/trust/”
);

5 . http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID

@RuleName = “Issue ImmutableID for computers”
c1:[
Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”,
Value =~ “-515$”,
Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”
]
&&
c2:[
Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”,
Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”
]
=> issue(
store = “Active Directory”,
types = (“http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID”),
query = “;objectguid;{0}”,
param = c2.Value
);

You can read more about the issuance of claims, and the configuration required/created by the Azure AD Connect wizard at:-

https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-manual#set-up-issuance-of-claims

Did it work?

If we have used due diligence then we should start to see some successful device registrations in Azure AD.

Hybrid Azure AD Joined Devices

There is no “Owner” when a Windows 10 device registers in Azure AD. Windows “Down-Level” devices e.g. Windows 7 will register with an owner. Careful consideration should be made as each down-level device registration will contribute to the users “Device Limit” (Default 20 devices).

You can also use the cmdlet Get-MSOLDevice to view Azure AD Hybrid Joined Devices

Get-MSOLDevice

Conclusion

In this post we looked at how we can register our on-premises, Windows 10 devices, with Azure AD – a process also known as “Hybrid Azure AD Join”. The main points we focused on were:-

  1. Setup the necessary GPO/Client Setting to control Azure Device Registration for Windows 10 Devices
  2. Ensure the correct Firewall Configuration is in place to allow Devices to communicate and register in Azure AD
  3. Check the pre-requisites and roles required to configure Azure AD Hybrid Join
  4. Use the Azure AD Connect wizard to create the ADFS claims and Service Connection Point (SCP)

The next step being considered by many is removing ADFS if its sole role is providing authentication to Office 365 services and replacing it with Azure AD Seamless Single Sign-On – a great feature!

I feel another blog post coming on 😉

4.5/5 - (2 votes)

9 thoughts on “Windows 10 – Hybrid Azure Active Directory Join for Federated Domains”

  1. Thank you very much for this detailed article about hybrid AAD join.
    There is one point that is a bit unclear to me. Why did you choose your ADFS server as the SCP and not Azure AD? What is the difference between those two? Do you know this?
    Regards

  2. Hi Ben, Nice article although I have noticed a deviation from Microsoft guidance – this may have changed from when you posted this as Microsoft state:
    “Both adfs/services/trust/2005/windowstransport and adfs/services/trust/13/windowstransport should be enabled as intranet facing endpoints only and must NOT be exposed as extranet facing endpoints through the Web Application Proxy. ” – https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-federated-domains

    This guide states:
    “When you’re using AD FS, either adfs/services/trust/13/windowstransport or adfs/services/trust/2005/windowstransport must be enabled. If you’re using the Web Authentication Proxy, also ensure that this endpoint is published through the proxy.”

    1. Thanks for the feedback MJ.

      The doc still suggests those endpoints SHOULD NOT be published externally.

      “Both adfs/services/trust/2005/windowstransport and adfs/services/trust/13/windowstransport should be enabled as intranet facing endpoints only and must NOT be exposed as extranet facing endpoints through the Web Application Proxy”

      What other guide are you referring to? Thanks

      https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-federated-domains

      1. Hi Gunter,

        Did you ever find the reason for why to use ADFS vs Azure AD for the SCP? It’s not clear anywhere I read and nobody seems to have the answer. The way that Azure AD Connect is said to just take over and forcibly do things if/when ADFS fails to register the devices makes it seem as though it’s just a voluntary step (when we’re dealing with only Windows 10).

        Would be nice to know the answer.

        FYI Ben, your two notes about making sure to enable the windowstransport endpoints on the proxy, Microsoft states in the linked docs articles to make sure NOT to enable those on the proxy as it’s a security risk. I think they may have used to document it the way you have here and then corrected it since they do all caps on the “NOT” in their statement.

  3. I think MJ’s point is that typical SOP is to publish extranet(internet) facing endpoints through the WAP. MS guidance is not to publish those 2 endpoints to the extranet. Your excellently written guide causes confusion with this statement “If you’re using the Web Authentication Proxy, also ensure that this endpoint is published through the proxy.” That implies to publish those endpoints to the extranet(internet).

    1. Hi Chuck, this post is quite old – I should update it. Using the Client setting or GPO was a requirement to control HAADJ for older Windows 10 versions. Windows 10 1709 and above automatically register to AAD when an SCP is present so in that scenario, for controlled validation, follow the article you highlighted.
      Thanks, Ben

Leave a Reply to Ben Whitmore Cancel Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.