Veebisaitide koormuse tasakaalustamine IIS autentimise NTLM ja ASP.NET impersonaliga

Vaata kategooriaid

Veebisaitide koormuse tasakaalustamine IIS autentimise NTLM ja ASP.NET impersonaliga

4 min lugeda

Ülevaade #

Microsofti veebiserver, Internet Information Services (IIS), integreerib mitmed autentimismehhanismid, et kinnitada kasutajaid Active Directory või iseseisva (LDAP-põhise autentimise) süsteemide vastu. NTLM- on Windowsi väljakutse / vastuse autentimise protokoll, mida saab kasutada võrkudes ja rakendustes, mida saab kasutada mõlemas keskkonnas.

Võiks arvesse võtta kahte erinevat stsenaariumi: Interaktiivne NTLM-autentimine on kahe süsteemi ühend, klient ja domeenikontroller, mida kasutatakse kasutajate autentimiseks autentimiseks vajalike andmete salvestamiseks; Mitte-interaktiivne NTLM-autentimine hõlmab kolme erinevat süsteemi, klienti, rakendusserverit ja domeeni, et võimaldada kasutajal juurdepääsu teatud ressursile rakenduses.

ASP.NETi äratamine lubab veebirakendustel autentida ja autoriseerida Microsoft IIS-i toetavaid kasutajaid.

Selles artiklis selgitame, kuidas laadida tasakaalu rakendusi, mis integreerivad NTLM-protokolli mitteinteraktiivsete kasutajate autentimise stsenaariumide jaoks.

Kuidas NTLM töötab? #

NTLM-i protokoll tugineb HTTP / S-protokollile, kus antud klient alustab autentse seansi loomiseks 6i sammude käepigistamist.

Autentitud seansi käepigistus nõuab järgmisi samme:

1. Klient algatab teatud ressursi anonüümse taotluse veebiserverile.

GET / HTTP

2. Server reageerib volitamata sõnumiga ja kliendi poolt kasutatava autentimismeetodiga.

401 Volitamata WWW-autentimine: NTLM

3. Klient saadab taotluse uuesti koos NTLM-vormingu autentimisprobleemiga.

GET / HTTP autoriseerimine: NTLM

4. Server reageerib volitamata sõnumiga ja nõuab kliendile rohkem teavet.

401 Volitamata WWW-autentimine: NTLM

5. Klient saadab päringu uuesti koos ülejäänud seansi informatsiooniga.

GET / HTTP autoriseerimine: NTLM

6. Server ühendab domeenikontrolleriga autentimistaotluse ja kinnitab seejärel kliendile autentimise.

HTTP 200 on korras

Pange tähele, et see käepigistus on vajalik igas uues ühenduses, mitte HTTP-päringutes, ja sammude 3–6 käigus tuleb ühendust hoida elus. Kui ühendus on suletud, tuleks seda käepigistuse osa korrata ja ei ole õige korrata alates punktist 5. Teisest küljest ei pea pärast ühenduse autentimist autoriseerimispäist uuesti saatma, kui ühendus pole suletud ressursist sõltumata.

Kuidas laadida tasakaalu veebirakendusi NTLM-i autentimist kasutades? #

koos RELIANOID, on 2 peamist viisi koormuse tasakaalu saavutamiseks ja NTLM-põhise veebirakenduse loomiseks kõrge kättesaadavusega, kasutades lihtsat 4. kihi TCP koormuse tasakaalustajat või 7. kihi puhverserverit täiustatud funktsioonide jaoks.

Lihtne NTLM koormuse tasakaalustamine kihis 4 #

Selleks, et laadida tasakaalu veebirakendusi lihtsa konfiguratsiooniga NTLM autentimistoega, saame LSLB-põhised talud luua L4xNAT-profiiliga. Saame kasutada kas HTTP- või HTTPS-protokolle.

Seejärel veenduge globaalses konfiguratsioonis, et kasutatud protokoll on TCP kuid me saame valida NAT or DNAT vastavalt vajalikule topoloogiale.

aasta Teenused jaotises on vaja määrata püsivus, et tagada, et teatud kliendi autentimine läheb alati samasse taustaprogrammi, vastasel juhul ei saa ühenduse autentimist teostada.

Lõpuks lisage oma taustaprogrammide loetelu ja konfigureerige tervisekontroll vastavalt allpool toodud punktidele.

NTLM koormuse tasakaalustamine kihil 7 #

See võimaldab HTTP / S-andmeid NTLM-toega käsitseda LSLB-mooduli ja HTTP-talu kaudu konfigureeritud kihi 7-puhverserveriga. Selleks peame virtuaalse teenuse SSL-i nõuete kohaselt looma HTTP- või HTTPS-talu. Ainus erinevus oleks Kuulaja konfigureeritud Global Settings loodud talu.

Sellel kihil, kuna rakendus ei suuda luua ühtegi seansiküpsist, et luua püsivus või ühenduse loomine, saame kasutada Prääniku sisestamine võimalus, mis võimaldab koormuse tasakaalustajal luua uue küpsise NTLM autentimise esialgse käepigistuse ajal.

Lõpuks lisage oma taustaprogrammide loetelu ja konfigureerige tervisekontroll vastavalt allpool toodud punktidele. Sellises talus olevate puhverserveri tasemel saate konfigureerida täiendavaid rakendusvõimalusi ja see ei mõjuta NTLM-i toetust.

NTLM-i autentimise veebisaitide täiustatud tervisekontrollid #

NTLM-i autentitud rakenduste kohandatud täpsema tervisekontrolli loomiseks peame looma tee alla /usr/local/relianoid/app/libexec skripti taustaprogrammi kontrollimiseks nagu allpool näidatud. Näiteks, check_ntlm.sh asjakohaste õigustega.

#!/bin/bash # hankige sisendparameetrid BACKEND=$1 PORT=$2 KASUTAJA=$3 PASS=$4 URI=$5 STRING=$6 /usr/bin/curl http://${BACKEND}:${PORT}${URI } --ntlm -negotiate -u ${USER}:${PASS} 2>/dev/null | grep "${STRING}" &>/dev/null, kui [ $? == 0 ] siis # kui curl käsk ei ebaõnnestu, siis teata, et taustaprogramm on üleval echo "Server ${BACKEND}:${PORT} OK" exit 0 fi # kui curl käsk nurjub, siis teatage, et taustaprogramm ei tööta echo "Server ${BACKEND}:${PORT} ei ole korras" exit 1

aasta Järelevalve >> Farmguardian kui see on olemas, või lisage see talumajapidamises kontrollimiseks käsklusele.

Me saame testida tervisekontrolli skripti:

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

Teades, et taustaprogramm on IP 192.168.0.99 sadam on 80 HTTP, johndoe on meie domeenis näiv kasutaja johnsecret on näiv parool, "/ Minu / uri" on kontrollitav ja URI „DOCTYPE html” on vastuste andmetes leiduv string, kui päring on edukas.

Selle kaasamiseks meie teenuste tervisekontrolli soovitame luua näiv kasutaja, kes saab domeenis sisse logida, kuid kellel pole õigusi. See on põhjus, miks kasutada johndoe näiv kasutaja meie tervisekontrollis.

Kui meie tervisekontroll on testitud käsurealt ja valmis, saame selle määrata NTLM-toega konfigureeritud taludele.

Nautige oma koormusega tasakaalustatud NTLM-i veebirakendusi!

📄 Laadige see dokument alla PDF-vormingus #

    EMAIL: *

    Linuxi poolt BetterDocs