Condividi tramite

Server farm federativa AD FS legacy con SQL Server

Questa topologia relativa a Active Directory Federation Services (AD FS) differisce dalla server farm federativa che usa la topologia di distribuzione del database interno di Windows (WID) in quanto non replica i dati in ogni server federativo nella farm. Al contrario, tutti i server federativi della farm possono leggere e scrivere dati in un database comune che viene archiviato in un server che esegue Microsoft SQL Server che si trova nella rete aziendale.

Importante

Se si desidera creare una farm ADFS e utilizzare SQL Server per archiviare i dati di configurazione, è possibile utilizzare SQL Server 2008 e versioni successive, incluso SQL Server 2012 e SQL Server 2014.

Considerazioni sulla distribuzione

Questa sezione vengono descritte varie considerazioni sui destinatari, vantaggi e limitazioni di cui è associate a questa topologia di distribuzione.

Chi dovrebbe utilizzare questa topologia?

  • Organizzazioni di grandi dimensioni con più di 100 relazioni di trust che devono fornire agli utenti interni e agli utenti esterni l'accesso Single Sign-On (SSO) alle applicazioni o ai servizi federati

  • Le organizzazioni che già utilizzano SQL Server e si desiderano sfruttare gli strumenti esistenti e competenze

Quali sono i vantaggi dell'utilizzo di questa topologia?

  • Supporto per un numero maggiore di relazioni di trust (più di 100)

  • Supporto per il rilevamento della riproduzione dei token (una funzionalità di sicurezza) e la risoluzione degli artefatti (parte del protocollo Security Assertion Markup Language (SAML) 2.0)

  • Strumenti di supporto per i vantaggi di SQL Server, ad esempio il mirroring del database, il clustering di failover, reporting e gestione

Quali sono le limitazioni dell'utilizzo di questa topologia?

  • Per impostazione predefinita questa topologia non fornisce ridondanza del database. Anche se una server farm federativa con topologia WID vengono replicati automaticamente il database interno di Windows in ogni server federativo nella farm, la server farm federativa con topologia SQL Server contiene solo una copia del database

    Nota

    SQL Server supporta molti dati diversi e opzioni di ridondanza dell'applicazione tra il clustering di failover, il mirroring del database e diversi tipi di replica di SQL Server.

Il reparto IT (Microsoft Information Technology) usa il mirroring del database di SQL Server in modalità sincrona (high-safety) e clustering di failover per fornire supporto a disponibilità elevata per l'istanza di SQL Server. SQL Server transazionale di SQL Server (peer-to-peer) e la replica di tipo merge non sono state testate dal team del prodotto AD FS in Microsoft. Per ulteriori informazioni su SQL Server, vedere Panoramica delle soluzioni a disponibilità elevata o selezionando il tipo di replica appropriato.

Versioni supportate di SQL Server

Sono supportate le seguenti versioni SQL server con AD FS in Windows Server 2012 R2:

  • SQL Server 2008 / R2

  • SQL Server 2012

  • SQL Server 2014

Consigli di layout posizionamento e la rete di server

Analogamente alla server farm federativa con topologia WID, tutti i server federativi nella farm sono configurati per l'uso di un nome DNS (Domain Name System) del cluster (che rappresenta il nome del servizio federativo) e un indirizzo IP del cluster come parte della configurazione del cluster Bilanciamento carico di rete (NLB). In questo modo l'host di bilanciamento carico di RETE di allocare le richieste client per i server federativi singoli. I proxy server federativi utilizzabile per le richieste client proxy per la server farm federativa.

Nella figura seguente viene illustrato come la società fittizia Contoso Pharmaceuticals distribuite la server farm federativa con topologia SQL Server nella rete aziendale. Illustra anche come la società ha configurato la rete perimetrale con accesso a un server DNS, un host bilanciamento carico di rete aggiuntivo che usa lo stesso nome DNS del cluster (fs.contoso.com) usato nel cluster bilanciamento carico di rete della rete aziendale e con due proxy dell'applicazione Web (wap1 e wap2).

Illustration that shows how the fictional Contoso Pharmaceuticals company deployed its federation server farm with SQL Server topology in the corporate network.

Per altre informazioni su come configurare l'ambiente di rete per l'uso con server federativi o proxy di applicazioni Web, vedere la sezione "Requisiti di risoluzione dei nomi" in Requisiti di AD FS e Pianificare l'infrastruttura del proxy applicazione Web (WAP).

Opzioni di disponibilità elevata per SQL Server farm

In Windows Server 2012 R2, ADFS sono disponibili due nuove opzioni per supportare la disponibilità elevata nella farm ADFS utilizzando SQL Server.

  • Supporto per i gruppi di disponibilità AlwaysOn SQL Server

  • Supporto per la disponibilità elevata distribuito geograficamente, replica di tipo merge SQL Server

In questa sezione viene descritta ciascuna di queste opzioni, quali problemi vengono risolti rispettivamente e alcune considerazioni importanti per decidere quali opzioni per la distribuzione.

Nota

Le farm AD FS che usano database interno di Windows (WID) offrono ridondanza dei dati di base con accesso in lettura/scrittura sul nodo del server federativo primario e l'accesso in sola lettura nei nodi secondari.  Può essere utilizzato un geograficamente locale o di una topologia distribuita geograficamente.

Quando si utilizza WID tenere presente le limitazioni seguenti:

  • Se si dispone di un massimo di 100 trust della relying party, una farm WID ha un limite di 30 server federativi.
  • Una farm WID non supporta il rilevamento della riproduzione dei token o la risoluzione degli artefatti (parte del protocollo SAML(Security Assertion Markup Language).

Nella tabella seguente fornisce un riepilogo di utilizzo di una farm database interno di Windows.

1-100 attendibilità della relying party Più di 100 attendibilità della relying Party
1-30 nodi AD FS: WID supportato 1-30 nodi AD FS: non supportato con WID - SQL obbligatorio
Più di 30 nodi AD FS: non supportato con WID - SQL obbligatorio Più di 30 nodi AD FS: non supportato con WID - SQL obbligatorio

Gruppi di disponibilità AlwaysOn

Panoramica

Gruppi di disponibilità AlwaysOn sono stati introdotti in SQL Server 2012 e forniscono un nuovo modo per creare un'istanza di SQL Server la disponibilità elevata.  Gruppi di disponibilità AlwaysOn combinano gli elementi di clustering e il mirroring del database per la ridondanza e failover sia al livello di istanza SQL a livello di database.  A differenza delle opzioni di disponibilità elevata precedenti, i gruppi di disponibilità AlwaysOn non richiedono una risorsa di archiviazione comune (o una rete di archiviazione) a livello di database.

Un gruppo di disponibilità è costituito da una replica primaria (un set di database primari di lettura/scrittura) e da una a quattro repliche di disponibilità (set di database secondari corrispondenti).  Il gruppo di disponibilità supporta una singola copia di lettura/scrittura (replica primaria) e da una a quattro repliche di disponibilità di sola lettura.  Ogni replica di disponibilità deve risiedere su un nodo diverso di un singolo cluster WSFC (Windows Server Failover Clustering).  Per altre informazioni sui gruppi di disponibilità AlwaysOn, vedere Panoramica dei gruppi di disponibilità AlwaysOn (SQL Server).

Dal punto di vista dei nodi di una farm di SQL Server AD FS, il gruppo di disponibilità AlwaysOn sostituisce la singola istanza di SQL Server come database norma/artefatto.  Il listener del gruppo di disponibilità è il client (servizio token di sicurezza AD FS) usato per connettersi a SQL.

Il diagramma seguente mostra un SQL Server Farm ADFS con gruppo di disponibilità AlwaysOn.

Diagram that shows an AD FS SQL Server Farm with AlwaysOn Availability group.

Nota

I gruppi di disponibilità AlwaysOn richiedono che le istanze di SQL Server si trovino nei nodi WSFC (Windows Server Failover Clustering).

Nota

Solo una replica di disponibilità può fungere da una destinazione del failover automatico, altri tre si baserà su failover manuale.

Considerazioni chiave sulla distribuzione

Se si prevede di usare i gruppi di disponibilità AlwaysOn in combinazione con la replica di tipo merge di SQL Server, prendere nota dei problemi descritti in "Considerazioni chiave sulla distribuzione per l'uso di AD FS con la replica di tipo merge di SQL Server" di seguito.  In particolare, quando un gruppo di disponibilità AlwaysOn contenente un database che è un sottoscrittore di replica esegue il failover, la sottoscrizione di replica ha esito negativo. Per riprendere la replica, un amministratore di replica deve riconfigurare manualmente il sottoscrittore.  Vedere la descrizione di SQL Server di un problema specifico in Sottoscrittori di replica e gruppi di disponibilità AlwaysOn (SQL Server) e istruzioni di supporto generali per i gruppi di disponibilità AlwaysOn con opzioni di replica in Replica, Rilevamento modifiche, Change Data Capture e Gruppi di disponibilità AlwaysOn (SQL Server).

Configurazione di AD FS per l'uso di un gruppo di disponibilità AlwaysOn

La configurazione di una farm ADFS con gruppi di disponibilità AlwaysOn richiede una modifica quasi irrilevante per la procedura di distribuzione di ADFS:

  1. Prima di configurare i gruppi di disponibilità AlwaysOn, è necessario creare i database che si desidera eseguire il backup.  ADFS crea i relativi database come parte del programma di installazione e configurazione iniziale del primo nodo del servizio federativo di una nuova farm di Server SQL di ADFS.  Come parte della configurazione di AD FS, è necessario specificare una stringa di connessione SQL, quindi sarà necessario configurare il primo nodo della farm AD FS per connettersi direttamente a un'istanza SQL (questa è solo temporanea).   Per indicazioni specifiche sulla configurazione di una farm di ADFS, inclusa la configurazione di un nodo della farm ADFS con una stringa di connessione SQL server, vedere configurare un Server federativo.

  2. Dopo aver creato i database AD FS, assegnarli ai gruppi di disponibilità AlwaysOn e creare il listener TCPIP comune usando gli strumenti e il processo di SQL Server in Creazione e configurazione dei gruppi di disponibilità (SQL Server).

  3. Infine, utilizzare PowerShell per modificare le proprietà di ADFS per aggiornare la stringa di connessione SQL per utilizzare l'indirizzo DNS del listener del gruppo di disponibilità AlwaysOn.

    Comandi PSH di esempio per aggiornare la stringa di connessione SQL per il database di configurazione di AD FS:

    PS:\>$temp= Get-WmiObject -namespace root/ADFS -class SecurityTokenService
PS:\>$temp.ConfigurationdatabaseConnectionstring="data source=<SQLCluster\SQLInstance>; initial catalog=adfsconfiguration;integrated security=true"
PS:\>$temp.put()

  4. Comandi PSH di esempio per aggiornare la stringa di connessione SQL per il database del servizio di risoluzione degli artefatti di AD FS:

    PS:\> Set-AdfsProperties –artifactdbconnection "Data source=<SQLCluster\SQLInstance >;Initial Catalog=AdfsArtifactStore;Integrated Security=True"

Replica di tipo Merge SQL Server

Inoltre introdotto in SQL Server 2012, replica di tipo merge consente la ridondanza dei dati dei criteri ADFS con le seguenti caratteristiche:

  • Funzionalità di lettura e scrittura in tutti i nodi (non solo il primario)

  • Più piccole quantità di dati replicati in modo asincrono per evitare l'introduzione di latenza per il sistema

Il diagramma seguente mostra una farm di SQL Server AD FS con ridondanza geografica con replica di tipo merge (1 server di pubblicazione, 2 sottoscrittori):

server farm using SQL

Considerazioni chiave sulla distribuzione per l'uso di AD FS con la replica di tipo merge di SQL Server (numeri di nota nel diagramma precedente)

Per istruzioni più dettagliate su come configurare ADFS utilizzare una replica di tipo merge SQL Server, vedere installazione ridondanza geografica con la replica di SQL Server.

Vedi anche

Pianificare la topologia di distribuzione di AD FSGuida alla progettazione di AD FS in Windows Server 2012 R2