Consultant specializing in Microsoft Cloud Technologies and Cloud PBX

Menu

Monthly Archives: July 2017

[Update 5/25/2018] Per this forum post [here] it looks like blocking legacy authentication is now possible with Conditional Access!.

Azure AD Premium’s Conditional Access feature requires Modern Authentication to function properly. This has led some to believe that legacy clients (ex: Outlook 2010 and older, or Activesync) can bypass Conditional Access Policies.

Based on my testing, this is only half true, as it depends upon the policy that you select. If you select a ‘Grant’ policy then the legacy clients will not be able to bypass your conditional access policy. However, if you select a Block policy, then the legacy clients will bypass it and connect to the service that you want to block.

So the most conservative thing to do is to use a Grant Policy, not a Block policy.

What does the conditional policy mean by “Domain Join” – is it on-premises or is it Azure AD Domain Join, both, or something else? (Answer: on-prem domain join with an account that has been synced by Azure AD Connect to the cloud… with a software deployment required for Windows 7, and a GPO required for Windows 10).

Is it necessary to deploy the Workplace Join v2.1 client to Windows 7 Machines? (Answer: Yes)

Does Azure AD Connect require configuration, and if so, what is the minimum version of Azure AD Connect required? (Yes, you must create a service connection point in Active Directory per this article).

What role does Azure AD Seamless Single Sign-On Play (also referred to as “Desktop SSO” in the Azure AD Connect documentation) Answer: (It provides a similar SSO experience to ADFS, but only when connected to the corporate network. And it is REQUIRED for Windows 7 machines that wish to have Workplace Join work without an ADFS server).

Is ADFS required? (Answer: No)

Is there any configuration necessary in Azure AD? (Answer: Not unless you changed the default settings)

Is it necessary to deploy a Group Policy change? If so, what are those changes? (Answer: For Windows 10, Yes, see below. For Windows 7, you’ll need to push out some Intranet Site to Zone mappings for the Azure Seamless SSO to work)

Is it necessary to create any DNS records? (Answer: Yes, see below)

Domain Join vs Azure AD Domain Join vs Azure AD Registration

If you configure a Conditional Access Policy and select the “require domain joined device” checkbox, what is it checking?

To find out, I created 6 virtual machines to see exactly what works and what does not work.

Computer Name

Operating System

Configuration

Test Results

Notes

Win10DomainJoin

Windows 10.0.15063 (Creators)

On-Prem Domain Joined

Azure AD Connect “Desktop SSO” is enabled

“enterpriseregistration” DNS CNAME exists

Success

Win10DJandReg

Windows 10.0.15063 (Creators)

On-Prem Domain Joined

Azure AD Connect “Desktop SSO” is enabled

“enterpriseregistration” DNS CNAME exists

GPO Applied “Register domain-joined computers as devices”

Success

Win10DJandAADJ

Windows 10.0.15063 (Creators)

On-Prem Domain Joined

Azure AD Connect “Desktop SSO” is enabled

“enterpriseregistration” DNS CNAME exists

Azure AD Domain Joined (aka ‘Workplace Joined’)

GPO *NOT* Applied “Register domain-joined computers as devices”

Success

Win10AADJoined

Windows 10.0.15063 (Creators)

Azure AD Joined Only

Azure AD Connect “Desktop SSO” is enabled

“enterpriseregistration” DNS CNAME exists

GPO *NOT* Applied “Register domain-joined computers as devices”

Fail – Got a block page (see block page example below)

Wasn’t entirely expecting this to work since the screen tip that is in-band of the configuration says that this checkbox does *not* apply to Azure AD joined machines.

Win7DomainJoin

Windows 7 SP1

Azure AD Joined Only

Azure AD Connect “Desktop SSO” is enabled

“enterpriseregistration” DNS CNAME exists

Fail – Got a block page (see block page example below)

Wasn’t expecting this to work – just testing to create a baseline before the Workplace Join client was installed. With no ADFS in the environment – just Azure AD Connect with Desktop SSO and Password Hash Sync.

Win7DJwithWPJ

Windows 7 SP1

Azure AD Joined Only

Azure AD Connect “Desktop SSO” is enabled

“enterpriseregistration” DNS CNAME exists

Workplace Join v2.1 client installed

SUCCESS

I was starting to lose hope after all these failed tests, but we now have a successful test!

The common denominator for the successful test was the DeviceTrustLevel changed to “Managed”

Block Page Example

This is the end-user example of what it looks like when you try to open an application protected by a Conditional Access Policy that requires Domain Join.

DNS Records

According to the documentation, is necessary to register the following DNS CNAME record in both internal and external DNS (if using split-zone / split-brain DNS):

DNS Entry

Type

DNS Value (Address)

enterpriseregistration.contoso.com

CNAME

enterpriseregistration.windows.net

Workplace Join v2.1

For Windows 7 and Windows 8.1 devices, the documentation states that it is necessary to deploy the Workplace Join client (MSI Package) from here. This is not required for Windows 10 systems, which can register to Azure AD via group policy, although in my lab that does not appear to be working, as that does not produce any records when I run get-msoldevice. Perhaps it requires ADFS for Windows 10 machines to work with Domain Join conditional access.

Workplace join Version 2.1 (Released June 2017) added support for Azure Active Directory Seamless Single Sign On (https://aka.ms/hybrid/sso).

Ready for some kludge? The installer creates a scheduled task on the system that runs in the user’s context. The task is triggered when the user signs in to Windows. The task silently registers the device with Azure AD with the user credentials after authenticating using Integrated Windows Authentication. To see the scheduled task, in the device, go to Microsoft > Workplace Join, and then go to the Task Scheduler library.

The two main benefits of this tool in my opinion is that it registers a Windows 7 machine in Azure AD, and, the version 2.1 client makes it so that you don’t have to use ADFS (simplifying the configuration).

Azure AD Seamless Single Sign-On

Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) is required for Windows 7 machines if you are not using ADFS. Instead, users will sign in and register to Azure Device Registration Services.

When enabled, users don’t need to type in their passwords to sign in to Azure AD, and usually, even type in their usernames. This feature provides your users easy access to your cloud-based applications without needing any additional on-premises components.

If you have ADFS, you do not need this feature as ADFS already provides “seamless SSO” (assuming you also deployed the ADFS STS web page to your Local Intranet zone in Internet Explorer).

*Note: The ‘Edge’ web browser is not yet supported. Currently IE, Chrome and Firefox are supported. Firefox requires custom configuration to make it work.

To deploy seamless SSO, you turn it on in Azure AD Connect, then you deploy it through Group Policy.

Azure AD Connect

You must be using version 1.1.484.0 or later of Azure AD Connect. Note: In the screen shot below, Pass-through auth is selected but ‘Password Synchronization’ could have been chosen as well.

If you already have an installation of Azure AD Connect, choose “Change user sign-in page” on Azure AD Connect and click “Next”. Then check the “Enable single sign on” option

Completing that step will create a new computer object in Active Directory “AZUREADSSOACC” – if this object is accidentally deleted, users can still logon, but it will just be the standard logon just like prior to seamless SSO being enabled (so it ‘fails open’ so to speak). For more information see the technical deep dive here.

Group Policy

You can add the Azure AD device authentication end-point to the local Intranet zones to avoid certificate prompts when authenticating the device. This works for both IE and Chrome which both share the same setting. For other browsers see the references section.

To roll this out in a group policy object, here are the steps:

Open the Group Policy Management tool on a domain controller, ex: start > run > gpmc.msc

Note: One of the references only listed the first URL, whereas another reference listed the bottom two. Since the documentation was not consistent, I’m including all three to be safe.

Note: Rollout the above GPO at your own risk… It will add these and lock out/remove any other intranet site zones your users may have manually configured. My personal preference is to deploy these as group policy preferences instead.

Azure AD Configuration

By default, Azure AD enables users to register devices. So unless someone in your organization changed this setting, you should not have to change this. This is found in http://portal.azure.com then find Azure Active Directory > Users and groups > Device settings. The policy “Users may register their devices with Azure AD” must be set to “All” (which is the default setting).

Windows 10

All domain-joined devices running Windows 10 Anniversary Update and Windows Server 2016 automatically register with Azure AD at device restart or user sign-in. However, Windows 10 November 2015 Update automatically registers with Azure AD only if the rollout Group Policy object is set. So the best thing to do is configure a Group Policy object to control the rollout of automatic registration of Windows 10 and Windows Server 2016 domain-joined computers.

Testing

The output of this cmdlet shows devices registered in Azure AD. To get all devices, use the -All parameter, and then filter them using the deviceTrustType property. Domain joined devices have a value of Domain Joined. In my testing, the only combination that seemed to work with conditional access is when the DeviceTrustType was Domain Joined, and the DeviceTrustLevel was Managed.

To test the scenario where the user enters only the username, but not the password:

Tips

When configuring your first conditional access policy, apply it to a test user, and apply it for only one cloud app. This prevents you from accidentally locking yourself or others out. See best practices reference below for more good ideas.

Troubleshooting

Check to make sure the computer account is syncing to the cloud by running get-msoldevice. If it does not show up there, then make sure the OU or container containing the computer objects is being synced. If it shows up there, it must have DeviceTrustType = ‘Domain Joined’ and DeviceTrustLevel = ‘Managed’

For Windows 10 only, Check to see if the computer object contains a value in the userCertificate attribute. If not, this means that the computer is unable to read the value of the SCP object in Active Directory. Check to make sure that the Authenticated Users group is not missing from the “Device Registration Configuration” object. To see if it can query the SCP, run this command:$config = [ADSI] “LDAP://CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=YourDomain,DC=com”;$config

On Windows 10, Run the dsregcmd /status and make sure ‘AzureAdJoined’ is Yes and ‘IsUserAzureAD’ is Yes
Under User State, verify that WamDefaultSet is Yes, WamDefaultAuthority is organizations, WamDefaultId is https://login.microsoft.com, AzureAdPrt is Yes, and WamDefaultGUID contains a value.

For Windows 7 only, run autoWorkplaceJoin.exe /i to find out the current status of the device, this will also provide helpful error messages as well.

Enable Debug and Analytic logs in Event Viewer. Click the View menu. Select Show Analytic and Debug Logs to make these logs visible. Enable logs under Applications and Services Logs > Microsoft > Windows > User Device Registration, and then export the logs for Admin and Analytic folders about five minutes after you have rebooted (or signed-out/in)

When pushing out the Workplace Join Client, users may get a pop-up “To continue, this application needs to create a key.”
To suppress this, you can push out a group policy object to not require user input for storing certificates.