Configurare Conditional Access per Remote Help

Simone Termine

Introduzione

In un precedente articolo abbiamo visto Come configurare Remote Help in Microsoft Intune partendo dai prerequisiti del servizio, dall’attivazione nel tenant, dalla distribuzione dell’applicazione e dalla configurazione dei ruoli RBAC necessari agli operatori del supporto. Una volta completata questa base, il passaggio successivo è proteggere l’accesso a Remote Help con criteri coerenti con il modello di sicurezza dell’organizzazione.

Remote Help è infatti una funzionalità sensibile, perché permette al personale IT di visualizzare o controllare il dispositivo di un utente e, quando l’operatore dispone delle autorizzazioni necessarie, di interagire anche con richieste di elevazione UAC. Per questo motivo non basta stabilire chi può usare il servizio tramite RBAC: è importante controllare anche da quale contesto l’operatore accede, quale livello di autenticazione viene richiesto e se il dispositivo usato per fornire assistenza rispetta i criteri aziendali.

In questa guida vedremo come configurare Conditional Access per Remote Help in Microsoft Intune, creando il service principal RemoteAssistanceService, verificandone la presenza tra le Enterprise Application di Microsoft Entra ID e applicando una policy dedicata al servizio. L’obiettivo è aggiungere un livello di controllo basato su identità, dispositivo e condizioni di accesso, senza sostituire i permessi RBAC di Intune che continuano a determinare cosa può fare concretamente l’helper durante una sessione.

Perché usare Conditional Access con Remote Help

Remote Help è uno strumento sensibile perché permette a un operatore IT di visualizzare o controllare il dispositivo di un utente, gestire prompt UAC nei casi consentiti e intervenire direttamente su problemi applicativi o di configurazione. Anche se il servizio richiede l’accesso con account aziendali e utilizza i permessi RBAC di Intune, è buona pratica evitare che una sessione possa essere avviata da qualsiasi contesto, soprattutto se l’account dell’helper accede da un dispositivo non gestito, da una rete non prevista o senza un controllo di autenticazione forte.

Conditional Access consente di applicare decisioni di accesso basate su segnali come utente, gruppo, dispositivo, applicazione, posizione e rischio, richiedendo azioni come MFA, authentication strength o dispositivo conforme prima di concedere l’accesso alla risorsa protetta. Per Remote Help, questo significa poter applicare criteri più rigorosi agli utenti che offrono assistenza, ai gruppi di supporto o a specifici scenari operativi, senza dover creare regole generiche su tutte le applicazioni cloud.

Cosa configureremo in questa guida

Questa guida parte dal presupposto che Remote Help sia già stato valutato o configurato nel tenant Intune. Per la procedura completa di attivazione del servizio, distribuzione dell’app Remote Help, assegnazione dei ruoli e avvio di una sessione di assistenza, puoi fare riferimento alla guida Come configurare Remote Help in Microsoft Intune già pubblicata su Endpoint Ninja.

Qui ci concentreremo invece sulla protezione dell’accesso a Remote Help tramite Conditional Access. Configureremo il service principal necessario per rendere Remote Help selezionabile come risorsa nelle policy, creeremo una policy dedicata agli operatori del supporto e verificheremo il comportamento in modalità Report-only prima dell’attivazione in produzione.

La procedura copre la creazione del service principal RemoteAssistanceService, la verifica della relativa Enterprise Application in Microsoft Entra ID, la configurazione della policy di Conditional Access, la scelta dei controlli di accesso più adatti e le verifiche nei sign-in log. Restano invece fuori dalla guida la distribuzione del client Remote Help, la progettazione completa dei ruoli RBAC e la configurazione degli scope group, già trattate nell’articolo introduttivo.

Prerequisiti

Gli utenti coinvolti devono essere coperti dalle licenze appropriate, perché Remote Help richiede una licenza valida sia per chi offre assistenza sia per chi la riceve. Nei tenant non ancora interessati dagli aggiornamenti di packaging 2026, questo può significare una licenza Remote Help add-on o Intune Suite; nei tenant Microsoft 365 E3 o Microsoft 365 E5 idonei, invece, Remote Help potrebbe già risultare disponibile come parte dei nuovi entitlement inclusi nel piano, in base allo stato del rollout e alle comunicazioni ricevute nel Message Center.

Per la policy di Conditional Access è necessario disporre di Microsoft Entra ID P1 o di un piano che includa Conditional Access. Le policy basate sul rischio richiedono invece Microsoft Entra ID P2; quindi, in questa guida useremo controlli più comuni e facilmente applicabili, come MFA e dispositivo conforme.

Ruoli necessari

Per completare la configurazione è importante distinguere tra i permessi necessari per preparare la risorsa in Microsoft Entra ID, quelli necessari per creare la policy di Conditional Access e quelli richiesti agli operatori che useranno Remote Help. La creazione del service principal RemoteAssistanceService richiede un account con un ruolo in grado di creare e gestire le Enterprise Application, come Application Administrator o Cloud Application Administrator; l’uso di Global Administrator funziona, ma dovrebbe essere limitato a scenari di bootstrap o amministrazione eccezionale, perché assegna privilegi molto più ampi di quelli necessari per questa attività.

La creazione e la modifica della policy di Conditional Access richiedono invece un ruolo amministrativo dedicato alla gestione delle policy, preferibilmente Conditional Access Administrator. Anche Security Administrator può gestire configurazioni di sicurezza in Microsoft Entra ID, incluse le policy di Conditional Access, ma in un modello least privilege è preferibile assegnare il ruolo più specifico possibile all’attività da svolgere.

Per gli operatori del supporto, Conditional Access non sostituisce in alcun modo i permessi RBAC di Intune. Un helper può superare correttamente la policy di accesso, completare MFA o accedere da un dispositivo conforme, ma non potrà offrire assistenza se non dispone anche di una role assignment Intune con i permessi Remote Help corretti e con scope coerente sugli utenti o sui dispositivi da assistere. In pratica, per offrire assistenza servono Remote tasks > Offer remote assistance, Remote assistance connectors > Read e almeno uno dei permessi dell’area Remote Help app, come View screen, Take full control, Elevation o Unattended control, in base al livello di supporto che si vuole concedere.

Preparare un gruppo pilota

Prima di applicare la policy a tutti gli operatori del supporto, è preferibile creare un gruppo pilota dedicato, ad esempio GRP-CA-RemoteHelp-Helpers-Pilot, includendo solo alcuni utenti IT che usano realmente Remote Help e che possono validare scenari di assistenza remota in condizioni controllate. In questa fase l’obiettivo non è coprire subito tutto il service desk, ma verificare che la policy venga valutata correttamente, che i controlli scelti siano compatibili con il modo in cui gli helper lavorano e che eventuali requisiti come MFA o dispositivo conforme non blocchino scenari legittimi di supporto.

Il gruppo pilota dovrebbe includere operatori con ruoli diversi, ad esempio supporto di primo livello, supporto avanzato e amministratori che possono eseguire sessioni con privilegi più elevati, in modo da testare il comportamento della policy su casi d’uso realistici. Durante questa fase è utile raccogliere evidenze nei sign-in log di Microsoft Entra ID, verificare quale applicazione viene intercettata dalla policy, controllare l’esito dei controlli di accesso e correggere eventuali esclusioni, condizioni o gruppi di destinazione prima di estendere il criterio a un numero maggiore di utenti.

La policy dovrebbe essere inizialmente configurata in modalità Report-only, così da osservare l’impatto sui sign-in senza applicare subito blocchi o requisiti vincolanti. Questo passaggio è particolarmente importante quando si introducono controlli come Require device to be marked as compliant, perché l’accesso può dipendere dal modo in cui il dispositivo dell’helper viene riconosciuto da Microsoft Entra ID e dallo stato di conformità riportato da Intune.

Creare il service principal Remote Assistance Service

Per rendere Remote Help selezionabile come risorsa in Conditional Access, è necessario creare nel tenant il service principal del servizio Remote Assistance Service. La procedura si esegue da PowerShell usando il modulo Microsoft Graph, con il permesso Application.ReadWrite.All.

Per procedere, apriamo PowerShell come amministratore ed eseguiamo:

Install-Module Microsoft.Graph -Scope CurrentUser

Connettiamoci a Microsoft Graph con lo scope richiesto e seguiamo le istruzioni per l’autenticazione recandoci alla pagina https://login.microsoft.com/device e inserendo il device code che appare nel terminale

Connect-MgGraph -TenantId "<tenant-id-or-domain>" -Scopes "Application.ReadWrite.All" -UseDeviceCode -NoWelcome

Procediamo con l’autenticazione

Al prompt “Si sta provando ad accedere a Microsoft Graph Command Line Tools?” Facciamo click su Continua

Al termine della procedura, possiamo chiudere la finestra del browser

A questo punto creiamo il service principal usando l’App ID documentato per Remote Assistance Service

New-MgServicePrincipal -AppId "1dee7b72-b80d-4e56-933d-8b6b04f9a3e2"

L’output dovrebbe mostrare un service principal con display name RemoteAssistanceService e App ID 1dee7b72-b80d-4e56-933d-8b6b04f9a3e2.

Al termine, disconnettiamoci dalla sessione Graph:

Disconnect-MgGraph

Verificare la Enterprise Application in Microsoft Entra

Dopo aver creato il service principal, accedi al Microsoft Entra admin center e rechiamoci in Entra ID > Enterprise applications > All applications.

Rimuoviamo eventuali filtri predefiniti che limitano la visualizzazione delle applicazioni e cerca RemoteAssistanceService. Aprendo il dettaglio dell’applicazione, verifica che l’Application ID corrisponda a 1dee7b72-b80d-4e56-933d-8b6b04f9a3e2. Questa verifica è importante perché la policy di Conditional Access dovrà essere assegnata a questa risorsa e non a un’app generica o a un’applicazione creata manualmente con nome simile.

Creare la policy di Conditional Access per Remote Help

A questo punto puoi creare la policy dedicata a Remote Help. La configurazione può essere eseguita dal Microsoft Entra admin center oppure dal collegamento Conditional Access presente nel Microsoft Intune admin center; in entrambi i casi la policy viene gestita da Microsoft Entra Conditional Access. Rechiamoci in Microsoft Entra admin center > Entra ID > Conditional Access > Policies > New policy

Assegniamo un nome alla policy, ad esempio CA – Remote Help – Require MFA and compliant device. Nella sezione Users, seleziona il gruppo pilota degli helper, evitando di partire subito da tutti gli utenti o da tutti i ruoli amministrativi. In una fase successiva potrai estendere la policy ad altri gruppi di supporto, ma durante il test è preferibile avere un perimetro limitato e facilmente controllabile.

Nella sezione Target resources, seleziona Resources (formerly cloud apps), scegli Include > Select resources > Select specific resources e cerca RemoteAssistanceService. Seleziona la risorsa con App ID 1dee7b72-b80d-4e56-933d-8b6b04f9a3e2, quindi conferma la selezione. Le policy di Conditional Access permettono di proteggere risorse specifiche e, per una policy dedicata a Remote Help, l’approccio più pulito è includere direttamente la risorsa del servizio invece di applicare il criterio a tutte le applicazioni cloud.

Scegliere i controlli di accesso di Conditional Access per Remote Help

La scelta dei controlli dipende dal livello di rischio e dal modello operativo dell’organizzazione. Per un primo scenario è possibile richiedere MFA agli helper che accedono a Remote Help, perché il supporto remoto è un’attività sensibile e dovrebbe richiedere un controllo forte sull’identità dell’operatore.

In alternativa, o in aggiunta, si può richiedere che il dispositivo sia marcato come conforme da Intune. Questo controllo è utile quando si vuole evitare che un helper possa avviare o gestire sessioni di assistenza da un dispositivo personale, non gestito o non conforme alle policy aziendali. Il controllo Require device to be marked as compliant usa le informazioni di conformità inviate da Intune a Microsoft Entra ID per prendere la decisione di accesso.

Una configurazione iniziale ragionevole può essere:

• Grant access
  
• Require multifactor authentication
  
• Require device to be marked as compliant
  
• Require all the selected controls
  

Questa scelta è più restrittiva rispetto alla sola MFA e va validata con attenzione, perché può bloccare gli helper che lavorano da dispositivi non enrolled o non conformi. Negli ambienti dove il service desk deve poter operare anche da postazioni dedicate, jump host o Privileged Access Workstation, conviene prima verificare che tali dispositivi siano correttamente registrati, gestiti e conformi.

Abilitare la policy per Remote Help in Report-only

Prima di attivare la policy, imposta Enable policy su Report-only e salva la configurazione. In questa modalità Conditional Access valuta la policy durante il sign-in, ma non applica i controlli e non blocca l’accesso; i risultati vengono registrati nei sign-in log, dove è possibile verificare se la policy sarebbe stata applicata, non applicata o bloccante.

Dopo alcuni test reali con gli account pilota, passiamo a Microsoft Entra admin center > Entra ID > Monitoring & health > Sign-in logs. Apriamo gli eventi relativi agli utenti coinvolti e controlliamo le schede Conditional Access e Report-only. L’obiettivo è verificare che la policy intercetti l’accesso a RemoteAssistanceService, che i controlli scelti siano valutati correttamente e che non compaiano blocchi inattesi dovuti a condizioni troppo restrittive.

Esperienza utente e comportamento atteso

Quando la policy viene portata da Report-only a On, gli utenti inclusi nel target dovranno soddisfare i controlli configurati per accedere a Remote Help. Se la policy richiede MFA, l’helper dovrà completare il metodo di autenticazione previsto; se richiede un dispositivo conforme, l’accesso sarà consentito solo quando il dispositivo usato per l’accesso risulta conforme in Microsoft Entra ID e Intune.

L’esperienza effettiva dipende dai controlli selezionati, dal tipo di dispositivo e dalla modalità con cui l’utente accede a Remote Help. Per questo motivo è importante testare la policy con più scenari reali, ad esempio helper da dispositivo aziendale conforme, helper da dispositivo non conforme, accesso da rete esterna e accesso da una postazione di supporto dedicata.

Portare la policy Conditional Access per Remote Help in produzione

Dopo aver validato i log e corretto eventuali problemi, possiamo modificare la policy e impostare Enable policy su On. La distribuzione dovrebbe seguire un modello progressivo: prima il gruppo pilota, poi il team di supporto principale e infine eventuali gruppi aggiuntivi che usano Remote Help in modo regolare. È opportuno documentare la policy nel modello operativo del service desk, specificando quali condizioni sono richieste, quali account o gruppi sono esclusi, quale comportamento aspettarsi in caso di dispositivo non conforme e come aprire una richiesta interna quando un helper non riesce ad avviare una sessione.

Troubleshooting

Se RemoteAssistanceService non compare tra le risorse selezionabili in Conditional Access, verifica che il service principal sia stato creato correttamente e che la ricerca in Enterprise Applications non sia limitata da filtri predefiniti. Puoi controllare la presenza dell’oggetto anche da PowerShell con

Connect-MgGraph -Scopes "Application.Read.All" 
Get-MgServicePrincipal -Filter "appId eq '1dee7b72-b80d-4e56-933d-8b6b04f9a3e2'" | Select-Object DisplayName, Id, AppId 
Disconnect-MgGraph

Se la policy non viene valutata durante il test, controlla che l’utente sia incluso nel gruppo target, che non sia escluso da altre configurazioni, che la risorsa selezionata sia effettivamente RemoteAssistanceService e che l’evento nei sign-in log corrisponda al flusso di accesso a Remote Help.

Se l’accesso viene bloccato quando richiedi un dispositivo conforme, verifica lo stato del dispositivo in Intune e Microsoft Entra, controlla che l’utente stia accedendo da un dispositivo registrato correttamente e assicurati che il browser o l’app stiano presentando il device identity necessario per soddisfare il controllo. Il grant control “Require device to be marked as compliant” dipende dal fatto che Microsoft Entra ID possa identificare correttamente il dispositivo e ricevere lo stato di conformità da Intune.

Se Remote Help risulta abilitato ma gli utenti non riescono ancora ad avviare sessioni, considera anche il tempo di propagazione delle licenze o delle trial license, che può richiedere da 30 minuti a 8 ore, e verifica che l’app Remote Help sia installata e aggiornata sui dispositivi coinvolti.

Best practice per Remote Help

Conditional Access per Remote Help dovrebbe essere progettato come parte del modello operativo del supporto remoto, non come una singola policy aggiunta a fine della configurazione di questa feature. La protezione più efficace parte dagli operatori che offrono assistenza, perché sono loro a poter visualizzare lo schermo dell’utente, prendere il controllo della sessione o gestire scenari con privilegi elevati; per questo motivo è consigliabile applicare controlli più rigorosi agli helper, richiedendo almeno MFA o authentication strength adeguata al livello di rischio e, dove possibile, l’uso di dispositivi aziendali gestiti e conformi.

La separazione dei livelli di supporto è uno degli aspetti più importanti da definire prima del rollout. Gli operatori di primo livello possono essere limitati alla sola visualizzazione dello schermo, mentre il controllo completo, l’elevation e gli scenari unattended dovrebbero essere riservati a gruppi più ristretti, con assegnazioni RBAC dedicate e scope coerenti con utenti, dispositivi o aree organizzative effettivamente gestite. In questo modo Conditional Access controlla le condizioni con cui l’helper accede al servizio, mentre Intune RBAC definisce in modo puntuale cosa quell’operatore può fare durante la sessione.

Negli ambienti più strutturati è opportuno affiancare la policy Conditional Access a gruppi separati per livello di supporto, Privileged Access Workstation o postazioni dedicate per gli operatori più privilegiati, assegnazioni temporanee tramite PIM dove disponibili e una revisione periodica dei permessi concessi. Questa impostazione riduce il rischio che Remote Help venga usato da dispositivi non controllati o da account con privilegi eccessivi rispetto al ruolo dell’operatore, mantenendo allo stesso tempo un’esperienza di supporto efficace per gli scenari quotidiani.

Il monitoraggio deve diventare parte del processo e non un’attività occasionale. Dopo l’attivazione della policy, è importante controllare regolarmente i sign-in log di Microsoft Entra ID, gli eventi legati a Remote Help e gli errori di accesso generati dai controlli di Conditional Access, così da individuare configurazioni troppo permissive, blocchi non previsti o tentativi di accesso da contesti non coerenti con le policy aziendali. Le evidenze raccolte dovrebbero essere usate per aggiornare gruppi, esclusioni, controlli di accesso e permessi RBAC, soprattutto quando cambiano il modello di supporto o l’organizzazione del service desk.

Conclusioni

Configurare Conditional Access per Remote Help permette di rafforzare la sicurezza delle sessioni di assistenza remota, applicando controlli mirati alla risorsa RemoteAssistanceService invece di affidarsi solo a criteri generici o ai permessi RBAC. La procedura richiede pochi passaggi tecnici, ma va pianificata con attenzione perché una policy troppo restrittiva può bloccare gli operatori di supporto proprio quando devono intervenire su un dispositivo.

Il modello consigliato è partire da un gruppo pilota, creare il service principal con Microsoft Graph e PowerShell, selezionare RemoteAssistanceService come risorsa della policy, applicare controlli coerenti con il rischio e validare tutto in modalità Report-only prima dell’attivazione. In questo modo Remote Help resta uno strumento efficace per il supporto IT, ma viene usato dentro un perimetro di accesso più controllato ed in linea con i principi Zero Trust.