Wednesday, 11 August 2021

Troubleshooting Hybrid Azure AD Join issue

I've been working with a customer this week to configure Hybrid Azure AD Join and co-management. In the first phase (HAADJ), most of my test devices successfully registered in Azure AD. However there were some stragglers. These devices didn't even show up as "Pending" in Azure AD. They just didn't appear at all.

It was time for troubleshooting. What is the best way to find out what is wrong? There are many things you can check.

Service Connection Point

As some of the domain joined devices had successfully registered in Azure AD already, it seemed unlikely that there was a problem with the Service Connection Point. However I had a look at it.

Beginning with version 1.1.819.0, Azure AD Connect provides you with a wizard to configure hybrid Azure AD join. Azure AD Connect deploys a Service Connection Point (SCP) into your Active Directory environment. A service connection point in AD is essentially an object that points to a specific service. The Azure AD Service Connection Point includes information on the following items in its keywords attribute:

  • azureADId; The Azure Active Directory tenant ID
  • azureADName; The Azure Active Directory tenant’s verified custom DNS domain name, or the *.onmicrosoft.com DNS domain name if no verified custom DNS domain name exists for the Azure AD tenant

 The Service Connection Point format is as follows:

CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration, CN=Services, CN=Configuration,DC=domain,DC=tld

 Follow this procedure to verify the Service Connection Point in Active Directory.

  • Launch ADSI Edit as an Enterprise Administrator.
  • Connect to the Configuration Naming Context of the domain.
  • Browse to CN=Configuration,DC=contoso,DC=com > CN=Services > CN=Device Registration Configuration
  • Verify that the leaf object CN=62a0ff2e-97b9-4513-943f-0d221bd30080 exists (this is the same CN value for every organization)
  • Select Properties
  • Select keywords from the Attribute Editor window and click Edit
  • Verify the value of azureADId
  • Verify the value of azureADName

This was all good for me.

OU Sync

The next step is to check that the device is in an OU which is synchronized to Azure AD. This is a configuration in Azure AD Connect. 


Navigate to the Domain and OU filtering screen and verify that the OU is selected for sync. I didn't find any problem here.

DSREGCMD

The next step was to have a look at one of the devices. You can get a lot of information using the DSREGCMD /STATUS cmdlet


In the Device State section I could see AzureADJoined = No. However the Diagnostics Data section gave me valuable information.

Failed to schedule Diagnostics Task. Error: 0x80041326

DSREGCMD /DEBUG /JOIN is also useful.


Cannot start Task: 0x80041326

Failed to schedule Join Task. Error: 0x80041326

This told me exactly where to find the problem. The issue was with the Workplace Join scheduled task.

Task Scheduler


Sure enough, I launched Task Scheduler and navigated to Microsoft > Windows > Workplace Join. I could see that all the tasks were disabled. In my experience some external configuration was preventing Azure AD registration on the device.

SCCM


ConfigMgr client settings was a good place to start. However automatic Azure AD registration was allowed (Cloud Services).

Group Policy

The next place to look was group policy, it's always a GPO, right?


A Resultant Set of Policy query showed me exactly where the problem was.

Computer Configuration > Administrative Templates > Windows Components > Device Registration > Register domain joined computers as devices was disabled.


What did this setting do? The description showed that this setting allowed devices to be silently registered in Azure AD. Disabling it obviously had the reverse effect and prevented the registration.

Solution

The solution was to remove this GPO setting from the affected devices.

I hope this helps. Until next time.....


Thursday, 17 June 2021

Migrating to a Microsoft Defender solution

This is becoming very popular and many of my customers have recently made the switch. It seems like a no-brainer, especially if you have purchased Microsoft 365 E5 licenses. 

This information should help you to plan and implement a migration from another endpoint protection solution.

Is Microsoft Defender Antivirus free?

It is, kind of. Microsoft Defender Antivirus is a core component of Windows 10. It's built into the operating system and is included in the cost of Windows. This is often good enough for a home user but certainly not for an enterprise organization. Defender AV needs to be managed and you must license the management tools. Microsoft Endpoint Manager (SCCM or Intune) are the favourites here.

What is Defender for Endpoint?

I've found that this is the most confusing part for customers. Defender for Endpoint (DfE), formerly Defender Advanced Thread Protection (ATP) is not Defender Antivirus. It's an enterprise endpoint security platform designed to help enterprise networks prevent, detect, investigate, and respond to advanced threats. Data from Defender antivirus can be consumed and used by DfE by onboarding devices independently to the service. You can currently access DfE (until 6th July 2021) using the Microsoft Defender Security Center 

https://securitycenter.windows.com/ (see next question).

What is Microsoft 365 Defender?

This is an integrated solution including the following:

  • Microsoft Defender for Endpoint
  • Microsoft Defender for Office 365
  • Microsoft Defender for Identity
  • Microsoft Cloud App Security

You can access the M365 Defender portal at https://security.microsoft.com/

The Microsoft Defender Security Center standalone portal will no longer be available from 6th July 2021. 

What license do I need for Defender for Endpoint for my workstations/laptops?

Microsoft Defender for Endpoint requires one of the following Microsoft volume licensing offers:

  • Windows 10 Enterprise E5
  • Windows 10 Education A5
  • Microsoft 365 E5 (M365 E5) which includes Windows 10 Enterprise E5
  • Microsoft 365 A5 (M365 A5)
  • Microsoft 365 E5 Security
  • Microsoft 365 A5 Security
  • Microsoft Defender for Endpoint (this is a standalone offering where you don't have any of the above subscriptions)
These are user based. Eligible licensed users may use Microsoft Defender for Endpoint on up to five concurrent devices. 

I have Microsoft 365 E5 licenses for all my users. Does this cover servers?

No, in this case you will need Microsoft Defender for Endpoint for Server (one per covered server). This is also covered with "Azure Security Center with Azure Defender enabled".

Can I just purchase Microsoft Defender for Endpoint for Server only?

No. Customers may acquire server licenses (one per covered server Operating System Environment (OSE)) for Microsoft Defender for Endpoint for Servers if they have a combined minimum of 50 licenses for one or more of the following user licenses:

  • Microsoft Defender for Endpoint
  • Windows E5/A5
  • Microsoft 365 E5/A5
  • Microsoft 365 E5/A5 Security
What else should I consider when migrating to a Microsoft Defender solution?

It's possible that this migration is not as simple as just switching to a new antivirus solution. There are a number of considerations.
  • Will you also be using Defender for Endpoint? This is recommended.
  • How will you manage Defender antivirus settings? It is recommended to use SCCM or Intune antimalware policies.
  • Note that Intune does not manage servers so you need to consider that.
  • Is your current solution providing more than antivirus functionality, which you must replace before decommissioning? Windows Firewall configuration is common, for example.
Can Microsoft Defender Antivirus and non-Microsoft antivirus/antimalware solutions co-exist?

Microsoft Defender Antivirus is automatically enabled and installed on endpoints and devices that are running Windows 10. But what happens when another (non-Microsoft) antivirus/antimalware solution is used? It depends on whether you're using Microsoft Defender for Endpoint together with your antivirus protection. 
  • In active mode, Microsoft Defender Antivirus is used as the antivirus app on the machine. Management products will apply. Files are scanned and threats remediated, and detection information are reported in your configuration tool.
  • In passive mode, Microsoft Defender Antivirus is not used as the antivirus app, and threats are not remediated by Microsoft Defender Antivirus. Files are scanned and reports are provided for threat detections that are shared with the Microsoft Defender for Endpoint service. 
  • When EDR in block mode is turned on (in Microsoft Defender for Endpoint) and Microsoft Defender Antivirus is not the primary antivirus solution, it will detect and remediate malicious items. EDR in block mode requires Microsoft Defender Antivirus to be enabled in either active mode or passive mode.
  • When disabled, Microsoft Defender Antivirus is not used as the antivirus app. Files are not scanned and threats are not remediated. Disabling/uninstalling Microsoft Defender Antivirus is not recommended in general; if possible, keep Microsoft Defender Antivirus in passive mode if you are using a non-Microsoft antimalware/antivirus solution.
  • If you are enrolled in Microsoft Defender for Endpoint and you are using a third-party antimalware product, then passive mode is enabled. The service requires common information sharing from Microsoft Defender Antivirus service in order to properly monitor your devices and network for intrusion attempts and attacks. 
  • When Microsoft Defender Antivirus is in passive mode, you can still manage updates for Microsoft Defender Antivirus; however, you can't move Microsoft Defender Antivirus into active mode if your devices have an up-to-date, non-Microsoft antivirus product that is providing real-time protection from malware. 
  • When Microsoft Defender Antivirus is disabled automatically, it can be re-enabled automatically if the protection offered by a non-Microsoft antivirus product expires or otherwise stops providing real-time protection from viruses, malware, or other threats. 
The following table summarizes what happens with Microsoft Defender Antivirus when non-Microsoft antivirus/antimalware solutions are used together, with or without Microsoft Defender for Endpoint.


Notes:

1. On Windows Server, version 1803 or newer, or Windows Server 2019, Microsoft Defender Antivirus does not enter passive mode automatically when you install a non-Microsoft antivirus product. you can set Microsoft Defender Antivirus to passive mode by setting the following registry key

Path: HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection
Name: ForceDefenderPassiveMode
Type: REG_DWORD
Value: 1

2. Passive mode is not supported on Windows Server 2016. If you are using a non-Microsoft antivirus product, you cannot run Microsoft Defender Antivirus in either passive mode or active mode. In such cases, disable/uninstall Microsoft Defender Antivirus manually.

How can Defender antivirus be configured and managed?

Microsoft Endpoint Manager (SCCM or Intune) is my tool of choice for managing these settings. Let's have a look at SCCM first.
  • The Endpoint Protection Point is a site system role that must be added.
  • Afterwards, we can see Endpoint Protection status under Monitoring > Security.
  • Create antimalware policies and deploy to device collections. This includes items like scheduled scans, scan settings, real-time protection and antivirus exclusions.
  • Use Automatic Deployment Rules (ADR) to download and install updated Defender antivirus definition files, now called "security intelligence updates".
You can also use Intune to manage the Defender antivirus settings on workstations.
  • You can find the antivirus policies under Manage in the Endpoint security node of the Microsoft Endpoint Manager admin center.
  • Antivirus policies include the same settings as endpoint protection or device restriction profiles for device configuration policy and are similar to settings from device compliance policy. However, those policy types include additional categories of settings that are unrelated to Antivirus. The additional settings can complicate the task of configuring antivirus.
  • Policies contain the same type of settings that we can configure using SCCM.
  • Policies are assigned to device groups.
How do I onboard devices to Defender for Endpoint?

Onboarding a client to Microsoft Defender for Endpoint will enable Endpoint Detection and Response, Threat and Vulnerability Management and many other SecOps related functionalities. Once onboarded, the endpoint will appear in the Microsoft 365 Defender portal and advanced security events and insights will become available.

There is a straightforward Microsoft Defender for Endpoint onboarding experience, for any client supported by Microsoft Endpoint Manager, whether it is SCCM, Intune, or co-managed.

For SCCM, we will need an onboarding XML file. This is generated in the M365 Defender portal.
  • Navigate to Settings > Endpoints > Device management > Onboarding.
  • Choose your operating system and deployment method and generate a download package.
  • In SCCM, navigate to Asset and Compliance > Endpoint Protection > Microsoft Defender ATP Policies and create a new policy. 
  • Choose an Onboarding policy and navigate to the configuration file.
  • Deploy to a collection of devices.
The configuration is more integrated for Intune. The first step you take is to set up the service-to-service connection between Intune and Microsoft Defender for Endpoint. 
  • Set up requires administrative access to both the Microsoft Defender Security Center, and to Intune.
  • In the MEM portal, select Endpoint security > Microsoft Defender for Endpoint, and then select Open the Microsoft Defender Security Center.
  • In Microsoft Defender Security Center, select Settings > Advanced features.
  • For Microsoft Intune connection, choose On
  • Return to Microsoft Defender for Endpoint in the Microsoft Endpoint Manager admin center
  • Under MDM Compliance Policy Settings, set Connect Windows devices to Microsoft Defender for Endpoint to On
  • When this configurations are On, applicable devices that you currently manage with Intune, and devices you enroll in the future, are connected to Microsoft Defender for Endpoint for compliance.
  • Finally create an Endpoint Detection and response profile. In the MEM portal, select Endpoint security > Endpoint detection and response.
  • Create a policy as shown.
  • Assign to a group.
What is Microsoft Defender Security Center app?

This is the UI on the client and can be accessed by clicking on the Defender shield icon on the system tray. 


The layout can be customized by using an Endpoint Protection configuration profile in Intune. See where I've blocked the Family Options section.


This is the Microsoft Defender Security Center app without Family Options.

Where does OneDrive fit into all this?

It's a good idea to configure OneDrive in advance for your users by using a GPO. 


If you don't you will end up with this warning when Defender is enabled and active. OneDrive is required for file recovery in case of a ransomware attack. The user can continue to set up OneDrive or Dismiss the warning but that's not the best approach.

What advanced features should be configured?

Microsoft Defender has a wide range of options available for configuration using MEM (SCCM or Intune). You should consider configuring all of the following:
Can I customize the Defender Security Center app for my organization?

Yes, you can. You can add details of your organization and support to the Defender Security Center app to assist your end users. Using an Intune Endpoint Protection configuration profile, navigate to the Microsoft Defender Security Center section. 


You can enter the organization name and support telephone number, email address and website URL. I've just entered the organization name and website URL here.


This is what it looks like in the Defender Security Center app. You can see a new button on the bottom right.


Click on the button and you'll see the details you have configured.


This configures the registry as shown:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Enterprise Customization

What are the high-level steps for a migration?

Microsoft provides good guidance to switch from non-Microsoft endpoint protection to Microsoft Defender for Endpoint.


The high-level steps are as follows (this example uses McAfee): 
  • Prepare phase
    • Get and deploy updates across your organization's devices
    • Get Defender for Endpoint.
    • Grant access to the Microsoft Defender Security Center.
    • Configure device proxy and internet connectivity settings.
  • Setup phase 
    • Reinstall or enable Microsoft Defender Antivirus on your endpoints.
    • Configure Defender for Endpoint.
    • Add Microsoft Defender for Endpoint to the exclusion list for McAfee.
    • Add McAfee to the exclusion list for Microsoft Defender Antivirus.
    • Set up your device groups, device collections, and organizational units.
    • Configure antimalware policies and real-time protection.
  • Phase 3 
    • Onboard devices to Microsoft Defender for Endpoint.
    • Run a detection test.
    • Confirm that Microsoft Defender Antivirus is in passive mode.
    • Get updates for Microsoft Defender Antivirus.
    • Uninstall McAfee.
    • Make sure Defender for Endpoint is working correctly.
How do I test Defender functionality?

In the Defender Security Center app we can see at a glance that our policies have been applied.


Also, Microsoft provide assistance to allow us to test demo scenarios. They provide sample files which are harmless and for demonstration purpose only.



You can test cloud-delivered protection.


Network protection


Controlled Folder access


URL reputation




I hope this helps. Until next time.......








Sunday, 2 May 2021

Locating a Windows 10 device with Microsoft Endpoint Manager

This is my favourite new feature in the 2104 service release of Microsoft Endpoint Manager (formerly Microsoft Intune). We have been able to do this with iOS devices for quite some time. I remember Peter Daalmans and I demonstrating the feature at MMS in 2019. Now we can locate Windows 10 devices in the console.

There are two prerequisites before you can use this feature with Windows 10 devices.

Location Services

First you must turn on Location Services on your devices.

You can create a custom configuration policy to do this using the following OMA-URI 

./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessLocation


Configure an integer with value of 1 to forcibly turn on location services.


You could also create a configuration profile using the Settings catalog. In the Privacy category, choose Let Apps Access Location.


Location services are turned on. This is what it looks like on a test client.

Minimum operating system version.

This feature is only supported on the following Windows 10 versions:
  • Windows 10 version 20H2 (10.0.19042.789) or later
  • Windows 10 version 2004 (10.0.19041.789) or later
  • Windows 10 version 1909 (10.0.18363.1350) or later
  • Windows 10 version 1809 (10.0.17763.1728) or later
How to locate a Windows 10 device

In the MEM console, select Devices > Windows devices. Click on the device you want to locate. Click on the three dots on the Overview page.


This is my test client. Locate device seems to be greyed out. What could be wrong?


Ah, I see why. It's an unsupported Windows 10 version. This device is 10.0.18363.418 but must be a minimum of 10.0.18363.1350.


I updated the device.


Now the Locate device feature is available. Click Locate device.


You are presented with a warning about local laws and regulations around location data. Essentially there are privacy concerns. You're told that Intune will only retain the location data for 24 hours. 


A Bing map opens with the status
Locate device pending.


Within a minute my test device was located and it's location was displayed. This is the Road view.


Click on the drop down arrow in the top right corner to choose the Aerial view. There is also a Bird's eye view but that wasn't available to me.


You can use the + and - buttons to zoom in and out.


This is a great view of the device location. I can see that the street names appear in the Irish language as well as English. I'm not sure where that setting comes from. Also, the location of the device is in the right area but it isn't 100% accurate. You can read more about location services here


Back in the console you will see the status change to Locate device: Completed.

On the device the user is notified that the location of the device has been accessed by the organization. That is crucial for transparency.

I hope this blog post has been useful. Until next time.......




Wednesday, 24 March 2021

Implementing hybrid AAD join over a VPN - the userCertificate attribute saga

Do you know what the userCertificate attribute is? If you don't then keep on reading.

This was fun. Once I learned more about how hybrid Azure AD join worked, I understood the behavior and was able to figure out how to make this work.

First, a little bit about the basics of HAADJ. What is a HAADJ device? This is a device that is joined to AD and registered with Azure AD. You can't be joined to both directories at the same time. Also you can't sign into a HAADJ device with Azure AD credentials. 

We know that we need an Azure AD Connect server. 

Version 1.1.819.0 and later of Azure AD Connect includes an option to configure Hybrid AAD Join. But what does that mean? When you choose this option the wizard creates a Service Connection Point in AD. The SCP contains all the information that a workstation needs to perform the HAADJ process.  

This isn't just a notional thing. You can actually see the SCP in AD using ADSIEDIT and connecting to the domain in the Configuration context. This is the SCP. The GUID (62a0ff2e-97b9-4513-943f-0d221bd30080) is what Windows 10 devices search for using an LDAP query, and is the same from organization to organization.

Have a look at the keywords and you will see the details of the specific organization's Azure AD domain and directory ID.

The next thing we do is to synchronize the workstations with AAD. Again we do this using Azure AD Connect. 

Check the box for the OU you need. The AAD Connect synchronization service runs on a schedule and creates computer objects in AAD for your workstations.


That's only the behind-the-scenes prep work though. On the workstation a scheduled task runs (Microsoft>Windows>WorkPlace Join). This task actually implements the Workplace join element. The device must have already synced to AAD for this to be successful.

That's it, that's all you need to do to implement HAADJ for an organization and to be fair, it just works. However there are some complications when most of the devices are remote and connect to the VPN infrequently. Then the process doesn't work and you need to understand the process and behavior a little more in order to make it work.

The first thing to understand is that the scheduled task really only runs when the user logs on to the workstation. That's the first trigger associated with the task.

There is a second trigger for this task. It runs whenever it detects Event ID 4096 in the event logs. In my experience though, this doesn't make any difference, and the task doesn't run again after the logon.


"Automatic device join pre-check tasks completed. The device can NOT be joined because a domain controller could not be located. The device must be connected to a network with connectivity to an Active Directory domain controller".

In the event log we get this continual error. We can see that workplace join fails as the device does not have line of sight to a domain controller. Unfortunately we are not connected to the VPN at that stage. The user may then connect to the VPN but at that stage it's too late, the scheduled task doesn't run again. You can see why this works seamlessly on the LAN, as the workstation is authenticating with a domain controller on log on and not using cached credentials.

OK, what if I run a script to run that scheduled task after the user connects to the VPN? I should be able to figure that out, right.

schtasks /Run /TN “Microsoft\Windows\Workplace Join\Automatic-Device-Join”

This is the command you need to run to kick that off.

However I found that it is not that simple. There are several steps involved to workplace join a device and you have to wait for the various schedules to see that in action. I'll explain the steps and introduce a new concept - the userCertificate attribute.


Azure AD Connect is configured to only synchronize devices that have the userCertificate attribute configured. AAD Connect does its job well and just filters out any devices that don't have this attribute set. You don't get an error or a warning to say that they are missing, which is a real nuisance.

So where does the attribute come from? These are two computers from the same organization, computer A has it and computer B doesn't. Computer A has synchronized with AAD but computer B has not. So how does that happen?

The science bit

Whenever the workplace join scheduled task runs it checks for a direct connection to a domain controller. When it finds one it looks for the Service Connection Point in AD using an LDAP query. The SCP has information on which AAD tenant the device should join. At that point the computer generates a self-signed certificate and the userCertificate attribute is added to the computer properties in AD. All is well at that stage and the computer will workplace join. Well, not really, quite a bit has to happen yet. If we run the workplace join scheduled task again at that point it will fail.

Automatic registration failed at join phase. Exit code: Unknown HResult Error code: 0x801c03f2. Server error: The device object by the given id (876df222-8565-4118-8193-f1d051d12e19) is not found.

It will tell us that the directory object cannot be found. Of course that makes sense. The device did not synchronize with AAD because of the missing userCertificate attribute. Now that we have forced that to happen, we must wait for the AAD Connect sync service to run again and this time the device sync successfully to AAD.

Now we must wait for the workplace join scheduled task to run again and this time, all the elements are in place and the workplace join is successful. This all works seamlessly for computers on the LAN but it does not work very well for VPN connected computers.


I created a task sequence that executes the workplace join scheduled task and I deployed it to VPN connected devices.

The script will execute the scheduled task every 10 mins. Then I encourage users to connect to the VPN and the magic happens.

  • Script executes #1 (needs to have line of sight to DC) - scheduled task runs and finds SCP in AD with LDAP query. The computer generates a self-signed certificate and the userCertificate Attribute is updated in computer properties.
  • AAD Connect sync service runs on a schedule - sync computer object to AAD
  • Script executes #2 (needs to have line of sight to DC) - scheduled task runs and finds SCP in AD with LDAP query. Device is workplace joined.
  • User that signs into the device will get an Azure AD user token that can be used to authenticate with Azure AD-based services

Don't forget to remove the deployment afterwards.

You can search AD to get a list of computers that are missing the userCertificate attribute.

Get-ADComputer -LDAPFilter '(!(userCertificate=*))' | Select Name,DNSHostName | export-csv -path C:\GH\Emptyattrib.csv

This will get you started but will include servers. You can filter them out.


You can also do a custom search on a specific OU using the LDAP query: 

(!(userCertificate=*))

I hope this helps you to understand what is going on with HAADJ. Until next time……..