Perché adottare il Digital Workspace

Le aziende di ogni dimensione stanno adottando il Digital Workspace per garantire agli utenti l’accesso a tutte le app, a tutti i servizi e a tutte le risorse da qualsiasi dispositivo (desktop, tablet e smartphone), ovunque e in qualsiasi momento.

Che cos’è il Digital Workspace? Quali sono i vantaggi offerti dal Digital Workspace alla tua azienda e alla tua organizzazione IT?

Segui un corso accelerato sul Digital Workspace per scoprire come partire con il piede giusto. Oggi è possibile grazie alla nuova VMware Special Edition della guida Secure Digital Workspace For Dummies, realizzata dai nostri esperti Pam Takahama, Josue Fontanez e Tricia Stream. Scopri tutto ciò che c’è da sapere sul Digital Workspace, sui vantaggi, sugli aspetti tecnici e sulle potenziali insidie.

Non importa in quale fase di adozione del Digital Workspace si trovi la tua azienda, l’importante è avere intrapreso questo percorso. Sempre più spesso, gli utenti si aspettano un’esperienza coerente indipendentemente da dove, quando e come accedono all’ambiente di lavoro. La risposta, come sottolineato dalla Dummies Guide, è il Digital Workspace.

“I dipendenti richiedono un’esperienza uniforme su qualsiasi dispositivo personale o aziendale, senza dover ricorrere a complicate configurazioni IT. Desiderano anche avere la certezza che i dati personali e quelli aziendali siano separati affinché venga rispettata la loro privacy. Lo stesso vale per le applicazioni, da quelle legacy, alle app native per il cloud, alle mobile app e alle app virtuali. Ai dipendenti non importa come queste applicazioni vengono distribuite: desiderano solo che tutte le applicazioni necessarie siano disponibili al momento opportuno.

In che modo la tua azienda è in grado di supportare la nuova area di lavoro definita in base all’identità per diverse tipologie di utenti (ad esempio, dipendenti di negozi al dettaglio consociati che controllano l’inventario tramite PC e smartphone, medici ospedalieri che immettono i risultati dei test usando workstation portatili e iPad o consulenti finanziari che fanno contrattazioni da dispositivi Android e laptop)?

La risposta è il Digital Workspace”.

Scarica ora una copia gratuita della guida “Secure Digital Workspace For Dummies” per promuovere la trasformazione digitale della tua azienda.

Per saperne di più:

Switch delle shell Linux con Windows 10 WSL

Sono passati 9 mesi dal rilascio di Windows 10 Anniversary Update, l’aggiornamento del sistema operativo che ha introdotto la funzionalità Windows Subsystem for Linux (WSL), grazie alla quale è possibile eseguire su Windows i binari di tipo ELF64, compilati cioè per funzionare su un sistema operativo Linux.

All’interno della community ICTPower ci siamo spesso occupati di questa nuova funzionalità, poiché ribadisce con forza la volontà di Microsoft di avvicinare il mondo dell’Open Source, e costituisce quindi una delle novità più importanti della politica aziendale degli ultimi tempi.

Rimandiamo quindi agli articoli precedenti in cui abbiamo illustrato gli step per l’installazione di questa funzionalità:

https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm

e mostrato come sostituire l’immagine di Ubuntu di default con una contenente Suse:

https://www.ictpower.it/guide/opensuse-in-windows-subsystem-for-linux-in-windows-10.htm

In questo articolo, invece, presentiamo un progetto molto interessante che è possibile trovare su github, chiamato WSL Distribution Switcher. Come è possibile intuire dal nome si tratta di un tool in grado di tenere installate sul nostro client Windows 10 molteplici distribuzioni di Linux, ed impostare quella in uso con WSL con un semplice comando.

Finalmente, quindi, ognuno è libero di utilizzare la propria distribuzione preferita, e l’occasione è imperdibile per chi si sta avvicinando al mondo Linux per la prima volta per provare le differenze tra le varie distribuzioni senza creare un numero enorme di macchine virtuali, e scegliere quella più adatta alle proprie esigenze. L’occasione è imperdibile anche per me, poiché utilizzando in maniera molto più agevole CentOS rispetto alle altre, finalmente ho la possibilità di farlo anche con WSL.

Come premessa riporto la pagina del progetto è la seguente, in modo da poterla seguire per tutti gli aggiornamenti futuri:

https://github.com/RoliSoft/WSL-Distribution-Switcher

Il tool è costituito da una serie di immagini, una per ogni distribuzione di Linux, ed uno script per effettuare lo switch da una distribuzione all’altra. Lo script è scritto in Python, un linguaggio di programmazione molto semplice e dinamico, e quindi abbiamo bisogno di installare le relative librerie per utilizzarlo.

Scarichiamo l’ultima versione di Python3 dal sito python.org, ad oggi troviamo la versione 3.6.1 disponibile a questo link:

https://www.python.org/ftp/python/3.6.1/python-3.6.1-amd64.exe

ed installiamo il pacchetto lasciando le impostazioni di default:

Scarichiamo quindi il pacchetto contenente il tool dall’indirizzo:

https://github.com/RoliSoft/WSL-Distribution-Switcher/archive/master.zip

Ed estraiamo l’archivio, ad esempio nella cartella Download

Nel mio caso particolare tutti i file sono nella cartella:

C:\Users\ICTPower\Downloads\WSL-Distribution-Switcher-master

Apriamo una PowerShell e posizionamoci in questa cartella. Per eseguire semplicemente questa operazione è possibile scrivere “powershell” nella barra degli indirizzi della cartella stessa, ed avviamo il download della distribuzione desiderata utilizzando lo script get-source. Iniziamo, ad esempio, scaricando un’immagine di CentOS con il comando:

py.exe .\get-source.py centos

Allo stesso modo è possibile effettuare il download di debian, fedora, suse ed alpine; in futuro saranno sicuramente disponibili immagini di altre distribuzioni. Per eseguire lo step successivo è necessario che WSL sia installato ma non attivo, quindi non dovranno essere aperte istanze di Windows bash al momento dell’esecuzione del comando altrimenti lo script restituirà un errore.

Scaricata l’immagine la installiamo con:

py.exe .\install.py centos

Al termine delle operazioni l’immagine appena installata diventa quella di default all’apertura di Windows bash, verifichiamolo subito aprendo una shell eseguendo dal prompt dei comandi:

bash

e leggiamo il contenuto del file /etc/os-release, che nelle distribuzioni CentOS ci da un po’ di informazioni sulla versione in uso

cat /etc/os-release

Come possiamo vedere ci troviamo su una CentOS7, loggati nel sistema con l’utente creato in fase di installazione di WSL. Nel mio caso il nome dell’utente è gnanoia. Ho trovato un problema nell’eseguire il comando “su” e guadagnare i privilegi di root. Al momento della richiesta della password, infatti, questa non veniva riconosciuta. Non avendo modo di indagare se il problema fosse dovuto alla versione dell’immagine, alla mia build di Windows10 o ad altri fattori, ho trovato un rapido workaround settando l’utente root come predefinito all’apertura di Windows bash; in questo modo la shell viene avviata senza la richiesta di alcuna password ed è possibile eseguire il comando “passwd” per settarne una nuova. E’ poi possibile reimpostare l’utente non privilegiato come predefinito per tornare alla condizione iniziale.

E’ possibile modificare l’utente predefinito di WSL utilizzando il comando lxrun /setdefaultuser <user>, quindi nel nostro caso eseguiamo da un prompt di DOS:

lxrun /setdefaultuser root

quindi apriamo bash e modifichiamo la password con il comando

passwd

chiudiamo la shell di root con

exit

chiudimo la shell iniziale per tornare al DOS con

exit

e risettiamo l’utente iniziale come predefinito. Nel mio caso:

lxrun /setdefaultuser gnanoia

Tutta la sequenza è visibile nello screenshot seguente:

Proviamo ora ad avviare bash ed utilizzare su per utilizzare la shell con privilegi amministrativi:

Ora la nostra immagine Centos7 è completa e funzionante, e possiamo utilizzare il gestore dei pacchetti yum per installare i nostri software preferiti.

Da un’analisi più approfondita però sono emerse delle limitazioni dovute alla tenera età di WSL, per cui non risulta possibile installare alcuni pacchetti, probabilmente per la mancanza del supporto ad alcune syscall; non ci rimane che essere pazienti e sperare che questa funzionalità cresca il più velocemente possibile chissà che nella prossima build di Windows10 non sia già tutto perfettamente funzionante.

In particolare i test di installazione sono falliti per iptools ed httpd, nello screenshot seguente vediamo il dettaglio dell’errore:

yum install httpd

Alla fine dell’elaborazione del comando il risultato sarà quello mostrato in figura:

Senza allarmarci troppo, quindi, fiduciosi di una rapida risoluzione, non perdiamo troppo di vista lo scopo dell’articolo, e torniamo all’installazione di distribuzioni alternative di Linux per WSL, provando ad effettuare in maniera rapida lo switch da una all’altra.

Torniamo quindi sulla nostra PowerShell per scaricare ed installare un’immagine di debian.

Come per l’installazione precedente, lo script imposta l’ultima immagine installata come predefinita, quindi avviando Windows bash ci aspettiamo di trovare una shell Debian. Infatti…

Per switchare da una distribuzione all’altra non è ovviamente necessario reinstallarla, quindi volendo tornare ad utilizzare CentOS, od una qualsiasi altra distribuzione già installata possiamo ricorrere allo script per lo switch:

py.exe .\switch.py centos

Verifichiamo che l’operazione ha avuto successo riaprendo bash e leggendo il file /etc/os-release

Ringraziamo sentitamente gli autori dello script, e rimaniamo in attesa della disponibilità delle nostre immagini preferite; anche in questo caso non possiamo fare a meno di notare che l’avvicinamento di Microsoft al mondo dell’Open Source sta scatenando una miriade di contributi di chi, ognuno a modo proprio, cerca di favorire la completa integrazione dei sistemi.

VMUG.it riparte: prima tappa Padova 5 Aprile

Dopo la celebre UserCON di Novembre dell’anno scorso, siamo pronti a partire con una nuova serie di eventi in Italia: prima tappa Padova 5 Aprile 2017.

Grazie al connubio tra sessioni a cura dei vendor e interventi provenienti dalla community, sono in programma i seguenti incontri:

  • 5 Aprile Padova
  • 17 Maggio Roma
  • 14 Novembre UserCON

L’evento di Padova

In breve:

  • Quando: 5 Aprile 2017 dalle ore 8:30 fino alle 17:30
  • Dove: Padova presso Hotel Crowne Plaza (Indicazioni stradali qui )
  • Costo: Ovviamente 0
  • Registrazione: Qui

Agenda:

  • ore 8:30 Registrazione
  • ore 9:10 Welcome by Leaders
  • ore 9:30 SAP HANA on vSphere by Enrico Ongaro (VMWare)
  • ore 10:15 Check Point: sicurezza a 360° – Cloud, Mobile e Threat Prevention by David Gubiani (Checkpoint)
  • ore 11:00 Coffee break
  • ore 11:20 Green Padlock : A survival guide to vsphere SSL certificates by Marco Scandaletti
  • ore 12:05 Introducing NAKIVO Backup & Replication v7 by Tullio Cozza, (CEO OmninNet srl, Nakivo partner)
  • ore 12:40 Pranzo
  • ore 14:00 Photon Controller 1.1.1 Live demo by Alan Civita (Sky UK)
  • ore 14:45 Rubrik: questo è Cloud Data Management! by Giampiero Petrosi (Sales Engineering – Rubrik)
  • ore 15:20 Ask the vExpert
  • ore 17:00 Saluti

Sponsor dell’evento:

Print

 

Altri appuntamenti

Per gli amici del centro-sud è corso di definizione dettagli e agenda dell’evento di Roma. Ma non è finita qui: stiamo preparando un evento anche a Napoli. Stay tuned!

 La UserCON

Sono iniziati anche i preparativi per la UserCON 2017. Come mai così presto? Si dice che per fare le cose in grande occorre avere il giusto tempo per organizzarle! Il successo dell’anno scorso deve essere il nostro nuovo punto di partenza per rendere il vmug un posto sempre più bello dove condividere esperienze ed essere al passo coi tempi sulle tecnologie di virtualizzazione e cloud.

Ricordate: il vmug siete voi! Proponete e Intervenite numerosi.

Riferimenti:

website: http://www.vmug.it

e-mail: info@vmug.it

twitter: @vmugit

NAKIVO v7 release

Dopo alcuni mesi di public beta, NAKIVO Backup & Replication v7 esce allo scoperto con diverse novità sia per VMware vSphere che per Microsoft Hyper-V. Tra le novità della nuova versione di questo prodotto di backup e replica delle VM, vi sono: Supporto per VMware vSphere v6.5: allineandosi ad altri programmi di backup che già supportano la nuova versione di vSphere, anche NAKIVO è in grado di gestire VM su 6.5, sia per il backup che per la replica.Supporta anche alcune nuove funzionalità di vSphere come VM attribute, encrypted VM, … Supporto per Hyper-V 2016 e 2012 R2): supporta sia il […]

The post NAKIVO v7 release appeared first on vInfrastructure Blog.

SharePoint Server: Sincronizzazione con Active Directory – Parte seconda

Premessa

A partire da SharePoint 2013 sono stati apportati sensibili miglioramenti ai meccanismi di sincronizzazione con Active Directory.

Nell’articolo SharePoint Server: Sincronizzazione con Active Directory – Parte prima abbiamo introdotto Active Directory Import (ADI), feature che permette di non utilizzare i servizi di Forefront Identity Management (FIM) per accedere ad Active Directory.

Abbiamo anche elencato le operazioni preliminari all’implementazione di ADI:

  • Creare una Web Application e una Site Collection per i “My Sites”;
  • Creare un’istanza della User Profile Service Application.

In questo articolo proseguiamo le attività impostando la sincronizzazione con Active Directory per poi effettuare il match delle informazioni raccolte da ADI con le proprietà dei profili utente gestiti da SharePoint.

Come già specificato, tutte le operazioni vanno svolte utilizzando un account con privilegi di Farm Administrator facente parte del gruppo locale Administrators dei server SharePoint.

Configurare le Connection Properties

Accedere al sito della Central Administration di SharePoint e, in Application Management, fare clic su Manage Service Application.

Nella pagina Manage
Service
Applications fare clic su nome della User Profile service application.

Figura 1 – Manage service applications

Nella pagina Manage Profile Service, sezione Synchronization, clic su Configure Synchronization Connections.

Figura 2 – Configure Synchronization Connections

Nella pagina Synchronizations
Connections fare clic su Create New Connection.

Figura 3 – Synchronizations Connections

Nella pagina Add new synchronization
connection, nella casella di testo Connection Name digitare il nome che si intende dare alla synchronization connection (ad esempio “ADI Sync”) e nell’elenco Type selezionare Active Directory Import.

Nella casella Fully Qualified Domain Name digitare il FQDN del dominio Active Directory (nel nostro caso demolab.local). Qualora necessario, specificare un Autentication Provider diverso da “Windows Authentication” a seconda delle caratteristiche della Web Application a cui afferisce la Site Collection dei “My Sites” (vedi prima parte di questa serie di articoli).

Nella casella Account digitare il nome che sarà utilizzato da ADI per effettuare la sincronizzazione con Active Directory, nell’esempio DEMOLAB\ADRepUser. Questo account è stato precedentemente configurato in modo che abbia i privilegi di Replicate Directory Changes a livello di dominio (vedi articolo precedente).

Nelle caselle Password e Confirm password digitare la password del suddetto account.

Figura 4 – Add new synchronization connection (1)

È possibile filtrare gli utenti disabilitati e specificare una query LDAP per sincronizzare solo alcuni oggetti. Ad esempio, con la query

    (&(objectCategory=person)(objectClass=user))

si estraggono solo gli oggetti di tipo “user”.

Figura 5 – Add new synchronization connection (2)

Maggiori informazioni sulle query LDAP possono essere trovate qui: https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx

Nella sezione Containers fare clic su Populate Containers e selezionare le OU e i containers che si intendono sincronizzare, poi fare clic su OK.

Nota: selezionando una OU vengono automaticamente selezionare anche tutte le sotto-OU.

Figura 6 – Add new synchronization connection (3)

Nella pagina Synchronizations
Connections viene inventariata la nuova connection appena creata.

Figura 7 – Connection creata e disponibile

Abbinare le proprietà degli User Profile agli attributi di Active Directory

Nella Central Administration, in Application Management, fare clic su Manage Service Application.

Nella pagina Manage
Service
Applications fare clic su nome della User Profile service application.

Nella pagina Manage Profile Service, sezione People, clic su Manage User Properties.

Figura 8 – Manage User Properties

Nella pagina Manage User Properties fare clic con il tasto destro sul nome della proprietà che si desidera abbinare ad un attributo preso da Active Directory e fare clic su Edit.

Figura 9 – Abbinamento User Properties

Per aggiungere un nuovo abbinamento, nella sezione Add New Mapping, nell’elenco Source Data Connection, selezionare la Data Connection che rappresenta il servizio di directory a cui vogliamo relazionarci (nel nostro esempio “ADI Sync”).

Nella casella di testo Attribute occorre poi digitare il nome dell’attributo presente in Active Directory a cui si desidera abbinare la proprietà, ad esempio “Description”, poi fare clic su Add.

Figura 10 – Add New Mapping

La stessa operazione va ripetuta per ogni ulteriore proprietà che vogliamo abbinare ad un attributo di Active Directory.

Avviare la sincronizzazione dei Profili

A questo punto siamo pronti per avviare la sincronizzazione dei profili: nella Central Administration, sezione Application Management, fare clic su Manage Service Application.

Nella pagina Manage Service Applications, fare clic su User Profile Service Application.

Nella pagina Manage Profile Service, nella sezione Syncronization, fare clic su Start Profile Syncronization.

Nella pagina Start Profile Synchronization fare clic su Start Full Syncronization.

Figura 11 – Avvio della sincronizzazione dei profili

Qualora sia stata già effettuata una sincronizzazione in precedenza, è anche possibile utilizzare l’opzione Start Incremental Syncronization.

Nel prossimo articolo

Nella terza parte di questa serie affronteremo l’integrazione di SharePoint Server 2016 con Microsoft Identity Management Server 2016, prodotto che sebbene richieda un server dedicato aumentando di fatto la complessità dell’infrastruttura, porta con sé alcune funzionalità di grande interesse, fra cui il supporto a scenari multi-foresta e la bidirezionalità del flusso con Active Directory.

Deploy PKI in Windows Server 2016 – Parte 2 – Installazione e configurazione di una Root CA Offline

L’implementazione di una Certification Authority (CA) nella propria infrastruttura prevede una preventiva analisi della struttura della Public Key Infrastructure (PKI) più adatta alla propria organizzazione e la predisposizione dei prerequisiti necessari. La trattazione delle componenti di una PKI e della configurazione di un server web per la pubblicazione della CRL e dei certificati delle CA è disponibile nel precedente articolo Deploy PKI in Windows Server 2016 – Parte 1.

Di seguito analizzeremo l’installazione e la configurazione di una Root CA Offline, nell’ipotesi di voler realizzare una CA Two-Tier (a due livelli) facendo riferimento al seguente schema che verrà utilizzato come scenario di esempio.

La Root CA viene mantenuta normalmente spenta, di conseguenza è preferibile che non sia integrata in Active Directory e quindi dovrà essere Standalone e non Enterprise, mentre la Subordinate CA a cui verrà demandano il compito di rilasciare i certificati sarà di tipo Enterprise per beneficiare dell’utilizzo dei modelli di certificato e dell’integrazione con Active Directory.

Sebbene spesso la giustificazione del fatto che la Root CA Offline è preferibile che sia non joinata ad un domino Active Directory, e quindi Standalone e non Enterprise, sia imputata al fatto che la scadenza della password dell’account computer che per default avviene ogni 30 giorni, causando l’impossibilità di utilizzare il secure channel. In realtà come indicato nel post Machine Account Password Process dal momento che il processo di rinnovo della password dell’account computer è avviato dal client non vi alcun rischio che il secure channel non possa essere utilizzato anche se la Root CA viene mantenuta spenta per lunghi periodi.

“Question: If a workstation does not change its password, will it not be allowed to log onto the network?

Answer: Machine account passwords as such do not expire in Active Directory. They are exempted from the domain’s password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.

So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time.

Before we set the new password locally, we ensure we have a valid secure channel to the DC. If the client was never able to connect to the DC (where never is anything prior the time of the attempt – time to refresh the secure channel), then we will not change the password locally.”

In realtà il vero motivo per cui è preferibile la Root CA sia Standalone è che per avere un’elevata sicurezza non dovrebbe essere connessa alla rete neppure quando viene avviata saltuariamente per installare gli aggiornamenti automatici, ma attestata su una rete separata che consenta la comunicazione con l’infrastruttura solo per permettere l’aggiornamento della CRL e del certificato della CA sul server web che si occupa di pubblicarli.

Per ulteriori informazioni si vedano:

Installazione e configurazione della Root CA Offline

Per configurare il servizio di CA occorre aggiungere il ruolo Active Directory Certificate Services selezionando l’installazione del servizio Certification Autority.

Terminata l’installazione è possibile configurare il servizio della CA in base alle seguenti impostazioni utilizzando le credenziali di amministratore locale.

Tipo installazione CA Standalone
Tipo CA Root
Provider servizio di crittografia RSA#Microsoft Software Key Storage Provider
Lunghezza chiave 4096
Algoritmo hash per firma certificati SHA512
Nome ICTPower Root CA
Validità certificato CA 20 anni
Validità certificati emessi dalla CA 10 anni
Path database e logs S:\Windows\system32\CertLog
Path certificato CA e CRL C:\Windows\System32\CertSrv\CertEnroll

Per sicurezza il nome della CA non fa alcun riferimento all’hostname del server e il database dei certificati viene mantenuto in un disco separato da quello di sistema.

Configurazione Estensioni della Root CA Offline per impostare i CRL (Certificate Revocation List) Distribution Points (CDP)

Lo scopo delle estensioni CRL CDP è quello di indicare ai client dove trovare le CRL aggiornate firmate dalla CA, tali informazioni verranno poi inserite nei certificati generati dalla CA.

Per impostazione predefinita vi sono quattro CRL CDP già configurati e su alcuni di essi occorre eseguire alcune impostazioni affinché l’unico riferimento alla CRL che verrà inserito nei certificati rilasciati sia quello dell’URL del server Web che pubblica la CRL. Nello scenario di esempio l’URL di pubblicazione della CRL è http://crl.ictpower.local/CertEnroll.

Il CRL CDP locale è usato dalla CA e non necessita di essere modificato.

Il CRL CDP ldap deve essere modificato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Il CRL CDP http è già impostato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Il CRL CDP file deve essere modificato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Creare un CRL CDP per l’URL http con le opzioni di inclusione nella CRL per l’URL http://crl.ictpower.local/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl.

Applicare le modifiche riavviando i servizi della CA.

Configurazione Estensioni della Root CA Offline per impostare gli Access Information Access (AIA) Distribution Points (CDP)

Lo scopo delle estensioni AIA CDP è quello di indicare ai client dove trovare il certificato della CA per eseguire la verifica dell’attendibilità nel caso in cui il certificato non contenga al suo interno la catena dei certificati, tali informazioni verranno poi inserite nei certificati generati dalla CA.

L’ AIA CDP locale per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato.

L’AIA CDP ldap per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

L’AIA CDP http per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

L’AIA CDP file deve essere modificato in modo da non essere incluso nei certificati, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

Creare un AIA CDP per l’URL http con le opzioni di inclusione nella CRL per l’URL http://crl.
ictpower.local/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt.

Applicare le modifiche confermando il riavvio dei servizi delle CA.

Configurazione della CRL della Root CA Offline

Impostare la pubblicazione della CRL ad un periodo superiore a quello a cui si prevede di avviare periodicamente la Root CA Offline che normalmente sarà mantenuta spenta. Tramite le proprietà dei Certificati revocati si imposta un intervallo di pubblicazione di 4 settimane ipotizzando che settimanalmente la CA sarà avviata per installare eventuali aggiornamenti del sistema.

Verificare in C:\Windows\System32\CertSrv\CertEnroll che la CRL sia stata pubblicata, è possibile avviare la pubblicazione della CRL tramite la voce del menu contestuale All Tasks\Pubblish dei Certificati revocati, oppure mediante il comando:

certutil -CRL

Configurazione della validità dei certificati emessi dalla Root CA Offline

Per default la validità dei certificati emessi da una CA Standalone è di un anno, ma tale impostazione è modificabile tramite certutil che a sua volata modificherà le impostazioni nel registro.

Dal momento che la durata del certificato della CA è stato impostato a 20 anni con previsione di rinnovo ogni 10 anni la validità dei certificati emessi verrà impostata a 10 anni tramite il comando:

certutil -setreg ca\ValidityPeriodUnits “10”

La chiave di registro in cui vene mantenuta tale impostazione è:

HKLM\System\CurrentControlSet\Configuration\CAName\ValidityPeriodUnitis

Al termine della configurazione riavviare il servizio della CA, ad esempio tramite il comando:

net stop certsvc & net start certsvc

Copia della CRL e del certificato della Root CA Offline su server Web per la pubblicazione della CRL

Per consentire l’accesso al server web da parte della Root CA Offline l’approccio più corretto è quello di creare sul server web un account con privilegi di lettura e scrittura su una share che punti alla cartella che conterrà le CRL e i certificati delle CA come illustrato nel precedente articolo Deploy PKI in Windows Server 2016 – Parte 1. Nello scenario di esempio sul server web Web01 si ipotizza che siano state eseguite le seguenti configurazioni:

  1. Creazione di un record DNS crl di tipo A per il server web consenta l’accesso a quest’ultimo tramite il nome crl.ictpower.local
  2. Creazione di un account CAUpdate che verrà utilizzato dal server Root CA e Subordinate CA per accedere alla cartella condivisa in cui copiare CRL e certificato CA.
  3. Creazione della share CertEnroll per concedere l’accesso in lettura e scrittura alla cartella S:\CertEnroll tramite l’account CAUpdate.

Sul server Root CA occorre quindi memorizzare sull’account che verrà utilizzato per aggiornare CRL e certificato CA sul server web le credenziali dell’account CAUpdate specificando come indirizzo del server crl.ictpower.local.

Aggiornare la CRL e copiare sul server web la CRL e il certificato CA della Root CA Offline tramite i comandi che possono anche essere eseguiti tramite un’operazione schedulata all’avvio della Root CA:

certutil -CRL
copy /Y “C:\Windows\System32\CertSrv\CertEnroll\*.crl” \\crl.ictpower.local\CertEnroll
copy /Y “C:\Windows\System32\CertSrv\CertEnroll\*.crt” \\crl.ictpower.local\CertEnroll

VMware ESXi 6.5: installare l’host dalla chiavetta USB

VMware ESXi 6.5: installare l’host dalla chiavetta USB

esxi65installfromusb01

Oggi non tutti i server sono equipaggiati con un drive CD-ROM e l’installazione di VMware ESXi 6.5 può essere effettuata facilmente tramite l’utilizzo di una chiavetta USB.

L’utilizzo di un drive USB rende il processo di installazione più veloce rispetto al classico CD-ROM drive.

 

Prerequisiti

Per creare l’installer USB sono necessari i seguenti componenti:

  • Una chiavetta USB da almeno 4 GB di capacità
  • Il file ISO VMware ESXi 6.5
  • Un tool come UNetbootin per rendere la chiavetta USB bootabile

 

Creare una chiavetta USB bootabile

Dal sito VMware effettuare lo scarico del file ISO VMware ESXi 6.5.

Avviare il tool UNetbootin e selezionare l’opzione Diskimage. Cliccare sul bottone browse () per selezionare l’immagine da utilizzare.

esxi65installfromusb02

Cliccare OK per creare la chiavetta USB bootabile.

esxi65installfromusb03

I file ESXi sono copiati nel drive USB.

esxi65installfromusb04

Quando il processo viene completato, cliccare su Exit per chiudere UNetbootin.

esxi65installfromusb05

 

Installare ESXi 6.5 dalla chiavetta USB

CConfigurare nelle impostazioni del BIOS del server la corretta sequenza di boot, inserire la chiavetta USB appena creata ed accendere il server. Il processo di installazione viene avviato caricando l’ESXi installer.

esxi65installfromusb06

Quando l’installazione viene completata correttamente, la console dell’ESXi viene visualizzata con le impostazioni di default.

esxi65installfromusb07

L’utilizzo della chiavetta USB permette agli amministratori di risparmiare parecchio tempo per l’installazione dell’hypervisor perchè è molto più veloce rispetto ai tradizionali CD-ROM drive.

signature

Copyright Nolabnoparty. All Rights Reserved.

SID 2017

Il SID (Server Infrastructure Day) è la conferenza IT Pro Business organizzata da Inside Technologies e dalla community WindowServer.it, dedicata a tutte le aziende, che ti permette di conoscere le novità dei prodotti e le best-practice di implementazione. Tutte le aziende hanno bisogno di essere sempre operative e di ridurre i costi di gestione; scopo della conferenza è di mostrare quali sono gli strumenti giusti per la vostra azienda e di studiare una strategia vincente per il futuro. L’edizione 2017 (la sesta) del SID si terrà il 14 e 15 giugno 2017 presso il Palazzo Lombardia […]

The post SID 2017 appeared first on vInfrastructure Blog.

Blog italiani (e in italiano) nel mondo IT/ICT