#POWERCON2021 l’evento sarà on line domani a partire dalle 9.00 non mancare
segui questo link per iscriverti :
Gestione di Google Drive Sync con SSL Decryption
In ambienti Enterprise è possibile che venga implementata la funzione di SSL-Decryption da parte degli apparati di controllo delle connessioni esterne, in una condizione di questo tipo l’applicazione Google Drive Sync presenta malfunzionamenti generalizzati
Figura 1 Applicazione Drive Sync di Google
In particolare smette di funzionare ed impedisce la sincronizzazione dei contenuti locali con il Drive esterno riportando questo messaggio all’interno dell’area di notifica
Figura 2 Errore di Sincronizzazione
Anche la prima configurazione dell’Applicazione fallirebbe dopo la richiesta delle credenziali con questo messaggio
Figura 3 Errore di accesso dell’account Google
Il motivo è che di default Google Drive Sync di default non tollera l’interposizione di una Decryption del tunnel SSL, per ovviare a questo comportamento, che in ambiente entreprise può essere un limite, ma che ha tutto il suo razionale in termini di protezione, è necessario avviare l’eseguibile con l’opzione
–unsafe_network
Dovremo quindi (in caso di avvio automatico) individuare la chiave di registro relativa nella sezione utente del registro “RUN” e modificare il comando di avvio come segue
“C:\Program Files\Google\Drive\googledrivesync.exe –unsafe_network” /autostart
Chiaramente il percorso dell’eseguibile dovrà essere adattato in coerenza con l’installazione sul sistema
Figura 4 Particolare del Registro
Riferimenti alla SSL Decryption/Encryption
https://en.wikipedia.org/wiki/Transport_Layer_Security
https://docs.paloaltonetworks.com/pan-os/10-0/pan-os-admin/decryption
https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/122078/deep-inspection
Ri-Utilizzo di Certificati Rilasciati Da Let’s Encrypt
In diverse occasioni, nella community ICTPOWER.it ci siamo occupati di Let’s Encrypt, questa breve guida ha lo scopo di evidenziare come dal client Win-Acme, almeno nella versione attuale (2.1.0), è possibile recuperare il certificato rilasciato dalla CA per un sito Web IIS ed utilizzarlo per altri servizi.
Qui di seguito una serie di articoli che ne spiegano l’utilizzo in contesti differenti
- https://www.ictpower.it/guide/implementazione-di-lets-encrypt-in-ambiente-windows-server-2016.htm
- https://www.ictpower.it/guide/utilizzo-e-configurazione-di-lets-encrypt-in-ambiente-linuxapache.htm
- https://www.ictpower.it/guide/utilizzo-di-azure-dns-per-la-validazione-automatica-di-lets-encrypt.htm
- https://www.ictpower.it/guide/generazione-di-certificati-san-con-lets-encrypt-ed-utilizzo-in-microsoft-exchange.htm
Let’s Encrypt rilascia un certificato pubblico, ne salva il formato .pfx e la relativa chiave in una cartella di appoggio in %ProgramData%\win-acme\ dove
all’interno sono disponibili anche altre informazioni, quali una cartella contenente i log dell’applicazione, un file .json con un riepilogo relativo al certificato rilasciato compreso il Thumbprint ed altre informazioni utili in caso di troubleshooting.
Figura 1 log file di Win-Acme
Figura 2 File Json relativo al certificato rilasciato
Se vogliamo utilizzare il certificato ottenuto da LE, lo troviamo nella sottocartella Certificates dove è salvata anche la CSR (Certificate Signing Request ) in formato .PEM
Figura 3 Contenuto della cartella Certificates
È da notare che il certificato avrà il nome che corrisponde ad un valore numerico che corrisponde all’ID di rilascio della CA
A questo punto, individuato il file sarà possibile utilizzarlo anche per altri servizi, che chiaramente devono corrispondere all’FQDN per il quale il certificato stesso è stato emesso, ad esempio con una serie di cmd-let Powershell potrebbe essere installato in una Farm RDS per i vari ruoli che la compongono.
Tuttavia un certificato .PFX come in questo caso è protetto da password che è necessario fornire per poterlo utilizzare. L’identificazione della password a protezione del Certificato è possibile rilanciando l’utility wacs.exe e selezionando l’opzione relativa alla visualizzazione della Schedulazione di rinnovo
Identificando poi il Binding IIS per il quale il certificato era stato richiesto
Completando il comando con invio vengono visualizzate tutte le informazioni relative al certificato stesso tra cui la password a protezione del PFX che è adesso possibile utilizzare in altri servizi dell’HOST
SMBv2 Guest Access Disabilitato di Default in Win10
Dalla versione 1709 di Windows 10, SMBv1 è disabilitato per default, e rimangono disponibili le versioni v2 e v3 del protocollo.
La versione v1 è nota per avere diverse vulnerabilità e questo è il motivo principale della sua dismissione
Tuttavia, sempre per ragioni di sicurezza, come spiegato in questo articolo la versione v2 di SMB ha disabilitato per default l’accesso guest, ossia senza autenticazione.
In alcuni casi, a prescindere dalle considerazioni sulla sicurezza, in termini più operativi questo comportamento può rivelarsi un ostacolo alle normali funzionalità di accesso a device che espongono tramite questo protocollo Share e servizi di rete.
Ad esempio, macchine fotocopiatrici multifunzione non legate in qualche modo a dominio od a servizi di autenticazione impediscono di fatto l’accesso alle loro aree di archiviazione dove sono salvati ad esempio il file oggetto delle scansioni effettuate.
In prima battuta un client (windows 10) che tenta di accedere ad una share di questo tipo proporrà all’utente un errore poco “parlante”
Figura 1 errore notificato in accesso
Che può lasciare spazio a numerose interpretazioni di ordine tecnico, se si utilizza il comando net share per la mappatura della risorsa condivisa, l’errore viene notificato in modo più preciso e circostanziato riportando il seguente messaggio
Errore di sistema 1272
Non puoi accedere a questa cartella condivisa perché i criteri di sicurezza dell’organizzazione bloccano l’accesso guest non autenticato.
Questi criteri garantiscono la protezione del PC da dispositivi non sicuri o dannosi nella rete.
Figura 2 errore 1272
L’evento è anche riportato all’interno del registro eventi nel ramo Applicazione e Servizi/Microsoft/Windows/SMBClient/Security dove è possibile rilevare l’Event ID 31017
Figura 3 Registro Eventi ID 31017
Il testo del messaggio riporta le seguenti Informazioni Aggiuntive:
Informazioni aggiuntive:
Questo evento indica che il server ha tentato di eseguire l’accesso dell’utente come Guest non autenticato e l’operazione è stata rifiutata dal client.
Gli accessi come Guest non supportano funzionalità di sicurezza standard come la firma e la crittografia.
Come risultato, gli accessi come Guest sono vulnerabili ad attacchi man-in-the-middle che possono esporre dati sensibili nella rete.
In Windows, gli accessi non sicuri come Guest sono disabilitati per impostazione predefinita. Microsoft sconsiglia di abilitare gli accessi non sicuri come Guest.
Che fornisce una più chiara descrizione del contesto di sicurezza e delle motivazioni della scelta da parte di Microcoft
Soluzione
A prescindere dalle considerazioni relative alla sicurezza, è possibile modificare questo comportamento tramite GPO o policy Locale
Figura 4 definizione della GPO
L’impostazione Abilita gli accessi guest non sicuri che deve essere portata in stato Abilitato è configurabile in Computer/Modelli Amministrativi/Rete/Workstation LANMAN
In generale prima di abilitare questa impostazione è bene effettuare un’attenta analisi della sicurezza all’interno dell’ambiente in cui viene attivata, infatti quando è attiva, nel registro eventi visto in precedenza è presente l’evento ID 31018
Figura 5 Event ID 31018
Che riporta in dettaglio quali chiavi di registro sono state modificate
Il valore del Registro di sistema AllowInsecureGuestAuth non è configurato con le impostazioni predefinite.
Valore del Registro di sistema:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
“AllowInsecureGuestAuth”=dword:0
Valore del Registro di sistema configurato:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
“AllowInsecureGuestAuth”=dword:1
E le relative informazioni Aggiuntive
Informazioni aggiuntive:
Questo evento indica che un amministratore ha abilitato gli accessi non sicuri come Guest. Un accesso non sicuro come Guest si verifica quando un server esegue l’accesso dell’utente come Guest non autenticato, in genere in risposta a un errore di autenticazione. Gli accessi come Guest non supportano funzionalità di sicurezza standard come la firma e la crittografia. Come risultato, consentire gli accessi come Guest rende il client vulnerabile ad attacchi man-in-the-middle che possono esporre dati sensibili nella rete. In Windows, gli accessi non sicuri come Guest sono disabilitati per impostazione predefinita. Microsoft sconsiglia di abilitare gli accessi non sicuri come Guest.
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++
}
}
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:
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://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
- https://www.ictpower.it/sistemi-operativi/deploy-pki-in-windows-server-2016-parte-1-architettura-di-una-pki-two-tier.htm
- https://www.ictpower.it/sistemi-operativi/deploy-pki-in-windows-server-2016-parte-2-installazione-e-configurazione-di-una-root-ca-offline.htm
- https://www.ictpower.it/sistemi-operativi/deploy-pki-in-windows-server-2016-parte-3-installazione-subordinate-ca.htm
Appunti e note tecniche 