Plaaslike NTLM-proxyhelpers: kliënttoegang teenoor opstroomaanmelding

Jou toepassing konnekteer aan 'n proxy op sy eie rekenaar. Daardie helper verifieer dan by die maatskappyproxy. Die toepassing voer nie noodwendig self die maatskappy se verifikasié-uitruiling uit nie.

application → local helper → company proxy → destination

'n Helper soos CNTLM het opstroomrekening- en proxykonfigurasie. Sy plaaslike luisteraar het 'n aparte bereikbaarheids- en toegangsgrens. 'n Blaaierwagwoord wat teen 'n ander eindpunt ingevoer word, konfigureer nie outomaties een van die twee nie.

Identifiseer die hop wat gefaal het

Bevestig eers dat die toepassing die helper se werklike luisteraar en protokol gekies het. 'n Fout voordat daardie luisteraar bereik word, is nie 'n NTLM-fout nie. Ondersoek dan of die helper sy gekonfigureerde ouer bereik het en of die ouer sy identiteit aanvaar het.

'n 407 wat langs hierdie roete terugkom, moet toegeskryf word. Korreleer die plaaslike transaksie met die helper se geredigeerde diagnostiek eerder as om te aanvaar dat die sigbare status die rekening identifiseer wat jou toepassing moet stuur.

Ou voorbeelde voeg soms 'n keep-alive-opskrif by en rapporteer sukses. Volharding kan saak maak vir verbindinggerigte verifikasie, maar daardie waarneming bewys nie dat elke mislukte helper-opstelling dieselfde opskrif nodig het nie. Eindpuntkeuse, ondersteunde metode, rekening en verbindingleeftyd bly aparte insette.

Die luisteraar is 'n werklike diens

Loopback hou 'n luisteraar van die omliggende netwerk af; dit onderskei nie alle prosesse of gebruikers op daardie rekenaar nie. 'n Gateway of wyer binding verander die stel oproepers wat moontlik die helper se opstroomidentiteit kan gebruik. Hou daardie verandering doelbewus.

Gebruik 'n goedgekeurde helper-reëling wanneer die toepassing nie die vereiste skema kan uitvoer nie. Die nuttige resultaat is 'n bekende pad met bekende rekeningeienaarskap, nie 'n onverklaarde ekstra diens wat toevallig een aflaai laat werk nie.