RDS Gestione del Numero di Sessioni Utente Concorrenti

Normalmente in RDS ogni singolo utente che accede al servizio dispone di una singola sessione, quindi, rieseguendo un secondo accesso, la prima sessione verrà disconnessa.

In alcuni scenari di utilizzo, questo comportamento può essere un limite, si pensi ad ambienti dove l’autenticazione avviene a livello applicativo e l’accesso al Sistema è necessario esclusivamente per avviare l’applicazione.

In un contesto di questo genere è possibile modificare il comportamento di Default tramite una GPO di Macchina da applicare sui sistemi dell’infrastruttura RDS che ospitano il ruolo Session Host

La GPO che determina questo comportamento è in

  • Computer > Modelli Amministrativi > Componenti di Windows > Servizi Desktop Remoto > Host Sessione Desktop Remoto > Connessioni
  • Impostare “Limita gli Utenti di Servizi Desktop remoto a una sola sessione di Servizi Desktop remoto” a Disabilitato.


Annunci

Conversione Fisico/Virtuale per mezzo di Disk2Vhd di un sistema con bios UEFI

 

Il tool Disk2Vhd permette agevolmente la conversione di sistemi fisici in VM pur non essendo un vero e proprio strumento di conversione.

Nei vari scenari affrontati, la conversione di sistemi legacy XP,2003 etc. può essere necessaria ( anche se ormai questi sistemi sono fuori supporto ).

Anche con sistemi operativi più recenti W7,10,2012 può essere necessario effettuare la conversione di installazioni fisiche.

Nel caso in cui queste siano in installate su HW con Bios UEFI, la conversione con Disk2Vhd, e la successiva creazione della VM non consentono al sistema un avvio corretto e la VM rimane inaccessibile con lo schermo completamente nero.

Figura 1 avvio fallito dopo la conversione del disco di sistema

 

Se ci si trova in questa situazione è sufficiente seguire alcuni passaggi per consentire il corretto avvio del sistema operativo.

Per prima cosa è necessario montare il disco convertito e verificare le partizioni esistenti, quasi certamente si vedrà un’organizzazione del disco simile a quella della figura sotto, ossia con un disco di tipo GPT ed una serie di partizioni che precedono la partizione di sistema vera e propria.

Nota. Per effettuare le operazioni descritte qui sotto possibile utilizzare numerosi tool, Free, OpenSource ed a pagamento, personalmente ho utilizzato Aomei Partition Assistant nella versione Free scaricabile dal sito

 

Figura 2 conversione VHDx

 

A questo punto è sufficiente effettuare la conversione del disco da GPT a MBR

 

Figura 3 Conversione ad MBR del disco

Successivamente, dopo aver applicato le modifiche, è necessario rimuovere tutte le partizioni che precedono quella di sistema ( chiaramente questa operazione dovrà essere valutata caso per caso se fossero presenti altre partizioni contenenti dati )

Figura 4 rimozione partizione

Ed al termine applicare, anche in questo caso le modifiche

 

 

A questo punto è possibile smontare il disco e creare una VM ( Gen1 ) con questo disco come disco principale.

 

La VM non sarà ancora avviabile, pertanto dovremo inserire un disco della versione di Sistema che è contenuta nel VHD ed avviare le procedure di ripristino, è da notare che possono esserci leggere differenza tra le varie versioni. ( in questo esempio un ripristino di un sistema W7)

Successivamente accedere al prompt comandi e con l’utility DISKPART eseguire i comandi di attivazione della partizione

 

  • diskpart
  • list disk
  • select disk 0
  • list partition
  • select partition 1
  • active
  • exit

Figura 5 impostazione della partizione attiva

 

e, dopo un ulteriore riavvio è necessario eseguire la ricostruzione delle componenti di boot con i comandi

 

  • bootrec /fixmbr
  • bootrec /fixboot

 

ed infine eseguire

  • bootrec /RebuildBcd

in modo da eseguire la scansione delle installazioni presenti sul disco e ricostruire l’archivio di configurazione di avvio…

 

Rilevazione degli errori di Assegnazione Siti ad Aree in IE impostati tramite Group Policy (Event ID 1805)

 

In Internet Explorer è la Sicurezza del browser è strutturata in 4 aree Internet / Intranet Locale / Siti Attendibili / Siti Con Restrizioni, per ognuna di queste aree è possibile la gestione delle impostazioni di sicurezza in modo indipendente.

 

Figura 1 Aree di Sicurezza di IE

L’appartenenza di un determinato sito ad un’area avviene inserendo direttamente l’url del sito all’interno di un elenco impostato nel browser (elenco che è disponibile per ogni area)

Figura 2 Assegnazione di un Sito ad un’Aera

Nella dichiarazione di un sito è possibile utilizzare caratteri jolly ed i vari nomi ma con una serie di vincoli. E’ anche possibile dichiarare un singolo indirizzo ip ( 10.0.0.1) oppure un range di indirizzi ( 10.0.0.1-100).

È inoltre possibile indicare un protocollo specifico per discriminare l’assegnazione ad un’area specifica includendo anche il protocollo stesso.

Nel momento in cui viene introdotto un valore questo viene automaticamente verificato in modo da evitare che il comportamento del browser non sia corretto. Ad esempio se viene impostato https://blogs.technet.microsoft.*com, che non è sintatticamente corretto, viene presentato il seguente messaggio

Figura 3 Warning Relativo ad un Errore Formale di Dichiarazione ( LOCALE )

 

Questo controllo è disponibile quando vengono inseriti i valori all’interno delle impostazioni del browser, in quanto viene effettuata la conversione in chiavi di registro delle impostazioni di IE dal browser stesso.

 

Gestione delle Assegnazioni tramite GPO

Nel momento in cui si effettua la gestione dell’ambiente di sicurezza direttamente dalle GPO, viene perso il controllo sulla correttezza del valore digitato, questo verrà passato al client all’atto dell’elaborazione della GPO, e solo in questo frangente verrà eseguita la conversione del valore impostato nella Group Policy verificandone la correttezza.

Nel caso venga impostato un valore in modo non corretto, e quindi non gestibile dal browser, viene riportato un evento ID 1085 all’interno del registro eventi della postazione.

 

Figura 4 Dichiarazione Errata nella GPO

Figura 5 Event ID 1805 Riportato sulla Postazione

 

Il registro tuttavia non riporta in modo puntuale dove è stato rilevato l’errore, nemmeno leggendo i dettagli dell’evento stesso.

Figura 6 Dettaglio Evento

 

Il livello di dettaglio che possiamo rilevare è nella descrizione dell’errore relativamente alla dicitura “Parametro non corretto”

Anche effettuando una “forzatura” tramite il comando GPUPDATE /FORCE sulla postazione otteniamo un avviso di errore

Figura 7 Comando Gpupdate

Tramite il tool di diagnostica GPRESULT /H <NomeFileDiOutput.html> possiamo ottenere informazioni più circostanziate e precise contenute all’interno del file di output.

A questo punto il report generato dal comando è disponibile nel file html e da qui è possibile verificare quali impostazioni sono state “passate” dalla GPO al client ed approfondire l’indagine.

Figura 8 Report in Formato HTML

Non viene tuttavia indicato quale sia il valore che genera l’errore.

 

IE Zone Analyzer TOOL

Uno strumento ulteriore per la diagnostica dei problemi legati a questo tipo di impostazioni è Zone Map Viewer
che è stato rilasciato ormai da alcuni anni ma ( sebbene non sia disponibile una informazione ufficiale di compatibilità con i sistemi recenti ) è ancora utilizzabile per la rilevazione delle impostazioni del browser.

Questo tool riporta la configurazione attiva sul browser tramite la funzione “Zone Map Viewer”

Figura 9 IE Zone Analyzer TOOL

 

E in dettaglio le impostazioni valide, che per differenza rispetto a quelle impostate tramite la GPO, individuano il settaggio non valido, in questo esempio https://www.bing.*com è il valore che non essendo coerente con i vincoli imposti dal browser, genera l’errore in applicazione della GPO, tramite Zone Analyzer infatti è applicato esclusivamente http://www.google.com

 

 

Figura 10 Report delle Impostazioni Effettivamente Attive

 

 

Riferimenti

https://blogs.msdn.microsoft.com/askie/2016/04/05/description-of-event-id-1085-from-internet-explorer-zonemapping/

https://blogs.technet.microsoft.com/fdcc/2011/09/22/iezoneanalyzer-v3-5-with-zone-map-viewer/

https://blogs.technet.microsoft.com/fdcc/2011/09/22/internet-explorers-explicit-security-zone-mappings/

 

 

 

 

 

 

Credssp vulnerabilità descritta in CVE-2018-0886

 

A partire da marzo 2018 secondo questo bollettino di sicurezza viene risolta la vulnerabilità relativa al Credential Security Support Provider protocol (CredSSP)

Con l’aggiornamento di sicurezza di maggio, installato sui vari sistemi che accedono in RDP ad un server non aggiornato, può essere visualizzato il seguente messaggio di errore

20180510-Credssp-Error

in quanto le seguenti KB

  • KB4103718 (Windows 7 Service Pack 1, Windows Server 2008 R2 Service Pack 1)
  • KB4103725 (Windows 8.1/Windows Server 2012R2)
  • KB4103726 (Windows Server 2012)
  • KB4103727 (Windows 10 version 1709)
  • KB4103723 (Windows 10 Version 1607, Windows Server 2016)

“forzano” client ad effettuare un collegamento in RDP esclusivamente verso server su cui sono state installate le patch di sicurezza rilasciate a marzo 2018 che risolvono la vulnerabilità.

l’evento è anche rilevabile sul client dove si è ottenuto l’errore, consultando il registro eventi di Sistema e rilevando l’error ID 6041 LSA

20180510-Credssp-Error-EventvWr

Con l’aggiornamento di sistema viene introdotta una chiave registry che è possibile modificare al fine di accedere ai server non ancora aggiornati, e per i quali risulta difficoltosa l’installazione della patch.

Essendo necessario un riavvio, la sua esecuzione può non essere immediata

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters]
“AllowEncryptionOracle”=dword:00000002

E’ fortemente consigliato di utilizzare il workaround riportato sopra esclusivamente per il tempo necessario alla completa applicazione delle patch lato server.

 

 

Riferimenti:

https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

https://blogs.technet.microsoft.com/askpfeplat/2018/05/07/credssp-rdp-and-raven/

https://blogs.technet.microsoft.com/yongrhee/2018/05/09/after-may-2018-security-update-rdp-an-authentication-error-occurred-this-could-be-due-to-credssp-encryption-oracle-remediation/

 

 

 

 

 

Watchguard Autenticazione Accesso su Active Directory

Active Directory, in quanto repository centralizzato di utenti può essere utilizzato anche come sorgente di autenticazione per dispositivi quali Firewall, apparati di rete ed altro.

In questo articolo analizziamo come è possibile configurare Watchguard in modo che utilizzi l’Active Directory centralizzata al fine di definire utenti che possono effettuare l’amministrazione del Firewall stesso, oppure, sempre tramite AD consentire l’accesso tramite VPN SSL definite sul Watchguard.

Definizione delle sorgenti di autenticazione

Tramite l’accesso di gestione per mezzo del portale Web ( https://”ip-delFirewall”:8080) dal menù Authentication/Servers è possibile la scelta tra una serie di sorgenti di autenticazione, nel nostro caso utilizzeremo Active Directory.

Figura 1 Selezione Sorgente di Autenticazione su AD

A questo punto selezionando Active Directory procederemo con ADD e successivamente dovremo fornire le varie informazioni relative al dominio, o meglio ad un Domain Controller Primario e ad un DC secondario che verrà usato come alternativa in caso di indisponibilità del primario, dovremo poi specificare la “Search Base” relativa all’LDAP, è possibile specificare una particolare OU di ricerca per gli utenti.

I campi Group String e Login Attribute specificano le informazioni relative all’account di accesso sull’AD ( nel nostro esempio sono utilizzati i valori di dafault), è poi possibile specificare anche se la connessione avverrà tramite il protocollo LADP(s) ossia in modalità cifrata.

Figura 2 definizione del riferimento al Dominio di autenticazione

Se per ragioni di configurazione il FireBox non raggiungesse un DNS a conoscenza del dominio locale, è possibile specificare l’indirizzo IP dell’Domain Controller anziché il suo FQDN.

Proseguendo si procede al salvataggio della sorgente di autenticazione per il dominio, è comunque possibile definire più di un riferimento di autenticazione in modo da permettere ad utenti differenti di accedere tramite lo stesso dispositivo.

Verifica della configurazione

Terminato il salvataggio è possibile effettuare un test delle impostazioni, dove verranno richiesti utente/password di un account presente in AD

Figura 3 test dell’autenticazione su AD

Figura 4 risultato autenticazione corretta

Definizione dei permessi di accesso in VPN ad utenti AD

A questo punto si può procedere con l’attribuzione dei permessi di accesso in VPN SSL ad utenti residenti su Active Directory , con le impostazioni definite prima l’accesso avviene secondo l’appartenenza di un utente ad un gruppo definito in modo puntuale su AD, nel nostro esempio il gruppo i chiama SSLVpnAdmins

Figura 5 attivazione servizio VPN SSSL

Figura 6 impostazione del Gruppo e del server di autenticazione

Nelle impostazioni relative all’autenticazione, dovremo definire il gruppo AD sulla base del quale è consentito l’accesso agli utenti e dovremo anche configurare il server di autenticazione impostato in precedenza.

Figura 7 impostazione del nome gruppo

Nella figura 7 è riportata la modalità con cui è possibile definire il nome del gruppo che, in relazione al server di autenticazione verrà poi ricercato in Active Directory

Terminate le configurazioni viste sopra è possibile autenticarsi al Firebox direttamente al Portale Vpn Ssl con le credenziale definite su Active Directory è necessario in fase di accesso selezionare il dominio AD di riferimento nella forma.

Figura 8 accesso portale VPN

Definizione dei permessi di amministrazione del Firebox

Sempre sulla base delle autenticazioni analizzate in questo articolo è possibile fare si che determinati utenti di AD possano anche essere, o avere ruoli di amministrazione sul Firewall, i vari ruoli sono accessibili dal menù System/Users and Roles da cui è possibile attribuire i vari ruoli sulla base di un determinato utente dichiarato in Active Directory

Figura 9 definizione dei ruoli di gestione

Figura 10 impostazione del nome utente

Automazione dell’Avvio/Arresto di VM in Azure

Nella gestione dell’infrastruttura aziendale può essere normale dover configurare servizi che per i motivi più disparati necessitano di essere attivi per poche ore al giorno o per poche ore al giorno in pochi giorni la settimana.

A questo punto è utile poter gestire l’avvio e l’arresto automatico di determinate VM.

Dal punto di vista della sicurezza il mantenere attiva un VM espone i servizi ad attacchi, questo a prescindere che il Workload sia attivo internamente oppure in Cloud, quindi il mantenere spento un servizio che non deve essere utilizzato è sicuramente una considerazione che si può fare anche in termini di sicurezza.

Se la VM è attiva in Cloud l’aspetto del tempo di esecuzione è ancora più importante in quanto permette notevoli risparmi sui costi della gestione della sottoscrizione.

In Azure è possibile gestire senza particolari complessità un evento si spegnimento di ogni VM al giorno definendo anche l’invio di notifiche dell’evento.

Figura 1 Vm AutoShutdown

Tuttavia non è possibile con la medesima impostazione definirne ad esempio il riavvio, così come operazioni multiple, per questo tipo di attività è necessario agire tramite un Account di Automazione e la gestione al suo interno dei vari RunBook ai quali vengono poi applicate una o più pianificazioni la relazione tra le varie entità è la seguente

Account di Automazione – RunBook- Schedulazione

Il RunBook può essere generico ossia prevedere in fase di “chiamata” il passaggio parametri, ad esempio il nome del Wokload, e l’attività da eseguire ( Avvio/Arresto) oppure può contenere al suo interno già i parametri preconfezionati per un particolare VM ed una particolare azione.

Creazione di una attività pianificata

Per prima cosa è necessario creare un Automation Account dalla pagina principale di gestione della sottoscrizione

Figura 2 Selezione del Servizio

Figura 3 Creazione dell’Automation Account

A questo punto è possibile creare l’Account di Automazione definendo un nome ed eventualmente un Resource Group di riferimento completando poi la procedura con CREATE

Figura 4 Accesso alle Schedulazioni

Completata la creazione dell’automazione è possibile creare prima le schedulazioni, in realtà, come vedremo sarà possibile anche crearle successivamente, in questo caso creeremo una schedulazione impostata alle 7 dei giorni lunedì mercoledì e venerdì per procedere è sufficiente selezionare Schedules e poi confermare la scelta successiva

Figura 5 Creazione di uno Schedule

La schedulazione è impostata e con create la definiamo, una volta creata questa non è associata ad alcuna operazione, attività che faremo successivamente.

Il passo successivo prevede la creazione di un RunBook ossia del flusso di operazioni da eseguire, al quale andrà agganciata la schedulazione creata sopra nella pagina di creazione esistono già preconfezionati dei RB Tutorial

Figura 6 Creazione del RunBook

Figura 7 Creazione del RunBook (dettaglio)

Terminata la creazione, la Dashboard di Azure si posiziona in modo da consentire l’immissione dei vari comandi, il codice per l’esecuzione del comando di Avvio/Arresto di una VM può essere simile al seguente:

 

 

 

Figura 8 Esempio di codice per Avvio/Arresto VM

Ed è sufficiente copiarlo ed incollarlo direttamente nella pagina di creazione del RunBook

Figura 9 Definizione del Codice

È necessario salvare e pubblicare il RunBook, importante ricordare che questo deve sempre essere pubblicato per diventare operativo

A questo punto è necessario associare la Schedulazione creata in precedenza

Figura 10 definizione della schedulazione associata al RB

Figura 11

E successivamente definire i “parametri” di esecuzione che sono individuati direttamente dallo script tramite il pannello di gestione di Azure

Figura 12 Definizione dei Parametri passati allo script

A questo punto dalla dashboard di azure possiamo monitorare lo stato di esecuzione del RunBook e dei parametri passati in esecuzione.

Come abbiamo visto in questa modalità, tramite il passaggio di parametri allo script  possiamo utilizzare il RunBook per differenti VM e per azioni di spegnimento, tuttavia se volessimo potremmo ” Cablare ” direttamente nello script il parametri voluti in modo da rendere l’esecuzione strettamente legata alla VM, la scelta di una o altra modalità è personale e dipende anche numero di azioni e di VM che esistono.

Controllo delle attività del RunBook

Tutte le attività eseguite dal RunBook sono consultabili, dalla pagina Jobs del portale

Riferimenti:

https://docs.microsoft.com/it-it/azure/automation/automation-starting-a-runbook

https://docs.microsoft.com/en-us/azure/automation/automation-create-standalone-account