wandelt doch den string, in einen unicode string um, oder?
und genau das, ist eben bei NTLM erforderlich...
In der windows-api z.B. gibt es ebenfalls NTLM Funktion; welche für unicode und äquivalent dazu auch für ascii strings. Wenn man sich dann aber mal die sache richtig anschaut, rufen die ascii funktionen einfach die unicode-funktionen auf!

Hallo,

die letzten Tage habe ich mit einem LWP-Skript gekämpft, dass per NTLM Authentifizierung Web-Seiten von einem Intranet-Server (IIS 5.0) laden sollte. Das Skript hatte ich mal vor 3 Jahren zum Testen geschrieben und wieder reaktiviert. Allerdings ging jetzt die Authentifizierung schief. Googeln nach "Authen::NTLM and MS04-011" brachte mich dann auf die richtigen Ideen.

Ich verwende Authen::NTLM 1.02. Der in den Newsgroups empfohlene Patch für MS04-011 brachte bei mir nur einen Teilerfolg, da der Intranet-Server in einer Root-Domäne registriert ist und mein User Account in einer Sub-Domäne. Im Authen::NTLM wird in

die Response vom Server ausgelesen und für die Authentifizierung wieder verwendet. Der Server liefert aber die Root-Domain zurück, in der ich keinen Account habe. Deshalb geht die Anmeldung also schief. Ich habe den Code jetzt in

geändert, so dass meine ursprüngliche Sub-Domain für die Anmeldung verwendet wird. Seitdem läuft mein Skript wieder.

Da ich mich mit NTLM und den entsprechenden Challenge/Response Verfahren kaum auskenne, wollte ich Euch mal bitten, diese Änderung zu bewerten. Ist die allgemeingültig oder hab ich nur Glück, dass es jetzt bei mir wieder läuft?

Genau. Aber die alte Version hat den Unicode-String nicht selbst erzeugt, sondern aus der Response (Typ 2) vom Server bezogen. Der liefert die Domäne auch in Unicode an. Das geht aber in genau dem Fall schief, wo User und Server in verschiedenen Domänen hängen und die Authentifizierung sich aus der Hierarchie oder einem Trust ergibt. Daher habe ich den Code modifiziert. Ob es so aber korrekt ist, kann ich nicht beurteilen. Für meinen Anwendungsfall läuft es jetzt jedenfalls.