Panoramica #

Il server Web Microsoft, Internet Information Services (IIS), integra diversi meccanismi di autenticazione per convalidare gli utenti contro un sistema Active Directory o autonomo (autenticazione basata su LDAP). NTLM è il protocollo di autenticazione Challenge / Response di Windows che può essere utilizzato in reti e applicazioni che potrebbero essere utilizzate in entrambi gli ambienti.

Si potrebbero prendere in considerazione due diversi scenari: Autenticazione NTLM interattiva è composto da due sistemi un client e un controller di dominio che viene utilizzato per archiviare i dati degli utenti necessari per fornire le autenticazioni e Autenticazione NTLM non interattiva coinvolge tre diversi sistemi un client, un server di applicazioni e un dominio per consentire a un utente di accedere a una determinata risorsa in un'applicazione.

Rappresentazione di ASP.NET consente alle applicazioni Web di autenticare e autorizzare utenti che si affidano a Microsoft IIS.

In questo articolo spiegheremo come bilanciare il carico delle applicazioni che integrano il protocollo NTLM per scenari di autenticazione di utenti non interattivi.

Come funziona NTLM? #

Il protocollo NTLM si basa sul protocollo HTTP / S in cui un determinato client avvia un handshake di un totale di passi 6 per stabilire la sessione autenticata.

L'handshake della sessione autenticato richiede i seguenti passaggi:

1. Il client avvia una richiesta anonima di una determinata risorsa a un server web.

OTTIENI/HTTP

2. Le risposte del server con un messaggio non autorizzato e il metodo di autenticazione che il client deve utilizzare.

401 Autenticazione WWW non autorizzata: NTLM

3. Il client rinvia la richiesta includendo una richiesta di autenticazione in formato NTLM.

Autorizzazione GET/HTTP: NTLM

4. Il server risponde con un messaggio non autorizzato e richiede ulteriori informazioni al client.

401 Autenticazione WWW non autorizzata: NTLM

5. Il client invia di nuovo la richiesta includendo il resto delle informazioni sulla sessione.

Autorizzazione GET/HTTP: NTLM

6. Il server si connette al controller di dominio per completare la richiesta di autenticazione e quindi conferma al client l'autenticazione.

HTTP 200 OK

Si noti che questo handshake è richiesto in ogni nuova connessione, non nelle richieste HTTP, e durante i passaggi da 3 a 6, la connessione deve essere mantenuta attiva. Se la connessione è chiusa, questa parte dell'handshake deve essere ripetuta e non è valido ripetere dal passaggio 5. D'altra parte, una volta che la connessione è stata autenticata, non è necessario inviare nuovamente l'intestazione di autorizzazione mentre la connessione non viene chiusa indipendentemente dalla risorsa a cui si accede.

Come caricare le applicazioni Web di bilanciamento utilizzando l'autenticazione NTLM? #

Con RELIANOID, esistono due modi principali per bilanciare il carico e creare un'applicazione Web basata su NTLM in alta disponibilità, con un semplice bilanciatore del carico TCP di livello 2 o con un proxy di livello 4 per funzionalità avanzate.

Semplice bilanciamento del carico NTLM sul layer 4 #

Per bilanciare il carico delle applicazioni Web con il supporto dell'autenticazione NTLM con una semplice configurazione, possiamo creare farm basati su LSLB con profilo L4xNAT. Possiamo utilizzare i protocolli HTTP o HTTPS.

Quindi, nella configurazione globale assicurarsi che il protocollo utilizzato sia TCP ma possiamo selezionare NAT or DTA secondo la topologia richiesta.

Nel Servizi sezione, è necessario impostare la persistenza in modo da garantire che l'autenticazione per un determinato client vada sempre allo stesso backend, altrimenti l'autenticazione della connessione non potrebbe essere eseguita.

Infine, aggiungi la tua lista di backend e configura un health check come indicato nelle sezioni seguenti.

Il bilanciamento del carico NTLM sul layer 7 #

Questa opzione consente di gestire i dati HTTP / S con supporto NTLM con il proxy 7 di livello configurato tramite il modulo LSLB e la farm HTTP. Per questo, abbiamo bisogno di creare una farm per HTTP o HTTPS in base ai requisiti SSL per il servizio virtuale. L'unica differenza sarebbe il Ascoltatore configurato nel Impostazioni globali della fattoria creata.

A questo livello, poiché l'applicazione non è ancora in grado di creare alcun cookie di sessione al fine di creare una permanenza o un pinning di connessione, possiamo fare uso del Inserimento di cookie opzione che consente al bilanciamento del carico di creare un nuovo cookie durante l'iniziale handshake dell'autenticazione NTLM.

Infine, aggiungi la tua lista di backend e configura un health check come indicato nelle sezioni seguenti. È possibile configurare opzioni di applicazione aggiuntive a livello di proxy incluse in questo tipo di farm e il supporto NTLM non sarà interessato.

Controlli avanzati di integrità per i siti Web di autenticazione NTLM #

Per creare il nostro controllo di integrità avanzato personalizzato per le applicazioni autenticate NTLM, dobbiamo creare sotto il percorso /usr/local/relianoid/app/libexec uno script per controllare il backend come mostrato di seguito. Per esempio, check_ntlm.sh con le autorizzazioni appropriate.

#!/bin/bash # ottieni i parametri di input BACKEND=$1 PORTA=$2 UTENTE=$3 PASS=$4 URI=$5 STRINGA=$6 /usr/bin/curl http://${BACKEND}:${PORT}${URI } --ntlm -negotiate -u ${UTENTE}:${PASSAGGIO} 2>/dev/null | grep "${STRING}" &>/dev/null if [ $? == 0 ] then # se il comando curl non fallisce, notifica che il backend è attivo echo "Server ${BACKEND}:${PORT} OK" exit 0 fi # se il comando curl fallisce, notifica che il backend è inattivo echo "Il server ${BACKEND}:${PORT} non è OK" exit 1

Nel Monitoraggio >> Farmguardian sezione, se applicabile, o aggiungendolo al comando per il check-in del servizio di fattoria.

Possiamo testare lo script di controllo sanitario eseguendo:

/usr/local/relianoid/app/libexec/check_ntlm.sh 192.168.0.99 80 johndoe johnsecret "/mio/uri" "DOCTYPE html"

Sapendo che l'IP back-end è 192.168.0.99 il porto è 80 HTTP, JohnDoe è un utente fittizio nel nostro dominio, johnsecret è la password fittizia, "/ Mio / uri" è l'URI da controllare e "DOCTYPE html" è la stringa da trovare nei dati di risposta quando la richiesta ha esito positivo.

Consigliamo di creare un utente fittizio che sia in grado di accedere al dominio ma senza permessi, in modo da includerlo nel controllo dello stato dei nostri servizi. Questo è il motivo per cui si utilizza JohnDoe utente fittizio nel nostro controllo sanitario personalizzato.

Quando il nostro controllo dello stato è testato dalla riga di comando e pronto, possiamo assegnarlo alle farm configurate con il supporto NTLM.

Goditi le tue applicazioni web NTLM con carico bilanciato!