Lokální pomocníci NTLM proxy: přístup klienta versus přihlášení k nadřazenému proxy

Vaše aplikace se připojuje k proxy na svém vlastním počítači. Tento pomocník se pak ověřuje vůči firemnímu proxy. Aplikace nemusí nutně sama provádět výměnu ověřování firmy.

application → local helper → company proxy → destination

Pomocník jako CNTLM má konfiguraci nadřazeného účtu a proxy. Jeho místní posluchač má samostatnou hranici dostupnosti a přístupu. Heslo zadané v prohlížeči vůči jinému koncovému bodu automaticky nenastaví ani jedno z toho.

Zjistěte, který přeskok selhal

Nejprve ověřte, že aplikace zvolila skutečný posluchač a protokol pomocníka. Chyba před dosažením tohoto posluchače není selhání NTLM. Poté zkontrolujte, zda pomocník dosáhl nakonfigurovaného rodiče a zda rodič přijal jeho identitu.

Kód 407 vrácený po této trase vyžaduje určení původu. Propojte místní transakci s redigovanou diagnostikou pomocníka, místo abyste předpokládali, že viditelný stav určuje účet, který má vaše aplikace odeslat.

Staré příklady někdy přidávají hlavičku keep-alive a hlásí úspěch. Trvalé spojení může být pro ověřování orientované na spojení důležité, ale toto pozorování nedokazuje, že každé neúspěšné nastavení pomocníka potřebuje stejnou hlavičku. Volba koncového bodu, podporovaná metoda, účet a životnost spojení zůstávají samostatnými vstupy.

Posluchač je skutečná služba

Loopback drží posluchač mimo okolní síť; nerozlišuje všechny procesy ani uživatele na daném počítači. Brána nebo širší navázání mění množinu volajících, kteří mohou potenciálně použít nadřazenou identitu pomocníka. Tutu změnu dělejte vědomě.

Použijte schválené uspořádání s pomocníkem, když aplikace nedokáže provést požadované schéma. Užitečným výsledkem je známá cesta se známým vlastnictvím účtu, ne nevysvětlená služba navíc, která náhodou umožní jedno stažení.