Lokale NTLM-proxyhjelparar: klienttilgang kontra pålogging oppstraums

Applikasjonen din koplar til ein proxy på sin eigen datamaskin. Den hjelparen autentiserer seg deretter mot bedriftsproxien. Applikasjonen utfører ikkje nødvendigvis bedrifta si autentiseringsutveksling sjølv.

application → local helper → company proxy → destination

Ein hjelpar som CNTLM har konfigurasjon for oppstraumskonto og proxy. Den lokale lyttaren har ei eiga grense for tilgjenge og tilgang. Eit nettlesarpassord som blir skrive inn mot eit anna endepunkt, konfigurerer ikkje nokon av dei automatisk.

Finn ut kva steg som feila

Stadfest først at applikasjonen valde den faktiske lyttaren og protokollen til hjelparen. Ein feil før denne lyttaren blir nådd er ikkje ein NTLM-feil. Undersøk deretter om hjelparen nådde den konfigurerte forelderen, og om forelderen godtok identiteten hans.

Ein 407 som blir returnert på denne ruta må tilskrivast. Korrelér den lokale transaksjonen med den redigerte diagnostikken til hjelparen i staden for å anta at den synlege statusen identifiserer kontoen applikasjonen din skal senda.

Gamle døme legg nokre gonger til ein keep-alive-header og rapporterer suksess. Vedvarande samband kan ha noko å seia for sambandsorientert autentisering, men den observasjonen beviser ikkje at kvar mislukka hjelparoppsett treng same header. Val av endepunkt, støtta metode, konto og levetida til sambandet er framleis separate inngangar.

Lyttaren er ein ekte teneste

Loopback held ein lyttar utanfor det omkringliggjande nettverket; det skil ikkje alle prosessar eller brukarar på den datamaskinen. Ein gateway eller breiare binding endrar settet med kallarar som potensielt kan bruka oppstraumsidentiteten til hjelparen. Gjer den endringa medvite.

Bruk eit godkjent hjelparoppsett når applikasjonen ikkje kan utføra den påkravde ordninga. Det nyttige resultatet er ein kjend veg med kjent kontoeige, ikkje ei uforklart ekstra teneste som tilfeldigvis får éi nedlasting til å virka.