Lokale NTLM-proxyhjelpere: klienttilgang kontra pålogging oppstrøms

Applikasjonen din kobler til en proxy på sin egen datamaskin. Den hjelperen autentiserer seg deretter mot bedriftsproxien. Applikasjonen utfører ikke nødvendigvis bedriftens autentiseringsutveksling selv.

application → local helper → company proxy → destination

En hjelper som CNTLM har konfigurasjon for oppstrømskonto og proxy. Den lokale lytteren har en egen grense for tilgjengelighet og tilgang. Et nettleserpassord som skrives inn mot et annet endepunkt, konfigurerer ikke noen av dem automatisk.

Finn ut hvilket hopp som feilet

Bekreft først at applikasjonen valgte hjelperens faktiske lytter og protokoll. En feil før denne lytteren nås er ikke en NTLM-feil. Undersøk deretter om hjelperen nådde den konfigurerte forelderen, og om forelderen godtok identiteten dens.

En 407 som returneres på denne ruten må tilskrives. Korrelér den lokale transaksjonen med hjelperens redigerte diagnostikk i stedet for å anta at den synlige statusen identifiserer kontoen applikasjonen din skal sende.

Gamle eksempler legger noen ganger til en keep-alive-header og rapporterer suksess. Vedvarende forbindelse kan ha betydning for forbindelsesorientert autentisering, men den observasjonen beviser ikke at hver mislykket hjelperoppsett trenger samme header. Valg av endepunkt, støttet metode, konto og forbindelsens levetid er fortsatt separate innganger.

Lytteren er en ekte tjeneste

Loopback holder en lytter utenfor det omkringliggende nettverket; det skiller ikke alle prosesser eller brukere på den datamaskinen. En gateway eller bredere binding endrer settet med kallere som potensielt kan bruke hjelperens oppstrømsidentitet. Gjør den endringen bevisst.

Bruk et godkjent hjelperoppsett når applikasjonen ikke kan utføre den påkrevde ordningen. Det nyttige resultatet er en kjent vei med kjent kontoeierskap, ikke en uforklart ekstra tjeneste som tilfeldigvis får én nedlasting til å virke.