Lokale NTLM-proxyhjælpere: klientadgang kontra logon på det overordnede proxy

Din applikation forbinder til et proxy på sin egen computer. Denne hjælper godkender derefter over for virksomhedens proxy. Applikationen udfører ikke nødvendigvis selv virksomhedens godkendelsesudveksling.

application → local helper → company proxy → destination

En hjælper som CNTLM har konfiguration for overordnet konto og proxy. Dens lokale lytter har en særskilt grænse for tilgængelighed og adgang. En browseradgangskode, der indtastes mod et andet endepunkt, konfigurerer ikke automatisk nogen af de to.

Fastslå, hvilket led der fejlede

Bekræft først, at applikationen valgte hjælperens faktiske lytter og protokol. En fejl før denne lytter nås er ikke en NTLM-fejl. Undersøg derefter, om hjælperen nåede sin konfigurerede forælder, og om forælderen accepterede dens identitet.

En 407 returneret ad denne rute kræver at blive henført. Korrelér den lokale transaktion med hjælperens redigerede diagnostik i stedet for at antage, at den synlige status identificerer den konto, din applikation skal sende.

Gamle eksempler tilføjer nogle gange et keep-alive-header og rapporterer succes. Vedvarende forbindelse kan have betydning for forbindelsesorienteret godkendelse, men den observation beviser ikke, at hver mislykket hjælperopsætning har brug for samme header. Valg af endepunkt, understøttet metode, konto og forbindelsens levetid er fortsat separate input.

Lytteren er en rigtig tjeneste

Loopback holder en lytter væk fra det omgivende netværk; det skelner ikke mellem alle processer eller brugere på den computer. En gateway eller bredere binding ændrer det sæt af kaldere, der potentielt kan bruge hjælperens overordnede identitet. Foretag den ændring bevidst.

Brug et godkendt hjælperarrangement, når applikationen ikke kan udføre det krævede skema. Det nyttige resultat er en kendt vej med kendt konto-ejerskab, ikke en uforklaret ekstra tjeneste, der tilfældigvis får én download til at virke.