Bilanciamento del carico e failover di autenticazione di Active Directory

Per le applicazioni che eseguono l'autenticazione con un controller di dominio Active Directory, ovviamente sarebbe preferibile puntarli al record DNS del dominio principale anziché a un controller di dominio specifico per il failover, il bilanciamento del carico, ecc.

Quali sono le migliori pratiche per quelle applicazioni che ti costringono a codificare l'IP di un controller di dominio? Potremmo invece codificare l'indirizzo IP di un bilanciamento del carico, quindi se un controller di dominio non funzionasse quell'applicazione sarebbe ancora in grado di autenticarsi. Ci sono alternative migliori?

In Active Directory sono già integrate tecniche di bilanciamento del carico. Il client Windows sa come individuare i controller di dominio ridondanti nel proprio sito e come utilizzarne un altro se il primo non è disponibile. Non è necessario eseguire un ulteriore bilanciamento del carico, come controller di dominio "cluster", ecc. Purché si disponga di controller di dominio ridondanti.

In un certo senso, è possibile pensare a un sito di Active Directory come a un "bilanciamento del carico", poiché i client in quel sito sceglieranno casualmente uno dei controller di dominio nello stesso sito. Se tutti i controller di dominio in un sito falliscono o se il sito non ha controller di dominio, i client sceglieranno un altro sito (o il sito più vicino successivo o a caso).

È possibile bilanciare il carico del servizio DNS fornito da Active Directory per i client aggiunti al dominio inserendo un VIP su un bilanciamento del carico hardware e avendo quel bilanciamento del carico VIP tra diversi controller di dominio. Quindi, sui client, inserisci quel VIP come server DNS preferito nella configurazione TCP / IP.

Lo sto facendo proprio ora per un'infrastruttura globale e funziona alla grande.

Questo vale solo per il servizio DNS.

Non tentare di bilanciare il carico dei controller di dominio per l'autenticazione. Chiede problemi. Dovresti almeno fare un sacco di lavoro SPN personalizzato complesso e ti spingeresti fuori dai confini del supporto Microsoft. Da questo blog, che dovresti leggere , lo citerò:

Torna dai fornitori e dì loro che non li consideri come AD integrati e troverai una soluzione diversa.

Ora, come per le applicazioni che ti chiedono di digitare l' indirizzo IP di un controller di dominio? Bene, ripeterò solo il mio commento:

Chiunque abbia scritto un'applicazione che ti costringe a inserire nel codice l'indirizzo IP di un controller di dominio, non sa cosa sta facendo.

non c'è mai stato un buon motivo per codificare un IP o utilizzare un IP per risolvere query AD. Non ci sono buone pratiche per cattive pratiche.

Molte delle altre risposte a questa domanda sembrano supporre che non vi sia altro mondo che le applicazioni consapevoli di Microsoft. Sfortunatamente non è così, come prova della domanda originale:

Quali sono le migliori pratiche per quelle applicazioni che ti obbligano a codificare l'IP di un controller di dominio?

Anche se Microsoft non supporta o consiglia di utilizzare una soluzione NLB di fronte ad Active Directory, in effetti sembrano esserci alcune opzioni per l'autenticazione di applicazioni non compatibili con Microsoft AD.

• Comprensione dell'autenticazione proxy in AD LDS
• IApp certificata F5 per il bilanciamento del carico LDAP
• Autenticazione pass-through con SASL

Un reale bisogno di AD "Load balancing" esterno è raro ed è difficile farlo correttamente. Una necessità di query tipiche può funzionare correttamente, tuttavia un client Windows tipico e le applicazioni devono eseguire aggiornamenti. Un client Windows tenta di stabilire un'affinità con un particolare dc, in modo che se aggiorna qualcosa e tenta immediatamente un'operazione successiva, colpisce lo stesso dc. Gli sviluppatori di applicazioni fanno la stessa cosa. Se si scrive codice che crea un account utente, quindi si tenta di modificare la password su quell'account 1 ms più tardi, è necessario premere lo stesso dc.

Se avessi front-end AD con una soluzione di bilanciamento del carico, ti assumerai la responsabilità di garantire che tali approcci e affinità non si rompano.

Se la necessità è la disponibilità, al contrario del bilanciamento del carico, il clustering potrebbe essere più appropriato (a parte il cluster può contenere worm).

Nelle grandi implementazioni AD, un approccio più tradizionale è quello di identificare la maggior parte dei consumatori e metterli in un sito con i propri DC. Ad esempio, se si dispone di cinque server Exchange, creare un sito per le sottoreti per tali server e inserire GC dedicati in quel sito. Lo stesso vale per altri server come SharePoint.