Ottimizzazione di SQL e risoluzione dei problemi di latenza con AD FS

  • Articolo

In un aggiornamento per AD FS 2016, sono stati introdotti i miglioramenti seguenti per ridurre la latenza del database. Uno dei prossimi aggiornamenti per AD FS 2019 includerà questi miglioramenti.

Aggiornamento della cache in memoria in un thread in background

Nelle distribuzioni Always on Availability (AoA) precedenti, esisteva una latenza per qualsiasi operazione di "lettura", perché il nodo master poteva trovarsi in un data center separato. La chiamata tra due data center diversi ha generato una latenza.

Nell’aggiornamento più recente di AD FS, la riduzione della latenza viene destinata tramite l'aggiunta di un thread in background per l'aggiornamento della cache di configurazione di AD FS e di un'impostazione per impostare il periodo di aggiornamento. Il tempo impiegato per la ricerca del database è notevolmente ridotto nel thread di richiesta, poiché gli aggiornamenti della cache del database vengono spostati nel thread in background.

Quando backgroundCacheRefreshEnabled è impostato su true, AD FS abilita il thread in background per eseguire gli aggiornamenti della cache. La frequenza di recupero dei dati dalla cache può essere personalizzata con un valore di tempo impostando cacheRefreshIntervalSecs. Il valore predefinito è impostato su 300 secondi quando backgroundCacheRefreshEnabled è impostato su true. Dopo la durata del valore impostato, AD FS inizia ad aggiornare la cache e, mentre l'aggiornamento è in corso, i dati della cache precedente continueranno a essere usati.

Quando AD FS riceve una richiesta per un'applicazione, AD FS recupera l'applicazione da SQL e la aggiunge alla cache. Al valore cacheRefreshIntervalSecs, l'applicazione nella cache viene aggiornata usando il thread in background. Finché esiste una voce nella cache, le richieste in arrivo useranno la cache mentre è in corso l'aggiornamento in background. Se viene eseguito l’accesso a una voce per 5 * cacheRefreshIntervalSecs, viene eliminata dalla cache. La voce meno recente può anche essere eliminata dalla cache una volta raggiunto il valore configurabile maxRelyingPartyEntries.

Nota

I dati della cache verranno aggiornati al di fuori del valore cacheRefreshIntervalSecs se AD FS riceve una notifica da SQL che indica che si è verificata una modifica nel database. Questa notifica attiverà l'aggiornamento della cache.

Elementi consigliati per l'impostazione dell'aggiornamento della cache

Il valore predefinito per l'aggiornamento della cache è cinque minuti. È consigliabile impostarlo su 1 ora per ridurre l'aggiornamento non necessario dei dati da parte di AD FS perché i dati della cache verranno aggiornati in caso di modifiche SQL.

AD FS registra un callback per le modifiche di SQL e, in caso di modifica, AD FS riceve una notifica. Tramite questo metodo, AD FS riceve ogni nuova modifica da SQL non appena si verifica.

In caso di problemi di rete, per cui AD FS non riceve la notifica SQL, AD FS verrà aggiornato all'intervallo specificato dal valore di aggiornamento della cache. Se si sospettano problemi di connettività tra AD FS e SQL, è consigliabile impostare il valore di aggiornamento della cache su un valore inferiore a 1 ora.

Istruzioni di configurazione

Il file di configurazione supporta più voci della cache. L’elenco seguente può essere configurato in base alle esigenze dell'organizzazione.

L'esempio seguente abilita l'aggiornamento della cache in background e imposta il periodo di aggiornamento della cache su 1800 secondi, o 30 minuti. Questa operazione deve essere eseguita su ogni nodo AD FS e il servizio AD FS deve essere riavviato in seguito. Le modifiche non influiscono sugli altri nodi e testano il primo nodo prima di effettuare la modifica in tutti i nodi.

  1. Passare al file di configurazione di AD FS (percorso predefinito C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe.config) e nella sezione "Microsoft.IdentityServer.Service" aggiungere la voce seguente:
  • backgroundCacheRefreshEnabled: specifica se la funzionalità della cache in background è abilitata. valori "vero/falso".
  • cacheRefreshIntervalSecs: valore in secondi al quale AD FS aggiorna la cache. AD FS aggiornerà la cache in caso di modifiche in SQL. AD FS riceverà una notifica SQL e aggiornerà la cache.

Nota

Tutte le voci del file di configurazione sono sensibili alle maiuscole e alle minuscole. <cache cacheRefreshIntervalSecs="1800" > backgroundCacheRefreshEnabled="true" />

Valori configurabili aggiuntivi supportati:

  • maxRelyingPartyEntries: numero massimo di voci di relying party che AD FS manterrà in memoria. Questo valore viene usato anche dalla cache delle autorizzazioni dell'applicazione oAuth. Se sono presenti più autorizzazioni dell’applicazione rispetto agli RP e se tutto verrà memorizzato, questo valore deve essere il numero di autorizzazioni di applicazione. Il valore predefinito è 1000.
  • maxIdentityProviderEntries: il numero massimo di voci del provider di attestazioni che AD FS manterrà in memoria. Il valore predefinito è 200.
  • maxClientEntries: il numero massimo di voci del client OAuth che AD FS manterrà in memoria. Il valore predefinito è 500.
  • maxClaimDescriptorEntries: il numero massimo di voci del descrittore di attestazioni che AD FS manterrà in memoria. Il valore predefinito è 500.
  • maxNullEntries: viene usata come cache negativa. Quando AD FS cerca una voce nel database e non la trova, AD FS aggiunge una cache negativa. Questa è la dimensione massima della cache. È presente una cache negativa per ogni tipo di oggetto, non una singola cache per tutti gli oggetti. Il valore predefinito è 50.0000.

Supporto di più database dell’artefatto tra i vari data center

Per le configurazioni precedenti di più data center, AD FS ha supportato solo un singolo database dell’artefatto, causando una latenza tra i data center durante le chiamate di recupero.

Per ridurre la latenza del data center, l'amministratore di AD FS può ora distribuire più istanze del database degli artefatti e quindi modificare il file di configurazione di un nodo AD FS per puntare a diverse istanze degli database dell’artefatto. La stringa di connessione al database degli artefatti può essere fornita nel file di configurazione, consentendo un database dell’artefatto per ogni nodo. Se la stringa di connessione non è presente nel file di configurazione, il nodo tornerà al progetto precedente per usare il database dell’artefatto, che è presente nel database di configurazione. Con questa configurazione sono supportati anche gli ambienti ibridi.

Requisiti

Prima di configurare il supporto di più database degli artefatti, eseguire un aggiornamento su tutti i nodi e aggiornare i file binari, perché le chiamate tra più nodi avvengono tramite questa funzionalità.

  1. Generare lo script di distribuzione per creare il database dell’artefatto: per distribuire più istanze del database dell’artefatto, un amministratore dovrà generare lo script di distribuzione SQL per il database dell’artefatto. Nell'ambito di questo aggiornamento, il cmdlet Export-AdfsDeploymentSQLScript esistente è stato aggiornato per accettare facoltativamente un parametro che specifica per quale database AD FS generare uno script di distribuzione SQL.

Ad esempio, per generare lo script di distribuzione solo per il database dell’artefatto, specificare il parametro -DatabaseType e passare al valore "Artefatto". Il parametro opzionale -DatabaseType specifica il tipo di database AD FS e può essere impostato su: Tutti (impostazione predefinita), Artefatto o Configurazione. Se non viene specificato alcun parametro -DatabaseType, lo script configurerà entrambi gli script Artefatto e Configurazione.

PS C:\> Export-AdfsDeploymentSQLScript -DestinationFolder <script folder where scripts will be created> -ServiceAccountName <domain\serviceaccount> -DatabaseType "Artifact"

Lo script generato deve essere eseguito sul computer SQL per creare i database richiesti e assegnare all'account del servizio AD FS, SQL SA, le autorizzazioni per tali database.

  1. Creare il database dell’artefatto usando lo script di distribuzione. Copiare gli script di distribuzione CreateDB.sql e SetPermissions.sql appena generati sul computer SQL server ed eseguirli per creare il database dell’artefatto locale.

  2. Modificare il file di configurazione per aggiungere la connessione al database dell’artefatto. Passare al file di configurazione del nodo AD FS e, nella sezione "Microsoft.IdentityServer.Service", aggiungere un punto di ingresso ad ArtifactDB appena configurato.

Nota

artifactStore e connectionString fanno distinzione tra maiuscole e minuscole. Assicurarsi che siano configurati correttamente. <artifactStore connectionString="Data Source=.\SQLInstance; Sicurezza integrata=True; Initial Catalog=AdfsArtifactStore" />

Usare un valore di origine dati che corrisponda alla connessione SQL.

  1. Riavviare il servizio AD FS per rendere effettive le modifiche.

Nota

Non è consigliabile utilizzare la replica o la sincronizzazione SQL tra i database degli artefatti. È consigliabile configurare un database dell’artefatto per ogni data center.

Failover e ripristino del database tra data center

È consigliabile creare database di artefatti di failover nello stesso data center del database dell’artefatto master. Se si verifica un failover, non verrà generato alcun aumento della latenza. I database degli artefatti di failover nei data center non sono consigliati. Di seguito viene illustrato come funzionano le chiamate per OAuth, SAML, ESL e il rilevamento del replay dei token con più database degli artefatti.

  • OAuth e SAML

    Per le richieste di artefatti OAuth e SAML, il nodo creerà l'artefatto nel database dell'artefatto presente nel file di configurazione. Se il file di configurazione non contiene una connessione al database dell’artefatto, verrà utilizzato il database dell’artefatto comune. Quando la richiesta successiva per recuperare l'artefatto passa a un altro nodo, l'altro nodo renderà l’API rest al primo nodo per recuperare l'artefatto dal database dell’artefatto. Questo operazione è necessaria perché i diversi nodi potrebbero avere database degli artefatti diversi e i nodi non lo sanno. Se il primo nodo è inattivo, la risoluzione degli artefatti avrà esito negativo. A causa di questa progettazione, non è necessario replicare il database dell'artefatto in diversi data center. Se un intero data center è inattivo, molto probabilmente anche il nodo che ha creato l'artefatto è inattivo, il che significa che l'artefatto non può più essere risolto.

  • Blocco Extranet

    Il database dell’artefatto a cui si fa riferimento nel file di configurazione verrà usato per i dati di blocco Extranet. Tuttavia, per la funzionalità ESL, AD FS sceglie un master, che scrive i dati nel database dell'artefatto. Tutti i nodi effettuano una chiamata API REST al nodo master per ottenere e impostare le informazioni più recenti su ogni utente. Se sono in uso più database degli artefatti, l'amministratore deve selezionare un nodo master per ogni database dell’artefatto o data center.

    Per selezionare un nodo come master ESL, passare al file di configurazione del nodo AD FS e, nella sezione "Microsoft.IdentityServer.Service", aggiungere quanto segue:

    Nel master aggiungere la voce seguente. Tutte e tre le chiavi fanno distinzione tra maiuscole e minuscole.

    <useractivityfarmrole masterFQDN=[FQDN della primaria selezionata] isMaster="true"/>

    Negli altri nodi aggiungere la voce seguente:

    <useractivityfarmrole masterFQDN=[FQDN della primaria selezionata] isMaster="false"/>

    Nota

    Poiché più database degli artefatti non sincronizzano i dati, i valori ESL non verranno sincronizzati tra i database degli artefatti. Un utente può potenzialmente colpire un data center diverso per una richiesta, rendendo quindi ExtranetLockoutThreshold dipendente dal numero di database degli artefatti, ExtranetLockoutThreshold * Numero di database degli artefatti.

    • Rilevamento della riproduzione dei token

      I dati di rilevamento della riproduzione dei token vengono sempre richiamati dal database degli artefatti centrale. AD FS salva il token dall'attendibilità del provider di attestazioni, assicurandosi che lo stesso token non possa essere riprodotto. Se un utente malintenzionato tenta di riprodurre lo stesso token, AD FS verifica se il token esiste nel database dell’artefatto. Se il token è presente, la richiesta verrà rifiutata. Il database dell’artefatto centrale viene usato per la sicurezza; perché i dati del DB dell’artefatto non vengono replicati, un utente malintenzionato potrebbe inviare la richiesta a un altro data center e riprodurre un token. La creazione di copie aggiuntive di sola lettura di ArtifactDB non impedirà la latenza tra data center in questo scenario, perché viene usato solo il database dell’artefatto centrale.