Archivi categoria: Datacenter

Rinominare un dominio di Active Directory

Facebooktwittergoogle_plusredditlinkedin

È possibile rinominare un dominio Active Directory? La risposta è affermativa ma spesso sottovalutata. A seconda delle dimensioni del dominio da rinominare, questa azione si può rivelare un incubo anche per il sysadmin più esperto: nel caso di procedura errata il rischio di bloccare un utente o di dover rifare le operazioni di join di una macchina al dominio è elevatissimo.

Contestualmente esistono numerosissime applicazioni incompatibili con tali attività.

Nel caso in cui foste costretti ad intraprendere questa strada, Microsoft ha rilasciato una lunga checklist che, se compresa e verificata attentamente, facilita di molto l’attività in oggetto.

Punti critici

Prima di prendere in considerazione l’azione di cambio nome, è necessario sapere che:

  • Il livello funzionale della foresta deve essere almeno Windows Server 2003;
  • Exchange Server 2003 è l’unico che supporta questa procedura;
  • Dopo aver rinominato il dominio è verranno rinominati anche i nomi degli host joinati;
  • In caso di foresta con domini figli, a seguito del cambio di nome e quindi di posizione del domain controller padre, sarà necessario ricreare le relazioni di trust affinché possano parlarsi nuovamente;
  • Le zone DNS dovranno essere create manualmente per il nuovo dominio;
  • Ogni membro del dominio deve essere riavviato due volte a seguito dell’aggiornamento del domain controller;
  • Il suffisso DNS dei membri del dominio rinominato potrebbe non essere corretto per un certo periodo di tempo. Di solito questa configurazione DNS viene aggiornata automaticamente in caso di modifiche al dominio. Il periodo di tempo per il quale potrebbe non essere corretto è proporzionale alle dimensioni del dominio.

Applicazioni non compatibili

  • Microsoft Exchange 2000
  • Microsoft Exchange 2007
  • Microsoft Exchange 2010
  • Microsoft Internet Security and Acceleration (ISA) Server 2004
  • Microsoft Live Communications Server 2005
  • Microsoft Operations Manager 2005
  • Microsoft SharePoint Portal Server 2003
  • Microsoft Systems Management Server (SMS) 2003
  • Microsoft Office Communications Server 2007

Preparazione ed esecuzione

Come prima cosa, assicuriamoci che la feature Remote Server Administration Tools sia installata.

Figura 1: Server Manager – Roles and features

Dobbiamo rinominare il dominio da contoso.local a laboratorio.local.

Predisponiamo, nel DNS primario, la nuova zona per il dominio:

Figura 2: DNS Manager – Creazione nuova zona

Figura 3: DNS Manager – Wizard – Tipo di zona

Figura 4: DNS Manager – Wizard – Replication scope

Figura 5: DNS Manager – Wizard – Nome zona

Figura 6: DNS Manager – Wizard – Gestione aggiornamenti

Figura 7: DNS Manager – Wizard – Riepilogo

Rimuoviamo l’associazione DNS con il vecchio dominio

Figura 8: DNS Manager – Rimozione zona

Figura 9: DNS Manager – Rimozione zona

Successivamente, da una macchina a dominio utilizzando il domain admin, eseguiamo una shell elevata ed eseguiamo il comando

rendom /list

Figura 10: Command line – Download XML

Il risultato sarà la generazione di un file xml, nel path dove viene eseguito il comando, che dovremo modificare

Figura 11: Modifica delle configurazioni

Modifichiamo ii nomi DNS e NetBios con quelli desiderati, nel mio caso:

Figura 12: XML – Modifica delle configurazioni

Verifichiamo le informazioni del dominio con il comando

rendom /showforest

Figura 13: Command line – Verifica configurazioni

Effettuiamo l’upload con il comando

rendom /upload

Figura 14: Command line – Upload

Verifichiamo che il dominio sia pronto ad effettuare il processo di ridenominazione con il comando

rendom /prepare

Figura 15: Command line – Preparazione ridenominazione

Eseguiamo la procedura con il comando

rendom /execute

Figura 16: Command line – Esecuzione

A questo punto il domain controller viene riavviato in maniera automatica.

A seguito del riavvio verifichiamo che la procedura sia andata a buon fine

Figura 17: Server Manager – Verifica dominio

Diverse configurazioni relative al nuovo nome dovranno essere eseguite a mano:

Figura 18: System Properties – Hostname errato

Il Full computer name del DC deve essere cambiato a mano. Per effettuare la ridenominazione, eseguire il comando

netdom computername LabDC.contoso.local /add:LabDC.laboratorio.local

Figura 19: Command line – Modifica hostname

Seguito dal comando

netdom computername LabDC.contoso.local /makeprimary:LabDC.laboratorio.local

Figura 20: Command line – Modifica hostname

Riavviamo il server, successivamente verifichiamo che sia stato rinominato correttamente

Figura 21: System Properties – Verifica hostname

Apriamo la console delle GPO

Cliccando sul nuovo nome configurato notiamo che punta ancora al vecchio dominio

Figura 22: Group Policy Management – Errore

Per correggere questo problema utilizziamo il comando

gpfixup /olddns:contoso.local /newdns:laboratorio.local

Figura 23: Command line – Fix GPO

seguito da

gpfixup /oldnb:CONTOSO /newnb:LABORATORIO

Figura 24: Command line – Fix GPO

A questo punto è necessario riavviare almeno due
volte tutti i server joinati al vecchio dominio in modo che recepiscano i cambiamenti avvenuti con la ridenominazione. Riavviare due volte assicura che ogni computer recepisca il cambio di dominio e propaghi a tutte le applicazioni le modifiche necessarie.

Attenzione: Il riavvio deve essere effettuato dopo aver fatto login sulla macchina. In caso di Power off e successivo avvio la procedura non funzionerà.

Una volta assicurati che tutti i membri del dominio siano allineati, proseguiamo con i comandi

rendom /clean

Figura 25: Command line – Pulizia dei riferimenti al vecchio dominio

infine

rendom /end

Figura 26: Command line – Termine delle configurazioni

In questo modo verranno rimossi i riferimenti al vecchio dominio.

Verifichiamo che lato DNS siano stati creati i record correttamente

Figura 27: DNS Manager – Verifica zona

Exchange

In caso di ridenominazione di AD con versioni di Exchange non supportate, sarà necessario creare una nuova foresta, installare nuovamente Exchange ed effettuare una migrazione dei contenuti esistenti.

Maggiori informazioni possono essere recuperate qui.

Una possibile soluzione in caso di Exchange incompatibile è registrare un nuovo dominio e creare delle regole di redirect in modo che le email inviate al vecchio dominio vengano inoltrate automaticamente ai nuovi indirizzi. In questo modo si evitano impatti agli utenti i quali utilizzeranno esclusivamente il nuovo indirizzo di posta.

Conclusioni

Con la dovuta attenzione ed una corretta analisi è possibile rinominare un dominio AD. In alcune situazioni attività del genere sono preferibili al rifacimento dell’intera infrastruttura ma se affrontate nel modo sbagliato possono diventare un incubo.

Per fortuna Microsoft fornisce tutte le informazioni necessarie per affrontare questa attività in sicurezza.

Classifica delle soluzioni Firewall e UTM secondo Gartner nel triennio 2015-2017

Facebooktwittergoogle_plusredditlinkedin

Introduzione

La corretta gestione di una moderna infrastruttura IT dipende principalmente dalle scelte dei prodotti software e una delle scelte più importanti è sicuramente la scelta della soluzione di sicurezza perimetrale ovvero firewall e unified threat management (UTM)

In questo articolo vi proponiamo un approccio basato sulla comparazione dei report di Gartner dell’ultimo triennio per analizzare l’evoluzione del posizionamento dei Vendor di soluzioni Enterprise Network Firewalls e Unified Threat Management (UTM) nel quadrante magico (QM) di Garner.

Lo scopo è quello di fornire una rapida panoramica di come, secondo Gartner, i Vendor si sono posizionati e di quale sia il loro l’attuale Trend senza fermarsi alla sola analisi dell’ultimo report annuale.

Sebbene Gartner divida in due report distinti i prodotti classificati Enterprise Network Firewalls da quelli classificati come Unified Threat Management (UTM) in questo articolo oltre ad analizzare i dati degli ultimi tre i report per ciascuna classificazione proveremo anche da fornire un’analisi globale per i vendor che sono stati valutati in entrambe le categorie.

Struttura dell’analisi

Gartner è una importante azienda nel mondo IT che si occupa di Analisi e ricerche di mercato/prodotto e advisoring e il cui obiettivo è quello di supportare le decisioni strategiche con consulenze e report che hanno lo scopo di fornire un punto di vista “super partes” sullo stato generale di un mercato, di una azienda o dei suoi prodotti.

Uno dei report prodotti da Gartner più famosi è il quadrante magico (QM) che è di semplice comprensione perché permette rapidamente di avere una panoramica, secondo Gartner, sul posizionamento che hanno gli attori del mercato. L’analisi del QM va però sempre approfondita con la lettura del documento a cui è affiancato in cui viene motivato in dettaglio le ragioni del posizionamento e che quindi vanno poi contestualizzate negli specifici scenari in cui si sta eseguendo la valutazione perché alcune motivazioni potrebbero essere poco influenti per le scelte necessarie. L’elenco dei Magic Quadrant è disponibile al seguente Gartner Magic Quadrant.

L’analisi dei Vendor di prodotti classificati da Gartner come Enterprise Network Firewalls è basata sui seguenti report:

Gartner definisce la categoria Enterprise Network Firewalls come i prodotti che offrono una protezione di tipo Next-Generation Firewalls (NGFWs):

“Next-generation firewalls (NGFWs) are deep-packet inspection firewalls that move beyond port/protocol inspection and blocking to add application-level inspection, intrusion prevention, and bringing intelligence from outside the firewall. An NGFW should not be confused with a stand-alone network intrusion prevention system (IPS), which includes a commodity or nonenterprise firewall, or a firewall and IPS in the same appliance that are not closely integrated.”

Una definizione più precisa della categoria viene fornita nella pagina sul sito di Gartner dedicata alla Reviews for Enterprise Network Firewalls:

“The enterprise network firewall market represented is still composed primarily of purpose-built appliances for securing enterprise corporate networks. Products must be able to support single-enterprise firewall deployments and large and/or complex deployments, including branch offices, multitiered demilitarized zones (DMZs), traditional “big firewall” data center placements and, increasingly, the option to include virtual versions for the data center. Customers should also have the option to deploy versions within Amazon Web Services (AWS) and Microsoft Azure public cloud environments.”

L’analisi dei Vendor di prodotti classificati da Gartner come Unified Threat Management (UTM) è basata sui seguenti report:

Gartner definisce la categoria Unified Threat Management (UTM)
come segue:

“Unified threat management (UTM) is a converged platform of point security products, particularly suited to small and midsize businesses (SMBs). Typical feature sets fall into three main subsets, all within the UTM: firewall/intrusion prevention system (IPS)/virtual private network, secure Web gateway security (URL filtering, Web antivirus [AV]) and messaging security (anti-spam, mail AV).”

Una definizione più precisa della categoria viene fornita nella pagina sul sito di Gartner dedicata alla Reviews for Unified Threat Management (UTM), Worldwide:

“Gartner defines the unified threat management (UTM) market as multifunction network security products used by small or midsize businesses (SMBs). Typically, midsize businesses have 100 to 1,000 employees. UTM vendors continually add new functions on the UTM platforms, and therefore they encompass the feature set of many other network security solutions, including, but not limited to:
• Enterprise firewall
• Intrusion prevention systems (IPSs)
• Remote access
• Routing and WAN connectivity
• Secure web gateway
• Secure email gateway
Therefore, this market focuses on the UTM products used by midsize businesses. Midsize organizations frequently manage the technology with in-house IT staff, or use a managed security service provider (MSSP) to handle the operational maintenance of the appliance, manage the configuration or handle the security monitoring.”

Nell’analisi saranno presi in considerazione i Vendor che sono stati inseriti nell’ultimo report disponibile al momento ovvero quello relativo all’anno 2017 e per semplicità di verranno ordinati in base ad uno Score calcolato sulla base del QM a cui verrà attribuito il seguente valore:

  • 4 = Leaders (execute well against their current vision and are well positioned for tomorrow)
  • 3 = Challengers (execute well today or may dominate a large segment, but do not demonstrate an understanding of market direction)
  • 2 = Visionaries (understand where the market is going or have a vision for changing market rules, but do not yet execute well)
  • 1 = Niche Players (focus successfully on a small segment, or are unfocused and do not out-innovate or outperform others)
  • 0 = Non Classificato

Lo Score attributo a ciascun Vendor, sulla base del quale sono stati ordinati dal valore maggiore a minore, è stato ottenuto con la seguente formula per pesare maggiormente il valore del QM degli ultimi anni:

  • Se QM 2017 > 0 allora lo Score vale (100* QM 2017) + (10 * QM 2016) + QM 2015
  • Se QM 2017 = 0 allora lo Score vale 0

L’obbiettivo è quello di ottenere una classifica del Vendor di soluzioni EPP ordinata in base al miglior posizionamento nei quadrante Gartner nel triennio e in base al miglior Trend di posizionamento nel corso degli anni.

Di seguito i tre MQ di Gartner relativi alla categoria Enterprise Network Firewalls sulla base dei quali è stata eseguita l’analisi:

Di seguito i tre MQ di Gartner relativi alla categoria Unified Threat Management (UTM) sulla base dei quali è stata eseguita l’analisi:

Risultato

Di seguito i Vendor della categoria Enterprise Network Firewalls ordinati in rispetto allo Score, calcolato sulla base delle considerazioni precedenti, dal valore maggiore al minore:

Vendor

QM 2015

QM 2016

QM 2017

Score

Trend

Check Point Software Technologies

4

4

4

444

«

Palo Alto Networks

4

4

4

444

«

Fortinet

3

3

4

433

­

Cisco

3

3

3

333

«

Huawei

1

1

3

311

­

Sophos

1

1

2

211

­

Forcepoint

0

1

2

210

­

AhnLab

1

1

1

111

«

Barracuda Networks

1

1

1

111

«

Hillstone Networks

1

1

1

111

«

Juniper Networks

1

1

1

111

«

Sangfor

1

1

1

111

«

SonicWall

1

1

1

111

«

Stormshield

1

1

1

111

«

WatchGuard

1

1

1

111

«

New H3C Group

0

0

1

100

In base alla classifica ottenuta i leader della categoria Enterprise Network Firewalls del triennio 2015-2017 sono Check Point, Palo Alto e Fortinet mentre Cisco mantiene stabilmente una buona posizione e Huawei sta aumentato la sua competitività. Non vi sono invece Vendor che hanno avuto un trend in discesa, inteso come cambio di quadrante rispetto alla posizione ottenuta nel report Gartner del 2017 confrontato col report del 2016.

Di seguito gli aspetti positivi evidenziati nel report Gartner del 2017dei primi 3 Vendor della classifica ottenuta:

Pro di Check Point:

  • Offerings: Check Point offers a large breadth of security products covering network, mobile and endpoint. It also offers a mobile security solution, which consists of a software container called Capsule (Workspace, Docs and Cloud) for both iOS and Android, Mobile Threat Prevention, and Capsule Connect/VPN. This makes the vendor a shortlist candidate for enterprises looking for an integrated and consolidated approach to their perimeter, endpoint and mobile security based on the maturity on their enterprise security.
  • Product Execution: Check Point offers a large number of firewall models to meet the requirements of all enterprise network types. Enterprise firewalls include the 12000, 13000, 15000, 21000, 23000, 41000 and 61000 series of appliances. In 2016, the vendor extended the integration capabilities for its vSEC virtual appliance line for VMware, Cisco ACI, KVM, Hyper-V, OpenStack, AWS, Google Cloud and Azure to support public cloud and highly virtualized infrastructure. This makes it a strong enterprise firewall vendor capable of meeting different enterprise deployment use cases.
  • Partners: Check Point has built a strong ecosystem of technology partners including software, server, and networking and managed services. Gartner strongly believes that security vendors should be able to identify and build product support and integration capabilities with the right technology providers to enhance their product offerings. Check Point also has a strong and well-established channel globally, through its partner program.
  • Features: Check Point’s enterprise firewalls offer strong web filtering capabilities with a combination of application control, URL filtering and DLP. It offers mature URL filtering capabilities with multiple end-user block and information pages. It allows end users to explain their reason to bypass policy. It also offers a user check feature to alert users in real time about their application access limitations, while educating them on internet risk and corporate usage policies. Both application control and URL filtering operations can be performed within the same rule. This makes these firewalls a desirable candidate for enterprises that are considering consolidating their web proxy and require granular web filtering capabilities in their firewall. Clients frequently comment that the Check Point roadmap aligns very well to their enterprise needs of tomorrow, imbuing strong client retention, especially in high-compliance environments.
  • Central Management: Check Point continues to lead the market with its strong, robust centralized management offering, which makes it a desirable vendor for complex firewall policy environments, such as deployments by very large enterprises and organizations that need formal approval workflow, have complex topologies, are subject to compliance that requires reliable reporting or have large operations teams. Even the surveyed VARs and customers have rated this to be the vendor’s strongest feature, and competitors acknowledge Check Point’s leadership in this domain.

Pro di Palo Alto:

  • Marketing Execution: Palo Alto Networks is the pure-play security vendor with the highest visibility on enterprise firewall shortlists. The vendor is visible on shortlists across all industries. Presales support is efficient, and the vendor very frequently comes out from shortlists with the highest overall evaluation score.
  • Sales Execution: Palo Alto Networks maintains a very high growth rate. With a list price of $1,000, the new PA-220 allows the vendor to target smaller branches. WildFire, the vendor’s sandboxing option, has the highest attach rate and the largest customer base of all vendors evaluated in this research.
  • Capabilities: The Application Command Center (ACC) includes visibility of sanctioned and unsanctioned SaaS applications. Combined with its automated event aggregation and filtering and drill-down options, it makes it easy to understand application flows and related risks.
  • Customer Experience: Palo Alto Networks has a faithful customer base and scores very highly for overall customer satisfaction. Many clients report that they will renew without performing a competitive assessment and that they recommend the product to their peers. Several clients give good scores to vendor support in North America, and to the vendor’s ability to meet expected performance in production environments.
  • Improvements: The vendor has initiated a refresh of its firewall appliances (PA-800 Series, PA-5200 Series and PA-220), with upgraded performance and a higher number of decrypted concurrent TLS connections. WildFire regional cloud options are available in Europe and Asia.

Pro di Fortinet

  • Marketing Execution: Fortinet has improved its visibility in final two vendor shortlists for enterprise firewalls, being frequently the finalist against one of the other two leaders. Surveyed channel partners acclaim Fortinet’s assistance during RFP and implementation.
  • Sales Strategy: Fortinet excels in providing the best price/performance offers, relying on the combined use of an extensive appliance portfolio, good total cost of ownership for bundles and a flexible discount strategy. The vendor grows much faster than the market average.
  • Customer Experience: Fortinet’s clients gives excellent scores to its firewall performance and hardware quality.
  • Capabilities: Customers not using centralized management tools liked the improved visibility they get from the FortiView reports. Fortinet customers also mentioned ease of deployment as a strong point.
  • Market Segmentation: Fortinet’s latest chassis models (7000 Series) reinforce its ability to serve the performance required in large data centers.

Di seguito i Vendor della categoria Unified Threat Management (UTM) ordinati in rispetto allo Score, calcolato sulla base delle considerazioni precedenti, dal valore maggiore al minore:

Vendor

QM 2015

QM 2016

QM 2017

Score

Trend

Check Point Software Technologies

4

4

4

444

«

Fortinet

4

4

4

444

«

Sophos

4

4

4

444

«

Cisco

3

3

3

333

«

SonicWall

3

3

3

333

«

WatchGuard

2

2

2

222

«

Juniper Networks

3

3

1

133

¯

Barracuda Networks

1

1

1

111

«

Hillstone Networks

1

1

1

111

«

Huawei

1

1

1

111

«

Rohde & Schwarz Cybersecurity

1

1

1

111

«

Stormshield

1

1

1

111

«

Untangle

0

1

1

110

«

Venustech

0

1

1

110

«

In base alla classifica ottenuta i leader della categoria Unified Threat Management (UTM) del triennio 2015-2017 sono Check Point, Fortinet e Sophos, mentre Cisco e SonicWall mantengono stabilmente una buona posizione, Juniper Networks ha invece avuto un trend in discesa, inteso come cambio di quadrante rispetto alla posizione ottenuta nel report Gartner del 2017 confrontato col report del 2016.

Di seguito gli aspetti positivi evidenziati nel report Gartner del 2017dei primi 3 Vendor della classifica ottenuta:

Pro di Check Point

  • Market understanding: Check Point continues to make investments to address SMB clients and MSSP requirements. Its recently announced Check Point Infinity relies on principles that appeal to smaller organizations with multifunction platforms, a block-first strategy and intuitive management for small teams.
  • Management console: Check Point’s reporting and management console and on-device GUIs are consistently rated very highly by midsize companies that need to handle complexity. R80 introduced integrated application control directly in the access policy. A SaaS discovery report is available.
  • Capabilities: Check Point’s UTM solutions benefit from its enterprise-level security features, such as the Anti-Bot option, threat intelligence feeds and credible intrusion prevention system (IPS), backed up by a robust threat research team. Its solutions consistently get high scores in independent testing for threat detection rate. Check Point’s sandboxing solution is now available for all of its firewall models.
  • Capabilities: Check Point provides a strong set of network options to protect against custom malware with its sandboxing subscription (SandBlast Emulation Service), a variety of threat intelligence feeds (ThreatCloud IntelliStore) and a feature that can automatically remove suspected harmful content from downloaded files (Threat Extraction).
  • Customer experience: Partners and customers note that creating and using objects easily is a particular strength. Some clients report that the compliance blade can facilitate audits of configuration in regulated environments. Client feedback on the new software versions in the R80.x family has been positive.
  • Marketing and sales execution: 2016 saw a clear uptick of SMBs opting for NGTP and NGTX feature bundles, allowing these organizations to utilize advanced security features without the complexity of having to buy and deploy eight to 10 software blades individually.

Pro di Fortinet

  • Geographic strategy: Fortinet has the largest channel presence across all regions, and its customer base is vastly distributed. Vendor support centers are available in 10 countries. In 2016, the vendor announced the opening of a European data center, based in Germany, for its FortiCloud and FortiSandbox features.
  • Marketing and sales execution: Fortinet is the clear leader in this market. It is the most visible vendor in SMB multifunction firewall client shortlists observed by Gartner. Fortinet is profitable, and its 2016 revenue grew almost twice as fast than the market average. It is also the vendor most frequently cited as being the strongest competitor in this market by surveyed resellers.
  • Customer experience: Fortinet provides very good performance and pricing to its SMB customers. Results from survey and Gartner client inquiries are consistent in highlighting this.
  • Capabilities: Fortinet’s security services are driven by a large threat research team. Dedicated application profiles for SaaS visibility and control are also available.
  • Market understanding: Fortinet offers integration between many products in its portfolio, including firewalls, endpoint, wireless access point and switches. The concept, named Fortinet Security Fabric, gives customers willing to invest in multiple Fortinet solutions a unified view of their infrastructure and the ability to manage AP and switches directly from the Fortigate console. It also allows integration with Fortinet’s endpoint solution (FortiClient) to perform a health check before authorizing a connection to the network.

Pro di Sophos

  • Capabilities: A majority of surveyed customers and partners mention security feature richness and breadth as a reason for the selection of Sophos. Continued execution on an aggressive roadmap has strengthened prospective buyers’ view of Sophos UTM as a security leader.
  • Sales execution: Sophos has a significant IaaS presence relative to most UTM competitors. The SG line has an integrated Web Application Firewall feature, which is useful in making Sophos UTM increasingly relevant to public cloud deployments.
  • Capabilities: Sophos customers and partners cite on-box UI quality and the ease with which they can interact with it as strong positives.
  • Technical architecture: With Security Heartbeat, the recently added capability to isolate endpoints missing a heartbeat, Sophos Synchronized Security is maturing and has become a recognized differentiator. The feature is tightly integrated in the management interface and provides a unified dashboard. It is still evolving, but shows increasing promise in enhancing the security posture of midmarket organizations willing to make the effort to integrate firewall and an endpoint.
  • Customer experience: Sophos is the only UTM vendor to offer three months of free support, along with a one-year warranty for customers that want to try Sophos UTM before committing to paying for a support contract.

Di seguito invece gli aspetti negativi dei Vendor che hanno avuto un trend in discesa rispetto al 2016:

Contro di Juniper Networks

  • Product strategy: Juniper’s product strategy lacks focus for SMB security use cases. Its product strategy and roadmap are more focused toward enterprises and carrier-class requirements.
  • Capabilities: Juniper SRX still lacks features desired by SMBs, such as strong, mobile VPN clients, enduser quarantine for spam, and endpoint security management. It has just released SSL encapsulation of IPsec traffic for remote hosts as a work-around for its lack of native SSL VPN capabilities. The vendor does not offer cloud-based management of Juniper SRX, which can be an important feature for cloud enthusiast industries, such as retail and education.
  • Sales execution: Juniper is hardly visible in SMB multifunction firewall client shortlists observed by Gartner. The vendor is quickly losing market share.
  • Advanced malware prevention: Juniper’s advanced malware prevention subscription known as Sky ATP is not available on smaller UTM models SRX 110 and SRX 220d 200. Sky ATP can inspect HTTP and HTTPS, but does not support IMAP. The vendor has only released support for SMTP in March 2017.
  • Technical architecture: Juniper lacks an EPP offering. Juniper security information and event management (SIEM) supports many third-party endpoint solutions, but there is not yet any integration between SRX firewalls and third-party endpoint protection platform vendors. The vendor has recently announced an API and partnerships to integrate with third-party endpoint vendors in the future.
  • Customer experience: Juniper receives below-average scores for ease of initial deployment, stability of its firmware updates and the quality of its app control feature.

Di seguito i Vendor presenti sia nella categoria Enterprise Network Firewalls che nella categoria Unified Threat Management (UTM) ordinati in rispetto alla somma dello Score nelle due categorie, calcolato sulla base delle considerazioni precedenti, dal valore maggiore al minore:

Vendor

QM 2015

QM 2016

QM 2017

Score

Trend

Check Point Software Technologies

8

8

8

888

«

Fortinet

7

7

8

877

­

Cisco

6

6

6

666

«

Sophos

5

5

6

655

­

SonicWall

4

4

4

444

«

Huawei

2

2

4

422

­

WatchGuard

3

3

3

333

«

Juniper Networks

4

4

2

244

¯

Barracuda Networks

2

2

2

222

«

Hillstone Networks

2

2

2

222

«

Stormshield

2

2

2

222

«

In base alla classifica ottenuta i leader delle categorie Enterprise Network Firewalls e Unified Threat Management (UTM) del triennio 2015-2017 sono Check Point e Fortinet e Sophos, mentre Cisco mantiene stabilmente una buona posizione e Sophos sta aumentato la sua competitività, Juniper Networks ha invece avuto un trend in discesa, inteso come cambio di quadrante rispetto alla posizione ottenuta nel report Gartner del 2017 confrontato col report del 2016.

Analisi delle Reviews

Gartner oltre ai MQ da ottobre 2015 offre anche la classifica delle soluzioni basandosi sulle review scritte da utenti che utilizzano i prodotti nelle proprie infrastrutture informatiche, per la metodologia adottata nella valutazione si veda Gartner Peer Insights Customers’ Choice:

Recognition for Top Customer-Rated Companies

Since starting Gartner Peer Insights in October of 2015, we have collected more than 75,000 reviews across over 260 markets. In a growing number of markets, we’ve collected enough data to help our clients with a top-level synthesis of which vendor products are the most valued by customers in a given market. We recognize them with a distinction showcasing top vendors in a market.

Recognition Criteria

Recognition will be given to a maximum of seven vendors in a market according to these criteria:
• The vendor must have at least one product designated by our research analysts as relevant to the market. Vendors with excessive concentrations from a specific geographic region*, industry** or non-enterprise users*** are not considered.
• During the submission period — defined as 12 months prior to the eligibility cutoff date — a vendor must have:
• 50 or more published reviews
• An average overall rating of 4.2 stars or greater.
• In markets where more than seven vendors meet t
he above criteria, the seven vendors with the highest number of published reviews within the submission period will be selected for the designation.

Di seguito la classifica emersa dalla Reviews for Enterprise Network Firewalls alla data del 1 agosto 2018 dei Vendor che hanno avuto più di 20 recensioni ordinate in relazione allo rating ottenuto ponderato sul numero delle recensioni avute che abbiamo cercato di rendere più evidente con uno Score calcolato sulla base del valore ottenuto tramilte la seguente formula arrotondato alla prima posizione decimale:

Score= 100 * (Reviews * Rating) / (N° Totale Reviews * Massimo Rating ottenuto)

Vendor

Reviews

Rating

Customer Choice 2018

Score

Fortinet

911

4,5

«

36,2

Cisco

495

4,3

«

18,8

Palo Alto Networks

466

4,5

«

18,5

Check Point Software Technologies

287

4,4

11,1

Juniper Networks

62

4,2

2,3

Sophos

45

4,2

1,7

Barracuda Networks

41

4,7

1,7

Forcepoint

41

4,6

1,7

WatchGuard

39

4,4

1,5

SonicWall

24

4,3

0,9

In base alla classifica ottenuta dalle Reviews il leader della categoria Enterprise Network Firewalls è Fortinet seguito da Cisco e Palo Alto. Si noti che Fortinet, Cisco e Palo Alto hanno anche ottenuto la qualifica Customer Choice 2018, a riguardo si veda he Best Enterprise Network Firewall Management Software of 2018 as Reviewed by Customers

Di seguito la classifica emersa dalla Reviews for Unified Threat Management (UTM), Worldwide alla data del 1 agosto 2018 dei Vendor che hanno avuto più di 20 recensioni ordinate in relazione allo rating ottenuto ponderato sul numero delle recensioni avute che abbiamo cercato di rendere più evidente con uno Score calcolato come descritto in precedenza:

Vendor

Reviews

Rating

Customer Choice 2018

Score

Cisco

196

4,4

26,7

Fortinet

183

4,6

26,1

SonicWall

107

4,3

14,2

Sophos

78

4,2

10,1

WatchGuard

58

4,6

8,3

Check Point Software Technologies

40

4,4

5,5

Barracuda Networks

25

4,7

3,6

In base alla classifica ottenuta dalle Reviews i leader della categoria Unified Threat Management (UTM) sono Cisco e Fortinet seguiti da SonicWall e Sophos.

Di seguito i Vendor presenti nella classifiche ottenuta dalle Reviews Enterprise Network Firewalls e Unified Threat Management (UTM) che hanno avuto più di 20 recensioni ordinati in rispetto alla somma dello Score nelle due categorie, calcolato sulla base delle considerazioni precedenti, dal valore maggiore al minore:

Vendor

Score

Fortinet

62,3

Cisco

45,5

Check Point Software Technologies

16,6

SonicWall

15,1

Sophos

11,8

WatchGuard

9,8

Barracuda Networks

5,3

In base alla classifica ottenuta dalle Reviews il leader della delle categorie Enterprise Network Firewalls e Unified Threat Management (UTM) è Fortinet seguito da Cisco.

Conclusioni

Ovviamente come già scritto precedente prima di trarre conclusioni è necessaria la lettura del documento a cui è affiancato il QM Gartner, inoltre le considerazioni relative ai vendor ovviamente prendono in esame la situazione che vi era alla data di pubblicazione del report, quindi, ad esempio, nel caso del QM Gartner del 2017 ovviamente alcune affermazioni relative a funzionalità del prodotto o alle scelte tecno – commerciali del Vendor che hanno portato al posizionamento potrebbero non essere corrette se valutate dopo il 24 luglio 2017, per la categoria Enterprise Network Firewalls, o dopo il 20 giugno 2017, per la categoria Unified Threat Management (UTM).

L’analisi dell’evoluzione del posizionamento nel quadrante sulla base della formula che abbiamo proposto può ovviamente non essere condivisibile, ma sicuramente la valutazione del Vendor sulla base di più report può aiutare a determinare la scelta di un prodotto della categoria Enterprise Network Firewalls e/o nella categoria Unified Threat Management (UTM) che dovrà essere utilizzato per alcuni anni sebbene debba essere impiegato per gestire una delle problematiche IT più dinamiche come la protezione perimetrale dell’infrastruttura informatica aziendale. In ogni caso la classifica può essere rivista inserendo nel calcolo dello Score dei parametri che vadano a pesare la presenza e l’implementazione di determinate funzionalità indispensabili nell’infrastruttura IT oggetto della valutazione.

L’analisi che abbiamo proposto può quindi essere utilizzata come metro di valutazione per la scelta di una soluzione Enterprise Network Firewalls e/o Unified Threat Management (UTM), ma anche come parametro di confronto per valutare una soluzione presentata durante un incontro commerciale o ancora come strumento per giustificare le propria scelta nei confronti della Direzione aziendale.

Implementare una VPN site-to-site in Azure con Veeam PN

Facebooktwittergoogle_plusredditlinkedin

Quando un’organizzazione decide di adottare servizi offerti da cloud pubblici si trova spesso a dover affrontare la sfida di interconnettere in modo sicuro e gestito utenti e servizi della propria rete con le risorse ospitate nel cloud.

Tipicamente, questo scenario implica mettere in conto i costi del servizio VPN offerto dal vendor del cloud pubblico e il dover configurare un appliance locale seguendo indicazioni e prescrizioni in termini di compatibilità legate a tale servizio.

Ad esempio, nel caso di Microsoft Azure, realizzare una VPN site-to-site prevede la disponibilità nella propria rete locale di un dispositivo VPN “convalidato” (vedi https://docs.microsoft.com/it-it/azure/vpn-gateway/vpn-gateway-about-vpn-devices).

Talvolta potrebbe essere necessario dover collegare una o più sedi della nostra organizzazione a virtual machine o applicazioni che abbiamo collocato su Azure non disponendo però del numero o del tipo di apparati necessari, oppure non essendo possibile alterare la configurazione di quelli esistenti…

In questo articolo vedremo come creare una VPN fra la rete locale aziendale e una subnet in Azure utilizzando il componente gratuito Veeam PN realizzato da Veeam Software (https://www.veeam.com).

Veeam Powered Network (PN)

Veeam PN è un tool di Software Defined Networking (basato su una distro Linux Ubuntu 16.04.1 LTS) che consente di creare in maniera molto semplice e lineare tunnel VPN fra reti aziendali (“site-to site”) o fra un client e la rete aziendale (“point-to-site”).

Si basa sulla tecnologia OpenVPN (https://openvpn.net/index.php/open-source/333-what-is-openvpn.html) la cui implementazione è semplificata da un’interfaccia web che permette di applicare intuitivamente configurazioni e politiche amministrative.

Si può scaricare, previa registrazione gratuita, da qui: https://www.veeam.com/cloud-disaster-recovery-azure-download.html

Il download consiste in un file .ova di circa 1 Gb.

Nota: I file .ova sono “pacchetti” che contengono descrizioni e informazioni di certificazione relative ad una macchina virtuale (nel nostro caso l’appliance Veeam PN) che possono agilmente essere importate in ambiente VMware.

Come anticipato, Veeam PN può aiutarci (e possiamo dire che il tool sia nato proprio per questo scopo) nel creare connessioni protette verso nostre risorse collocate in Azure risolvendo il problema di dover modificare la configurazione di apparati VPN esistenti in conformità con le specifiche indicate da Microsoft:

  • VPN site-to-site, fra una o più sedi della nostra organizzazione ed una nostra subnet in Azure;
  • VPN point-to-site, fra uno o più client ed una nostra subnet in Azure.

Figura 1 – Scenari di implementazione di Veeam PN

Il ruolo svolto da Veeam PN, e quindi la relativa configurazione, dipende dalla collocazione nell’architettura:

  • Network Hub: gestisce il traffico fra la rete che offre i servizi e le reti o i client che devono accedervi in modo protetto; nel nostro schema il ruolo Network Hub di Veeam PN è collocato in Azure.
  • Site Gateway: stabilisce il tunnel VPN fra la rete che offre i servizi ed una rete remota; nel nostro schema, il ruolo Site Gateway è collocato on-premise.

Per consentire ad un singolo computer di accedere ad una rete gestita dal ruolo Network Hub, occorre installare sul PC Windows o Linux il client OpenVPN (https://openvpn.net/index.php/open-source/downloads.html). Per OS X e MacOS seguire le indicazioni riportate qui: https://openvpn.net/index.php/access-server/docs/admin-guides/183-how-to-connect-to-access-server-from-a-mac.html.

Requisiti di Veeam PN

Per installare l’appliance on-premise si raccomanda di utilizzare VMware vSphere versione 5.x o successive. La virtual machine dovrà disporre di almeno 1 CPU, 1GB di RAM e di un disco thin-provisioned di 4 GB. Per fare qualche sperimentazione è anche possibile utilizzare VMware Workstation o Virtual Box, ma non se ne raccomanda l’impiego in produzione.

Per installare l’appliance in Azure, dovremo prevedere una virtual machine almeno di dimensioni A1 (1 core, 1,75GB di RAM, 70 GB di spazio disco.

L’amministrazione di Veeam PN si effettua via browser: le versioni più recenti di Internet Explorer, Edge, Firefox, Chrome sono tutte supportate.

Informazioni sui requisiti e le indicazioni relative all’installazione del client OpenVPN sono disponibili qui: https://openvpn.net/index.php/open-source/documentation/install.html.

Porte utilizzate da Veeam PN:

Da Verso Protocollo Porta
Site Gateway Network Hub TCP/UDP 1194
Computer client Network Hub TCP/UDP 6179
Browser Network Hub o Site Gateway HTTPS 443

Installazione del ruolo Network Hub

Il primo ruolo di Veeam PN da installare è quello di Network Hub su Azure.

Una volta fatto accesso alla sottoscrizione Azure sulla quale abbiamo privilegi amministrativi, selezionare l’opzione Create a Resource e, nella casella di testo, digitare veeam pn, poi premere Invio.

Figura 2 – Create a Resource

Nei risultati della ricerca, fare clic su Veeam PN for Microsoft Azure.

Figura 3 – Veeam PN for Microsoft Azure, trovato!

Nella pagina successiva, fare clic su Create.

Figura 4 – Avvio creazione risorsa

Viene presentata la prima delle schede di configurazione della virtual machine che ospiterà il network appliance.

Fornire un nome per la virtual machine, un nome ed una password per l’account amministrativo, selezionare la sottoscrizione Azure in cui collocare la risorsa, decidere se utilizzare un Resource Group esistente (ma privo di risorse) o se crearne uno ad hoc e la regione Azure in cui desideriamo operare.

Infine, clic su OK.

Figura 5 – Informazioni di base

Nella scheda Veeam PN Settings:

  • Selezionare la dimensione della virtual machine: una Standard A1 può essere sufficiente per sperimentazioni o piccoli carichi di lavoro; in produzione si raccomanda di selezionare almeno una Dv2;
  • Specificare o creare uno Storage Account in cui verrà creato il disco della virtual machine;
  • Dare un nome univoco alla virtual machine;
  • Selezionare la Virtual Network a cui l’appliance sarà connesso (tipicamente la stessa Virtual Network in cui si trovano le risorse che dovranno essere raggiunte tramite VPN) e la relativa Subnet;
  • Fare clic su OK.

Figura 6 – Veeam PN Settings

Nella scheda successiva, Security Settings, selezionare la lunghezza della chiave di cifratura adottata per la generazione del canale sicuro e fare clic su OK.

Figura 7 – Security Settings

Nella scheda VPN Information è possibile selezionare le funzionalità con cui sarà configurato l’appliance Veeam PN e quindi stabilire se sarà possibile consentire connessioni site-to-site o point-to-site o entrambe. È anche possibile specificare protocolli e porte non di default. I valori predefiniti sono UDP 1194 per le connessioni site-to-site e UDP 6179 per le connessioni point-to-site.

Effettuate le scelte, fare clic su OK.

Figura 8 – VPN Information

Nella scheda Summary, dopo una verifica finale dei parametri impostati, è possibile fare clic su OK.

Figura 9 – Summary

Nella scheda successiva fare clic su Create.

Il processo di creazione delle risorse e della macchina virtuale dura pochi minuti.

Figura 10 – Fasi della creazione appliance Veeam PN

Configurazione del ruolo Network Hub

Al termine della creazione della macchina virtuale Veeam PN, è necessario effettuare alcune configurazioni preliminari.

Dal portale amministrativo di Azure, fare clic su Virtual Machines, poi sul nome della macchina virtuale Veeam PN appena creata per visualizzarne le proprietà.

Figura 11 – Indirizzo pubblico appliance

Annotare il Public IP Address (nel nostro caso 40.127.163.70), avviare un browser e connettersi via https.

Effettuare il login con le credenziali amministrative specificate al momento della creazione della virtual machine.

Figura 12 – Login

Nella scheda Azure Setup, fare clic su Next.

Figura 13 – Avvio wizard

Veeam PN richiede che ci si autentichi su Microsoft Azure Active Directory. Copiare il codice di autenticazione fornito e accedere al link indicato nella scheda.

Figura 14 – Codice di autenticazione (CTRL+C)

Incollare il codice nella casella di testo della pagina Web e, se il codice fornito risulta corretto, fare clic su Continua.

Figura 15 – Codice di autenticazione (CTRL+V)

Qualora richiesto, selezionare l’account corrente o specificarne uno diverso che abbia accesso alla sottoscrizione Azure.

Figura 16 – Conferma account

Tornare alla pagina di configurazione di Veeam PN e fare clic su Next.

Figura 17 – Il wizard prosegue

Al termine della configurazione automatica, fare clic su Finish.

Figura 18 – Azure setup completato

Configurazione dell’accesso dalla rete remota

È ora necessario consentire l’accesso al Veeam PN con il ruolo Network Hub da parte del Veeam PN con il ruolo Site Gateway che sarà installato e configurato successivamente.

Nella pagina principale del portale amministrativo di Veeam PN, fare clic su Clients.

Figura 19 – Portale amministrativo Veeam PN

Fare clic su Add.

Figura 20 – Aggiunta client

Nella scheda Add Client selezionare l’opzione Entire
Site e fare clic su Next.

Figura 21 – Opzione Entire Site

Specificare un nome identificativo e la subnet (nel formato CIDR) a cui appartengono gli host on-premise che dovranno connettersi ad Azure tramite VPN. Poi fare clic su Next.

Figura 22 – Informazioni sulla subnet on-premise

Nella scheda di riepilogo, fare clic su Finish.

Figura 23 – Completamento aggiunta client

Viene proposta la finestra di dialogo per il salvataggio del file (.xml) di configurazione che sarà poi necessario importare durante la configurazione del Veeam PN con il ruolo di Site Gateway.

Salvare il file in una posizione successivamente accessibile.

Nel portale amministrativo di Veeam PN è ora presente la rete che abbiamo appena definito come client.

Figura 24 – Conferma dell’aggiunta client

Installazione del ruolo Site Gateway

Passiamo ora a configurare Veeam PN on-premise per poter connettere con un tunnel VPN la rete aziendale ad Azure.

Collocare il pacchetto .ova scaricato dal sito Veeam (https://www.veeam.com/cloud-disaster-recovery-azure-download.html) in una posizione accessibile dall’ambiente VMware.

Per istruzioni dettagliate su come effettuare il deployment di un template OVA in ambiente vSphere: https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-AFEDC48B-C96F-4088-9C1F-4F0A30E965DE.html

Figura 25 – Package OVA caricato in vSphere

Qui https://spaces.uncc.edu/display/CKB/Importing+OVA+File+into+VMware+Workstation+14 una guida su come procedere utilizzando invece VMware Workstation (scenario consigliato unicamente nel caso di laboratori o sperimentazioni).

Completato il deployment del pacchetto .ova, dal client vSphere o dalla console di VMware Workstation, ricavare l’indirizzo IP dell’appliance Veeam PN (nel nostro caso 192.168.1.94) e accedervi via browser con le credenziali di default:

  • Utente: root
  • Password: VeeamPN

Figura 26 – Login al Veeam PN on-premise

Viene immediatamente richiesto di cambiare la password di default.

Figura 27 – Cambio password

Nella scheda successiva, Initial Configuration, è possibile scegliere il ruolo che dovrà svolgere questo appliance o se ripristinare la configurazione da un precedente backup.

Nel nostro caso, selezionare l’opzione Site gateway, poiché il ruolo Network Hub è stato precedentemente collocato su Azure, e fare clic su Next.

Figura 28 – Configurazione ruolo

Occorre ora effettuare l’upload del file .xml di configurazione generato durante la configurazione del ruolo Network Hub.

Fare clic su Browse e selezionare il file. Poi fare clic su Finish.

Figura 29 – Completamento configurazione

Dopo qualche secondo, nel portale amministrativo del Veeam PN on-premise viene segnalata l’effettuata connessione con il Veeam PN collocato su Azure.

Figura 30 – Conferma connessione lato on-premise…

Connettersi con il browser al Veeam PN su Azure e verificare che anche da quel lato gli indicatori siano “verdi”,

Figura 31 – …e conferma connessione lato Azure

Test della connessione VPN

Nello schema qui dis eguito, lo scenario oggetto della verifica: il client aziendale appartenente alla sede di Roma (indirizzo IP 192.168.1.246) deve potersi connettere tramite VPN al server AZRSRV01 collocato su Azure (indirizzo IP privato 10.1.0.4).

Figura 32 – Schema scenario da verificare

Nel portale amministrativo di Azure, fare clic su Virtual Machines, poi sulla macchina virtuale Veeam PN. Infine fare clic su Networking. Prendere nota dell’indirizzo IP privato (nel nostro caso 10.1.0.5).

Figura 33 – Rilevamento IP privato appliance Veeam PN su Azure

Accedere al client aziendale collocato nella rete on-premise, aprire una sessione Command Prompt con privilegi amministrativi elevati.

Eseguire il comando:

route -p add x.x.x.x mask y.y.y.y z.z.z.z

Dove:

  • x.x.x.x è l’indirizzo della subnet Azure a cui si desidera accedere
  • y.y.y.y è la relativa Subnet Mask
  • z.z.z.z è l’indirizzo IP del Veeam PN on-premise

Nel nostro caso:

route -p add 10.1.0.0 mask 255.225.255.0 192.168.1.94

Effettuare un tracert verso l’IP privato del Veeam PN su Azure.

Figura 34 – Tracert OK!

Vogliamo ora verificare di poter accedere anche al server collocato nella subnet Azure.

Il server ha come indirizzo privato 10.1.0.4 e non è raggiungibile (per regole di firewall) tramite il suo indirizzo IP pubblico.

Figura 35 – Rilevamento IP privato VM server su Azure

Proviamo ad accedere in RDP al server AZRSRV01 attraverso il suo IP privato 10.1.0.4.

Figura 36 – RDP OK!

WOW!

Instradamento automatico

Si noti che non è stato necessario modificare la routing table del server su Azure, grazie ad uan configurazione effettuata automaticamente dal Veeam PN con il ruolo Network Hub.

Accedere al portale amministrativo di Azure, fare clic su Resource Groups e poi sul nome del Resource Group in cui è stato collocato l’appliance Veeam PN.

Tra i vari elementi presenti, ne è elencato anche uno di tipo Route table.

Figura 37 – Route table creata da Veeam PN

Facendo clic su questo elemento si evidenza come sia stata automaticamente creata una route che inoltra attraverso l’host 10.1.0.5 (il Veeam PN) il traffico indirizzato verso la rete 192.168.1.0/24 (la subnet on-premise).

Tale route è applicata alla subnet su cui sono attestati sia l’appliance Veeam PN che il server AZRSRV01.

Figura 38 – Caratteristiche route table

Magia!

Conclusioni

In questo articolo abbiamo visto, passo per passo, come sia possibile, grazie ad un appliance gratuito realizzato da Veeam, realizzare una VPN site-to-site fra una sede aziendale e una subnet su Azure senza implicare modifiche agli apparati di networking esistenti o dover configurare un VPN Gateway su Azure.

Utilizzare un server RADIUS per autenticare le connessioni VPN Point-to-Site verso le Azure Virtual Network

Facebooktwittergoogle_plusredditlinkedin

Le connessioni Point-to-Site (P2S) consentono ai computer client di potersi collegare alle reti virtuali in Azure (VNET) ed sono utili per tutti quei telelavoratori che quando sono a casa o sono in trasferta da un cliente hanno necessità di accedere alle risorse su Azure o alle risorse aziendali.

Per accedere anche alle risorse aziendali è necessario però che sia stata configurata anche una connessione Site-to-Site (S2S) tra la Azure VNet e la rete on-premises.

Figura 1: Schema di una connessione Point-to-Site

Gia in passato ho scritto la procedura per Creare una connessione Point to Site in Azure Resource Manager usando Powershell, anche se l’operazione è possibile effettuarla direttamente dal portale di Azure. Per l’autenticazione del client mi sono servito dei certificati digitali, che nonostante offrano un livello di sicurezza maggiore, sono più difficili da gestire.

Da qualche mese è però possibile utilizzare anche un server RADIUS per l’autenticazione degli utenti, a patto che utilizziate un Virtual Network Gateway di tipo VpnGw1, VpnGw2 o VpnGw3.

Quali SKU del gateway supportano la connessione VPN da punto a sito?

SKU Connessioni P2S Benchmark della velocità effettiva aggregata Autenticazione RADIUS VPN da punto a sito IKEv2
VpnGw1 128 650 Mbps Supportato Supportato
VpnGw2 128 1 Gbps Supportato Supportato
VpnGw3 128 1,25 Gbps Supportato Supportato
Basic 128 100 Mbps Non supportato Non supportato

Il server RADIUS potrà trovarsi nella stessa VNET di Azure, ospitato all’interno di una VM, oppure potrà essere contattato tramite una connessione Site-to-Site nella rete on-premises.

La modalità Point-to-Site (P2S) crea una connessione VPN tramite SSTP (Secure Sockets Tunneling Protocol) o IKEv2.

  • SSTP è un tunnel VPN basato su SSL supportato solo nelle piattaforme client Windows. Può penetrare i firewall e per questo è l’opzione ideale per connettersi ad Azure ovunque. Usa solo la porta 443
  • IKEv2 è una soluzione VPN IPsec basata su standard e può essere usato per connettersi da dispositivi Mac (versioni OSX 10.11 e successive). Usa la porta UDP 500 e 4500 e il protocollo IP 50. Molti proxy e firewall bloccano queste porte.

I client supportti sono:

  • Windows 7 (32-bit and 64-bit)
  • Windows Server 2008 R2 (64-bit only)
  • Windows 8.1 (32-bit and 64-bit)
  • Windows Server 2012 (64-bit only)
  • Windows Server 2012 R2 (64-bit only)
  • Windows Server 2016 (64-bit only)
  • Windows 10
  • Mac OS X version 10.11 (El Capitan)
  • Mac OS X version 10.12 (Sierra)
  • Linux (StrongSwan)
  • iOS

Per configurare il Virtual Network Gateway ad utilizzare il server RADIUS per l’autenticazione degli utenti vi basterà selezionare dal portale di Azure il Virtual Network Gateway e nel ramo Point-to-site configuration sarà possibile dichiarare, oltre all’Address Pool da utilizzare, anche quale server RADIUS dovrà essere contatatto per l’autenticazione e lo Shared Secret da utilizzare per connettersi al server RADIUS.

Figura 2: Configurazione della RADIUS Authentication

Per connettersi alla VNET in Azure attraverso al connessione Point-to-Site (P2S) gli utenti dovranno inserire le proprie credenziali di dominio (o credenziali di utenti locali del server RADIUS). È anche possibile integrare un server RADIUS con la Multi-facotr Authentication (MFA) in modo tale da aumentare il livello di sicurezza dell’accesso. Per la configurazione MFa vi rimando alla lettura dell’articolo Integrate your existing NPS infrastructure with Azure Multi-Factor Authentication

Figura 3: Schema di funzionamento dell’autenticazione con server RADIUS on-premises

Configurazione del server RADIUS

Il server RADIUS che ho utilizzato è il Network Policy Server di Windows Server. La configurazione del ruolo è molto semplice e dura pochi secondi. Al termine dell’installazione sarà necessario configurare il server per accettare le connessioni VPN e per autenticarle. Dalla console del Network Policy Server potete effettuare il wizard per la creazione di una Configurazione Standard, come quella mostrata in figura:

Figura 4: Wizard per la creazione di una configurazione per una RADIUS server per le connessioni VPN

Scegliete di configurare una connessione VPN e date un nome alle policy che verranno configurate alla fine del wizard.

Figura 5: Scelta del tipo di connessione e del nome

Nel passaggio successivo inserite i RADIUS Client, cioè il vostro Azure Virtual Network Gateway. Inserite la Gateway Subnet che avete associato al momento della creazione del Gateway e lo Shared Secret che avete configurato nella Point-to-Site configuration.

Figura 6: Configurazione del RADIUS Client

Figura 7: RADIUS Client aggiunto

È possibile utilizzare due tipi di autenticazione con la connessione Point-to-Site (P2S): EAP-MSCHAPv2 ed EAP-TLS. In questo caso ho deciso di utilizzare EAP-MSCHAPv2 e l’ho aggiunto nella pagina degli Authentication Methods, come mostrato in ffigura:

Figura 8: Aggiunta di EAP-MSCHAPv2 agli Authentication Methods

Selezionate il gruppo di utenti che potranno autenticarsi e procedete con il wizard. Io ho creato un gruppo dedicato che possa connettersi alla VNET tramite P2S.

Figura 9: Scelta del gruppo di utenti autorizzati ad autenticarsi tramite VPN

Lasciate invariate le altre configurazioni

Figura 10: Packet filtering per limitare il tipo di traffico

Figura 11: Encryption settings

Figura 12: Realm name

Completate la configurazione facendo clic su Finish.

Figura 13: Configurazione del server RADIUS completata

Download del client di connessione Point-to-Site

Terminata la configurazione del server RADIUS dovete soltanto provare a connettervi. Collegatevi al portale Azure e scaricate il client di connessione, come mostrato in figura, scegliendo anche il protocollo di autenticazione che volete utilizzare. Io ho scelto EAP-MSCHAPv2.

Figura 14: Download del client di connessione P2S

Verrà scaricato un file .zip all’interno del quale troverete gli installer per Windows 32 e 64 bit e per Mac OSx. Procedete all’installazione della connessione per il tipo di sistema operativo che state utilizzando.

Figura 15: Installazione della configurazione del client VPN per la P2S

Terminata la configurazione sarà possibile lanciare la connessione VPN P2S, inserendo le credenziali di un utente che appartenga al gruppo che avete autorizzato nel server RADIUS.

Figura 16: Connessione P2S alla VNET con le credenziali di dominio o locali del server RADIUS

Se volete personalizzare la configurazione del client e se volete aggiungere delle rotte alla connessione VPN (per esempio per raggiungere anche la rete on-premises) vi invito a leggere l’articolo Personalizzare il client di una connessione Point to Site su Azure

Conclusioni

Utilizzare un server RADIUS per autenticare i nostri utenti quando effettuano una connessione Point-to-Site è decisamente facile e vantaggioso, perché sfrutta le credenziali di dominio dell’utente e si può integrare con la Multi-Factor Authentication.

Creare rapidamente laboratori di test per Windows 10, Windows Server 2016 e Windows Server 2019 utilizzando PowerShell

Facebooktwittergoogle_plusredditlinkedin

Da qualche mese è presente su GitHub un progetto Microsoft gratuito che permette con una serie di script PowerShell di configurare rapidamente dei laboratori di test basati su Hyper-V (io ho utilizzato la mia macchina con Windows 10 e con Client Hyper-V per i lab), partendo soltanto dalla ISO di Windows Server 2016 e di Windows 10. È anche possibile testare la versione Insider dei due sistemi operativi ed il prossimo Windows Server 2019.

Si possono creare decine di scenari diversi, alcuni anche complessi, frutto dell’esperienza dei Premier Field Engineer di Microsoft, che li usano proprio per realizzare delle demo per i clienti.

Ho trovato particolarmente facile la creazione dei laboratori con gli script messi a disposizione, visto che in fin dei conti dovevo solo fornire la ISO del sistema operativo da utilizzare e attendere la creazione del lab!

Gli script sono stati realizzati solo per creare alcuni scenari, molti di questi dedicati alle funzioni di Storage di Windows Server, ma offrono la possibilità di essere modificati e quindi possono anche essere adattati alle nostre esigenze.

Collegandosi alla pagina https://github.com/Microsoft/WSLab/tree/master/Scenarios troverete un elenco di scenari che attualmente sono stati sviluppati, ma ne vengono creati sempre di nuovi.

Se invece volete testare le nuove funzionalità della prossima versione di Windows 10 e di Windows Server 2019 potete collegarvi alla pagina https://github.com/Microsoft/WSLab/tree/master/Insider , dove c’è il file di configurazione per creare le macchine del lab utilizzando la ISO del programma Insider.

Nella pagina dei progetti sono anche presenti dei video esplicativi che vi possono aiutare nelle prime fasi, raggiungibili direttamente al link https://github.com/Microsoft/WSLab/#videos

Download dei prerequisiti

Per cominciare abbiamo bisogno di scaricare alcuni prerequisiti fondamentali:

Estraete gli script in una cartella del vostro computer oppure di una macchina virtuale su Azure che supporti la Nested Virtualization, cioè della famiglia Dv3 ed Ev3. Ho già avuto modo in passato di scrivere l’articolo Abilitare la nested virtualization con le nuove Azure VM Dv3 ed Ev3 che citava proprio questa nuova ed utilissima funzionalità.

Figura 1: Estrazione degli script utili per la creazione del laboratorio

Eseguite quindi il file 1_Prereq.ps1 con privilegi amministrativi e scaricate i prerequisiti richiesti, come mostrato in figura, che verranno poi salvati nella cartella Tools:

Figura 2: Download dei prerequisiti richiesti

Al termine del download dei prerequisiti, eseguite con privilegi amministrativi il file 2_CreateParentDisks.ps1. Vi verrà richiesta la ISO di Windows Server 2016 e vi verranno chiesti i file MSU che volete utilizzare per l’aggiornamento dell’immagine. Verranno creati diversi VHDX, con l’installazione di Windows Server 2016 Datacenter Full, Core e Nano. L’operazione dura diversi minuti e i dischi saranno salvati nella sottocartella ParentDisks, che verrà creata dallo script.

Figura 3: Richiesta dei file MSU per aggiornare l’installazione di Windows Server

Figura 4: Creazione dei dischi che verranno utilizzati dalle VM completata

Dopo la creazione dei VHDX, lo script procede in automatico e crea una macchina virtuale dentro la quale verranno installati i ruoli di Domain Controller e di DHCP utilizzando PowerShell Desired State Configuration (DSC). L’operazione dura diversi minuti, quindi siate pazienti 😊
La macchina virtuale creata verrà poi eliminata dalla console di Hyper-V e sarà riutilizzata nel momento in cui creerete il laboratorio secondo lo scenario che avete scelto.

Per ingannare l’attesa potete leggere l’articolo Introduzione a PowerShell Desired State Configuration o gli altri articoli che trattano dello stesso argomento https://www.ictpower.it/?s=PowerShell+Desired+State+Configuration

Figura 5: Installazione del Domain Controller tramite PowerShell Desired State Configuration

Figura 6: esecuzione dello script 2_ CreateParentDisks.ps1 terminata

Figura 7: Il Domain Controller che verrà utilizzato nei laboratori

Terminata l’esecuzione dello script 2_CreateParentDisks.ps1 vi verrà chiesto se volete eliminare i primi 2 script. Rispondente come preferite perché la vostra scelta non inficerà sulla creazione del laboratorio e sui successivi passaggi.

Se volete creare un’immagine di Windows 10 vi basterà lanciare lo script che troverete nella cartella Tools e scegliere la ISO di Windows 10 oppure di Windows 10 Insider, con gli eventuali Update che volete installare (file .MSU). Vi verrà chiesto quale versione di Windows volete installare, come mostrato in figura:

Figura 8: Creazione di un VHDX con Windows 10

Figura 9: Installazione del sistema operativo nel VHDX

Al termine della creazione sarà necessario spostare il VHDX dalla cartella Tools alla cartella ParentDisks.

Figura 10: Spostamento del VHDX di Windows 10 nella cartella ParentDisks

Creazione di un laboratorio utilizzando uno Scenario

Come già anticipato, diversi sono gli scenari che possono essere utilizzati per la creazione dei laboratori e sono tutti visibili al link https://github.com/Microsoft/WSLab/tree/master/Scenarios

In questo articolo utilizzerò lo Scenario S2D and Windows Admin Center, che creerà 6 macchine virtuali. Copiate la configurazione presente nella pagina nella sezione LabConfig and Prerequisites e incollatela nel file LabConfig.ps1, come mostrato in figura. Salvate il file LabConfig.ps1

Figura 11: Modifica della configurazione del file LabConfig.ps1 per adattarlo allo scenario scelto

A questo punto, per creare le macchine virtuali, lanciate lo script Deploy.ps1 (o 3_Deploy.ps1 se non lo avete rinominato). Verrà prima creata la macchina virtuale che ospita il Domain Controller e lo script aspetterà che il servizio di Active Directory sia online prima di procedere alla creazione delle altre VM, che verranno tutte automaticamente joinate al dominio (corp.contoso.com). Nell’attesa che il DC sia online potrete ricevere nello script dei messaggi di errore, ma non preoccupatevene perché questi errori sono “by design”.

Figura 12: Creazione delle VM del laboratorio utilizzando lo script Deploy.ps1

Figura 13: Creazione delle VM completata

Figura 14: Macchine virtuali create in Hyper-V

Le macchine virtuali sono state create. Accendetele e procedete con la configurazione dello scenario scelto. La creazione dell’infrastruttura sarà completata in meno di 5 minuti!

Da questo momento in poi le altre operazioni saranno fatte dall’interno delle VM e potete procedere con la configurazione delle funzionalità di Windows Server. A me interessa, con questo articolo, solo farvi vedere come creare facilmente l’infrastruttura di test e quanto sia facile passare da uno scenario all’altro, seguendo le indicazioni presenti su GitHub https://github.com/Microsoft/WSLab/tree/master/Scenarios

Rimozioni del laboratorio

Se volete rimuovere il laboratorio e tutte le macchine virtuali create, compreso i virtual switch, vi basterà lanciare lo script Cleanup.ps1. Le VM vengono individuate tramite il prefisso che avete deciso nel file LabConfig.ps1 e quindi non c’è possibilità che vengano rimosse altre macchine virtuali presenti nella vostra infrastruttura.

Figura 15: La rimozione del laboratorio viene completata in pochissimi secondi

Conclusioni

Davvero interessante creare dei laboratori di test ed eseguire delle configurazioni particolarmente complesse soltanto lanciando pochissimi script PowerShell e partendo dalla ISO di Windows. Utilissimo per le demo da fare ai nostri clienti, utilissimo per lo studio delle nuove funzionalità, utilissimo per risparmiare tantissimo tempo per i nostri test. Grazie Microsoft!

Come funziona la risoluzione DNS nei sistemi operativi Windows

Facebooktwittergoogle_plusredditlinkedin

Tutti sappiamo quanto sia importante la risoluzione dei nomi DNS. Il processo di tradurre un indirizzo IP assegnato ad un computer, difficile da ricordare, in un nome che gli utenti possano leggere e capire semplifica di molto l’utilizzo delle risorse di rete. Il DNS ci permette, come una rubrica telefonica, di recuperare gli indirizzi dei server web, dei file server e di tutti i dispositivi presenti nella rete aziendale o in Internet in maniera davvero semplice.

Abbiamo già parlato in altri articoli delle novità del servizio DNS in Windows Server 2016 oppure delle funzionalità avanzate relative al DNSSEC, ma in questo articolo mi voglio soffermare sul funzionamento del DNS LATO CLIENT e sulle configurazioni da fare sulle macchine. Durante i corsi che tengo mi è capitato spesso infatti di trovare gente, anche con una certa “anzianità di servizio”, che aveva difficoltà a comprendere bene come funzionasse la risoluzione lato client.

Risoluzione dei nomi DNS per Windows Server e Windows Client

Il set di protocolli TCP/IP identifica i computer sorgente e destinazione tramite i propri indirizzo IP. Tuttavia gli utenti trovano più facile ricordare i nomi piuttosto che i numeri e per questo motivo gli amministratori assegnano un nome ai computer. I nomi assegnati agli indirizzi IP vengono poi scritti nel DNS. Il formato tipico di questi nomi è dc1.demo.com, dove DC1 è il nome del computer (hostname) e DEMO.COM è il nome del dominio. L’unione dell’hostname e del dominio formano il Fully Qualified Domain Name (FQDN).

Figura 1: Fully Qualified Domain Name (FQDN)

Un hostname può essere lungo fino a 255 caratteri e può contenere lettere, numeri, punti e trattini.

Come i Client risolvono i nomi DNS interni

Tutti i sistemi operativi Windows utilizzano diversi metodi per risolvere i nomi dei computer: DNS, WINS e NETBIOS. WINS è un database centralizzato che serve a risolvere i nomi NETBIOS. I nomi NETBIOS sono fondamentalmente solo i nomi host, senza il suffisso DNS, limitati ai primi 15 caratteri del nome macchina.

Quando un’applicazione richiede di raggiungere un certo hostname, il TCP/IP utilizza la DNS Resolver Cache per cercare di risolvere il nome host. Se NETBIOS over TCP/IP è abilitato nella configurazione della scheda di rete, il protocollo TCP/IP utilizza la risoluzione NETBIOS per risolvere i nomi.

Figura 2: Configurazione del NETBIOS attiva in maniera predefinita in Windows

I sistemi operativi Windows risolvono gli hostname utilizzando le seguenti operazioni in questo specifico ordine:

  1. Controllano se l’hostname cercato è lo stesso del pc da cui facciamo la richiesta (loopback)
  2. Controllano se il nome sia già stato risolto verificando la presenza nella cache locale del computer / Controllano se ci sono dei nomi computer scritti nel file HOSTS
  3. Inviano una richiesta al server DNS che è configurato nella scheda di rete
  4. Utilizzano, se è abilitato, il protocollo Link-Local Multicast Name Resolution (LLMNR)
  5. Convertono il nome host in un nome NETBIOS e controllano la presenza del nome nella cache NETBIOS locale del computer
  6. Inviano una richiesta al server WINS che è configurato nella scheda di rete
  7. Mandano una richiesta in BROADCAST nella stessa sottorete dove si trova
  8. Controllano se ci sono dei nomi computer scritti nel file LMHOSTS

Figura 3: Risoluzione dei nomi da parte di un Client Windows

Pertanto, se sto cercando di risolvere il nome fileserver1 (NETBIOS) la risoluzione avverrà in maniera diversa se cerco di risolvere il nome fileserver1.demo.com (FQDN).

Risoluzione DNS di nomi pubblici

Se cerchiamo di risolvere nomi DNS che non siano presenti nel nostro server DNS interno, come ad esempio i nomi Internet, la risoluzione DNS si comporta in modo completamente diverso. In questo caso, poiché il server DNS interno della nostra rete non ospita lo spazio di nomi cercato si dice che non è autoritativo per la zona DNS. Deve quindi rivolgersi ad un server DNS esterno per la risoluzione dei nomi, comportandosi quindi come un client.

Se il server DNS interno
non è autoritativo allora la risoluzione dei nomi viene effettuata dal server in uno di questi 3 modi:

  • Controlla nella propria cache di aver già risolto il nome cercato
  • Inoltra la richiesta ad un server esterno che abbiamo configurato (Forwarder). In questo caso effettua una query ricorsiva
  • Usa i Root Hints per conoscere chi sono i server autoritativi per la zona da cercare. In questo caso effettua una query iterativa

Il DNS è organizzato in maniera gerarchica e alla radice c’è la zona (.) (punto), chiamata Root. I Root Hints sono i 13 server mondiali che ospitano il livello gerarchico delle zone Internet, cioè la radice.

Figura 4: I Root Hints contengono gli indirizzi IP dei DNS Root Server

NOTA: Sia che il server DNS interno sia configurato con o senza Forwarder, la risoluzione dei nomi DNS pubblici avviene sempre e comunque tramite i Root Hints, che sono gli unici a sapere quali sono i server autoritativi per la zona cercata (ad esempio ictpower.it).

Ci sarebbe davvero molto da dire sul funzionamento dei server DNS e sulle loro configurazioni. Consiglio quindi vivamente di partire dal documento DNS Physical Structure per cominciare ad approfondire l’argomento e successivamente di leggere il documento DNS Processes and Interactions

Figura 5: Query DNS ricorsiva e iterative effettuate dal server DNS interno

Figura 6: Query DNS ricorsiva e iterative effettuate dal server DNS interno configurato con un Forwarder

Come configurare correttamente la scheda di rete per la risoluzione DNS

Per configurare correttamente la scheda di rete per la risoluzione DNS bisogna inserire i parametri dei server DNS, che variano a seconda che la macchina stia lavorando in dominio o in workgroup. Supponendo che la macchina sia stata aggiunta al dominio, dovremo inserire come server DNS l’indirizzo (o meglio gli indirizzi) dei domain controller aziendali. I Domain controller aziendali saranno capaci di risolvere sia i nomi interni sia i nomi pubblici. Se abbiamo due server con indirizzi 192.168.11.10 e 192.168.11.11 la configurazione corretta sarà:

Figura 7: Configurazione di una scheda di rete di una macchina in DOMINIO con gli IP dei Domain Controller, che fanno anche da DNS Server

Se la macchina è invece in workgroup, non ci saranno domain controller né server DNS interni e quindi sarà necessario configurare la scheda di rete con un indirizzo IP di un server DNS pubblico, come nell’esempio mostrato nella figura sotto:

Figura 8: Configurazione di una scheda di rete di una macchina in WORKGROUP con IP di DNS pubblici

Quali sono gli errori più comuni che vengono commessi?

Uno degli errori più comuni che vengono commessi è mischiare tra di loro indirizzi IP di DNS interni (domain controller) e di DNS pubblici. Per fare un esempio, una delle configurazioni che vedo più spesso è quella mostrata nella figura sotto:

Figura 9: Configurazione DNS errata

Quando viene utilizzato il DNS alternativo?

Quando il server DNS Preferito non risponde (è SPENTO o NON RAGGIUNGIBILE, non quando non sa rispondere ad una query DNS). Quindi la giustificazione che mi viene data per questo tipo di configurazione è che se sto riavviando il Domain Controller (molto spesso nelle piccole aziende ce n’è solo uno!) o il Domain controller non è raggiungibile, viene utilizzato il DNS secondario, che è capace di risolvere i nomi Internet. Così gli utenti navigano e non mi creano problemi!

Per capire dopo quanto tempo viene utilizzato il DNS server secondario vi spiego in che modo avviene una query DNS:

  1. Se il server DNS primario è disponibile la query viene immediatamente risolta
  2. Se il DNS primario NON è disponibile, la query viene effettuata sul server DNS alternativo dopo un time-out di circa 1 secondo

La situazione si complica quando avete diverse schede di rete sulla stessa macchina. Un ottimo articolo che spiega l’ordine di ricerca dei DNS alternativi ed il time-out che ne consegue è DNS Clients and Timeouts (part 2)

Quando viene utilizzato nuovamente il server DNS preferito?

È importante saperlo perché nell’esempio sopra il Domain Controller è l’unico in grado di risolvere i nomi interni del dominio e assicura il corretto funzionamento di servizi che dipendono da Active Directory. Quindi se non posso contattare il domain controller e continuo ad utilizzare il DNS pubblico potrei non essere in grado di poter utilizzare tutti i servizi interni del mio dominio.

La risposta è che di default ci vogliono 15 minuti. Passati i 15 minuti il server DNS alternativo viene cancellato dalla DNS Cache e la successiva query potrà ricominciare a contattare il server DNS preferito.

È però possibile modificare questo time-out agendo sulla chiave di registro Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters e modificando il valore REG_DWORD chiamato ServerPriorityTimeLimit. Se impostate il valore a 0, le priorità nella scelta dei server vengono cancellate dalla cache del DNS Client e quindi l’ordine di utilizzo dei server DNS viene controllato ogni volta che effettuate una nuova query.

Figura 10: modifica della chiave di registro per il ServerPriorityTimeLimit

Quindi, se proprio volete mettere un DNS server esterno come DNS secondario, tenete ben presente il time-out di 15 minuti ed eventualmente modificate la chiave di registro indicata.

Conclusioni

Conoscere il funzionamento della risoluzione DNS e delle configurazioni da effettuare sulla scheda di rete ci permette di evitare grossolani errori e ci aiuta nel troubleshooting della risoluzione dei nomi, che è uno dei più importanti concetti da capire per la gestione di un’infrastruttura di rete.

Implementare Azure AD password protection per Windows Server Active Directory

Facebooktwittergoogle_plusredditlinkedin

Una delle problematiche relative alla sicurezza più evidenti nelle aziende è l’utilizzo di password troppo facili da parte degli utenti. Problemi legati alla memorizzazione, alla troppa lunghezza della password imposta a livello di dominio e alla complessità richiesta fanno si che gli utenti spesso si servano di password facilmente individuabili.

Abbiamo già avuto modo di parlare della modifica delle password policies In Active Directory nell’articolo Active Directory Password Policies: facciamo un po’ di chiarezza, soprattutto perché le aziende si sono dovute adeguare all’entrata in vigore delle sanzioni previste dal GDPR in merito alla sicurezza dei sistemi.

In questo articolo ci occuperemo invece di implementare Azure AD password protection per Windows Server Active Directory, sfruttando una funzionalità del Cloud per proteggere i nostri sistemi dall’utilizzo di password troppo semplici. Andremo cioè a migliorare le password policies previste on-premises sfruttando una funzionalità che è già presente in Azure AD, che ci permetterà di effettuare un controllo delle password sia on-premises che nel Cloud.

Azure AD password protection

Azure AD password protection è una funzionalità disponibile in Azure se avete sottoscritto il piano Azure AD P1 Premium, che vi permette di evitare che i vostri utenti utilizzino password prese da una lista di più di 500 password comunemente utilizzate ed oltre un milione di variazioni delle stesse password che utilizzano la sostituzione di alcuni caratteri. Un esempio eclatante è Pa$$w0rd1!, in cui la parola “password” viene resa più “difficile” da indovinare utilizzando maiuscole, minuscole, caratteri speciali e numeri. In realtà molte di queste password sono facilmente individuabili.

Quindi Azure AD password protection non è altro che un sistema che “banna” le password nel momento in cui gli utenti cercano di cambiarla (perché l’hanno dimenticata oppure perché è scaduta) e può essere anche personalizzato (immaginate quante persone in questo momento stanno utilizzando la password “Luglio2018!” ) 😊

Una volta che avete acquistato il piano Azure AD Premium 1 potete personalizzare la lista delle password “bannate” semplicemente andando in Azure Active Directory à Authentication Methods (attualmente ancora in Preview) dal portale di Azure, come mostrato in figura:

Figura 1: Personalizzazione delle configurazioni di Azure AD Password Protection

Dal portale sarà possibile inserire una lista di password che volete “bannare” e come si può vedere è abilitata di default la voce Enable password protection on Windows Server Active Directory. In maniera predefinita la funzionalità è in modalità Audit, per permettervi di testarla. Una volta terminate tutte le configurazioni potrete metterla in modalità Enforced ed iniziare ad utilizzarla.

Nella stessa finestra è anche possibile personalizzare Smart Lockout. Smart Lockout è una funzionalità abilitata di default per tutti gli utenti di Azure AD (è gratuita e non richiede un piano aggiuntivo) che utilizza l’intelligenza artificiale per bloccare tutti i tentativi di accesso malevoli ai nostri account di Azure AD. Ci sono circa 10 milioni di tentativi giornalieri registrati da Microsoft da parte di malintenzionati che usano combinazioni di username e password per indovinare l’accesso degli utenti. Con Smart Lockout è possibile riconoscere se l’accesso proviene da un utente valido (che magari in quel momento non ricorda la password) oppure proviene da una sorgete sconosciuta (ad esempio un indirizzo IP che generalmente non utilizziamo per connetterci).

Utilizzare Azure AD password protection in Windows Server Active Directory

È possibile utilizzare la funzionalità appena descritta anche per proteggere gli utenti di dominio dall’utilizzo di password troppo facili. Per poter controllare quindi che anche on-premises non vengano utilizzate le password “bannate” o le password troppo “riconoscibili” è necessario installare on-premises due componenti software diversi:

  1. Azure AD password protection proxy service, che serve ad inoltrare le richieste dal domain controller ad Azure AD
  2. Azure AD password protection DC agent service, che riceve le richieste di validazione delle password, le processa utilizzando le password policy scaricate localmente (ogni ora) da Azure AD password protection e accetta/rifiuta la password scelta dall’utente

Figura 2: Processo di validazione delle password utilizzando la password policy scaricata da Azure AD Password Protection

Nessuna connessione Internet è richiesta dai Domain Controller. L’unica macchina che si connetterà ad Internet sarà quella in cui avete installato Azure AD password protection proxy service. Non verranno apportate modifiche allo Schema di Active Directory né tantomeno è richiesto un livello minimo funzionale di foresta e/o di dominio per l’utilizzo di Azure AD password protection con Windows Server Active Directory. Non verrà creato nessun utente locale.

Installazione del software

Al link Azure AD password protection for Windows Server Active Directory (preview) troverete i due installer per i due componenti software già citati. Installate il componente AzureADPasswordProtectionProxy.msi su una macchina joinata al dominio locale di Active Directory, che abbia l’accesso ad Internet, mentre installate il componente AzureADPasswordDCAgent.msi su tutti i domain controller della vostra infrastruttura. Attenzione perché il componente AzureADPasswordDCAgent richiede il riavvio del domain controller.

Figura 3: Download dei due software richiesti per l’abilitazione di Azure AD password protection for Windows Server Active Directory

Procedete all’installazione, su tutti i Domain Controller della vostra infrastruttura di Active Directory on-premises, dell’ Azure AD Password Protection DC Agent

Figura 4: Azure AD password protection DC Agent – License Agreement

Figura 5: Azure AD password protection DC Agent – Installazione del servizio

Figura 6: Azure AD password protection DC Agent – Installazione completata

Figura 7: Azure AD password protection DC Agent – Riavvio del domain controller necessario

Procedete all’installazione, in una macchina joinata al dominio e connessa ad Internet, dell’ Azure AD Password Protection proxy

Figura 8: Azure AD password protection proxy – License Agreement

Figura 9: Azure AD password protection proxy – Avvio servizi

Figura 10: Azure AD password protection proxy – Installazione completata

Terminata la procedura di installazione dei due software è necessario registrare la foresta di Active Directory ed il Password Protection Proxy con Azure AD. Posizionatevi sul server dovete avete installato il Password Protection Proxy, lanciate un prompt di PowerShell con le credenziali di Domain Admin e lanciate le due cmdlet Register-AzureADPasswordProtectionForest e Register-AzureADPasswordProtectionProxy . Autenticatevi con i permessi di un Global Admininistrator della vostra istanza di Azure AD, ma accertatevi che non usi la Multi-Factor Authentication perché nella Preview non può essere utilizzata (MFA potrà essere utilizzata nella versione finale).

Figura 11: Registrazione della foresta e del proxy di Azure AD Password protection

Verifica della funzionalità di Azure AD Password protection

Se volete forzare l’utilizzo di Azure AD Password protection e quindi impedire l’uso di password comuni o che avete deciso di “bannare” è necessario mettere a Enforced la Password protection for Windows Server Active Directory.

Figura 12: Modalità Enforced per la Password protection for Windows Server Active Directory

Se un amministratore tenta di resettare la password dell’utente ed utilizza una password “bannata” oppure non rispetta i prerequisiti dettati dalla password policy di Azure AD Passsword protection riceverà un errore come quello in figura:

Figura 13: Reset della password utente da parte dell’amministratore

Se un utente tenta, al momento di cambiare la password, di immettere una password non consentita riceverà un messaggio di errore tipico in cui lo si avvisa che non sta rispettando i requisiti di cronologia, di lunghezza o di complessità della password

Figura 14: All’utente viene chiesto di cambiare la password

Figura 15: Inserimento di una password non consentita dalla policy di Aure AD Password Protection

Figura 16: Messaggio di errore ricevuto dall’utente che ha cercato di usare una password “bannata”

Nel Domain Controller on-premises utilizzato per l’autenticazione sarà anche possibile verificare che la richiesta di cambiamento password dell’utente è stata rifiutata perché non soddisfa i requisiti imposti dalla Azure AD Password Policy (che come abbiamo detto viene scaricata ogni ora) andando nel registro Eventi nel ramo Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin.

Figura 17: Evento di errore relativo al rifiuto del cambiamento della password dell’utente perché non soddisfa la Azure password policy

Con la cmdlet di PowerShell Get-AzureADPasswordProtectionSummaryReport è anche possibile ottenere un report minimale

Figura 18: Reportistica tramite PowerShell

Per ulteriori informazioni sul logging e sul troubleshooting vi invito a leggere l’articolo Azure AD password protection monitoring, reporting, and troubleshooting

Conclusioni

Azure AD password protection per Windows Server Active Directory ci aiuta, grazie al Cloud, ad evitare che gli utenti utilizzino delle password troppo semplici o, anche se complesse, troppo comuni e facilmente indovinabili. Sicuramente una funzionalità utilissima per combattere le password prevedibili, oppure per impedire i Password Spray Attack, grazie ad un copioso database (abbiamo parlato di circa 500 password ed 1 milione di varianti) e all’Intelligenza Artificiale che il Cloud ci mette a disposizione.

Migrazione dei dischi delle macchine virtuali in Azure a Managed Disks

Facebooktwittergoogle_plusredditlinkedin

Da qualche giorno ho notato che nella pagina Overview delle macchine virtuali in Azure appare un messaggio che invita a migrare i dischi della VM da Unmanaged a Managed. Le macchine virtuali interessate in effetti sono state create diversi anni fa, quando gli Azure Managed Disks non esistevano. I dischi delle diverse macchine virtuali sono infatti conservati in uno Storage Account e sono stati progettati per il 99,999% di disponibilità. Per maggiori informazioni sui dischi che vengono collegati alle Azure VM vi rimando alla lettura dell’articolo Informazioni sull’archiviazione su dischi per le VM Windows di Azure

Se create una nuova VM dal portale di Azure vi viene chiesto se volete che i dischi siano Managed o Unmanaged e a dirla tutta la selezione su Managed Disk è attiva di default.

Il vantaggio dell’uso dei Managed Disk è offerto dalla gestione automatica che Azure fa dei dischi, senza necessariamente associarli ad uno Storage Account e senza subirne i limiti. Infatti i dischi avranno la massima tolleranza ai guasti offerta da Azure e saranno disponibili in modalità ridondata, esattamente come avviene per tutte le funzionalità offerte da Azure. I dischi verranno inseriti in differenti Storage Scale Units (stamps) che servono a limitare l’impatto che si avrebbe sulle VM nel momento in cui avvenisse un guasto hardware o software sullo storage.

Figura 1: Durante la creazione di una nuova Azure VM vengono utilizzati di default i Managed Disks

Migrazione dei dischi delle VM esistenti

È possibile eseguire la migrazione delle macchine virtuali di Azure esistenti a Managed Disks per trarre vantaggio dalla maggiore affidabilità delle macchine virtuali in un set di disponibilità. Dalla pagina Overview della VM sarà infatti sufficiente cliccare sul link Migrate to Managed Disks to get more benefits, come mostrato in figura:

Figura 2: Invito alla migrazione ai Managed Disks nella pagina di Overview della Azure VM

È importante notare che la conversione degli Unmanaged Disks a Managed Disks NON sarà reversibile e che una volta completata la conversione non sarà più possibile collegare dischi Unmanaged alla VM. Se la macchina non è accesa, verranno prima convertiti i dischi e successivamente la VM verrà automaticamente avviata per completare la migrazione e successivamente sarà possibile spegnerla. Se la Azure VM fa parte di un set di disponibilità, sarà necessario prima convertire il Virtual Machine Availability Set a Managed Availability Set e successivamente sarà possibile migrare i dischi, come mostrato in figura:

Figura 3: Conversione dell’Availabilty Set esistente a Managed Availability Set

Completata la migrazione dell’Availability Set basterà cliccare sul pulsante Migrate per migrare i dischi della VM. Terminata la migrazione dei dischi la macchina virtuale verrà automaticamente accesa.

Figura 4: Migrazione dei dischi della VM a Managed Disks

Figura 5: Operazione di migrazione dei dischi in corso

Figura 6: Migrazione dei dischi completata

Considerate che i dischi originali della VM NON verranno cancellati dallo Storage Account e che quindi continuerete a pagarli. Dopo la conversione vi conviene quindi cancellare i VHD originali dallo Storage Account.

Conversione tramite Azure Powershell

È possibile eseguire la procedura di conversione dei dischi di una singola VM utilizzando un paio di comandi di Azure PowerShell. Assicuratevi di avere almeno la versione 6.0.0 del modulo Azure PowerShell (verificatelo con il comando Get-Module -ListAvailable AzureRM) e se necessario aggiornate il modulo con il comando Update-Module AzureRM , come mostrato in figura:

Figura 7: Aggiornamento del modulo PowerShell di AzureRM

Connettetevi a Microsoft Azure con il comando Connect-AzureRmAccount e lanciate i seguenti comandi:

#Spegnimento della VM con deallocazione del disco
$rgName “mioResourceGroup” $vmName “miaVM”

Stop-AzureRmVM -ResourceGroupName $rgName -Name $vmName -Force

#Conversione dei dischi e successiva riaccensione della VM
ConvertTo-AzureRmVMManagedDisk -ResourceGroupName $rgName -VMName $vmName

Figura 8: Conversione dei dischi tramite PowerShell

Se volete convertire tutte le VM all’interno di un Availability Set allora potete usare i seguenti comandi:

#Aggiornamento dell’Availability Set a Managed Availiability Set
$rgName ‘mioResourceGroup’

$avSetName ‘mioAvailabilitySet’

$avSet Get-AzureRmAvailabilitySet -ResourceGroupName $rgName -Name $avSetName

Update-AzureRmAvailabilitySet -AvailabilitySet $avSet -Sku Aligned

#Migrazione di tutte le VM contenute nell’Availability Set
foreach($vmInfo in $avSet.VirtualMachinesReferences)

{

$vm Get-AzureRmVM -ResourceGroupName $rgName Where-Object {$_.Id -eq $vmInfo.id}

Stop-AzureRmVM -ResourceGroupName $rgName -Name $vm.Name -Force

ConvertTo-AzureRmVMManagedDisk -ResourceGroupName $rgName -VMName $vm.Name

}

Figura 9: Conversione di tutte le VM di un Availability Set

Problematiche nella migrazione

Durante la migrazione di una delle VM ho riscontrato un errore, che indicava che l’operazione di conversione a Managed Disks non era possibile a causa di una problematica relativa ad un’estensione della VM. Nel mio caso l’estensione era IaaSDiagnostics. Ho provveduto quindi a rimuovere l’estensione direttamente dal portale di Azure, cliccando sul nodo Extensions della VM e scegliendo la voce Uninstall, e a rilanciare la migrazione dei dischi, che si è svolta senza ulteriori intoppi. Successivamente ho reinstallato l’estensione che avevo rimosso.

Figura 10: l’estensione IaaSDiagnostics è in failed state ed impedisce la migrazione a Managed Disks

Figura 11: Rimozione dell’estensione effettuata a macchina accesa

Conclusioni

La migrazione dei dischi a Managed Disks è un’operazione molto semplice, che però richiede un certo downtime in quanto le macchine devono essere arrestate. Prima di iniziare vi consiglio di leggere due articoli: Plan for the migration to Managed Disks e the FAQ about migration to Managed Disks. Avete ancora macchine virtuali con Azure Service Manager (ASM) create con il vecchio portale? Allora seguite la guida Eseguire manualmente la migrazione di una macchina virtuale classica a una nuova macchina virtuale con disco gestito ARM

Buon lavoro!

Nic