Archivi categoria: 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.

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.

Utilizzare certificati gratuiti di Let’s Encrypt in una Azure Web App

Facebooktwittergoogle_plusredditlinkedin

Da quando è nata, il 12 aprile 2016, abbiamo avuto modo di parlare in diversi articoli della Certification Authority gratuita Let’s Encrypt. In questo articolo voglio far vedere come ottenere un certificato digitale gratuito generato da Let’s Encrypt da utilizzare con una Web App di Azure.

È infatti disponibile nelle Azure Web App un’estensione, creata da Simon J.K. Pedersen, che permette di ottenere e di rinnovare i certificati digitali da utilizzare con i Custom Domains delle Azure Web App.

Darò per scontato che abbiate già creato una Azure Web App e vi farò vedere come attivare l’estensione per Let’s Encrypt.

Creazione del Service Principal (Registered App)

La prima operazione che faremo sarà quella di creare un Service Principal in Azure AD. Si tratta fondamentalmente di un service account che viene utilizzato per ottenere un accesso alle risorse di Azure e che ci permetterà di richiedere e rinnovare il certificato digitale di Let’s Encrypt senza che sia necessario alcun intervento manuale. La creazione del Service Principal può essere effettuata dal portale di Azure selezionando la directory dentro la quale lo volete creare, scegliendo il nodo App Registrations e cliccando su + New application registration, come mostrato in figura:

Figure 1: Creazione di un nuovo Service Principal in Azure AD

Nel blade che si aprirà digitate il nome che volete dare al Service Principal (io ho scelto nicferr) e l’url della Web App, come mostrato in figura:

Figure 2: configurazione di un nuovo Service Principal in Azure AD

Una volta che avrete creato la Registered App sarà necessario creare una Secret Key (password). Infatti, per le autenticazioni utilizzeremo la combinazione Application ID e Secret Key per permettere all’estensione di Let’S Encrypt di potersi autenticare ed effettuare le operazioni di richiesta e rinnovo del certificato. Cliccate quindi su Settings e scegliete il nodo Keys. Creare una nuova password semplicemente scrivendo la description e la data di scadenza, come mostrato in figura. Quando cliccherete su Save la chiave verrà generata automaticamente.

Figure 3: Creazione di una nuova chiave di accesso per la Registered App

Dopo il salvataggio sarà possibile copiare la chiave generata automaticamente. Ricordatevi di salvarla perché non sarà successivamente visibile, come avrà modo di suggerirvi il banner mostrato in figura:

Figure 4: Generazione della chiave completata

Terminata la creazione del Service Principal (Registered App) sarà necessario assegnargli i giusti permessi per poter eseguire l’estensione. Andate nel Resource Group che ospita la vostra Web App e dal nodo Access Control (IAM), cliccate su Add e date il ruolo di Contributor alla Registered App che avete creato. La Registered App non sarà visibile nell’elenco, ma vi basterà scriverla nel campo Select e sarà subito trovata, come mostrato in figura

Figure 5: Aggiunta dei privilegi al Service Principal (Registered App)

ATTENZIONE: Se la Web App e l’App Service Plan si trovano in due Resource Group differenti, sarà necessario dare il permesso di Contributor ad ENTRAMBI

Installazione dell’estensione Let’s Encrypt

Terminata la fase preparatoria, siamo pronti per installare le due estensioni necessarie a far funzionare Let’S Encrypt con una Azure Web App. Dal portale di Azure, selezionate la Web App e dal nodo Extensions cliccate su Add per aggiungere l’estensione, come mostrato in figura:

Figure 6: Aggiunta di una estensione alla Web App di Azure

Scegliete l’estensione Azure Let’s Encrypt dalla lista delle estensioni disponibili e procedete all’installazione

Figure 7: Scelta dell’estensione Azure LEt’s Encrypt

Questa estensione NON è supportata da Microsoft. È bene tenerne conto nel caso ci siano malfunzionamenti, perché l’autore non da garanzie, come esplicitamente dichiarato nei termini legali.

Figure 8: Accettazione dei termini legali di utilizzo

L’estensione sarà subito visibile tra quelle installate

Figure 9: Installazione dell’estensione completata

Aggiungete anche l’estensione Azure Let’s Encrypt (no Web Jobs)

Figure 10: Aggiunta dell’estensione Azure Let’s Encrypt (no Web Jobs)

Se vi spostate nel modo WebJobs della vostra Web App potrete notare che sarà stata installato un nuovo webjobs, che servirà a rinnovare il certificato prima della scadenza.

Figure 11: Creazione del WebJob nella Web App

Configurazione dell’estensione di Azure Let’s Encrypt

Siamo ora pronti per configurare l’estensione. Cliccate sul tasto Browse dell’estensione Azure Let’s Encrypt per aprire la pagina di configurazione, come mostrato in figura:

Figure 12: Configurazione dell’estensione

Nella nuova pagina del browser vi apparirà la possibilità di configurare in maniera completamente automatica la richiesta e il rinnovo del certificato. Completate tutti i campi come richiesto. Maggiori dettagli su quello che deve essere inserito nei diversi campi sono anche disponibili alla pagina https://github.com/sjkp/letsencrypt-siteextension/wiki/How-to-install

Figure 13: inserimento delle informazioni necessarie per configurare l’estensione

Cliccando su Next si avvierà il processo di richiesta del certificato. Se non avete aggiunto dei Custom Domain alla vostra Web App vi apparirà l’errore mostrato in figura 15:

Figure 14: Prima richiesta del certificato

Figure 15: Errore relativo alla mancanza di un Custom Domain per cui richiedere il certificato

Aggiunta di un host name per il Custom Domain

Aggiungere un Custom Domain alla Web App richiede pochi semplici passaggi, ben descritti nell’esercitazione Eseguire il mapping di un nome DNS personalizzato esistente ad una Web App di Azure

Figure 16: Aggiunta di un host name personalizzato alla Web App

Una volta che avrete aggiunto il Custom Domain, rilanciando la configurazione dell’estensione di Let’s Encrypt, vedrete che il wizard potrà proseguire e vi chiederà per quale hostname volete generare il certificato, come mostrato in figura:

Figure 17: Il wizard ha riconosciuto gli hostname personalizzati

Figure 18: Scelta del nome host per cui richiedereil certificato

Dopo qualche secondo, il certificato sarà stato creato e associato (binding) all’hostname che avete scelto nel wizard.

Figure 19: Creazione del certificato completata

Se provate a caricare la vostra Web App infatti vedrete che starà utilizzando un certificato emesso da Let’s Encrypt, come mostrato in figura:

Figure 20: La Web App utilizza il certificato emesso da Let’s Encrypt

Conclusioni

Sono decisamente notevoli I vantaggi offerti da Let’s Encrypt, che ci permette di avere certificati digitali gratuiti ed automaticamente rinnovati. Poterli integrare con le Azure Web App ed avere la possibilità di utilizzare il protocollo HTTPS anche per gli hostname personalizzati garantisce i migliori livelli di sicurezza per la navigazione web.

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.

Configurare Active Directory Federation Services 2016 e Azure Multi-Factor Authentication

Facebooktwittergoogle_plusredditlinkedin

Tra le novità introdotte in Active Directory Federation Services (AD FS) in Windows Server 2016 c’è la possibilità di integrare l’autenticazione con Microsoft Azure Multi-Factor Authentication (MFA), in modo tale da inserire una One-Time Password (OTP) invece che la password di dominio.

Tra le problematiche più note, infatti, si riscontra quella dovuta al blocco dell’account in Active Directory dopo che qualcuno ha tentato di indovinare la password e l’ha sbagliata diverse volte.

Figura 1: Numero massimo di tentativi di accesso falliti prima che l’account venga bloccato

Figura 2: Account bloccato dopo 10 tentativi di accesso falliti

Come avrete modo di leggere nell’articolo Azure AD and ADFS best practices: Defending against password spray attacks, utilizzare ADFS 2016 ed Azure MFA con sistema principale di autenticazione permette di ottenere un sistema passwordless, basato esclusivamente su un OTP.

Ho già avuto modo di farvi vedere come Configurare Active Directory Federation Services in Windows Server 2016 e come Configurare AD FS 2016 ed Office 365 con Azure AD Connect nei miei precedenti articoli. Oggi vi voglio mostrare quanto sia facile integrare ADFS 2016 con Azure MFA.

Registrazione degli utenti in Azure MFA

AD FS non permette che avvenga la registrazione degli utenti in Azure MFA (proofup), ma gli utenti devono essersi già registrati e aver attivato l’MFA. Per farlo possono collegarsi a https://account.activedirectory.windowsazure.com/Proofup.aspx oppure in alternativa a https://aka.ms/mfasetup ed eseguire la procedura di registrazione, in cui possono inserire il numero di telefono a cui ricevere messaggi SMS, le chiamate oppure posso collegare l’App per il cellulare (Azure Authenticator)

Figura 3: Configurazione della Multi-factor authentication

Azure MFA come autenticazione principale

Se si utilizza Azure MFA come Primary Authentication in AD FS si può evitare di inserire la password durante il login ad Azure AD, ad Office365 oppure ad altre applicazioni SaaS ed utilizzare un codice temporaneo OTP. Se stiamo utilizzando un pc sconosciuto per autenticarci allora è il caso di prendere il massimo delle precauzioni (potrebbe esserci un keylogger sulla macchina oppure qualcuno potrebbe vedere la password che digitiamo).

Prerequisiti

Per poter connettere ADFS a Azure MFA dovete accertarvi di avere i seguenti prerequisiti:

  • Installazione on-premises di un’infrastruttura AD FS basa su Windows Server 2016
  • Federazione dell’infrastruttura con Azure AD
  • Aver installato il modulo PowerShell per Azure AD (Msoline)
  • Permessi di Global Administrator nella sottoscrizione di Azure AD
  • Credenziali di Enterprise Administrator per configurare la Farm ADFS per Azure MFA

Configurazioni dei server ADFS

Come prima operazione creeremo un certificato digitale da utilizzare per MFA. Il certificato dovrà essere creato su TUTTI i server AD FS della vostra Farm. Per creare un certificato relativo alla nostra Azure AD useremo la cmdlet di PowerShell

$certbase64=New-AdfsAzureMfaTenantCertificate -TenantIdnicolaferrini.onmicrosoft.com

Ovviamente sostituite il TenantID con quello della vostra directory di Azure AD

Figura 4: Creazione del certificato da utilizzare per Azure MFA

Il certificato verrà salvato nello store Local Computer

Figura 5: Certificato da utilizzare per Azure MFA creato

Connettetevi al vostro tenant di Azure AD con il comando Connect-MsolService e successivamente aggiungete le credenziali al Service Principal Name (SPN) del client di Azure Multi-Factor Auth utilizzando il comando PowerShell

New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certBase64

981f26a1-7f43-403b-a875-f8b09b8cd720 è il guid dell’ Azure Multi-Factor Auth Client

Figura 6: Aggiunta delle credenziali al Service Principal Name (SPN) del client di Azure Multi-factor Auth

Configurazione della Farm AD FS

Dopo aver completato i passaggi precedenti in ogni server della Farm ADFS, è necessario impostare il servizio Azure MFA come fattore di autenticazione. Lanciate, una sola volta e su un server ADFS qualsiasi, il comando PowerShell

Set-AdfsAzureMfaTenant -TenantId nicolaferrini.onmicrosoft.com -ClientId981f26a1-7f43-403b-a875-f8b09b8cd720

Ovviamente sostituite il TenantID con quello della vostra directory di Azure AD.

Riavviate il Servizio di Active Directory Federation Service su tutte le macchina ADFS della vostra Farm.

Figura 7: Impostazione del servizio Azure MFA come fattore di autenticazione

Verificate che il nuovo metodo di autenticazione Azure MFA sia presente ed abilitato nella console AD FS Management, come mostrato in figura:

Figura 8: Azure MFA è adesso un Primary Authentcation method per la nostra Farm ADFS

Nel mio caso ho abilitato Azure MFA solo per l’accesso dall’esterno e non dall’interno dell’infrastruttura.

Verifica della presenza di Azure MFA come Primary Authentication method

Per verificare che tutto funzioni perfettamente è possibile collegarsi alla pagina di login del vostro server ADFS (nel mio caso è https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm)

Poiché ho federato la mia ADFS con Office 365, vado sul portale di autenticazione https://portal.office.com ed inserisco le credenziali di un utente del dominio e testo l’autenticazione dall’ESTERNO della mia infrastruttura.

Figura 9: Connessione al portale di Office 365

Figura 10: Il dominio di Azure AD è federato e vengo reindirizzato al mio Federation Server

Nella pagina di login è apparso un nuovo link che mi permette di utilizzare la Azure Multi-Factor Authentication.

Figura 11: Nella pagina di login del Federation Server è presente il link per utilizzare la Azure Multi-Factor Authentication

Cliccando però sul link ricevo un messaggio di errore. L’utente che sta tentando di connettersi non ha infatti effettuato il ProofUp, cioè la registrazione di Azure MFA. Per poter accedere deve prima collegarsi a https://account.activedirectory.windowsazure.com/Proofup.aspx oppure in alternativa a https://aka.ms/mfasetup ed eseguire la procedura di registrazione. Successivamente potrà riprovare a loggarsi con ADFS e Azure MFA.

Figura 12: Pagina di errore se l’accesso viene effettuato da un utente che non si è registrato in Azure MFA

Se invece tento di accedere con un utente che si è precedentemente registrato in Azure MFA, mi viene presentata una pagina dove posso inserire il codice di verifica che ho sulla mia App Azure Auhtenticator oppure posso utilizzare altre opzioni (SMS, telefonata, notifica sull’App)

Figura 13: Inserimento della One-Time Password (OTP) per l’autenticazione

Personalizzazione del portale di accesso di AD FS

AD FS non permette che avvenga la registrazione degli utenti in Azure MFA (proofup) e abbiamo visto che se un utente non si è precedentemente registrato non riuscirà ad utilizzare Azure MFA. È possibile però apportare delle modifiche alle pagine del portale di autenticazione ADFS e fare in modo di venire rediretti automaticamente alla pagina a https://account.activedirectory.windowsazure.com/Proofup.aspx oppure in alternativa a https://aka.ms/mfasetup per eseguire la procedura di registrazione.

Per poter personalizzare l’aspetto della pagina di Sign-In di ADFS è possibile seguire la procedura descritta nell’articolo Advanced Customization of AD FS Sign-in Pages

In questo esempio farò apparire un errore personalizzato, che avvisa gli utenti che devono prima registrarsi ad Azure MFA e successivamente provare a loggarsi al portale.

Come prima operazione clonerò il tema di default delle pagine di Sign-In (che chiamerò AzureMFA) e lo esporterò in modo tale da poterne modificare il file onload.js. La procedura deve essere effettuata da PowerShell su tutti i server ADFS della vostra Farm utilizzando i comandi:

#Creazione di un nuovo tema per il portale ADFS
New-AdfsWebTheme –Name AzureMFA –SourceName default

#Esportazione del tema per poter effettuare le modifiche
Export-AdfsWebTheme –Name AzureMFA –DirectoryPath c:\AzureMFAtheme

Figura 14: Creazione di un nuovo tema per la pagina di Sign-In di ADFS

Nella cartella C:\AzureMFATheme\script troverete il file onload.js, che dovrete modificare inserendo alla fine del file le seguenti righe:

// Se Azure MFA non è disponibile per l'utente si riceve un messaggio che fornisce la procedura corretta per la registrazione
if (document.getElementById('errorMessage').innerHTML.search("The selected authentication method is not available") ) { 
// Show message with redirect link
	errorMessage.innerHTML = 'E\' necessario prima registrarsi per la Multi-Factor Authentication. Collegarsi al portale <a href="https://aka.ms/mfasetup">https://aka.ms/mfasetup</a>, inserire per l\'autenticazione la propria password, registrarsi ad Azure MFA e riprovare successivamente a loggarsi a questa pagina utilizzando la Multi-Factor Authentication.';
}

Figura 15: Modifica del file onload.js con il messaggio di errore personalizzato

Terminata la modifica del file è necessario inserirlo nel tema che avete clonato (nel mio caso si chiama AzureMFA) eseguendo il comando PowerShell

#Aggiornamento del tema con il file onload.js personalizzato
Set-AdfsWebTheme -TargetName AzureMFA -AdditionalFileResource @{Uri=‘/adfs/portal/script/onload.js’;path=“c:\AzureMFAtheme\script\onload.js”}

Successivamente rendete il tema attivo, sostituendo quello di default, con il comando:

#Applicazione del tema personalizzato
Set-AdfsWebConfig -ActiveThemeName AzureMFA

Figura 16: Modifiche apportate al tema di ADFS

Adesso se un utente non ha effettuato il ProofUp, cioè non si è registrato ad Azure AD, invece che ricevere un messaggio di errore che gli indica la procedura corretta di registrazione ad Azure MFA.

Figura 17: Accesso al portale con le credenziali di un utente che non ha effettuato il ProofUp

Figura 18: Messaggio di errore che avvisa l’utente che non può usare la Azure MFA perché deve prima registrarsi (proofup)

Figura 19: L’utente si deve autenticare con la password per poter attivare Azure MFA

Figura 20: L’utente viene reindirizzato al portale di registrazione di Azure MFA

Conclusioni

Per rendere più sicura l’infrastruttura, per evitare che gli utenti vengano bloccati in Active Directory per troppi tentativi di indovinare la password e per stare più tranquilli quando si autenticano utilizzando AD FS da un computer che non è il loro, la soluzione di integrare AD FS 2016 con Azure MFA ed utilizzare un OTP per l’autenticazione è decisamente la migliore e vi permette di sfruttare al massimo le tecnologie disponibili per impedire attacchi di password spray o di password guessing.

Configurare AD FS 2016 ed Office 365 con Azure AD Connect

Facebooktwittergoogle_plusredditlinkedin

Azure AD Connect è un tool gratuito che integra le directory locali (dominio) con Azure Active Directory. Questo permette di sincronizzare utenti e password on-premises con il tenant di Office 365 e con tutte le applicazioni SaaS che usano Azure AD per l’autenticazione.

In alcuni casi però le aziende preferiscono non sincronizzare le password dei propri utenti con Azure AD. Per poter consentire l’accesso ai servizi cloud si può ricorrere all’autenticazione basata sugli Active Directory Federation Services. Grazie all’accesso federato, gli utenti possono accedere ai servizi basati su Azure AD con le proprie password locali e, se si collegano da un computer all’interno della rete aziendale (joinato al dominio), non devono immettere di nuovo le password per autenticarsi (Single Sign-On).

Per configurare un’infrastruttura basata su ADFS potete leggere il mio articolo Configurare Active Directory Federation Services in Windows Server 2016

Figura 1: Autenticazione ai servizi SaaS effettuata con Active Directory Federation Services

In questo articolo vi voglio mostrare come il tool Azure AD Connect vi permetta facilmente di configurare la federazione con Active Directory Federation Services (ADFS) locale e Azure AD. Usando l’opzione di federazione con ADFS, è possibile distribuire una nuova installazione di ADFS oppure specificare un’installazione esistente in una farm ADFS di Windows Server 2012 R2 o di Windows Server 2016.

Assicuratevi di aver verificato tutti i Prerequisiti di Azure AD Connect e procedete al download del tool Azure AD Connect. In questo momento è disponibile la versione 1.1.819.0 del 14/05/2018.

Lanciate il wizard di installazione e accettate la licenza, come mostrato in figura:

Figura 2: Lancio del wizard di installazione di Azure Ad Connect

La configurazione che vogliamo applicare richiede che venga effettuata una Installazione personalizzata di Azure AD Connect, pertanto cliccate sul tasto Customize

Figura 3: Scelta dell’installazione personalizzata di Azure Ad Connect

Figura 4: Installazione dei componenti richiesti

Terminata l’installazione dei componenti, scegliamo in quale modo gli utenti faranno il Sign-in. Ho già avuto modo di affrontare in un altro articolo i vantaggi della Azure AD Pass-through Authentication, mentre in questo articolo vi mostro come configurare la Federation con AD FS.

Figura 5: scelta della modalità di Sign-in per gli utenti

Figura 6: Connessione al tenant di Azure AD con le credenziali di Global Admin

Figura 7: Connessione all’Active Directory locale

Cliccate sul pulsante Add Directory ed inserite le credenziali di un utente che abbia permessi sufficienti per leggere le informazioni dal dominio locale. È anche possibile creare un nuovo utente.

Figura 8: Selezione di un utente di AD locale

Figura 9: Connessione all’AD locale effettuata

Assicuratevi di aver configurato correttamente i suffissi UPN per gli utenti del vostro AD locale. Trovate maggiori informazioni leggendo l’articolo How to prepare a non-routable domain for directory synchronization

Figura 10: LIsta dei dominio presenti on-premises e verifica dei domini personalizzati aggiunti online

Nella schermata successiva sarà possibile scegliere quali domini della vostra foresta volete sincronizzare e quali OU. Sarà possibile modificare i filtri anche in un secondo momento, come ho già avuto modo di spiegare nel mio articolo Configurare i filtri in Azure AD Connect

Figura 11: Filtro dei domini e delle OU da sincronizzare

Figura 12: Scelta dell’identificativo univoco con cui vengono rappresentati utenti, gruppi e dispositivi

Figura 13: Eventuale filtro in base al Distinguished Name di un gruppo di AD

Nella schermata relativa alle Optional features potete scegliere se abilitare la Password hash Synchronization o l’attribute filtering. Obiettivo di questo articolo è quello di usare i Federation Services per l’autenticazione ed evitare di sincronizzare le password con il Cloud e per questo motivo lasciate invariate tutte le scelte di default.

Figura 14: Scelta delle Optional features

A questo punto siete pronti per configurare Azure AD Connect con la vostra Farm ADFS. Inserite le credenziali di un amministratore del dominio in cui si torva la vostra Farm ADFS e cliccate su Next.

Figura 15: Inserimento credenziali dell’amministratore del dominio

È possibile creare una nuova AD FS Farm oppure utilizzare una Farm esistente. Nel mio caso ho già una Farm (che ho creato con gli steps descritti nel mio articolo Configurare Active Directory Federation Services in Windows Server 2016). Specifico quindi il server che ospita la Farm ADFS e proseguo con il wizard.

Figura 16: Scelta del server che ospita la Farm ADFS

Figura 17: Selezione del dominio online da federare con la directory on-premises

Figura 18: Conferma dell’installazione di Azure AD Connect

Figura 19: Configurazione completata

Terminata l’installazione di Azure AD Connect potete procedere alla verifica della funzionalità di connettività. Il vostro dominio personalizzato di Azure AD è stato convertito da Standard a Federato ed il Federation Server Gateway di Microsoft adesso punta per l’autenticazione al vostro Web Application Proxy (nel mio caso è sts.nicolaferrini.cloud). Assicuratevi di aver configurato correttamente la risoluzione dei nomi (sia internamente che esternamente alla vostra infrastruttura) e di aver aperto le porte del firewall.

Figura 20: Verifica della funzionalità di federation

Figura 21: Funzionalità verificata

Test di autenticazione – Accesso dall’ESTERNO dell’organizzazione

Adesso che avete configurato tutto correttamente vi basterà collegarvi ad una applicazione Saas che usa Azure AD per l’autenticazione. Ad esempio potete collegarvi ad Office365 tramite il portale https://portal.office.com. Verrete subito reindirizzati al Federation Gateway di Microsoft (https://login.microsoftonline.com) e potrete inserire le credenziali del vostro utente di dominio.

Figura 22: Connessione al portale Office365

Il Microsoft Federation Gateway si accorgerà che il dominio è federato e vi farà collegare direttamente al vostro Web Application Proxy. A quel punto potrete inserire la password del vostro account di dominio, che tramite il vostro Active Directory Federation Server verrà verificata col domain controller.

Figura 23: Reindirizzamento da parte del Microsoft Federation Gateway verso il Web Application Proxy aziendale

Figura 24: Pagina di autenticazione del Federation Server aziendale

Se le credenziali inserite sono corrette verrete reindirizzati alla pagina del Federation Gateway di Microsoft (https://login.microsoftonline.com)

Figura 25: Funzionalità “Mantieni l’accesso (KMSI)”. Questa funzionalità concede l’accesso agli utenti che tornano alle applicazioni senza richiedere di immettere nuovamente il nome utente e password

Figura 26: Accesso al portale di Office365 completato

Test di autenticazione – Accesso dall’INTERNO dell’organizzazione

Se vi collegate da una macchina in dominio e siete loggati con lo stesso utente con cui volete fare il Sign-In ad Azure AD, Active Directory Federation Services provvederà ad usare il token Kerberos che già possedete e ad utilizzare la Windows Integrated Authentication (WIA) per farvi accedere ad Azure AD (Single Sign-On). Però appena utilizzerete il browser vi accorgerete che vi apparirà lo stesso una finestra di autenticazione. Per evitare di reinserire le credenziali ed utilizzare il Single Sign-On sarà necessario considerare attendibile l’url del Federation Server ed inserirlo nella Local Intranet.

Figura 27: Richiesta delle credenziali di accesso anche da una macchina in dominio

Figura 28: Aggiunta nelle Internet Options dell’url del Federation Server nei Local Intranet Trusted Sites

Se non usate Internet Explorer ma usate Google Chrome non avrete problemi perché per impostazione predefinita Chrome usa lo stesso insieme di URL di siti attendibili di Internet Explorer.

È anche possibile utilizzare una Group Policy per poter automatizzare questa impostazione. Ci basterà creare una nuova GPO da collegare al dominio e in User Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page dobbiamo modificare la voce Site to Zone Assignment List

Figura 29: Aggiunta ai Trusted Sites dell’url del Federation Server tramite GPO centralizzata

Connessione tramite i browser Google Chrome, Mozilla Firefox e Microsoft Edge

Se volete effettuare la connessione da browser alternativi ad Internet Explorer sarà necessario, dopo aver inserito nella Local Intranet l’url del Federation Server, apportare alcune modifiche alla configurazione del server ADFS, come spiegato nell’articolo

Configurazione autenticazione intranet basata su form per i dispositivi che non supportano WIA

Infatti sarà necessario modificare la lista dei client che possono supportare la Windows Integrated Authentication (WIA). Per farlo vi basterà eseguire sul server ADFS, da un prompt di PowerShell eseguito con privilegi elevati, i seguenti comandi:

#Verifica dei client attualmente supportati
Get-ADFSProperties Select -ExpandProperty WIASupportedUserAgents

#Aggiunta dei browser Firefox, Chrome e Edge
Set-AdfsProperties –WIASupportedUserAgents @(“MSAuthHost/1.0/In-Domain”,“MSIE 6.0”,“MSIE 7.0”,“MSIE 8.0”,“MSIE 9.0”,“MSIE 10.0”,“Trident/7.0”, “MSIPC”,“Windows Rights Management Client”,“Mozilla/5.0”,“Edge/12”)

#Riavvio dei servizio Active Directory Federation Services
Restart-Service ADFSSRV

Figura 30: Modifica dei client che supportano la WIA in ADFS

Active Directory Federation Services 2016 e Azure Multi-Factor Authentication

Tra le novità introdotte in Active Directory Federation Services (AD FS) in Windows Server 2016 c’è la possibilità di integrare l’autenticazione con Microsoft Azure Multi-Factor Authentication (MFA), in modo tale da inserire una One-Time Password (OTP) invece che la password di dominio. Alla pagina Active Directory Federation Services 2016 e Azure Multi-Factor Authentication troverete tutti gli step necessari ad integrare le due funzionalità.

Conclusioni

Azure AD Connect vi permette di configurare facilmente la federazione con Active Directory Federation Services (ADFS) locale e Azure AD. In questo modo gli utenti potranno beneficiare del Single Sign-On (SSO) e le aziende non saranno costrette a dover sincronizzare le password degli utenti con Azure AD. Con pochi semplici passaggi l’autenticazione avviene in azienda e i nostri dati sono al sicuro, permettendo di rispettare i requisiti di privacy e di compliance.

Active Directory Federation Services in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Gli Active Directory Federation Services (ADFS) permettono di identificare, autenticare ed autorizzare gli utenti e di offrire il web single sign-on per applicazioni che non sono ospitate nei server del vostro dominio.

Supponete infatti di voler utilizzare un applicativo web creato da un’azienda esterna alla vostra organizzazione (Resource Partner) e di non voler comunicare a questa azienda username e password dei vostri utenti di dominio (Account Partner). ADFS vi permette di reindirizzare le autenticazioni per l’applicazione web verso il vostro Federation Server e di usare il vostro domain controller come database per le autenticazioni. Basta quindi installare due Federation Server ed aprire un’unica porta (il traffico tra i server è HTTPS) per poter avere la possibilità di loggarsi senza reinserire le credenziali e allo stesso tempo non doverle comunicare a nessuno.

Figura 1: Principio di funzionamento di ADFS

In questo articolo mi occuperò della configurazione di una nuova Farm ADFS in Windows Server 2016. Per conoscere tutte le novità della nuova versione di ADFS vi rimando alla lettura dell’articolo What’s new in Active Directory Federation Services per Windows Server 2016

Prima però di avventurarci nella configurazione vera e propria della nostra Farm ADFS vi consiglio di leggere l’articolo Checklist: Deploying a Federation Server Farm e l’articolo Best practices for securing Active Directory Federation Services

L’infrastruttura tipica di una Farm ADFS è quella presentata nella figura 2. All’interno della LAN abbiamo il domain controller e le macchine in dominio, tra cui i server ADFS, mentre nella DMZ abbiamo il Web Application Proxy, che rimarrà in workgroup e che si occuperà di proteggere le connessioni da Internet verso il server ADFS.

Figura 2: Infrastruttura di ADFS che verrà realizzata

Gestione dei certificati per il Namespace ADFS

Come prima operazione procuratevi un certificato digitale per il nome del vostro ADFS Namespace. Utilizzate le informazioni contenute alla pagina Requisiti del certificato per ADFS per conoscere le caratteristiche che deve avere il certificato da installare su tutti i server della vostra infrastruttura ADFS, compresi i Web Application Proxy.

NOTA: Tutti i server ADFS e i server Web Application Proxy necessitano di un certificato SSL per soddisfare le richieste HTTPS per il servizio federativo. Il certificato da installare deve essere esattamente
lo stesso su tutti i server dell’infrastruttura ADFS.

Nel mio caso utilizzerò il certificato con il nome sts.nicolaferrini.cloud. Dopo che avrete installato lo stesso certificato sia sulla macchina ADFS (in dominio) che sulla macchina Web Application Proxy (in workgroup) potete procedere con la configurazione del server ADFS

Requisiti per il dominio

ADFS 2016 richiede che il controller del dominio sia almeno Windows Server 2008 (il livello funzionale del dominio può invece essere ancora Windows Server 2003) e che tutte le macchine ADFS della Farm siano joinate allo stesso dominio. Per la creazione della Farm ADFS potete utilizzare uno standard service account oppure un Group Managed Service Account (gMSA). Per utilizzare un gMSA è necessario che i domain controller sia almeno Windows Server 2012 e uno dei vantaggi più evidenti del loro utilizzo è che la password dell’account viene aggiornata automaticamente.

Io preferisco utilizzare i Group Managed Service Account (gMSA),
e poiché sto usando un ambiente nuovo ed è la prima volta che ne creo uno devo prima creare la Key Distribution Services KDS Root Key, necessaria al domain controller per generare le password dei gMSA. Per poter creare la chiave è sufficiente eseguire, con privilegi elevati, in un domain controller il seguente comando PowerShell

Add-KdsRootKey –EffectiveImmediately

I domain controller aspetteranno fino a 10 ore dal momento della creazione della chiave prima di poter permettere la creazione di un Group Managed Service Account (gMSA), in modo tale da consentire a tutti i domain controller presenti nel dominio di poter replicare la chiave appena creata. In un ambiente di laboratorio potete accelerare questa operazione eseguendo con privilegi elevati in un domain controller il seguente comando PowerShell:

Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)

Figura 3: Creazione della Key Distribution Services KDS Root Key per la generazione delle password dei Group Managed Service Account (gMSA).

Requisiti per il database di ADFS

Per l’installazione di ADFS è possibile utilizzare sia il Windows Internal Database (WID) che Microsoft SQL Server (sono supportate le versioni SQL Server 2008 e successive). Per maggiori informazioni vi rimando alla lettura dell’articolo Requisiti del database di configurazione di una Farm ADFS. In questo articolo utilizzerò il Windows Internal Database.

Installazione del primo server della Farm ADFS

Aprite il Server Manager in Windows Server 2016 e lanciate il wizard per l’aggiunta di un nuovo ruolo. Io sto utilizzando la macchina ADFS1.cloud. lab, che ho joinato al dominio, e procedo all’installazione del ruolo di Active Directory Federation Services, come mostrato in figura:

Figura 4: Installazione del ruolo Active Directory Federation Services

Figura 5: Riepilogo delle funzionalità offerte dal ruolo ADFS

Figura 6: Installazione del ruolo ADFS completata

Cliccando sul collegamento Configure the federation service in this server potrete lanciare il wizard che vi permetterà di creare il primo server della vostra Farm ADFS. Verificate anche dal link AD FS prerequisites di aver completato tutti i prerequisiti d’installazione e procedete cliccando su Next.

Figura 7: Creazione del primo Federation Server nella Farm

Figura 8: Account di dominio da utilizzare per la configurazione del server ADFS

Nella schermata successiva scegliete dal menù a tendina il certificato da utilizzare (che dovrete aver precedentemente installato) ed il Federation Service Name, che vi servirà successivamente per configurare il Web Application Proxy. Indicate anche il nome da visualizzare nella pagina di autenticazione di ADFS.

Figura 9: Certificato, Federation Service Name e nome della Farm ADFS da creare

Nella schermata successiva specificate il Service Account che farà girare i servizi ADFS. Utilizzerò, come già detto, un Group Managed Service Account chiamato ADFSservice

Figura 10: Creazione del Group Managed Service Account

Figura 11: Utilizzo del Windows Internal Database (WID)

Figura 12: Schermata riassuntiva delle configurazioni scelte

Figura 13: Controllo dei prerequisiti

Figura 14: Configurazione della Farm ADFS completata

La creazione della Farm ADFS è completata, ma è necessario riavviare la macchina. Notate alcuni warning che mi sono apparsi nella schermata finale. I warning si riferiscono ad alcuni nomi che mancano nel certificato (certauth.sts.nicolaferrini.cloud e enterpriseregistration.nicolaferrini.cloud). La mancanza di questi nomi non permetterà di registrare i dispositivi tramite ADFS e non permetterà l’autenticazione tramite certificato (novità della versione 4.0 di ADFS). Ricordatevi quindi di utilizzare certificati di tipo SAN con tutti i nomi. Il certificato corretto da utilizzare nel mio dominio avrebbe dovuto includere questi nomi:

  • Subject Name (CN): sts.nicolaferrini.cloud
  • Subject Alternative Name (DNS): sts.nicolaferrini.cloud
  • Subject Alternative Name (DNS): certauth.sts.nicolaferrini.cloud
  • Subject Alternative Name (DNS): enterpriseregistration.nicolaferrini.cloud

Dopo il riavvio potete connettervi alla AD FS Management console e verificare le configurazioni del vostro server. Aprendo le proprietà potrete accertarvi di aver utilizzato i nomi corretti, come mostrato in figura:

Figura 15: ADFS Management console e Federation Service Properties

Creazione della zona DNS e record per il server ADFS

Per permettere la corretta risoluzione dei nomi del server ADFS ho creato nel domain controller una zona con il nome pubblico nicolaferrini.cloud e ho creato un record host per sts.nicolaferrini.cloud, in modo tale che le macchine interne sappiano come contattare il server ADFS. Il dominio interno ed il dominio esterno infatti differiscono ed è necessario configurare correttamente la risoluzione dei nomi.

Figura 16: Creazione della zona e del record DNS per il server ADFS

Verifica della funzionalità ed accesso alla pagina di Sign-In

ADFS in Windows Server 2016 disabilita di default la pagina idpinitiatedsignon, utile per testare se l’installazione è avvenuta correttamente. È possibile riabilitarla lanciando sul server ADFS il comando Powershell, eseguito con privilegi elevati

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

Figura 17: Abilitazione della pagina idpinitiatedsignon

Collegatevi quindi all’indirizzo https://<FQDN DEL SERVER ADFS>/adfs/ls/idpinitiatedsignon.htm per verificare che tutto funzioni. Nel mio caso ho digitato l’indirizzo https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm e ho potuto verificare di avere accesso alla pagina di Sign-In

Figura 18: Verifica dell’accesso alla pagina di Sign-In

È anche possibile verificare che sia attivo l’url relativo ai Federation Service Metadata collegandosi a https://<FQDN DEL SERVER ADFS>/federationmetadata/2007-06/federationmetadata.xml. Nel mio caso ho utilizzato l’indirizzo https://sts.nicolaferrini.cloud/federationmetadata/2007-06/federationmetadata.xml

Figura 19: Verifica dell’accesso ai Federation Service Metadata

Aggiunta dei altri server ADFS alla Farm esistente

In caso il server ADFS non funzionasse i vostri utenti non potrebbero loggarsi. È quindi opportuno aggiungere un ulteriore server alla Farm ADFS che avete appena realizzato. La procedura è ben descritta nell’articolo Add a Federation Server to a Federation Server Farm. Dopo aver aggiunto il secondo server alla Farm sarà necessario anche utilizzare un bilanciatore di carico a monte dei due server per assicurarne l’alta disponibilità. Ulteriori informazioni sono disponibili alla pagina Load Balancer Requirements for ADFS 2016

Installazione del Web Application Proxy

Il Web Application Proxy (WAP), da installare in DMZ e da lasciare in Workgroup, è necessario per proteggere i server ADFS ed evitare di esporli direttamente ad Internet. Il WAP si comporta da Reverse Proxy e permette l’accesso sicuro alle applicazioni on-premises dall’esterno dell’infrastruttura aziendale. Maggiori dettagli sono disponibili nell’articolo Web Application Proxy in Windows Server 2016

Prerequisiti per la configurazione del proxy

  • Installare esattamente lo stesso certificato che avete installato sui server ADFS
  • Assicurarsi che il WAP possa risolvere il nome interno del vostro server ADFS o del VIP del vostro Load Balancer
  • Creare un record DNS pubblico per il WAP, in modo tale che possa essere contattato dall’esterno
  • Aprire le porte del firewall (la porta 443 per l’HTTPS deve essere aperta dall’esterno verso il WAP e dal WAP verso ADFS)

Installazione del Web Application Proxy

L’installazione del Web Application Proxy è molto semplice. Dal Server Manager lanciate il wizard per aggiungere un nuovo ruolo e scegliete il ruolo Remote Access, come mostrato in figura:

Figura 20: Aggiunta del ruolo Remote Access, necessario per l’installazione del Web Application Proxy

Figura 21: Descrizione delle funzionalità offerta dal ruolo Remote Access

Scegliete di installare il role service Web Application Proxy e aggiungete tutte le funzionalità richieste dal ruolo

Figura 22: Installazione del role service Web Application Proxy

Figura 23: Installazione del ruolo completata

Fate clic sul link Open the Web Application Proxy Wizard per lanciare la configurazione del WAP

Figura 24Web Application Proxy Configuration Wizard

Indicate quale sarà il server ADFS a cui dovrà puntare il WAP quando riceverà le richieste di autenticazione ed autorizzazione. Nel mio caso il server è sts.nicolaferrini.cloud

Figura 25: Configurazione del Federation Server da contattare

Figura 26: Scelta del certificato digitale

Figura 27: Comandi PowerShell che verranno eseguiti per la configurazione del WAP

Terminata la configurazione potrete aprire la Remote Access Management console e verificare che tutti i servizi siano perfettamente funzionanti, come mostrato in figura:

Figura 28: Remote Access Management console

Accesso dall’esterno dell’organizzazione

Per verificare che tutto funzioni perfettamente potete collegarvi da una macchina ESTERNA alla vostra infrastruttura e collegarvi al WAP. Modificate il DNS pubblico in modo tale che punti all’IP pubblico del WAP, controllate le configurazioni dei firewall e connettetevi al vostro server (nel mio caso sts.nicolaferrini.cloud) tentando di raggiungere la pagina idpinitiatedsignon, esattamente come avete fatto prima. Se avete configurato tutto correttamente vi collegherete al WAP che inoltrerà la richiesta al server ADFS (o al bilanciatore).

Figura 29: Connessione al server ADFS avvenuta dall’esterno dell’organizzazione, tramite WAP

Accesso dall’interno dell’organizzazione

Se provate a collegarvi da una macchina in dominio, usando qualsiasi browser, alla pagina di autenticazione https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm vi apparirà un messaggio che vi richiederà di inserire le credenziali. Per poter garantire l’accesso automatico dell’utente è prima necessario impostare nella Local Intranet l’url del Federation Server. Questa impostazione consente al browser di inviare automaticamente le credenziali dell’utente connesso sotto forma di un ticket Kerberos per AD FS.

Figura 30: Richiesta di credenziali anche dalla macchina in dominio

Figura 31: Aggiunta nelle Internet Options dell’url del Federation Server nei Local Intranet Trusted Sites

Se non usate Internet Explorer ma usate Google Chrome non avrete problemi perché per impostazione predefinita Chrome usa lo stesso insieme di URL di siti attendibili di Internet Explorer.

È anche possibile utilizzare una Group Policy per poter automatizzare questa impostazione. Ci basterà creare una nuova GPO da collegare al dominio e in User Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page dobbiamo modificare la voce Site to Zone Assignment List

Figura 32: Aggiunta ai Trusted Sites dell’url del Federation Server tramite GPO centralizzata

Connessione tramite i browser Google Chrome, Mozilla Firefox e Microsoft Edge

Se volete effettuare la connessione da browser alternativi ad Internet Explorer sarà necessario, dopo aver inserito nella Local Intranet l’url del Federation Server, apportare alcune modifiche alla configurazione del server ADFS, come spiegato nell’articolo Configurazione autenticazione intranet basata su form per i dispositivi che non supportano WIA

Infatti sarà necessario modificare la lista dei client che possono supportare la Windows Integrated Authentication (WIA). Per farlo vi basterà eseguire sul server ADFS, da un prompt di PowerShell eseguito con privilegi elevati, i seguenti comandi:

#Verifica dei client attualmente supportati
Get-ADFSProperties Select -ExpandProperty WIASupportedUserAgents

#Aggiunta dei browser Firefox, Chrome e Edge
Set-AdfsProperties –WIASupportedUserAgents @(“MSAuthHost/1.0/In-Domain”,“MSIE 6.0”,“MSIE 7.0”,“MSIE 8.0”,“MSIE 9.0”,“MSIE 10.0”,“Trident/7.0”, “MSIPC”,“Windows Rights Management Client”,“Mozilla/5.0”,“Edge/12”)

#Riavvio dei servizio Active Directory Federation Services
Restart-Service ADFSSRV

Figura 33: Modifica dei client che supportano la WIA in ADFS

Configurazione di Active Direcotry Federation Service con Office 365

Per configurare AD FS 2016 con Office 365 è possibile utilizzare il tool Azure AD Connect, che si occuperà di automatizzare la procedura. Alla pagina Configurare AD FS 2016 ed Office 365 con Azure AD Connect trovate tutti i passaggi necessari per eseguire l’integrazione di AD FS 2016 con Azure AD e Office 365.

Active Directory Federation Services 2016 e Azure Multi-Factor Authentication

Tra le novità introdotte in Active Directory Federation Services (AD FS) in Windows Server 2016 c’è la possibilità di integrare l’autenticazione con Microsoft Azure Multi-Factor Authentication (MFA), in modo tale da inserire una One-Time Password (OTP) invece che la password di dominio. Alla pagina Active Directory Federation Services 2016 e Azure Multi-Factor Authentication troverete tutti gli step necessari ad integrare le due funzionalità.

Conclusioni

I vantaggi offerti dai Federation Services sono notevoli, perché permettono il Single Sign-On ed evitano che le password dei nostri utenti vengano memorizzate al di fuori della nostra organizzazione. Sia per motivi burocratici, che di privacy, sarebbe impossibile rivolgersi a fornitori di servizi esterni, che dovrebbero archiviare e gestire (e quindi mantenere aggiornate) le nostre credenziali. Con ADFS l’autenticazione avviene in azienda e i nostri dati sono al sicuro!