Automazione operazioni su client Active Directory tramite scripts: considerazioni e hardening

In un’infrastruttura Active Directory vi sono molti casi in cui è necessario eseguire sui client determinate attività che richiedono l’esecuzione di script sui client. Escludendo gli scripts di accesso elenco di seguito alcuni esempi:

• Installazione e configurazione di software che non prevendono il package d’installazione in formato msi o che richiedono configurazioni post installazione non realizzabili tramite le Group policy Preferences (ad esempio la creazione o la modifica in modo non predefinito)
• Raccolta di dati specifici sui client e invio tramite mail o mediante memorizzazione su share
• Esecuzione si specifiche attività sui client in conseguenza a determinati eventi (ad esempio per ripristinare funzionalità in seguito a errori o impostare configurazioni in modo dinamico)

Per eseguire scripts sui sui client si può utilizzare un’operazione pianificata esattamente come fa nativamente il sistema operativo per eseguire svariate attività di manutenzione, a riguardo si veda Automatic maintenance (Task Scheduler) – Win32 apps.

Per creare sui client un’operazione pianificata è possibile utilizzare una Group Policy Preference, a riguardo si veda Working with Control Panel Settings Preference Items Using the GPMC. Durante la creazione della Group Policy Preference è preferibile utilizzare l’Action Update per evitare che la ricreazione dell’operazione pianificata che avviene ogni volta che vengono applicate le Group Policy impedica l’esecuzione dell’operazione pianificata :

Replace Delete and re-create scheduled tasks for users or computers. The net result of the Replace action is to overwrite all existing settings associated with the task. If the task does not exist, then the Replace action creates a new scheduled task.

Update Modify the settings of an existing scheduled task for users or computers. This action differs from Replace because it only updates settings that are defined within the preference item. All other settings remain as configured in the task. If the task does not exist, then the Update action creates a new scheduled task.

Lo script che viene eseguito dall’operazione pianificata può essere gestito con approcci differenti, ma occorre tenere presente delle limitazioni e delle problematiche di sicurezza di ciascun approccio.

Approccio 1: Esecuzione di uno script memorizzato su una share

Questo approccio ha il vantaggio di poter modificare lo script in modo semplice essendo memorizzato in una posizione centralizzata.

Per poter essere eseguita l’operazione pianifica dovrà utilizzare una credenziale che permetta di accedere alla share e contemporaneamente avere i privilegi sui client per eseguire le attività previste dallo script.

Se è necessario che l’operazione pianificata sia configurata a livello Computer il security context è quello dell’account SYSTEM, quindi la share dove risiede lo script dovrà permettere l’accesso in lettura al gruppo Domain Computers o ad un gruppo i cui membri sono gli account computer su cui lo script dovrà essere eseguito.

Se invece è necessario che l’operazione pianificata sia configurata a livello Utente e le credenziali dell’utente corrente non sono sufficienti perché ad esempio lo script prevede attività che richiedono privilegi amministrativi occorrerà creare un account di dominio con password robusta che abbia i privilegi necessari (la password dell’utente sarà memorizzata nel Group Policy Object nella cartella SYSVOL e crittografata mediante 256-bit Advanced Encryption Standard (AES).

A riguardo si veda Security options Configure the security context under which the task is run.:

Run as Configure the security context under which the task is run.

If the preference item is part of Computer Configuration, by default the task is run in the security context of the SYSTEM account.
If the preference item is part of User Configuration, by default the task is run in the security context of the logged-on user. The task is run only if the user is logged on to the computer, but can continue after the user logs off.
To run a task under the security context of a specified account (enabling the task to run regardless of whether that account is logged on), select the Run as check box and enter credentials for the account.
Important

This password is protected by 256-bit Advanced Encryption Standard (AES) encryption and stored as part of the GPO in SYSVOL. This password should be changed on a regular basis and should not be relied on as the sole method of protecting confidential data

Ovviamente è di fondamenta importanza dal punto di vista della sicurezza consentire l’accesso alla share solo a gruppi e/o utenti strettamente necessari sia per evitare che lo script venga analizzato, se questo può costituire un problema di sicurezza, o peggio modificato da utenti non autorizzati che potrebbero eseguire sui client operazioni potenzialmente pericolose o volte a compromettere il client.

A tal proposito è preferibile che la share consenta accessi esclusivamente in lettura e che sia nascosta, a riguardo si veda Share and NTFS Permissions | Microsoft Learn.

Questo approccio non può essere ovviamente utilizzato nel caso lo script debba essere eseguito quando il client non è connesso alla rete aziendale in quanto la share su cui è memorizzato lo script non sarebbe accessibile.

Approccio 2: Esecuzione di uno script memorizzato localmente sul client

Questo approccio permette di poter eseguire lo script anche quando il client non è connesso alla rete aziendale, ma occorre prestare attenzione ad una serie di criticità operative e di sicurezza.

Affinché lo script possa essere eseguito localmente è necessario che venga copiato da una share sul client, ad esempio tramite una File Group Policy Preferences configurata con l’Action Update impostando il flag hidden sul file e sulla cartella locale in cui è memorizzato. L’utilizzo dell’Action Update permette di evitare che quando il client è disconnesso dalla rete lo script venga eliminato e non aggiornato. Occorre però considerare che utilizzando l’Action Update se lo script viene modificato è necessario modificare il nome dello script per poterlo aggiornare tramite, a riguardo si veda Working with Windows Settings Preference Items Using the GPMC.

Dal momento che per distribuire lo script sui client verrà utilizzata una share configurata preferibilmente per consentire accessi esclusivamente in lettura e impostata per essere nascosta, a riguardo si veda Share and NTFS Permissions | Microsoft Learn.

L’esecuzione dello script in locale semplifica la gestione delle contesto di sicurezza dell’operazione pianificata che eseguirà lo script i quanto se sono necessari i privilegi amministrativi lo si potrà eseguire come SYSTEM e in caso contrario con i privilegi dell’utente corrente senza la necessita di creare un utente di dominio dedicato.

Occorre però prestare attenzione al fatto che lo script non possa essere modificato sul client dagli utenti che accedono al computer perché potrebbe diventare una veicolo per eseguire azioni malevole volte a compromettere il sistema. Per impedire accessi non autorizzati al file dello script è possibile configurare sul file o sulla cartella in cui è memorizzato le opportune NTFS Permissions tramite la Group Policy Computer  Windows Settings / Security Settings / File System, a riguardo si veda Administer security policy settings.

E’ preferibile impostare le NTFS Permissions in modo che allo script possa accedere in lutta e scrittura solo l’account SYSTEM per gestire la copia ed l’esecuzione, se lo script deve essere invece essere eseguito dall’utente corrente concedere agli Users o se possibile ad un gruppo di utenti di dominio specifico i soli privilegi di lettura ed esecuzione.

Considerazioni conclusive

L’automazione di attività su client Active Directory può essere gestita tramite script eseguiti mediante operazioni pianificate. L’intero processo di configurazione del client per l’esecuzione del client può essere gestito tramite Group Policy.

Occorre configurare correttamente i vari componenti che permetteranno l’automazione per garantire l’esecuzione dello script, se necessario anche quando il client non è connesso alla rete aziendale, e per consentire un eventuale modifica dello script nel caso sia necessario implementare nuove funzionalità o correggere errori.

Inoltre bisogna porre particolare attenzione alla sicurezza implementando l’hardening delle configurazioni di accesso delle script per evitare che questi si trasformi in un varco di sicurezza sfruttabile per eseguire azioni malevole che permettano la compromissione del sistema o peggio dell’infrastruttura informatica aziendale.