Lokaj NTLM-proksi-helpiloj: klienta aliro kontraŭ supra ensaluto
Spuru aparte la konektojn aplikaĵo–helpilo kaj helpilo–firmaa proksio kiam NTLM-aŭtentikiga helpilo estas implikita.
Via aplikaĵo konektiĝas al proksio en sia propra komputilo. Tiu helpilo poste aŭtentikiĝas ĉe la firmaa proksio. Ne nepre la aplikaĵo mem faras la aŭtentikigan interŝanĝon de la firmao.
application → local helper → company proxy → destinationHelpilo kiel CNTLM havas agordojn pri supra konto kaj proksio. Ĝia loka aŭskultanto havas apartan atingeblan kaj aliran limon. Retumila pasvorto enigita ĉe alia finpunkto ne agordas aŭtomate nek unu nek la alian.
Identigu la malsukcesintan salteton
Unue konfirmu, ke la aplikaĵo elektis la veran aŭskultanton kaj protokolon de la helpilo. Eraro antaŭ ol atingi tiun aŭskultanton ne estas NTLM-malsukceso. Poste kontrolu, ĉu la helpilo atingis sian agorditan gepatron kaj ĉu la gepatro akceptis ĝian identecon.
407 redonita laŭ tiu vojo bezonas atribuon. Kunligu la lokan transakcion kun la redaktitaj diagnozoj de la helpilo anstataŭ supozi, ke la videbla stato identigas la konton, kiun via aplikaĵo devas sendi.
Malnovaj ekzemploj kelkfoje aldonas kaplinion keep-alive kaj raportas sukceson. Persisteco povas gravi ĉe konekt-orientita aŭtentikigo, sed tiu observo ne pruvas, ke ĉiu malsukcesa helpila agordo bezonas la saman kaplinion. Elekto de finpunkto, subtenata metodo, konto kaj vivo de la konekto restas apartaj enigoj.
La aŭskultanto estas reala servo
Loopback tenas aŭskultanton ekster la ĉirkaŭa reto; ĝi ne distingas ĉiujn procezojn aŭ uzantojn de tiu komputilo. Kluzo aŭ pli larĝa bindado ŝanĝas la aron de alvokantoj, kiuj potence povas uzi la supran identecon de la helpilo. Faru tiun ŝanĝon konscie.
Uzu aprobitan helpilan aranĝon kiam la aplikaĵo ne povas plenumi la postulatan skemon. La utila rezulto estas konata vojo kun konata kontoposedo, ne neklarigita kroma servo, kiu hazarde funkciigas unu elŝuton.