windows - Java HTTP NTLM Implementeringsforskelle

Indlæg af Hanne Mølgaard Plasc

Problem



Dette link beskriver de forskellige http-klient-java-implementeringer. Jeg leder efter nogen links, der kunne give oplysninger om deres NTLM protokol implementationsforskelle. [1]


På en af ​​Windows-maskine fandt jeg, at Commons-http-klient 3.1-implementeringen mislykkes med en autorisationsfejl (http-statuskode 401), men implementeringen af ​​Java 1.5 gennemføres. Da implementeringen af ​​java 1.5 til NTLM-godkendelsesprotokollen ikke er åben kilde, kan jeg ikke sammenligne de to implementeringer for at forstå, hvad der kunne gå galt.


Opdater 1


Jeg er klar over, at commons http-klienten ikke understøtter NTLM v2. Dette link giver en sammenligning mellem forskellige java http-klientimplementeringer og nævner, at apache http-klienten giver en delvis implementering af NTLM-protokollen. Det beskriver ikke mere om det. [2]


Ved fejlfinding af problemet yderligere fandt jeg også, at NTLM-implementeringen, der leveres af dette link i kombination med HTTPClient, fungerer på Windows-maskinen (Commons http-klientimplementeringen virker ikke som nævnt ovenfor). [3] [4]


Opdater 2


Ved at snuse pakker (ved hjælp af wireshack) indså jeg, at commons http klient 3.1 ntlm protokol implementering ikke genererer NTLM Response i Type 3 beskeden. Dette genereres af JDK implementeringen. Kender du til en hvilken som helst server/klientindstilling, der angiver, at godkendelsen vil mislykkes, hvis NTLM-responsdataene er tomme? (da den godkendelsesfejl, vi står overfor, kun kan reproduceres på en maskine. Autentificeringen lykkes ellers hvor.)

Bedste reference


Commons httpclient 3.1 implementerer ikke NTLMv2, det implementerer kun den ældre NTLM (aka NTLMv1) specifikation.

Andre referencer 1


Vi fandt årsagen til dette problem. Konfigurationsindstillingen, der førte til godkendelsesfejlen, blev styret af en sikkerhedspolitik kaldet NoLMHashPolicy. Aktivering af denne politik betyder, at Windows-serveren ikke længere vil lagre LM Hash-værdien for ethvert kodeord, og det ville bruge NT Response hash til at gøre godkendelsen. Da implementeringen af ​​NTLM-protokollen fra commons http-klient 3.1-bibliotek slet ikke beregner NT-svaret, kunne man stå over for denne fejl, når denne indstilling er aktiveret. Flere detaljer om denne indstilling findes her. [5]


Som en løsning kan man blot tilføje en implementering af AuthScheme-grænsefladen og udtrække koden fra højere versioner af Commons http-klientbiblioteket (for eksempel 4.1.2), som beregner NT-svaret i Type 3-meddelelsen. Glem ikke at opdatere længden og forskydningsværdierne for NT Response-felterne.
Når implementeringen af ​​AuthScheme-grænsefladen er klar, kan den injiceres ved hjælp af AuthPolicy.registeryScheme () -metoden.