Script personalizzato: distribuzione dell’agente NinjaOne tramite un’attività pianificata immediata di AD tramite GPO

Argomento

Questo articolo spiega come e in quali scenari utilizzare lo script di automazione " NinjaOne Agent Deployment by AD Immediate Scheduled Task GPO " presente nella NinjaOne Automation Template Library.

Ambiente

• NinjaOne Endpoint management
• Microsoft Windows

Descrizione

NinjaOne offre una funzionalità di individuazione e distribuzione di Active Directory (AD) che semplifica la distribuzione dell’agente in ambienti controllati da dominio AD. Per ulteriori informazioni su questa opzione, consultare NinjaOne Endpoint Management: Individuazione e distribuzione di Active Directory.

In alternativa, è possibile utilizzare un modello di distribuzione dell’agente basato sul dominio che utilizza un'attività pianificata immediata tramite un Oggetto Criteri di Gruppo (GPO). L'utilizzo di questo modello potrebbe essere più appropriato se si verifica almeno uno dei seguenti scenari:

• È necessario distribuire l’agente su laptop remoti e dispositivi simili che si connettono alla rete tramite una rete privata virtuale (VPN).
• Si dispone di un dominio di grandi dimensioni con un numero elevato di unità organizzative (OU) contenenti gli oggetti computer, oppure è necessario effettuare la distribuzione su più OU contemporaneamente.
• Si desidera distribuire l’agente agli oggetti computer in base all’appartenenza a gruppi di sicurezza anziché per OU.
• Si desidera registrare gli oggetti computer in diverse OU o gruppi di sicurezza in diverse posizioni all’interno di NinjaOne.
• È necessario distribuire l’agente agli oggetti computer con una frequenza superiore a una volta al giorno, ogni settimana o ogni mese.
• I vostri oggetti computer passano attraverso un Proxy per connettersi a Internet.
• Non è possibile integrare NinjaOne nel proprio Controller del dominio (DC) per motivi di sicurezza.
• Non si dispone di accesso diretto al DC e si amministra invece il dominio tramite gli Strumenti di amministrazione remota del server (RSAT).
• È necessario effettuare la distribuzione contemporaneamente sia sui server che sulle workstation.
• È necessario effettuare la distribuzione agli oggetti computer in segmenti di rete diversi, indipendentemente da quello in cui risiede il DC.

Per utilizzare un modello di distribuzione dell’agente basato sul dominio con GPO, accedi allo script di automazione disponibile nella Libreria dei modelli di NinjaOne denominato “Distribuzione dell’agente NinjaOne tramite GPO con attività pianificata immediata di AD”. Consulta la Libreria delle automazioni: Script modello per i passaggi di navigazione.

Indice

Selezionare un argomento per ulteriori informazioni:

• Funzionalità e vantaggi aggiuntivi
• Prerequisiti, campi personalizzati e valori delle variabili di script
  • Campi personalizzati utilizzati per l’automazione
  • Variabili di script utilizzate per l'automazione
• Processi degli script di automazione
  • Fase uno: preparativi
  • Fase due: configurazione della selezione dell’ambito di destinazione
  • Fase tre: Crittografia delle password Proxy
  • Fase 4: Creazione del GPO principale e dei file di supporto
  • Fase 5: Processo dello script GPO
• Come modificare il campo personalizzato dell'elenco dei destinatari del GPO di NinjaOne
• Come ottenere l'ID del token di posizione
• Risorse aggiuntive

Funzionalità e vantaggi aggiuntivi

Oltre ai casi d'uso descritti nella sezione "Descrizione " di questo articolo, questo script offre le seguenti funzionalità e vantaggi:

• Il GPO generato dall’automazione è un’attività programmata a esecuzione immediata. L'attività verrà applicata immediatamente al successivo aggiornamento automatico o manuale dei Criteri di gruppo, quindi non è necessario riavviare gli endpoint per distribuire l'agente NinjaOne. L'attività verrà riapplicata continuamente a ogni successivo aggiornamento automatico o manuale dei Criteri di gruppo fino a quando l'agente non sarà stato distribuito con successo. L'attività si applicherà anche ai dispositivi remoti, come i laptop, ogni volta che si connettono alla rete, tramite VPN o in altro modo, e successivamente al DC, senza la necessità di una VPN sempre attiva.
• Il processo scaricherà automaticamente il file di installazione generico dell’agente dalla piattaforma NinjaOne su cui è registrato l’endpoint che lo esegue e ne verificherà la firma digitale.
• Questa automazione è pienamente compatibile con gli ambienti Microsoft Entra Domain Services e non è necessario mantenere un server di gestione sempre online. Salverà tutti i file richiesti dal GPO nell’archivio dei Criteri di gruppo.
• Si noti che questo script non è compatibile con Microsoft Entra ID o Microsoft Intune. Per le istruzioni sulla distribuzione tramite Intune, consultare Installazione agente NinjaOne: Distribuzione tramite Microsoft Intune.
• Ove applicabile, NinjaOne trasmetterà la password del proxy all’automazione tramite un campo personalizzato sicuro e la memorizzerà esclusivamente in forma criptata, limitatamente all’attività pianificata immediata sul DC. Il GPO trasmetterà la password criptata all’endpoint come argomento dello script PowerShell, pertanto non verrà mai memorizzata sull’endpoint né in alcun altro luogo in testo in chiaro.
• Lo script eseguito dal GPO presenta le seguenti caratteristiche:
  • Rileverà se il servizio dell’agente NinjaOne è installato sull’endpoint e tenterà di installare l’agente solo se il servizio non viene trovato. Lo script rileverà e rimuoverà eventuali residui di precedenti installazioni non riuscite o disinstallazioni per massimizzare le probabilità di successo della distribuzione.
  • Verificherà l’intestazione del file di installazione dell’agente corrente proveniente da NinjaOne (scaricherà solo l’intestazione, non l’intero file) per determinare se è disponibile un aggiornamento e, in tal caso, lo scaricherà e lo verificherà. Ciò garantisce che i vostri endpoint non installino un agente obsoleto per poi aggiornarsi immediatamente.
  • Facoltativamente, può registrare eventi nel Log evento di Windows per facilitare la risoluzione dei problemi e la diagnosi delle distribuzioni non riuscite.
• Come misura di sicurezza, lo script di automazione memorizzerà i riferimenti alle unità organizzative (OU) o ai gruppi di sicurezza utilizzati per determinare l’ID del token di posizione come identificatori univoci globali (GUID), anziché come nomi in testo semplice.

Prerequisiti, campi personalizzati e valori delle variabili di script

L’automazione “Distribuzione dell’agente NinjaOne tramite GPO dell’attività pianificata immediata di AD ” presuppone che abbiate attivato la tokenizzazione degli agenti, poiché utilizzerà gli ID token per determinare la posizione a cui gli endpoint si registreranno. Per ulteriori informazioni sulla tokenizzazione degli agenti, consultate la sezione “Piattaforma NinjaOne: Tokenizzazione degli agenti ”.

A seconda dei propri privilegi di accesso all’interno del dominio, è possibile eseguire questo script di automazione su qualsiasi DC o su qualsiasi computer aderente al dominio su cui siano installate e attive le funzionalità facoltative di Windows RSAT Active Directory e RSAT Group Policy.

Se la configurazione del dominio impedisce all’account di sistema del DC locale di apportare modifiche a livello di dominio, eseguire l’automazione utilizzando credenziali con i privilegi appropriati. Tali modifiche includono la creazione e l’importazione di GPO, la lettura di oggetti AD e la lettura e la scrittura nella condivisione del volume di sistema (SYSVOL). Per ulteriori informazioni sull’uso delle credenziali in NinjaOne, consultare NinjaOne Endpoint Management: Scambio di credenziali.

Se si intende leggere da o scrivere in campi personalizzati, è necessario eseguire l’automazione con credenziali che possano essere elevate per farlo.

Lo script di automazione scriverà i file necessari nella cartella {[Il proprio GUID GPO]} all’interno della cartella "Policies" della condivisione SYSVOL. Questa condivisione verrà replicata automaticamente su tutti gli altri DC senza necessità di funzionalità Windows aggiuntive come la replica DFS (Distributed File System), pertanto il DC su cui lo si esegue è arbitrario per i domini con più DC.

Campi personalizzati utilizzati per l’automazione

Lo script di automazione può utilizzare uno o tutti i seguenti campi personalizzati. Questi campi personalizzati sono facoltativi, a seconda delle vostre esigenze.

Per le distribuzioni su larga scala, può essere utile compilare il campo personalizzato "ID token di ubicazione NinjaOne " su larga scala utilizzando un file di importazione in formato CSV (valori separati da virgola). È possibile trovare le istruzioni per farlo nella nostra pagina Script Share: Importazione di dati da foglio di calcolo nei campi personalizzati (API) (pagina della comunità Dojo/Community).

Variabili di script utilizzate per l’automazione

Lo script di automazione utilizza le seguenti variabili di script:

Processo di elaborazione dello script di automazione

Questa sezione descrive le fasi del flusso di lavoro relative al processo dello script di automazione.

Fase uno: preliminari

Lo script inizia con la convalida di tutti i prerequisiti e fallirà immediatamente se uno qualsiasi di essi non viene soddisfatto.

Gli esempi includono, ma non si limitano a:

• Convalida delle variabili di script
• Verifica che l'endpoint sia membro del dominio e che sia un DC oppure un altro computer con RSAT per AD e GPO installati e attivi
• Verifica che l'account che esegue lo script sia attivo e possa scrivere su SYSVOL

Lo script otterrà quindi l’elenco di tutti gli oggetti computer e recupererà tutte le unità organizzative (OU) e i gruppi di sicurezza che li contengono, filtrando quelli che contengono solo oggetti utente. Lo script recupererà quindi l’ID del token di posizione dalla variabile dello script o dal campo personalizzato.

Fase due: configurazione della selezione dell’ambito di destinazione

La fase successiva dipende dall’ambito di destinazione. Per le unità organizzative (OU) e i gruppi di sicurezza, se è la prima volta che si esegue lo script oppure se si seleziona “Ricrea elenco di destinazione”, lo script popolerà il campo personalizzato “Elenco di destinazione GPO di NinjaOne” con l’elenco dei nomi delle OU o dei gruppi di sicurezza insieme all’ID del token di posizione fornito, dopodiché si interromperà. Lo script restituirà i nomi canonici delle OU anziché i loro nomi distintivi, in modo che siano più facili da comprendere.

A questo punto, è possibile modificare l’ambito di distribuzione e, facoltativamente, controllare in quali posizioni registrare gli oggetti computer in ciascuna unità organizzativa o gruppo di sicurezza. Per le istruzioni, fare riferimento alla sezione di questo articolo intitolata “Come modificare il campo personalizzato ‘Elenco destinatari GPO NinjaOne’”.

Fase tre: Crittografia della password del Proxy

Se sono stati configurati dettagli del proxy che includono una password, lo script leggerà il campo personalizzato protetto e crittograferà la stringa con lo stesso metodo utilizzato per la crittografia locale.

Fase quattro: creazione del GPO principale e dei file di supporto

Lo script di automazione esegue le azioni seguenti durante la fase quattro:

1. Lo script di automazione eliminerà qualsiasi GPO di distribuzione preesistente con lo stesso nome per rimuovere tutti i collegamenti preesistenti.
2. Lo script creerà un nuovo GPO e personalizzerà il modello incluso nello script di automazione per il dominio e il DC su cui è in esecuzione.
3. Lo script importerà il contenuto personalizzato del GPO nel GPO appena creato. Lo script indirizzerà e collegherà il GPO di conseguenza, alla radice del dominio, a livello di unità organizzativa (OU), alla radice del dominio con filtraggio del gruppo di sicurezza dell’attività programmata immediata, oppure non lo collegherà affatto.

4. Una volta che l’oggetto GPO è pronto, collegato e filtrato secondo necessità, lo script di automazione genererà lo script che l’oggetto GPO attiverà al momento dell’aggiornamento della politica, personalizzato in base al dominio e al DC. Lo script viene automaticamente personalizzato secondo le esigenze, includendo la registrazione degli eventi di Windows, il targeting a livello di Unità organizzativa (OU) o di gruppo di sicurezza, i controlli di aggiornamento degli agenti e altre specifiche.

Lo script verrà salvato automaticamente nella cartella del GPO.

5. Per il targeting su OU e gruppi di sicurezza, lo script di automazione scriverà nella cartella GPO un file di riferimento CSV contenente i GUID di destinazione e i corrispondenti GUID di posizione di NinjaOne. Se è stata selezionata l’opzione “Elenco computer di output”, lo script scriverà anche l’elenco delle OU e dei gruppi di sicurezza di destinazione nell’ambito di applicazione e i rispettivi oggetti computer nel campo personalizzato “Elenco nomi host GPO” di NinjaOne.

6. Lo script di automazione scaricherà il file di installazione dell’agente nella cartella GPO e verificherà la firma digitale prima di visualizzare un messaggio con il risultato finale.

Fase cinque: elaborazione dello script GPO

Quando l’aggiornamento automatico o manuale dei Criteri di gruppo attiva lo script, quest’ultimo verificherà prima se il servizio dell’agente NinjaOne esiste e, in caso affermativo, terminerà immediatamente l’esecuzione.

Se il servizio dell’agente NinjaOne non esiste, lo script rimuoverà quindi tutti i potenziali residui di qualsiasi tentativo di installazione o disinstallazione fallito in precedenza, per massimizzare le probabilità di successo dell’installazione.

Il passaggio successivo dipende dalla configurazione dell’ambito di destinazione:

• Per il targeting per OU, lo script recupererà il GUID dell’OU dell’endpoint e lo confronterà con quelli presenti nel file CSV di riferimento. Questo confronto determinerà l’ID del token di posizione NinjaOne.
• Per il targeting per gruppo di sicurezza, lo script recupererà i GUID dei gruppi di sicurezza di cui l’endpoint è membro e li confronterà con quelli presenti nel file CSV di riferimento. Questo confronto determinerà l’ID del token di posizione NinjaOne.
• Per il targeting alla radice del dominio o in assenza di targeting, l’ID del token di posizione fornito dalla variabile dello script o dal campo personalizzato è già hardcoded.

L’azione successiva che lo script GPO eseguirà dipende dalla piattaforma da cui è stata avviata l’automazione. A seconda dei casi, lo script GPO copierà il file di installazione dell’agente dal controller di dominio oppure verificherà la data del file di installazione dell’agente attualmente disponibile su NinjaOne dall’intestazione. Se la data del file di installazione disponibile su NinjaOne è la stessa di quella del file presente sul controller di dominio, lo script copierà il file di installazione dell’agente dal controller di dominio. Tuttavia, se la data del file di installazione disponibile su NinjaOne è successiva a quella presente sul Controller del dominio, lo script scaricherà il file di installazione dell’agente più recente e ne verificherà la firma digitale. Se il download o la verifica della firma digitale falliscono, lo script ricorrerà alla copia del file di installazione dal Controller del dominio; in caso di esito positivo, lo script utilizzerà il file più recente.

Successivamente, lo script installerà l’agente, imposterà il dispositivo affinché si registri nella posizione corretta, determinata dall’ID del token di posizione, ed eliminerà la copia locale.

Se è stata fornita una configurazione proxy, lo script la imposterà al momento dell’installazione dell’agente. Se la configurazione proxy includeva una password, questa verrà passata come stringa criptata in qualità di argomento dello script, in modo che non venga mai memorizzata sull’endpoint.

Infine, lo script attenderà la conferma dell’avvenuta registrazione sulla piattaforma NinjaOne, che potrebbe essere non riuscita se l’ID del token di posizione è non valido. Dopo aver confermato lo stato della registrazione, lo script terminerà l’esecuzione.

Se è stata selezionata l’opzione Abilita registrazione eventi, lo script scriverà gli eventi nel log evento Applicazione con l’origine NinjaOneGPODeployment durante l’intero processo. Nella seguente Figura 6, si noti l’origine NinjaOneGPODeployment nel log evento Applicazione:

Come modificare il campo personalizzato "Elenco destinazioni GPO di NinjaOne"

È possibile modificare il campo personalizzato “Elenco destinatari GPO di NinjaOne ” dopo la prima esecuzione dello script, dopo aver ricreato l’elenco dei destinatari o in qualsiasi altro momento successivo.

Per rimuovere un'unità organizzativa (OU) o un gruppo di sicurezza dall'ambito, eliminare la riga utilizzando l'opzione "Cancella la riga " nel menu delle azioni. Fare riferimento alla Figura 8 per un esempio illustrato.

È necessario apportare almeno una modifica all’elenco iniziale dei destinatari quando si selezionano le OU come destinatarie, eliminando una o più righe dall’ambito o modificando uno o più ID dei token di posizione.

L'esecuzione dell'automazione con tutte le unità organizzative (OU) con lo stesso ID del token di posizione avrà lo stesso risultato della selezione della radice del dominio; pertanto, in questo scenario, l'automazione fallirà.

Si noti che questo è uno scenario diverso dall’individuazione di ogni gruppo di sicurezza senza modificare alcun ID del token di posizione, poiché potrebbero esserci casi in cui non tutti gli oggetti computer siano membri di un gruppo.

Per ogni OU o gruppo di sicurezza di cui si desidera modificare la posizione di destinazione, sarà necessario il rispettivo ID del token di posizione.

Come ottenere l’ID del token di posizione

Per individuare l’ID del token di posizione in NinjaOne, procedere come segue:

1. Accedere alla dashboard di sistema di NinjaOne e aprire la scheda " Dispositivi ". Selezionare "Agent-Installer".
2. Copiare l’ID token relativo alla posizione desiderata dalla colonna "Token " e incollarlo nella colonna "ID token " della riga corrispondente nell’elenco di destinazione. L’ID token scelto deve supportare un ruolo del dispositivo basato su Windows; in caso contrario, tali endpoint non riusciranno a registrarsi sulla piattaforma.

3. Al termine, salvare le modifiche.
4. Esegui nuovamente lo script di automazione. Lo script verificherà le modifiche e fallirà se si verifica una o più delle seguenti condizioni:
   • Hai eliminato la riga di intestazione, la riga finale o tutte le righe di destinazione.
   • Si stanno selezionando le unità organizzative (OU) come destinazione, ma non è stata apportata alcuna modifica al campo personalizzato.
   • Hai impostato " Ambito di destinazione " su " Gruppi di sicurezza", ma il campo personalizzato contiene unità organizzative (OU), o viceversa.
   • Hai modificato i nomi delle unità organizzative o dei gruppi di sicurezza in modo che non corrispondano più al DC.
   • Uno o più oggetti computer sono presenti in più gruppi di sicurezza con ID token di posizione in conflitto.
   • Qualsiasi ID token è registrato in un formato GUID non valido.

Quando lo script di automazione convalida il campo personalizzato, passerà alla fase tre.

Risorse aggiuntive

Per ulteriori informazioni sull’automazione dei flussi di lavoro di NinjaOne e sulla personalizzazione dell’istanza, consultare i seguenti articoli:

• Scripting, Automazione, CLI: Catalogo delle risorse
• Campi personalizzati di NinjaOne: Guida rapida