Configure Windows Hello for Business with Cloud Kerberos Trust

In this post we will be going through the process of setting up Cloud Kerberos Trust to allow Entra Joined devices to access on prem resources (FileShare, Web apps..).

Prerequisites

Before starting, ensure you have the following:

  • Microsoft Entra ID Tenant
  • Active Directory
  • Domain Admin and Global Admin rights
  • Intune license and admins rights to configure Windows Hello for Business settings.
  • Windows 10 or Windows 11 devices

I used this learn article to setup the cloud Kerberos trust.

https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust?tabs=intune

Currently when I try to access resource using a Entra only joined device I get prompted for my username and password by on-prem resources. This is due to NTLM being blocked and not being issue Kerberos tickets due to being a Entra Only joined device.

We can run klist to see if any Kerberos tickets have issues.

First we need to setup the AD object that will be used by Entra to generate Kerberos TGTs.

Open a PowerShell prompt using the Run as administrator option. Install the Azure AD Kerberos PowerShell module by running:

# First, ensure TLS 1.2 for PowerShell gallery access.
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

# Install the AzureADHybridAuthenticationManagement PowerShell module.
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Run the following PowerShell commands to enable cloud trust Kerberos.

# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter an Azure Active Directory Hybrid Identity Administrator username and password.
$cloudCred = Get-Credential -Message 'An Active Directory user who is a member of the Hybrid Identity Administrators group for Microsoft Entra ID.'

# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred

This will then create a object in AD similar to a read only domain controller.

One thing to note is that if your account is part of a privileged group in AD, your password wont be replicated to this new object. We can check the group by going to the AD object and password replication tab. If your account is in any of the deny group you wont be issued Kerberos tickets.

Next we need to go to Intune and Configure the Windows Hello for Business policy.

Logon to the Intune Admin portal > Devices > Windows > Configuration > Create New Policy.

Select platform Windows 10 and Later and profile type Settings Catalog, click Create

Give the policy a name and description.

Click add settings and search for Windows Hello for Business.

I used the below settings for my pin and we need to enable use cloud trust for on prem auth and Cloud Kerberos Ticket Retrieval.

I left scope as defualt and apply the policy to my Intune Managed group.

Once the policy is applied we can connect back to the asset and restart.

On the next logon if we check we should now be able to connect to onprem resources and get issued Kerberos tickets.

This has been a quick run through of Setting up Cloud Kerberos Trust.

Set Local Account Policies Using Intune

In the post we will be going through the process of setting local account policies settings like maximum password age, password length, account lockout ….

To set these will be a configuration policy, these settings done have settings catalogue yet so we will be using custom policy.

I will be using an Entra Joined Windows 11 device, but this will also work if the device is hybrid joined and MDM is set to Win over GPO.

To check the current policy settings we can use secpol.msc to open the local security policy console.

Next we can check the account policies.

Once we have the current settings we can create the policy and change as required.

Next we need to configure the policy in Intune.

Go to Intune Admin center > Devices > Manage Devices > Configuration

Select Create

Select Platform and Profile type (Will be using Windows 10 or later and Settings catalog in the example)

Give the policy a name and description

Search for Device Lock and select the required settings.

Enable and set the required values.

I will be using a dynamic group for all Intune managed devices.

Next we need to review and create the policy.

Once the policy is create we can run a manual sync or wait for the next sync.

To manually sync open Settings > Accounts > Access Work or School

Select the account and go to info. Go to Device sync status and select Sync.

We can now try to set a simple password.

The only issue I have seen with this setup is that it doesn’t update the local security policy and can fail compliance scans.

If the settings needs to be set in local security policy we can apply the same settings using CSP policy and this will update the local policy.

To create a custom policy go back to Intune Admin center > Devices > Manage Devices > Configuration.

This time select templates > custom

Give the policy a name.

Next we need to add the Microsoft OMA-URI for device lock. These can be found here.

https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-devicelock

I wont be going through OMA-URI in this post, I have done a previous post on this

We need to add in a name, OMA-URI, Data type (can be gotten from the documentation for the OMA) and the value.

In the below we will be setting the account lockout values, this is a string value and all values can be added in to the one row.

Next we will set the the allow simple device password and this is a integer value, 0 is disabled and 1 is allowed.

Once we have all custom settings added.

I will use the same Intune managed device group for the assignment.

I will be leaving applicatio nrules as default.

Go to review and create and review the settings.

Next we can run a manual sync or wait for the automatic sync to complete.

We can check the event logs to confirm the setting has been applied.

Now if we check local security policy, we can see the setting are now updated.

This has been a over view of setting local security policies using Intune, the method to use will depend on the requirement.

Using setting catalogue is a simpler process but the issue with compliance reports has meant in some case i need to use custom policy to successfully pass compliance audits.

Managing Windows Defender Firewall Rules with Intune

In this post we will be going through the process of setting up and configuring Windows Defender Firewall and firewall rules using Intune.

There are two parts in Intune for setting up in Windows Defender Firewall.

  • Windows Firewall – Configure settings for Windows Firewall with Advanced Security.
  • Windows Firewall rules – Define Firewall rules, including specific ports, protocols, applications and networks, and to allow or block network traffic. Each instance of this profile supports up to 150 custom rules.

First we will create the Firewall Policy.

Go to Intune admin center > Endpoint security > Firewall.

Select Create Policy.

Select Windows and Windows Firewall.

Give the Firewall policy a name

I will enabling the Domain, Private and Public.

I will only be changing the log name and log size. Everything else I will leave as default.

I am leaving scope as default. I will be applying the rules to a specific security group that i have added two assets to.

Next we will review and create the Firewall Policy.

Once we review the settings we can start creating our firewall rules.

I have been using Windows Firewall on a Windows 11 asset to get the specific details for the rules I want to create.

To create go back to Create Policy, select the platform and profile type Windows Firewall Rules.

Give the policy a name and description.

Next we will add a rule, give the rule a name and set the action to either allow or deny.

To modify the settings click on edit instance.

This rule we will be creating using the below details.

  • Enabled: Enabled
  • Interface Types: All
  • File Path: System
  • Remote Port Ranges: Any
  • Network Types: Domain / Private
  • Local Port Ranges: 445
  • Direction: The rule applies to Inbound traffic
  • Local Address ranges: Any
  • Local Port Ranges: Any
  • Protocol: 6

We can check what each setting can be set to by click on the i button.

Once we have all the setting we want to configure we can save.

I am leaving scope as default. I will be applying the rules to the same security group used for the Firewall policy.

Next we can review settings and create.

Next we can need to either manually sync the client or wait for the next policy refresh. We can check the compliance in Intune to check for any errors.

To confirm on the client we need to open Windows Defender Firewall with Advanced Security > Monitoring > Firewall. The rules wont show under Inbound Rules.

To test we can try ping the devices and open a remote SMB connect to confirm that only SMB is allowed.

We can also check the firewall policy settings have applied.

This has been a quick run through of setting up Firewall policy and rules in Intune. Setting up rules in Intune is a bit more difficult than it is through group policy or using PowerShell (At least for predefined rules).

It takes a little getting use to and know how each setting can be configured but it become easier after setting up a few rules.

Updating Group Policy Administrative Templates (ADMX)

In this post we will go through the process of downloading and update ADXM templates for Group policy.

First we need to download the ADMX installer, I will be downloading the Windows 11 version.

Download Administrative Templates (.admx) for Windows 11 2024 Update (24H2) from Official Microsoft Download Center

To view the settings available we can use the corresponding spreadsheet for the templates, below is for Windows 11 24H2.

https://www.microsoft.com/en-sg/download/details.aspx?id=106255

Once downloaded we can run the installer, the default install location for is

C:\Program Files (x86)\Microsoft Group Policy

Once installed we can go to the folder and check for the admx and adml files.

The admx files will be in the root folder.

The adml files will be under the specific language version in my case it en-US

When deploying, you only need to copy the specify language version you need not all of them.

The default location for the files is c:\Windows\PolicyDefinitions, on the domain controller.

This is fine if you only have one DC but if there are multiple its better to move the PolicyDefinitions folder to the replicated sysvol folder.

Before updating the files it is recommend to backup the existing PolicyDefinitions folder.

Once backed up we can copy and overwrite the admx and adml files.

After the files are overwritten we can now use the policy settings in the new templates.

Using Microsoft Intune Custom Policies

In this post we will be going through setting up custom policy in Intune using Configuration Service Providers (CSP’s).

CSPs are similar to Group Policy and provide an interface to read, set, modify, or delete configuration settings. There are some settings that are not available in other types of configuration policies and can only be set using CSP or remediation script’s.

I am using the below link to find CPS policy settings.

https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-configuration-service-provider

To use CPS we need to find the setting we want to configure. We can then copy the OMA-URI which follows the below format.

Device: ./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName
User: ./User/Vendor/MSFT/Policy/Config/AreaName/PolicyName

We can then check what format and values can be set.

Once we have the settings we want to configure, we can create a new policy.

To create a policy go to Intune Admin center > Devices > Windows > Configuration and click create new policy.

Set the platform, profile type and use custom template.

Give the policy a name and description.

Click Add, Give the setting a name, description, OMA-URI, Data type (based on CSP documentation) and value to set.

Click save and the setting should now show. Add any additional settings and click next.

We can assign the policy to a group, or all devices / Users.

Add applicability rules if required and then review and create.

To confirm policy assignment we can generate a report by going to the policy and clicking on device assignment status.

Click generate report.

Select device from report and view setting status.

We can also check on the clients event log under Application and services logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider/Admin

Entra Hybrid: Enroll Hybrid Joined devices to Intune using Group Policy

In this post we will be going through the process of enrolling hybrid joined devices to Intune. There are a few different methods to enroll but in this post we will using GPO to enable auto enrollment.

First we need to confirm that MDM is not set on the device. Log on to Microsoft Entra ID portal and go to all devices.

Next we need to check that auto enrollment is enabled, go to Intune > Devices > Windows > Automatic Enrollment.

We can either scope MDM to some users or all (we will enabled for all).

Next we need to confirm the devices that we are trying to enroll is hybrid joined, we can use dsregcmd /status to check the device state.

Once we confirm MDM User enrollment is enabled and the device is hybrid joined, we can create the group policy.

Open gpmc.msc on the domain controller or admin workstation.

Right Click Group Policy Object, click New and give it a name.
Right click on newly created GPO and click Edit
go to Computer Configuration > Policies > Admin Templates > MDM and Double click Enable automatic MDM enrollment
Select Enable, select User Credentials under Select Credential Type.

Next, we need to link the group policy with the OU where the Hybrid joined devices are located.

In group policy, right click on the OU, click link an existing GPO, select Group Policy that we created.

Go to the device and run GPUPDATE /force

It can take a while for the client to register in the Azure portal. Once it has should see MDM change in my case its to ConfigMgr as I still have the ConfigMgr agent installed.

We can run dsregcmd /status to view that the MDM urls have been configured.

We can also check Intune to confirm the device shows.

This was a quick overview of setting up auto enrollment for hybrid devices to Intune.

Configure Microsoft Entra hybrid join

In this post we will going through the process of enabling and setting up Entra ID hybrid with on-premises AD join.

There is some debated on whether companies should go with hybrid join or Entra ID joined. The decision should be based on business requirements, if there is very little on- premises resources and no required for legacy application then the move to fully cloud managed is most likely the best option but for larger organization that have on-premises resources, then doing hybrid join can be a good alternative till full cloud management can be implemented.

Below are the prerequisite for setting hybrid join

  • Microsoft Entra Connect 1.1.819.0 or later
  • Account with Hybrid Identity Administrator on your Microsoft Entra tenant.
  • Enterprise administrator credentials for each of the on-premises Active Directory Domain Services forests.
  • Users can register their devices with Microsoft Entra ID. More information about this setting can be found under the heading Configure device settings, in the article, https://learn.microsoft.com/en-us/entra/identity/devices/manage-device-identities#configure-device-settings
  • The OU which contains the computer accounts that need to be synced must be selected in Entra Connect.

I would recommend reviewing Plan your Microsoft Entra hybrid join implementation article before enabling.

https://learn.microsoft.com/en-us/entra/identity/devices/hybrid-join-plan

If you need to know how to configure Microsoft Entra Connect see previous blog post. https://thesleepyadmins.com/2025/02/17/install-and-configure-microsoft-entra-connect/

We can either enabled hybrid join during the initial install of Entra Connect, but in this case we will be adding the feature to an existing Entra Connect deployment.

First we can check the status of the client to confirm we are not using hybrid joined by running the below command.

dsregcmd /status

Next to configure hybrid join we need to open Microsoft Entra Connect sync configuration application.

Select configure.

Next on tasks tab select Configure device options.

Check the overview

Enter the usersname and password for the account with Hybrid Identity Administrator.

Select Configure Hybrid Microsoft Entra ID join.

Windows 10 or later domain-joined devices.

Select the domain to create the service connect point, the account used must be a enterprise admin.

Click configure to start the deployment of the configuration.

Once completed exit the console.

We can now run a delta sync using the below PowerShell command.

We can check the metaverse search to show if the device has been synced.

We can also confirm by going to Microsoft Entra ID > Devices > all devices and confirm the devices is now showing.

We next need to restart the device, then run the dsregcmd again to confirm if we are now showing as hybrid joined.

dsregcmd /status

This has been a overview of setting up Microsoft Entra Hybrid join.

Install and configure Microsoft Entra Connect

In this post we will be going through the process of installing and configure Microsoft Entra Connect to sync on premises AD object to Microsoft Entra ID.

We will be syncing users and groups.

We will be using a dedicated server you can co locate on another server but it best to have a dedicated server or Entra Connect. The server must be domain joined.

We will need an account with Global Admin rights on the tenant we want to sync too and Enterprise admin in AD that we will be syncing.

The account can be setup temporary and remove the rights after Entra Connect is setup as we will let it configure its own accounts with required rights during the install.

Entra Connect Pre-reqs

  • .NET Framework 4.6.2 or later
  • Domain-joined Windows Server 2016 or later
  • TLS 1.2 enabled
  • SQL (Can select to use SQL Expresses during install or use full SQL)
  • Domain we want to sync is external routable not .local and has been verified in the M365.

To view the prerequisites for see below link .

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-install-prerequisites

TLS script to check and enabled required TLS settings.

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/reference-connect-tls-enforcement

We can download the Entra Connect installer from here.

https://www.microsoft.com/en-ie/download/details.aspx?id=47594

Once we confirm all permission, pre req and firewall rules are in place we can start to configure Entra ID.

Run the AzureADConnect.msi installer and agree to the license terms and click Continue.

    We can either select custom or express install. We will use custom to select a specify install location but this can be use to set an existing SQL server or use pre configure service accounts also.

    Click install once all settings are configured.

    Next we need to configure the sign in options. We will be using Password hash synchronization below link outlines each type.

    https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/plan-connect-user-signin

    Next enter the account with Hybrid Identity Administrator or Global Administrator.

    Enter the password and MFA prompt if required.

    Next we need to select the domain and click add directory.

    Enter the credentials for the enterprise admin and select to create a new account or use an existing account.

    Click ok and the domain now show as configured.

    Leave attribute at UPN unless there is a requirement to change.

    Select the required OU’s to sync.

    Leave identifying users as default.

    We can either sync sub set of users or all users we will go for all users.

    We can enabled option features, we will be leaving this at password hash sync.

    Next we can start the sync process and enabled staging mode if we only want to write the details to the Entra Connect database but not M365 or AD. We will be starting the sync process.

    Click install to start.

    Wait for the install to complete.

    We can launch Synchronization Service to verify the sync

    We can also check and verify that on-prem users have been created.

    We can also verify the sync account service accounts have been created these should have names like

    On-Premises Directory Synchronization Service Account on Entra

    and

    MSOL_numbers in AD.

    We have now successfully configured Entra Connect. The sync will now happen every 30 minutes.

    Using Filtering in Microsoft Graph SDK

    In this post we will be going through using different filter types in Microsoft Graph SDK.
    Using filters is useful when trying to return specific results or subset of data.

    To check if a command supports filtering we can look up the command on the Microsoft Learn page or try -Filter.

    There a few different operators we can use for filtering below is the full list.

    • eq
    • not ne
    • startswith
    • endswith
    • in
    • le
    • ge
    • not and endswith
    • not and startswith
    • not and eq
    • not and in contains
    • has

    Once we know the command supports filtering, we need find a property to filter on for users we will use display name.

    Get-MgUser -Filter "DisplayName eq 'Name'"
    

    To find all displaynames that start P we can use startsWith(DisplayName, ‘value’)

    Get-MgUser -Filter "startsWith(DisplayName, 'P')"
    

    To filter using a variable we can create a new variable with a value and call that in side the filter. This can be use when doing foreach loops to go through each object in an array.

    We can also use filtering to return objects by date, the date has to be formatted in a specific way or the filter will error out.

    The data has to be yyyy-MM-ddT00:00:00Z To get the correct date format we can use ToString and the format.

    $date = (Get-Date).AddDays(-30).ToString('yyyy-MM-ddT00:00:00Z')
    Get-MgAuditLogSignIn -Filter "AppDisplayName eq 'OfficeHome' and CreatedDateTime ge $($date)" | Select-Object AppDisplayName,CreatedDateTime
    

    Filtering is an import to learn when using Microsoft Graph without it, it can be difficulty to find the right data or objects.

    Filtering also helps improve performance and reduce the amount of data retrieved from Microsoft Graph.

    Create Azure Alert Using KQL Custom Search

    In this post we will be going through creating an alert rule using Azure monitor and custom log search.

    This can be setup for for most services in Azure that are set to use Azure log work space or have activity logs but we will be setting up for a Azure VM in this post.

    We needed to create an alert for a specific server that we have powered off and wanted to be alerted when it was powered on.

    There is no out of the box alerting for this, we end up deciding to use an alert rule with a KQL query.

    First we need to logon to the Azure portal and go to the VM we wanted to alert on.

    Select Alerts blade and create custom alert rule.

    Select custom log search from the drop down signal name.

    Add the search query. I used the AzureAcitivty table and search for the operation value name for virtual machine start action.

    AzureActivity
    | where OperationNameValue == 'MICROSOFT.COMPUTE/VIRTUALMACHINES/START/ACTION' and ActivityStatusValue == 'Success'
    | where EventSubmissionTimestamp >= (ago(2h))
    

    We will also need to set the required measurement type, aggregation type and aggregation.

    I used count as I want to alert when there is a count greater than 1, as this will mean the VM has been booted up.

    Next we need to set the alert logic.

    Set the operator, threshold value and frequency check for the alert. I set the threshold to greater than one alert and evaluate the logs every 2 hours.

    We can change the preview to view the current aggregate, which is one for me as I started the VM earlier in the day.

    Next we need to either create a new action group or use a pre existing one. I will be creating a new group.

    This can be set to send email, SMS message, push notification or voice message.

    Next we need to set the subscription and resource group for the alert. We will also set the alert rule severity, name, description and region.

    We can also set advanced option like automatically resolving alerts.

    Next we set the tags to be used, if required.

    Last step is to review and confirm all the settings.

    To test we can Power on the VM and check if the alert fires in the Azure portal and we received the email alert.

    Setting up alerts using custom log search’s can be very usefully especially if there is no out of the box report.