Setting up a new device for a developer usually means installing tools, cloning repositories, and applying configurations, all in a specific order. Microsoft Intune handles app and script deployment well, but it does not guarantee execution order. A Git install that finishes after the script that clones your repos is a problem.

Nerdio Scripted Sequences solve this. Introduced in Nerdio Manager for Enterprise (NME), Scripted Sequences let you define complex, multi-step task workflows with a guaranteed order of operations. They target Intune-managed devices, including Windows 365 Cloud PCs, and execute tasks sequentially through the Nerdio Endpoint Worker.

In this post we will build a real-world developer workstation onboarding sequence that installs Git, Visual Studio Code, clones team repositories, and confirms completion, all in the right order, every time.

Note: Scripted Sequences are in Public Preview. Feature scope and limitations may change in future NME releases.

What Are Scripted Sequences?

Scripted Sequences are an automation feature in NME that lets you create multi-step task workflows deployed to Intune-managed devices. Think of them as a lightweight task sequencer built into the Nerdio console.

Key characteristics:

Sequences respect the defined order of operations: Task 2 will not start until Task 1 completes successfully. Tasks can be grouped into Task Groups for logical organization. You can clone sequences, groups, and individual tasks for faster iteration.

Prerequisites

Before building your first sequence, make sure you have:

The Demo Scenario

We will automate day-one setup for a developer joining the team. The sequence installs prerequisites first, then tools, then runs a configuration script, in that exact order.

Let’s build it.

Step 1: Enable the Intune Integration

Before you can use Scripted Sequences, the Intune integration must be enabled. This is where NME connects to your Intune tenant.

1. Navigate to NME > Settings > Environment > Integrations > Intune.
2. Ensure the Intune integration is enabled.

Note: The initial Endpoint Worker deployment is controlled by Intune platform script delivery and may take some time. Subsequent tasks to the same device execute within a 15 to 30 minute window.

Step 2: Configure Task Automation

Task Automation must be configured before you can create or run Scripted Sequences.

1. Navigate to NME > Settings > Nerdio Environment > Task Automation.
2. Click Configure.
3. Enter a name and select a resource group for the Azure storage account that Nerdio Manager will create.
4. Click Save to complete the configuration.

Warning: If your NME deployment uses the Enable Private Endpoints scripted action, the storage account created here may have public network access disabled by default. The Nerdio Endpoint Worker on target devices needs to reach this storage account, so verify that public access is enabled or that a private endpoint is configured for it.

Step 3: Create the Scripted Sequence

1. Navigate to NME > Automation > Scripted Sequences.
2. Click New Scripted Sequence.
3. Name the sequence Developer Onboarding - Day One.
4. Optionally add a description: Installs developer tools and configures the workstation on first login.

Step 4: Add a Task Group

Task Groups let you organize related tasks. We will create one group for this sequence.

1. Inside the sequence, click Add task or Add group.
2. Select Add group.
3. Name the group Developer Tooling.

Note: A group must contain at least one task.

Step 5: Define the Tasks

Add the following six tasks inside the Developer Tooling group. The order you add them is the order they will execute.

Task 1: Set PowerShell Execution Policy

This ensures all subsequent PowerShell-based tasks can run.

• Task name: Set Execution Policy
• Type: PowerShell script
• Script:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine -Force

Task 2: Install Git

This task uses a PowerShell script to install Git via winget. You could also use the Install Application task type instead.

• Task name: Install Git
• Type: PowerShell script
• Script:

winget install --id Git.Git --accept-source-agreements --accept-package-agreements --silent

Task 3: Install Visual Studio Code

This task uses the Install Application task type, which lets you select a winget package directly without writing a script. You could also use a PowerShell script as shown in Task 2.

• Task name: Install Visual Studio Code
• Type: Install Application
• Winget package ID: Microsoft.VisualStudioCode

Task 4: Clone Repos and Configure VS Code

This script clones the team repository and installs essential VS Code extensions. Adjust the repository URL and extension list to match your environment.

• Task name: Configure Workstation
• Type: PowerShell script
• Script:

# Refresh PATH so git and code are available
$env:Path = [System.Environment]::GetEnvironmentVariable("Path", "Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path", "User")

# Clone team repository
$repoPath = "$env:USERPROFILE\Source\Repos"
New-Item -ItemType Directory -Path $repoPath -Force | Out-Null
git clone https://dev.azure.com/contoso/project/_git/main-repo "$repoPath\main-repo"

# Install VS Code extensions
code --install-extension ms-vscode.powershell
code --install-extension ms-python.python
code --install-extension hashicorp.terraform

Task 5a: Add Registry Key

First, create the registry key that will hold the completion marker.

• Task name: Log Completion
• Action: Add Registry Key
• Key path: HKLM\SOFTWARE\LeafIT\NerdioSequences

Task 5b: Set Registry Value

Next, set a value under the key to confirm the sequence completed. This makes it easy to query device status remotely via Intune or PowerShell.

• Task name: Log Completion clone
• Action: Set Registry Value
• Key path: HKLM\SOFTWARE\LeafIT\NerdioSequences
• Name: DeveloperOnboarding
• Value type: String
• Value: Completed

Step 6: Clone Tasks for Quick Iteration

Need a second sequence for designers with different tools? Since NME v7.6.0, you can clone the entire sequence or individual task groups and tasks.

1. On the Scripted Sequences page, select the Developer Onboarding - Day One sequence.
2. Click Clone.
3. Rename the cloned sequence and swap Git/VS Code for the tools your designers need.

This saves significant time compared to rebuilding sequences from scratch.

Step 7: Target Devices and Execute

1. On the Scripted Sequences page, click the three dots to the right of the Developer Onboarding - Day One sequence.
2. Click Run now.
3. Select the target Windows 365 Cloud PC or Intune device.

NME will push the tasks to the Nerdio Endpoint Worker on the device. Each task runs in order. Task 2 only starts after Task 1 reports success.

Tip: Monitor progress in NME > Logs.

Step 8: Validate on the Device

Log into the target Cloud PC and verify:

1. Git is installed. Open a terminal and run git --version.
2. VS Code is installed. Launch it from the Start menu.
3. Repos are cloned. Check %USERPROFILE%\Source\Repos\main-repo.
4. Extensions are present. Open VS Code and navigate to the Extensions panel.
5. Registry key exists. Open a terminal and run reg query "HKLM\SOFTWARE\LeafIT\NerdioSequences" /v DeveloperOnboarding.

Current Limitations

Scripted Sequences are still in Public Preview. Keep these constraints in mind:

Conclusion

Nerdio Scripted Sequences bring deterministic, ordered task execution to Intune-managed devices. This is something native Intune cannot guarantee today. By combining simple PowerShell scripts in a defined sequence, you can automate complex onboarding workflows and ensure every new device is configured consistently.

As the feature moves toward general availability, expect expanded scope and deeper integration within NME. For now, it is already a practical tool for any organization managing Intune endpoints at scale.

The post Automating New Device Setup with Nerdio Scripted Sequences appeared first on Jens Du Four.

Note: The Frontier Preview is a public preview. Future availability depends on its results and is subject to change.

Prerequisites at a Glance

Before diving into the configuration, make sure you have the following in place:

With these in place, let’s start configuring.

Step 1: Create Dynamic Entra ID Groups

To target the right Cloud PCs and users, we will create two dynamic groups in Entra ID. This ensures that any future 8 vCPU Cloud PCs and their users are automatically included.

W365-U-Frontier (Dynamic user group)

This group automatically contains all users that have a Windows 365 Enterprise 8 vCPU license assigned.

1. Navigate to Microsoft Entra admin center > Groups > All groups > New group.
2. Set the Group type to Security.
3. Set the Group name to W365-U-Frontier.
4. Set Membership type to Dynamic User.
5. Click Add dynamic query and enter the following rule:

(user.assignedPlans -any (assignedPlan.servicePlanId -eq "69dc175c-dcff-4757-8389-d19e76acb45d" -and assignedPlan.capabilityStatus -eq "Enabled"))

The service plan ID 69dc175c-dcff-4757-8389-d19e76acb45d corresponds to the CPC_E_8C_32GB_256GB SKU (Windows 365 Enterprise 8 vCPU, 32 GB, 256 GB).

1. Click Save and then Create.

W365-D-Frontier (Dynamic device group)

This group automatically contains all Cloud PC devices that match the 8 vCPU configuration. The deviceModel property in Entra ID follows the format Cloud PC Enterprise 8vCPU/<RAM>/<disk>, so we use a -startsWith operator to capture all variants (128 GB, 256 GB, 512 GB).

1. Navigate to Microsoft Entra admin center > Groups > All groups > New group.
2. Set the Group type to Security.
3. Set the Group name to W365-D-Frontier.
4. Set Membership type to Dynamic Device.
5. Click Add dynamic query and enter the following rule:

(device.deviceModel -startsWith "Cloud PC Enterprise 8vCPU")

1. Click Save and then Create.

Tip: Give the dynamic membership rules a few minutes to evaluate. You can check the membership under Groups > W365-D-Frontier > Members to confirm devices are populating.

Step 2: Configure the PowerShell Execution Policy

AI-enabled features require the RemoteSigned execution policy on the Cloud PC. Instead of configuring this manually on each device, deploy it through Intune.

1. Navigate to Microsoft Intune admin center > Devices > Configuration > Create > New Policy.
2. Select Windows 10 and later as the platform and Settings catalog as the profile type.
3. Name the policy DEV-CONF-W365-FRONTIER-EXECUTIONPOLICY.
4. Click Add settings and search for PowerShell.
5. Select Administrative Templates > Windows Components > Windows PowerShell and enable Turn on Script Execution.
6. Set Execution Policy to Allow only signed scripts (this is the RemoteSigned equivalent).

1. On the Assignments tab, assign to the W365-D-Frontier device group.
2. Click Create.

Step 3: Enable Features Introduced via Servicing

A Windows Update policy must be enabled so that features delivered through servicing updates are activated. This setting is not available in the Settings Catalog, so we deploy it as a custom configuration profile using OMA-URI.

1. Navigate to Microsoft Intune admin center > Devices > Configuration > Create > New Policy.
2. Select Windows 10 and later as the platform and Templates as the profile type, then select Custom.
3. Name the policy DEV-CONF-W365-FRONTIER-SERVICING.
4. Click Add under OMA-URI Settings and configure the following:

1. Click Save, then Next.
2. On the Assignments tab, assign to the W365-D-Frontier device group.
3. Click Create.

Step 4: Enable Optional Diagnostics Data

The Windows Insider Program requires optional diagnostics data to be enabled on Cloud PCs. Without it, the device will display “To join the Insider program, turn on optional diagnostics data” and cannot enroll in the Beta channel. Deploy this through a Settings Catalog policy.

1. Navigate to Microsoft Intune admin center > Devices > Configuration > Create > New Policy.
2. Select Windows 10 and later as the platform and Settings catalog as the profile type.
3. Name the policy DEV-CONF-W365-FRONTIER-DIAGNOSTICS.
4. Click Add settings and search for Allow Telemetry.
5. Select System > Allow Telemetry and set it to Full (this enables optional diagnostics data).

1. On the Assignments tab, assign to the W365-D-Frontier device group.
2. Click Create.

Step 5: Enroll Cloud PCs in the Windows Insider Beta Channel

The AI features require the Windows Insider Beta channel. Instead of having each user manually opt in, use an Intune Update Ring to handle this at scale.

1. Navigate to Microsoft Intune admin center > Devices > Windows updates > Update rings.
2. Click + Create profile.
3. Name it DEV-CONF-W365-FRONTIER-INSIDERBETA.
4. Under Update ring settings:
   • Set Enable pre-release builds to Enable.
   • Set Select pre-release channel to Beta Channel.
5. Leave the remaining settings at their defaults.

1. On the Assignments tab, assign to the W365-D-Frontier device group.
2. Click Create.

After the policy syncs, Cloud PCs will start receiving Beta channel updates. Make sure devices check for updates and restart.

Step 6: Assign AI-Enablement in Intune

With all prerequisites deployed, you can now flip the switch to enable AI features on the targeted Cloud PCs.

1. Navigate to Microsoft Intune admin center > Devices > Device onboarding > Windows 365.
2. Select the Settings tab.
3. Click Create and select Cloud PC configurations.
4. Enter a Name, for example USR-CONF-W365-FRONTIER-AIENABLEMENT.
5. On the Configuration settings tab, set AI-enabled features to Enable.

1. On the Assignments tab, assign to the W365-U-Frontier user group.
2. Proceed to Review + create and click Create.

Important: After AI-enablement is assigned, it can take up to 48 hours for the background processes to complete. During this time, the Cloud PCs are setting up the AI infrastructure locally.

Step 7: Apply Updates and Restart

Once the 48-hour enablement window has passed, updates need to be applied:

1. On the Cloud PC, open Settings > Windows Update.
2. Click Check for updates, install any pending updates, and restart.
3. Repeat this process 3-5 times until no more updates are pending.

This can also be managed at scale using Intune’s Windows Update for Business policies or by using Expedite updates to push things along.

Step 8: Validate the Deployment

After the updates have been applied, you can verify that AI features are active in several places.

Intune Admin Validation

Device Overview page: Navigate to Devices > select a Cloud PC > Overview. The Essentials tab will show an AI-enabled field.

Reports dashboard: Navigate to Reports > Windows 365 > Cloud PC overview. You will see a breakdown of AI-enabled Cloud PCs by status:

• Initiated – AI enablement is in progress
• Ready to use – Features are available
• Failed – Setup could not complete

End-User Validation

Windows App: AI-enabled Cloud PCs show an “AI-enabled” tag on the device card within the Windows App.

Windows Taskbar: The search box on the taskbar displays a magnifying glass with sparkles icon when AI features are active.

Note: After a Windows Update, the sparkles icon might temporarily disappear. If clicking the search box doesn’t restore it, check the AI-enabled Cloud PC Known Issues page.

What You Get: Supported Features

Once everything is set up, your Cloud PCs get access to the following Copilot+ features:

Improved Windows Search

Users can find files using descriptive, natural-language queries. The AI interprets intent and searches across local files and OneDrive. For example, searching “airplane” will surface a photo named Picture26.jpg that contains an airplane.

This works in both the Windows Search box on the taskbar and in File Explorer. It supports English, Chinese (Simplified), French, German, Japanese, and Spanish.

Click to Do

Press Win + Q or hold the Windows key while left-clicking an element on screen to get contextual actions on highlighted text or images. You can summarize text, look up information, or perform actions on images without switching apps.

Note: You must launch the Click to Do app once after AI-enablement and after every Cloud PC restart before the keyboard shortcuts work. Some intelligent text actions (like “Ask Microsoft 365 Copilot”) are not yet supported on Cloud PCs.

Managing and Removing AI Features

Granular Feature Control

If you want to keep AI-enablement but toggle individual features:

• Click to Do: Manage through Click to Do client management policies.
• Improved Windows Search: Use the Search Policy CSP settings in Intune.

Disabling AI-Enablement Entirely

There are two options:

1. Unassign the user from the Enable policy.
2. Create a Disable policy: Follow the same steps as Step 6, but set AI-enabled features to Disable and assign to the target group. The Disable policy takes precedence over Enable during conflict resolution.

After disabling, it can take up to 48 hours for the AI features to be removed from the Cloud PCs.

Privacy and Security

AI-enabled Cloud PCs follow the same Windows 365 privacy and data policies:

• Processing: AI features process data ephemerally using a secure Windows 365 cloud service. No personal or user data is stored in the cloud service or used for AI model training.
• Storage: All data and indexes are stored locally on the Cloud PC. This is unchanged from existing Windows AI features.
• Controls: AI features are off by default. The IT admin must explicitly enable them through the configuration steps described above.

Conclusion

With a few Intune policies and a couple of dynamic Entra ID groups, you can bring Copilot+ AI features to your Windows 365 8 vCPU fleet without touching a single Cloud PC. The key steps are:

1. Create dynamic groups to target the right users and devices.
2. Deploy execution policy and servicing feature policies.
3. Enable optional diagnostics data for Windows Insider enrollment.
4. Enroll devices in the Windows Insider Beta channel.
5. Enable AI features through a Cloud PC configuration.
6. Apply updates and validate.

For troubleshooting, check the AI-enabled Cloud PC Known Issues page. For the full Microsoft documentation, see AI-enabled Cloud PC (Frontier Preview) and Manage AI-enabled features.

Looking for more Windows 365 management tips? Check out Windows 365 Restore Points: A Guide to Long-Term Storage and Adding Language Packs Using Proactive Remediations.

Sources

• AI-enabled Cloud PC (Frontier Preview)
• Manage AI-enabled features on Cloud PCs
• AI-enabled Cloud PC Known Issues
• Product names and service plan identifiers for licensing

The post Enabling AI Frontier Capabilities on Windows 365 with Intune appeared first on Jens Du Four.

Update (March 2026): With Ubuntu 26.04 LTS, AuthD is now included in the official Ubuntu archive (universe) and no longer requires a PPA. The instructions in this guide target Ubuntu 24.04 LTS, where the PPA is still required. If you are running Ubuntu 26.04 LTS, you can skip the PPA step and install AuthD directly with sudo apt install authd. Additionally, a generic OIDC broker is now available for integration with any standards-compliant identity provider. For full details, see the official announcement.

Introduction to Entra ID Authentication

This guide replaces the legacy PAM-based Entra ID authentication method for older Ubuntu versions.

Entra ID authentication using AuthD represents a significant shift in how enterprises manage Linux workstation identity. As organizations adopt Ubuntu for development, data science, and productivity workloads, the need for cloud-native authentication becomes critical. AuthD provides the solution, enabling users to log in to Ubuntu with their Microsoft Entra ID credentials.

Figure 1: Ubuntu 24.04 LTS with GDM showing Microsoft Entra ID login option

Traditional approaches like LDAP, Kerberos, or SSSD configurations require significant infrastructure and expertise. Furthermore, they complicate the user experience with separate credentials. For organizations invested in Microsoft Entra ID (formerly Azure AD), the question becomes: can we provide the same seamless, secure Entra ID authentication experience that users expect on Windows?

The answer is yes, thanks to AuthD (Ubuntu’s authentication daemon). With AuthD, you can achieve:

• Single Sign-On with Entra ID credentials on Ubuntu desktops
• Multi-Factor Authentication (MFA) using Microsoft Authenticator
• Device code flow authentication at the login screen
• Elimination of local accounts for enhanced security
• Offline credential caching for disconnected scenarios

In this guide, you’ll learn how to:

• Configure Azure app registration for AuthD
• Install and configure AuthD on Ubuntu 24.04 LTS
• Disable local account login while maintaining recovery access
• Troubleshoot common authentication issues

Whether you’re securing a handful of Linux workstations or planning an enterprise-wide rollout, this guide provides everything you need for Entra ID authentication.

Note: This guide focuses on manual AuthD configuration. For device management with Microsoft Intune, see our companion article on Enrolling Ubuntu 24.04 LTS in Microsoft Intune. For a fully automated zero-touch deployment using autoinstall and cloud-init, see Automating Ubuntu Entra ID Authentication.

Understanding Entra ID Authentication Components

Before configuring Entra ID authentication, it’s essential to understand the technologies that make this solution work.

AuthD: The Core of Entra ID Authentication

AuthD is Ubuntu’s modern authentication daemon designed specifically for cloud identity providers. Unlike traditional solutions that require domain controllers or complex LDAP configurations, AuthD provides a streamlined approach to cloud authentication.

Figure 2: AuthD architecture with MS Entra ID broker integration

Key Features:

AuthD consists of two main components:

1. authd: The core authentication daemon (Debian package) that handles PAM integration
2. Identity broker: A Snap package that interfaces with your identity provider (e.g., authd-msentraid for Microsoft Entra ID)

Together, these components enable secure Entra ID authentication with minimal configuration overhead.

Microsoft Entra ID as the Identity Provider

Microsoft Entra ID serves as the identity provider for Entra ID authentication. Key capabilities include:

Architecture Overview

The following diagram shows how Entra ID authentication works:

┌─────────────────────────────────────────────────────────────────────┐
│                         Ubuntu 24.04 LTS                            │
│                                                                     │
│  ┌──────────┐    ┌──────────┐    ┌──────────────────────────────┐   │
│  │   GDM    │───▶│  AuthD   │───▶│  MS Entra ID Broker (Snap)  │   │
│  │ (Login)  │    │ (daemon) │    │  (authd-msentraid)           │   │
│  └──────────┘    └──────────┘    └──────────────────────────────┘   │
│       │               │                      │                      │
│       │               │                      │                      │
│  ┌────▼───────────────▼──────┐               │                      │
│  │      PAM Configuration    │               │                      │
│  │   (Pluggable Auth Module) │               │                      │
│  └───────────────────────────┘               │                      │
│                                              │                      │
└──────────────────────────────────────────────│──────────────────────┘
                                               │
                                               ▼
                         ┌────────────────────────────────────────────┐
                         │           Microsoft Entra ID               │
                         │      (Authentication & Authorization)      │
                         └────────────────────────────────────────────┘

The Entra ID authentication flow works as follows:

1. First, the user attempts login at GDM (GNOME Display Manager)
2. Then, GDM invokes AuthD through PAM to handle authentication
3. Next, AuthD delegates to the MS Entra ID broker
4. Subsequently, the broker initiates authentication flow with Entra ID
5. Upon success, AuthD creates or updates the local user account
6. Finally, the user is logged in to the desktop

Prerequisites for Entra ID Authentication

Before implementing Entra ID authentication, ensure all prerequisites are met.

Licensing Requirements

Note: AuthD itself is free. Licensing requirements depend on features you want to use in Entra ID.

Technical Prerequisites

Ubuntu System:

• Ubuntu Desktop 24.04 LTS (fresh install recommended)
• GNOME desktop environment (included by default)
• amd64 or arm64 architecture
• Network connectivity to Microsoft services
• Local administrator account for initial setup

Azure Requirements:

• Global Administrator or Application Administrator role
• Permission to create app registrations in Entra ID

Network Requirements

Ensure the following endpoints are accessible:

Security Considerations

Before disabling local accounts, plan for:

Azure Configuration for Entra ID Authentication

To enable Entra ID authentication, you must first create an app registration in Azure.

Figure 3: Azure Portal showing app registration configuration for AuthD

Step 1: Create App Registration

1. Navigate to Azure Portal
   • Go to portal.azure.com
   • Select Microsoft Entra ID > App registrations > New registration
2. Register the Application
   • Name: Ubuntu-Device-Auth
   • Supported account types: Accounts in this organizational directory only
   • Redirect URI: Leave blank
3. Click Register

Step 2: Configure API Permissions

Add the required Microsoft Graph permissions:

1. Navigate to API permissions > Add a permission
2. Select Microsoft Graph > Delegated permissions
3. Add the following permissions:
   • User.Read: Read user profile
   • offline_access: Refresh tokens for offline access
   • openid: OpenID Connect authentication
   • profile: Read user profile information
4. Click Grant admin consent for your organization

Step 3: Enable Public Client Flow

Device code flow requires public client settings:

1. Navigate to Authentication
2. Under Settings, set Allow public client flows to Enabled
3. Click Save

Step 4: Record Application Details

Note down these values for later configuration:

Ubuntu Configuration: Installing AuthD

With Entra ID configured, you can now install and configure AuthD to enable Entra ID authentication.

Step 1: Update System

Start with a fresh system update:

# Update package lists
sudo apt update
sudo apt upgrade -y

Step 2: Add AuthD PPA

AuthD is available from the Ubuntu Enterprise Desktop PPA:

# Add the AuthD PPA
sudo add-apt-repository -y ppa:ubuntu-enterprise-desktop/authd

# Update package list
sudo apt update

Step 3: Install AuthD

Install AuthD with GNOME integration:

# Install AuthD
sudo apt install -y authd

Step 4: Install MS Entra ID Broker

The broker is distributed as a Snap package:

# Install the MS Entra ID broker
sudo snap install authd-msentraid

# Verify installation
snap list authd-msentraid

Figure 4: Installing AuthD and MS Entra broker on Ubuntu

Configuring AuthD for Entra ID Authentication

After installation, configure AuthD with your Azure app registration details.

Step 1: Create Broker Configuration Directory

# Create broker directory (required by AuthD)
sudo mkdir -p /etc/authd/brokers.d
sudo chmod 700 /etc/authd/brokers.d

# Copy broker declaration from the snap package
sudo cp /snap/authd-msentraid/current/conf/authd/msentraid.conf /etc/authd/brokers.d/
sudo chmod 600 /etc/authd/brokers.d/msentraid.conf

Step 2: Configure the Broker

Edit the broker configuration with your Azure details:

# Edit broker configuration
sudo nano /var/snap/authd-msentraid/current/broker.conf

Add or modify the following configuration:

[oidc]
issuer = https://login.microsoftonline.com/<YOUR_TENANT_ID>/v2.0
client_id = <YOUR_CLIENT_ID>

[users]
# Allow all authenticated users
allowed_users = ALL
# Entra ID password becomes the local Linux password
password_passthrough = true


# Or restrict to specific users:
# allowed_users = user1@yourdomain.com

# Or use OWNER mode (first user becomes owner):
# allowed_users = OWNER

Replace:

• <YOUR_TENANT_ID> with your Microsoft Entra tenant ID
• <YOUR_CLIENT_ID> with your app registration client ID

User Access Options

Step 3: Configure Login Timeout

The default login timeout may be too short for MFA. Increase it:

# Edit login.defs
sudo nano /etc/login.defs

# Find LOGIN_TIMEOUT and modify (or add if not present)
LOGIN_TIMEOUT 120

Step 4: Restart Services

Apply the configuration:

# Secure the broker configuration
sudo chmod 600 /var/snap/authd-msentraid/current/broker.conf
sudo chmod 700 /var/snap/authd-msentraid/current

# Restart AuthD service
sudo systemctl restart authd

# Restart the broker
sudo snap restart authd-msentraid

# Verify services are running
systemctl status authd
snap services authd-msentraid

Step 5: Test Authentication

Before making further changes, verify Entra ID authentication works:

1. Log out of your current session
2. Click “Microsoft Entra ID” to select it as the broker (or similar option)
3. Enter your organizational email
4. Complete the device code authentication flow:
   • Open https://microsoft.com/devicelogin on another device
   • Enter the code displayed on the Ubuntu screen
   • Complete MFA authentication
5. You should be logged in with your Entra ID account

Figure 5: The device code authentication flow

Disabling Local Accounts for Secure Entra ID Authentication

Warning: Only proceed after successfully testing Entra ID authentication. Ensure you have recovery access planned.

Understanding the Security Implications

Disabling local account login enhances security:

However, you must plan for:

• Network connectivity requirements (first login requires network)
• Recovery procedures (boot-level or break-glass access)
• Cached credential limitations

Method 1: Lock Local User Accounts

The safest approach preserves accounts for emergency recovery:

# List local users (UID >= 1000, excluding nobody)
awk -F: '$3 >= 1000 && $1 != "nobody" {print $1}' /etc/passwd

# Lock each local user account (example for user 'localadmin')
sudo passwd -l localadmin

# Remove from sudo group if not needed
sudo deluser localadmin sudo

To unlock in emergency:

sudo passwd -u localadmin

Method 2: PAM Configuration for AuthD Priority

Configure PAM to prioritize AuthD:

# Backup existing PAM configuration
sudo cp /etc/pam.d/common-auth /etc/pam.d/common-auth.backup

# Edit PAM configuration
sudo nano /etc/pam.d/common-auth

Modify to prioritize AuthD:

# AuthD authentication (primary)
auth    [success=2 default=ignore]    pam_authd.so

# Local authentication (fallback - comment out to disable)
# auth   [success=1 default=ignore]    pam_unix.so nullok_secure

# Deny if all methods fail
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Method 3: Hide Local Users from GDM

Hide local users from the login screen:

# Create/edit GDM configuration
sudo nano /etc/gdm3/greeter.dconf-defaults

# Add the following
[org/gnome/login-screen]
disable-user-list=true

Apply changes:

sudo dpkg-reconfigure gdm3

Recovery Access Setup

Always maintain emergency access:

1. Recovery Mode Access
   • To access single-user mode:
     • Reboot and hold SHIFT to access GRUB
     • Edit boot entry, add ‘single’ to kernel parameters
     • Boot into single-user mode (requires disk encryption password)
2. Break-Glass Admin Account
   • Create a dedicated admin account in Entra ID
   • Add to allowed_users in broker configuration
   • Store credentials securely (password manager)
   • Document when and how to use
3. Create Recovery Script

sudo tee /root/emergency-recovery.sh > /dev/null << 'EOF'
#!/bin/bash
# Emergency recovery script - Run from recovery mode
mount -o remount,rw /
passwd -u localadmin
cp /etc/pam.d/common-auth.backup /etc/pam.d/common-auth
echo "Recovery complete. Reboot normally."
EOF
sudo chmod 700 /root/emergency-recovery.sh

Automation Script for Entra ID Authentication

For consistent deployments, use this automation script for Entra ID authentication:

#!/bin/bash
#===============================================================================
# Script Name: setup-authd.sh
# Description: Automated setup of AuthD on Ubuntu 24.04 LTS
# Author: Enterprise IT
# Version: 1.0
#===============================================================================

set -e  # Exit on error

# Configuration Variables - MODIFY THESE
TENANT_ID="YOUR_TENANT_ID_HERE"
CLIENT_ID="YOUR_CLIENT_ID_HERE"
ALLOWED_USERS="ALL"  # Options: ALL, OWNER, or comma-separated emails
DISABLE_LOCAL_LOGIN="false"  # Set to "true" to disable local login

# Logging
LOG_FILE="/var/log/authd-setup.log"
exec 1> >(tee -a "$LOG_FILE") 2>&1

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1"
}

error() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] ERROR: $1" >&2
    exit 1
}

# Check if running as root
if [[ $EUID -ne 0 ]]; then
    error "This script must be run as root (use sudo)"
fi

# Validate configuration
if [[ "$TENANT_ID" == "YOUR_TENANT_ID_HERE" ]]; then
    error "Please set TENANT_ID before running this script"
fi

if [[ "$CLIENT_ID" == "YOUR_CLIENT_ID_HERE" ]]; then
    error "Please set CLIENT_ID before running this script"
fi

# Check Ubuntu version
if ! grep -q "24.04" /etc/lsb-release; then
    error "This script is designed for Ubuntu 24.04 LTS"
fi

log "Starting AuthD setup..."

#===============================================================================
# PHASE 1: Install AuthD
#===============================================================================

log "Phase 1: Installing AuthD..."

apt update

# Add AuthD PPA
if ! grep -q "ubuntu-enterprise-desktop/authd" /etc/apt/sources.list.d/*.list 2>/dev/null; then
    add-apt-repository -y ppa:ubuntu-enterprise-desktop/authd
    log "AuthD PPA added"
fi

apt update
apt install -y authd

log "AuthD installed"

#===============================================================================
# PHASE 2: Install MS Entra ID Broker
#===============================================================================

log "Phase 2: Installing MS Entra ID broker..."

snap install authd-msentraid

log "MS Entra ID broker installed"

#===============================================================================
# PHASE 3: Configure Broker
#===============================================================================

log "Phase 3: Configuring broker..."

# Create broker configuration directory
mkdir -p /etc/authd/brokers.d/

# Copy broker declaration
cp /snap/authd-msentraid/current/conf/authd/msentraid.conf /etc/authd/brokers.d/

# Configure broker
cat > /var/snap/authd-msentraid/current/broker.conf << EOF
[oidc]
issuer = https://login.microsoftonline.com/${TENANT_ID}/v2.0
client_id = ${CLIENT_ID}

[users]
allowed_users = ${ALLOWED_USERS}
password_passthrough = true
EOF

log "Broker configured"

#===============================================================================
# PHASE 4: Configure Login Timeout
#===============================================================================

log "Phase 4: Configuring login timeout..."

if grep -q "^LOGIN_TIMEOUT" /etc/login.defs; then
    sed -i 's/^LOGIN_TIMEOUT.*/LOGIN_TIMEOUT 120/' /etc/login.defs
else
    echo "LOGIN_TIMEOUT 120" >> /etc/login.defs
fi

log "Login timeout configured"

#===============================================================================
# PHASE 5: Disable Local Login (Optional)
#===============================================================================

if [ "$DISABLE_LOCAL_LOGIN" = "true" ]; then
    log "Phase 5: Disabling local login..."

    # Backup PAM configuration
    cp /etc/pam.d/common-auth /etc/pam.d/common-auth.backup.$(date +%Y%m%d)

    # Hide user list in GDM
    mkdir -p /etc/gdm3
    cat >> /etc/gdm3/greeter.dconf-defaults << 'EOF'

[org/gnome/login-screen]
disable-user-list=true
EOF

    # Lock local accounts
    for user in $(awk -F: '$3 >= 1000 && $1 != "nobody" {print $1}' /etc/passwd); do
        passwd -l "$user" 2>/dev/null || true
        log "Locked local user: $user"
    done

    log "Local login disabled"
else
    log "Phase 5: Skipping local login disable (set DISABLE_LOCAL_LOGIN=true to enable)"
fi

#===============================================================================
# PHASE 6: Restart Services
#===============================================================================

log "Phase 6: Restarting services..."

systemctl restart authd
snap restart authd-msentraid

log "Services restarted"

#===============================================================================
# COMPLETION
#===============================================================================

log "=============================================="
log "Setup completed successfully!"
log "=============================================="
log ""
log "Next steps:"
log "1. Reboot the system"
log "2. Log out and test Entra ID authentication at GDM"
log ""
log "Configuration details:"
log "  - Tenant ID: ${TENANT_ID}"
log "  - Client ID: ${CLIENT_ID}"
log "  - Allowed Users: ${ALLOWED_USERS}"
log "  - Local Login Disabled: ${DISABLE_LOCAL_LOGIN}"
log ""
log "Log file: ${LOG_FILE}"

echo ""
echo "Reboot now? (y/n)"
read -r response
if [[ "$response" =~ ^[Yy]$ ]]; then
    reboot
fi

Using the Automation Script

1. Save the script as setup-authd.sh
2. Edit configuration variables:
   • TENANT_ID=”your-tenant-id”
   • CLIENT_ID=”your-client-id”
   • ALLOWED_USERS=”ALL”
   • DISABLE_LOCAL_LOGIN=”false”
3. Run the script:
   • chmod +x setup-authd.sh && sudo ./setup-authd.sh
4. Complete post-script steps:
   • Reboot the system
   • Test Entra ID authentication
   • If successful, re-run with:
     • DISABLE_LOCAL_LOGIN="true"

Troubleshooting Entra ID Authentication Issues

When implementing Entra ID authentication, you may encounter various issues.

AuthD Authentication Failures

Login Issues After Configuration

Useful Troubleshooting Commands

# Check AuthD service status
systemctl status authd

# View AuthD logs
journalctl -u authd -f

# Check broker logs
snap logs authd-msentraid

# View broker configuration
cat /var/snap/authd-msentraid/current/broker.conf

# Test authentication manually
authd-cli authenticate

Recovery Commands

If locked out, boot to recovery mode:

# Mount filesystem read-write
mount -o remount,rw /

# Restore PAM configuration
cp /etc/pam.d/common-auth.backup /etc/pam.d/common-auth

# Unlock local user
passwd -u localadmin

# Restart services
systemctl restart authd

Best Practices for Entra ID Authentication

To ensure your Entra ID authentication deployment is secure and reliable, follow these best practices.

Security Hardening

Operational Best Practices

1. Document Recovery Procedures
   • Create step-by-step recovery documentation
   • Store recovery keys securely (not on the device)
   • Test recovery procedures quarterly
2. Plan for Offline Scenarios
   • AuthD caches credentials for offline login
   • First login always requires network
   • Document offline limitations for users
3. User Communication
   • Provide training on device code authentication
   • Create FAQ for common issues
   • Establish support channels
4. Staged Rollout
   • Pilot with IT team first
   • Expand to early adopters
   • Full deployment after validation

Monitoring Commands

# Check AuthD service status
systemctl status authd

# View AuthD logs
journalctl -u authd -f

# Check broker logs
snap logs authd-msentraid

# List logged-in users
who

Conclusion: Embracing Entra ID Authentication

Implementing Entra ID authentication with AuthD transforms Ubuntu workstations into cloud-native enterprise systems. As a result, organizations achieve:

• Eliminate password sprawl with single sign-on
• Enhance security through MFA enforcement
• Simplify management with centralized identity
• Reduce attack surface by eliminating local accounts
• Enable unified identity across all platforms

This Entra ID authentication solution represents the future of enterprise Linux management. With AuthD now included in the Ubuntu 26.04 LTS archive, expect even deeper integration and additional identity provider support, including a generic OIDC broker for standards-compliant providers.

Ready to implement Entra ID authentication? Begin with a single test workstation, validate the authentication flow, then scale your deployment with confidence.

Additional Resources

External Documentation

• AuthD Official Documentation
• AuthD GitHub Repository
• Microsoft Entra ID Documentation

Have questions about implementing Entra ID authentication? Share your experience in the comments below or reach out for assistance!

The post Entra ID Authentication with AuthD on Ubuntu 24.04 LTS appeared first on Jens Du Four.

EPM automation with Adaptive Cards transforms how IT teams handle elevation requests in Microsoft Intune. By combining Azure Logic Apps with Teams Adaptive Cards, you can automate the entire Endpoint Privilege Management (EPM) approval workflow, allowing approvers to act on requests without leaving Microsoft Teams. This EPM automation solution eliminates the need to constantly monitor the Intune portal.

What Is Endpoint Privilege Management?

Endpoint Privilege Management (EPM) is a feature in the Microsoft Intune Suite that allows organizations to manage and control local administrator rights on Windows devices — without granting permanent admin access. It enables rule-based and Just-In-Time (JIT) elevation, ensuring users can perform privileged tasks only when necessary, and only under defined conditions.

Rules-Based Elevation: Three Options

EPM supports three types of elevation rules:

1. Automatic Elevation — The application is elevated silently without user interaction, based on predefined rules.
2. User-Confirmed Elevation — The user is prompted to confirm the elevation request, typically with a business justification and/or Windows authentication.
3. Support-Approved Elevation — The user submits a request that must be approved by IT or support staff before elevation is granted. This is the model we focus on in this post, as it allows integration with Microsoft Teams for real-time approvals.

Just-In-Time Elevation with Support Approval

Support-approved elevation is ideal for organizations that want to maintain strict control over admin rights while still enabling flexibility for end users. When a user requests elevation, the request is logged and routed for approval. By integrating this process with Microsoft Teams using Azure Logic Apps, IT teams can receive instant notifications and respond quickly — without switching tools or missing critical requests.

Currently, when approved, these requests remain valid for 24 hours.

Benefits of Using EPM

Implementing Endpoint Privilege Management offers several key advantages:

• User Empowerment: Allows users to perform necessary tasks without waiting for manual intervention — when policies allow it.
• Improved Security: Reduces the attack surface by eliminating standing admin rights.
• Operational Efficiency: Automates elevation workflows and reduces helpdesk overhead.
• Compliance and Auditing: Provides detailed logs of elevation activity for auditing and compliance reporting.

The Challenge with Manual EPM Approvals

When EPM is configured in Microsoft Intune, end users can request elevation to run applications requiring administrator privileges. However, the traditional approval workflow requires IT administrators to:

1. Navigate to the Intune portal
2. Find the pending elevation request
3. Review the request details
4. Approve or deny the request

This process, while secure, creates friction, especially when approvers are busy with other tasks or aren’t actively monitoring the Intune console.

The result?

Delayed approvals and frustrated users waiting for elevated access.

Configuring EPM in Microsoft Intune

Before setting up the automation, you need an EPM elevation rules policy. In this example we enable the “Mark 8 Project Team” to request elevation for Wireshark. I am assuming here that EPM was already enabled in your tenant.

Start in Microsoft Intune and navigate to the Endpoint security blade. Under Endpoint Privilege Management go to Policies and create a new Elevation rules policy.

After going through the basics, fill in the detailed information about the application you are adding to the rule. This information can be collected using the EpmTools.dll.

Using this tool you can even extract publisher certificates from the file. These can be added to the reusable library.

Finally, fill in all the necessary details about the file.

Verify the configuration from a demo device. From the end-user perspective the Run with elevated access option should be visible, and the elevation request dialog should open.

For the Intune administrator, the request should appear in the Elevation requests tab almost immediately.

Verifying the Graph API Data

Before building the Logic App, confirm that elevation requests are visible through the Microsoft Graph API. Open the Graph Explorer and query deviceManagement/elevationRequests.

Make sure you are using the beta version of the API and that the DeviceManagementConfiguration.Read.All permission has been granted. Otherwise, the query returns a permission error.

How EPM Automation with Adaptive Cards Works

Our EPM automation solution bridges Microsoft Intune and Microsoft Teams by creating an automated workflow that:

• Polls for pending requests every 5 minutes using Microsoft Graph API
• Posts Adaptive Cards to a designated Teams channel with all request details
• Enables one-click approval or denial directly from Teams
• Updates the Adaptive Card to show the final decision and who made it

Architecture for EPM Automation

1. Logic App (Recurrence Trigger - every 5 minutes)
        │
        ├──> GET Microsoft Graph API
        │    /deviceManagement/elevationRequests
        │
        ├──> Filter requests with status = "pending"
        │
        ├──> For each pending request:
        │    └──> Post Adaptive Card to Teams channel
        │         ├──> Approve button
        │         └──> Deny button
        │
        └──> When button clicked:
             └──> POST approval/denial via Graph API
             └──> Update Adaptive Card with decision

Key Components of the EPM Automation Solution

Azure Logic App for EPM Automation

The Logic App serves as the orchestration engine for EPM automation. Using a recurrence trigger, it periodically queries the Microsoft Graph API for pending EPM elevation requests and processes each one by posting an interactive Adaptive Card to Teams.

Adaptive Cards for Approval Actions

The Adaptive Cards display comprehensive request information:

• Requester – Who’s requesting elevation
• Device Name – Which device the request originates from
• Application – The executable requesting elevation
• File Path – Where the application is located
• Publisher – The application’s publisher
• Justification – Why the user needs elevation

The card includes two action buttons: Approve (green) and Deny (red). Once clicked, the Adaptive Card updates to reflect the decision.

Managed Identity for Secure EPM Automation

Security is paramount. Instead of storing credentials or secrets, the EPM automation solution uses an Azure Managed Identity to authenticate to Microsoft Graph API. This eliminates secret management overhead and follows security best practices.

Microsoft Graph API Integration

The solution leverages the Graph API beta endpoint for EPM operations:

• GET /deviceManagement/elevationRequests – Retrieve pending requests
• POST /deviceManagement/elevationRequests/{id}/approve – Approve a request
• POST /deviceManagement/elevationRequests/{id}/deny – Deny a request

Infrastructure as Code with Bicep

The entire EPM automation solution is defined using Azure Bicep, making it reproducible and version-controllable. Here’s a simplified look at the main resources:

// Managed Identity for secure Graph API access
resource managedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
  name: '${logicAppName}-identity'
  location: location
  tags: tags
}

// Teams API Connection
resource teamsConnection 'Microsoft.Web/connections@2016-06-01' = {
  name: 'teams-connection'
  location: location
  properties: {
    displayName: 'Teams Connection for EPM Approval'
    api: {
      id: subscriptionResourceId('Microsoft.Web/locations/managedApis', location, 'teams')
    }
  }
}

// Logic App with workflow definition
resource logicApp 'Microsoft.Logic/workflows@2019-05-01' = {
  name: logicAppName
  location: location
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${managedIdentity.id}': {}
    }
  }
  properties: {
    definition: loadJsonContent('workflow.json').definition
    // ... parameters
  }
}

Deploying Your EPM Automation with Adaptive Cards

A PowerShell deployment script automates the entire setup process:

# Deploy with default settings
.\deploy.ps1

# Or customize the deployment
.\deploy.ps1 -ResourceGroupName "rg-epm-approval" -Location "westeurope"

# Preview changes first
.\deploy.ps1 -WhatIf

The script handles:

• Prerequisites validation (Azure CLI, Bicep, login status)
• Resource group creation
• Bicep template deployment
• Graph API permission assignment via Microsoft Graph PowerShell
• Teams connection authorization prompt

Required Graph API Permissions

The Managed Identity needs the following application permissions:

Cost of EPM Automation

One of the best aspects of this EPM automation solution is its cost-effectiveness:

Total: ~$2-6/month depending on the number of requests processed.

Security Best Practices

The EPM automation solution follows security best practices:

• No secrets stored – Managed Identity handles authentication
• Least privilege – Only required Graph permissions are assigned
• Audit trail – All decisions are logged in both Intune and Logic App run history
• Secure outputs – Sensitive data is protected in Logic App runs

Extending the EPM Automation Solution

The modular design allows for easy extensions:

• Email notifications – Add email alerts for high-priority requests
• ServiceNow integration – Create tickets for tracking purposes
• Conditional logic – Auto-approve requests from specific applications
• Escalation workflows – Escalate unanswered requests after a timeout

Conclusion

EPM automation with Adaptive Cards transforms the approval experience from a portal-centric task into a seamless Teams-based workflow. Approvers can now handle elevation requests without context-switching, leading to faster response times and improved user satisfaction.

The solution is cost-effective (under $10/month), secure (no secrets, managed identity), and easy to deploy (Infrastructure as Code with automated deployment scripts).

Ready to implement EPM automation with Adaptive Cards in your environment? Check out the full source code and detailed deployment instructions on GitHub!

Sources

• Endpoint Privilege Management overview | Microsoft Learn
• Azure Logic Apps documentation | Microsoft Learn
• Adaptive Cards documentation | Microsoft Learn
• Microsoft Teams Connectors | Microsoft Learn
• Microsoft Graph API | Microsoft Learn
• Azure Managed Identities | Microsoft Learn
• Azure Bicep documentation | Microsoft Learn

The post EPM Approval Workflow: Adaptive Cards and Logic Apps appeared first on Jens Du Four.

Overview of Windows 365 Restore Points

Using restore points in Windows 365 offers several advantages. Firstly, they provide a safety net for system recovery, ensuring that users can quickly restore their system to a working state in case of any issues.

Secondly, restore points help protect data by preserving user settings and installed applications. This means that even if a system crash occurs, users can recover their data without losing important information.

Additionally, restore points can be used to test new software or updates, allowing users to revert to a previous state if the changes cause problems.

How to adapt the automatic Windows 365 Restore Points in Microsoft Intune

By default Microsoft Intune will create several restore points for each and every Cloud PC.

The amount of restore points will never change and is two bi-weekly restore points and ten restore points you can adapt the recurrence of, this is done through a “User Setting”:

Once you are here, you can adapt the recurrence.

What about Storage Accounts?

Storage accounts play a crucial role in managing restore points for Windows 365. These provide a secure solution for storing large amounts of data, including your restore points.

By utilizing storage accounts, users can ensure that their restore points are safely stored and easily accessible when needed. One of the key benefits of using storage accounts is the ability to manage data efficiently, with options for redundancy and backup to protect against data loss.

Additionally, storage accounts offer flexibility, allowing users to configure permissions and access controls to suit their needs. To use storage accounts for restore points, users can integrate their Windows 365 environment with Azure, setting up containers and blobs to store the restore points securely.

This integration ensures that restore points are preserved long-term and can be retrieved quickly in case of system recovery needs.

Creating the right Azure Storage Account

There a few requirements to be met when creating a Storage Account for the Restore Points of the Cloud PC. They are listed below and we will go over the steps needed in Azure after these.

• Instance details
  • Region: Same region as Cloud PC is recommended because of performance. There is no restriction on which region you should choose.
  • Performance: Premium (supports hot access tier) or Standard (supports all access tiers).
  • Premium account type: Page blobs
• Security
  • Minimum TLS version: Version 1.2.
  • Confirm Allow blob anonymous access is disabled (the default).
  • Disable Enable storage account key access.
• Networking
  • Network access: Enable public access from all networks

Creating a manual Restore Point in Microsoft Intune

Once the Storage Account has been set up, you have the option to create a manual restore point in Microsoft Intune.

If this option is not visible, verify the requirements above as the Storage Account will not be visible if it does not meet these.

Conclusion

In summary, Windows 365 restore points are an essential feature. They provide a reliable way to recover from system issues, preserve user settings, and test new software or updates.

By creating and managing restore points effectively, users can safeguard their systems and minimize downtime.

Additionally, utilizing Azure Storage Accounts for long-term storage of restore points offers a scalable and secure solution for preserving these critical backups. I encourage everyone to take advantage of them in Windows 365 to enhance system management and data protection strategies.

If you want to further enhance your Windows 365 environment, check out Enabling AI Frontier Capabilities on Windows 365 with Intune or learn how to automate language packs in Adding Language Packs Using Proactive Remediations.

Sources

• Windows 365 documentation | Microsoft Learn
• Cloud PC restore points | Microsoft Learn
• Azure Storage Accounts | Microsoft Learn
• Access tiers for blob data | Microsoft Learn

The post Windows 365 Restore Points: A Guide to Long-Term Storage appeared first on Jens Du Four.