Gestione delle Sessioni RDS Disconnesse

La configurazione dell’ambiente RDS permette la gestione delle sessioni utente che risultano disconnesse.

È possibile definire un intervallo di tempo entro il quale il server Session Host termina le sessioni disconnesse, questo valore è impostato direttamente nel pannello di configurazione del servizio RDS e prevede una serie di intervalli di tempo selezionabili

Dallo stesso pannello è possibile gestire più in generale i limiti delle sessioni di connessione al di là della sessione disconnessa si può definire il comportamento sia per le sessioni attive che inattive. Una sessione è da considerarsi inattiva quando al suo interno non è presente alcuna attività

Figura 1 time out Sessione disconnessa

Il minimo intervallo di tempo impostabile per terminare una sessione disconnessa è di 1 minuto. In alcuni scenari di impiego di un sistema RDS questo valore può non essere sufficiente.

Sebbene non sia raccomandato, come riportato in questo articolo l’utilizzo di un utente comune di accesso, può essere una scelta implementativa, ed in questo caso la possibilità che in caso di disconnessione i vari utenti accedano a sessioni attive in attesa della terminazione è reale.

Intercettando sul Session Host la sessione disconnessa, è possibile intervenire tramite uno script per forzarne la chiusura, per questo scopo è possibile utilizzare i comandi

  • qwinsta
  • reset

il primo permette di rilevare lo stato delle sessioni RDP, mentre il secondo ne permette il reset sulla base dell’ID, qui di seguito è riportato uno script che avviato con una frequenza maggiore di un minuto intercetta le sessioni in stato disconnesso e ne effettua il reset

### Script per la rilevazione ed il reset di sessioni disconnesse
# Impostare il nome del server Session Host di cui effettuare il controllo delle sessioni Disconnesse
$RdsServer=”rdsh01srv.ictpower.local”
# Comando per la rilevazione delle Sessioni ed il parsing di quelle Disconnesse NON vengono rilevate quelle nelle condizioni dello Statement REGEX tra ()
$RdsSessions=(qwinsta /server:$RdsServer)| Select-String -pattern ‘^(?!.*(services|Conn|rdp-tcp)).*$’
# rilevazione dei soli valori numerici dall’array creato sopra
$IDSessions = $RdsSessions -replace “[^0-9]” ,””
# definizione del comando di reset della sessione
$ResetCmd=”reset.exe “
# definizione del LogFile
$LogFile = “C:\GestioneRds\KillSessionDiconnected\Log\$RdsServer.log”
# Creazione della Funzione di Log
Function LogWrite
{
Param ([string]$LogString)
Add-content $LogFile -value $LogString
}
# Ciclo di lettura dell’Array con il solo ID numerico delle sessioni da cancellare
foreach ($IDSession in $IDSessions)
{
# Controllo della presenza di valori numerici nella variabile ed uscita in caso di variabile non numerica
if ($IDSession -match ‘\d’ )
{
#Formazione della stringa di log
$LogEvent = (Get-Date -Uformat %d-%m-%Y” Ora “%H.%M) + ” Kill ID Sessione “+ $IDSession + ” ” + $RdsServer
Write-Output $LogEvent
# Scrittura ed esecuzione del reset della Sessione
LogWrite $LogEvent
&$ResetCmd session /Server:$RdsServer $IDSession

}
else
{

}

}

Questo script può essere richiamato tramite un ulteriore script PS che è responsabile della sua esecuzione con l’intervallo desiderato, La sola operazione pianificata non può essere utilizzata in quanto anch’essa non permette intervalli di esecuzione minori di un minuto.

#lancio PS di kill RDS session su Session HOST
for ($i=0; $i -le 4)
{
invoke-expression -Command C:\GestioneRDS\KillSessionDiconnected\ResetDisconnectedSession-rdsh01srv.ps1
sleep 10
$i++
}
}

 

Annunci

SqlServer Creazione di un Linked Server Oracle ed errore 7302

 

Durante la creazione di un Linked Server Oracle all’interno di SqlServer è possibile incorrere nell’errore 7302 in fase di validazione

 

 

L’errore può presentarsi a prescindere dalla versione di SqlServer e dalla versione del Client Oracle utilizzato.

In questa condizione l’errore si presenta ancora prima della verifica delle credenziali fornite all’atto della definizione del Server Collegato.

Per poter “risolvere” l’inconveniente è necessario abilitare la proprietà AllowInprocess relativa al Provider di connessione OraOLEDB.Oracle.

Questa proprietà non è abilitata di default

 

Applicazione di GPO sulla base di appartenenza ad una Subnet (Vlan)

In Active Directory è possibile definire l’applicazione di determinate GPO sulla base dell’appartenenza a Siti differenti, tuttavia nel caso in cui in un sito siano presenti più subnet e sia necessaria l’applicazione di una GPO ad una sola di queste è necessario ricorrere ad un filtro WMI che permetta di applicare la Group Policy in modo puntuale.

Partendo dalla tabella di routing di una postazione è possibile identificare la rete in cui il sistema operativo è collocato, il comando che visualizza la tabella è route print

 

Figura 1 visualizzazione tabella di routing

Il sistema è configurato per un indirizzo ip 10.69.143.187 ed una subnet 255.255.255.248 e gli indirizzi di subnet e broadcast sono rispettivamente 10.69.143.184 e 10.69.143.191

Le informazioni contenute nella tabella sono leggibili anche tramite una semplice query WMI

select * from Win32_IP4RouteTable Where Destination =’10.69.143.184′ and Mask=’255.255.255.248′

con il comando WBEMTEST è possibile verificare la correttezza sintattica della query ed il risultato ottenuto

 

Figura 2 output Wbemtest

 

A questo punto essendo certi che la query è corretta possiamo creare un filtro WMI da applicare poi alle GPO che devono essere attive per la porzione di rete in cui ci troviamo.

La GPO verrà applicata in caso di un confronto positivo del filtro basato sulla query

 

Figura 3struttura del filtro WMI

 

Figura 4 GPO con filtro Wmi applicato

 

Riferimenti:

https://docs.microsoft.com/it-it/windows/security/threat-protection/windows-firewall/create-wmi-filters-for-the-gpo

https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wmiiprouteprov/win32-ip4routetable

 

 

 

 

 

 

Identificare la tipologia di Sistema Operativo tramite WMI

 

Nell’applicazione delle Group Policy, piuttosto che in ambiti differenti, può essere necessario applicare determinate impostazioni, o rilevare in modo puntuale la tipologia di Sistema Operativo.

Tramite un apposito filtro applicato all’ambiente WMI è possibile rilevare se il sistema è un Client, un server e se si tratta di un server, se questo è un Domain Controller oppure un sistema Server comune

Il valore da identificare è la Proprietà Product_Type relativa alla classe Win32_OperatingSystem il cui contenuto è un valore di tipo uint32

La proprietà può contenere i seguenti valori

  • 1 Work Station
  • 2 Domain Controller
  • 3 Server

Una semplice query può essere strutturata in questo modo

select ProductType from Win32_OperatingSystem

e può essere eseguita con il tool WbemTest

Figura 1 risultato della query su un DC

Ed è inoltre possibile rilevare lo stesso valore tramite il comando VMIC

wmic os get ProductType /value

 

Figura 2 valore rilevato con WMIC

 

 

Definizione di un Filtro WMI da applicare ad una GPO

Avendo presente la struttura WMI interrogabile con i due tool riportati sopra è possibile costruire una query che verrà applicata ad una GPO, in modo che questa venga applicata esclusivamente in caso di un confronto positivo con la query effettuata

select * from Win32_OperatingSystem where ProductType=”1″

la query sopra su un filtro WMI applicato ad una GPO permette l’applicazione della stessa solo in caso di un sistema operativo di tipo “Client”

 

Figura 3

Figura 4 creazione del filtro e relativa query

 

 

Riferimenti

https://docs.microsoft.com/en-us/windows/desktop/CIMWin32Prov/win32-operatingsystem

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc947846(v=ws.10)

https://blogs.technet.microsoft.com/askperf/2012/02/17/useful-wmic-queries/

 

 

GESTIONE DELLE REGOLE DI CONSERVAZIONE DEI DATI SU AZURE LOG ANALITYCS

 

Azure Log Analitycs è la soluzione di gestione dei vari log collezionati localmente o sulle infrastrutture in cloud, che matte a disposizione dell’utilizzatore un motore di analisi e di ispezione dei log stessi molto potente.

All’atto della sua attivazione viene configurata con un piano di tariffazione per GB di dati inviati dai collector, all’atto dell’attivazione di soluzioni di analisi avanzate, quali ad esempio la Soluzione di Security and Audit, la tariffazione avviene per nodo.

Da notare che i primi 60 giorni sono gratuiti.

Al di la della soluzione adottata è possibile comunque variare il periodo di conservazione dei dati archiviati che di default è di 31 giorni, anche la conservazione dei dati di log ha una sua tariffazione che è basata sulla quantità di dati inviati, secondo lo schema qui sotto.

 

Figura 1 tariffazione mensile Azure Log Analitycs

I primi 5 Gb mensili sono gratuiti così come la conservazione base di 31 giorni, solamente gli sforamenti in termine di periodo di conservazione e spazio occupato avranno un costo che varia, in misura minima, a seconda delle region di allocazione del servizio.

 

Per poter modficare il periodo di conservazione dei dati, così come la quantità giornaliera archiviata, è sufficiente collegarsi al portale di Azure https://portal.azure.com, accedere alla soluzione di monitoring selezionare la funzione relativa a “Utilizzo e Costi Stimati”

Figura 2 visualizzazione dei consumi e costi attuali

 

e da questa pagina accedere alle impostazioni di “Gestione del Volume dei Dati” e selezionare le impostazioni volute.

Si possono mantenere i dati in linea per un periodo massimo di due anni, ed è possibile anche impostare un limite di upload giornaliero

 

Figura 3 impostazione dei limiti di archiviazione

È possibile anche impostare un’ora del giorno a cui vengono applicati i limiti di archiviazione in termini utilizzo di dati

Riferimenti

https://docs.microsoft.com/it-it/azure/log-analytics/

 

IMPLEMENTAZIONE del PROTOCOLLO LDAPs in Active Directory

All’interno di realtà aziendali complesse, con sistemi eterogenei, può essere abbastanza comune riferirsi ad Active Directory come provider di autenticazione “esterno” per le applicazioni aziendali.

In alcuni casi, questi ambienti possono utilizzare in modo nativo le credenziali con cui un utente ha effettuato il login sulla postazione, ma più frequentemente è richiesto che l’applicazione, a prescindere dalla credenziale fornita per l’accesso al pc, esegua l’autenticazione dell’operatore richiedendo username e password.

Questa modalità operativa è utilizzata principalmente nelle realtà dove una singola postazione è utilizzata da operatori diversi in tempi brevi e con brevi attività di lavoro.

Un esempio è sicuramente una realtà ospedaliera dove un PC è utilizzato quasi continuamente da più operatori e per ognuno di questi deve essere garantita la “tracciabilità” delle operazioni compiute. Questa modalità operativa prevede (per ovvie ragioni di velocità di accesso) che le applicazioni permettano una funzione di “Cambio Operatore” senza essere chiuse.

Inoltre essendo demandata all’ambiente applicativo la gestione delle autenticazioni è utile che possa essere eseguito anche il cambio password all’interno dell’applicazione stessa, così come i vari controlli sulle password policies implementate a livello Aziendale

In uno scenario di questo tipo non è raro trovare applicazioni che utilizzano il protocollo LDAP per le funzioni di autenticazione e gestione delle credenziali utente.

Limitazioni nell’uso del protocollo LDAP

l’articolo How to change a Windows Active Directory and LDS user password through LDAP riporta:

  • The password is stored in the AD and LDS database on a user object in the unicodePwd attribute. This attribute can be written under restricted conditions, but it cannot be read. The attribute can only be modified; it cannot be added on object creation or queried by a search.
  • In order to modify this attribute, the client must have a 128-bit Transport Layer Security (TLS)/Secure Socket Layer (SSL) connection to the server.

È evidente che tramite LADP, che non dispone di una connessione cifrata, non è possibile gestire in modo completo le funzioni di cambio password, risulta quindi necessario ricorrere al protocollo LDAPs

Attivazione del Protocollo LDAPs

Durante la “promozione” di un sistema alle funzioni di Domain Controller viene attivato anche il protocollo LDAP, mentre per poter attivare la connessione cifrata con LDAPs è necessario che venga fornito un certificato che deve contenere l’OID 1.3.6.1.5.5.7.3.1 8 (Server Authentication) come è ampiamente spiegato nel seguente articolo Technet LDAP over SSL (LDAPS) Certificate

  • Certificate must be valid for the purpose of Server Authentication. This means that it must also contains the Server Authentication object identifier (OID): 1.3.6.1.5.5.7.3.1
  • The Subject name or the first name in the Subject Alternative Name (SAN) must match the Fully Qualified Domain Name (FQDN) of the host machine, such as Subject:CN=server1.contoso.com. For more information, see How to add a Subject Alternative Name to a secure LDAP certificate (http://support.microsoft.com/kb/931351).

Ed è anche richiesto che l’account macchina del DC possa accedere alla chiave privata del certificato

  • The host machine account must have access to the private key.

 

 

Installazione di un PKI aziendale

Sul sito ICTPOWER, abbiamo proposto una serie di articoli in cui viene spiegato il modo corretto per installare e configurare una PKI all’interno di un dominio Active Directory.

Di default se un Domain Controller rileva la presenza di una Certification Authority ( Enterprise ) richiede in modo automatico un certificato alla CA ed attiva le comunicazioni cifrate in LDAPs di fatto attivando questo protocollo.

 

Figura 1 Certificato presente nello Store Computer di un DC

Il libro Windows Server 2008 PKI and Certificate Security” di Brian Komar affronta in modo completo le problematiche e gli scenari di attivazione di una CA, in particolare a pagina 671 viene sipegato il comportamento citato in precedenza.

 

 

 

Scelta del posizionamento della CA nel dominio

 

La scelta del dove installare il ruolo e le funzioni della PKI non è di secondo piano, numerosi articoli consultabili nel web ne propongono l’installazione direttamente su un Domain Controller, gli articoli proposti su ICTPower.it delineano uno scenario in cui le funzioni della CA sono installate su server dedicati.

Si riporta di seguito la nota di Brian Komar che propone il medesimo scenario di installazione

Mentre sul Technet l’articolo Public Key Infrastructure Design Guidance argomenta ulteriormente la scelta di server dedicati.

 

Se la scelta di implementazione della CA è basata su due livelli con la CA Root off-line è necessario considerare il fatto che i Domain Controller presenti NON inizieranno a richiedere i certificati in autonomia finché non verrà distribuito il certificato della Root-CA, questo comportamento è spiegato dal fatto che i sistemi conoscono sì la issuing-CA ma non è disponibile il certificato che attesta l’autenticità di quest’ultima.

Per fare si che i DC possano quindi “Dialogare” con questo servizio è necessario creare una GPO che distribuisca il certificato Root, che deve essere scaricato dalla Root-CA.

Figura 2 Export del certificato della Root-CA

A questo punto è sufficiente creare la GPO con cui viene distribuito il certificato della Root-CA, per comodità di configurazione è possibile creare una GPO applicata a livello di Dominio.

Figura 3 Definizione della GPO

Non appena i vari DC ricevono la Group-Policy eseguono la richiesta del proprio certificato alla Issuing-CA

Figura 4 Issuing CA e relativi rilasci per i DC

 

A questo punto per determinare se il Domain Controller ha effettivamente attivato le comunicazioni in LDAPs è sufficiente verificare la connessione tramite il tool LDP.exe

 

Figura 5 connessione LDAPs

La connessione avvenuta riporta le informazioni relative al DC ed ai servizi disponibili

Figura 6 connessione LDAPs

 

 

Il funzionamento a questo punto è anche verificabile attivando e disattivando la GPO creata, se questa viene disattivata, in modo del tutto automatico i DC ritornano ad utilizzare il protocollo LDAP ( che in ogni caso non viene disattivato)

 

Riferimenti

Di seguito il link agli articoli pubblicati su IctPower.it insieme ad Ermanno Goletto relativi ad una architettura PKI a due livelli

 

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.