Din applikation ansluter till en proxy på sin egen dator. Den hjälparen autentiserar sig sedan mot företagets proxy. Applikationen utför inte nödvändigtvis företagets autentiseringsutbyte själv.

application → local helper → company proxy → destination

En hjälpare som CNTLM har konfiguration för uppströmskonto och proxy. Dess lokala lyssnare har en egen gräns för nåbarhet och åtkomst. Ett webbläsarlösenord som anges mot en annan slutpunkt konfigurerar inte någon av dem automatiskt.

Avgör vilket steg som misslyckades

Bekräfta först att applikationen valde hjälparens faktiska lyssnare och protokoll. Ett fel innan den lyssnaren nås är inte ett NTLM-fel. Undersök sedan om hjälparen nådde sin konfigurerade förälder och om föräldern accepterade dess identitet.

En 407 som returneras på denna väg behöver tillskrivas. Korrelera den lokala transaktionen med hjälparens redigerade diagnostik i stället för att anta att den synliga statusen identifierar det konto som din applikation ska skicka.

Gamla exempel lägger ibland till en keep-alive-rubrik och rapporterar framgång. Ihållande anslutning kan spela roll vid anslutningsorienterad autentisering, men den observationen bevisar inte att varje misslyckad hjälparinställning behöver samma rubrik. Val av slutpunkt, stödd metod, konto och anslutningens livslängd är fortfarande separata indata.

Lyssnaren är en riktig tjänst

Loopback håller en lyssnare utanför det omgivande nätverket; det skiljer inte alla processer eller användare på den datorn. En gateway eller bredare bindning ändrar uppsättningen anropare som potentiellt kan använda hjälparens uppströmsidentitet. Gör den ändringen medvetet.

Använd en godkänd hjälparinställning när applikationen inte kan utföra det schema som krävs. Det användbara resultatet är en känd väg med känt kontoinnehav, inte en oförklarad extra tjänst som av en slump får en nedladdning att fungera.

Relaterade artiklar