Hallo, wenn ich versuch mit Konqueror (KDE 3.4.1) auf die Weboberfläche unseres MS Exchange 2003 Servers zuzugreifen scheint es Probleme mit der Authentifizierung zu geben. Mit Firefox funktioniert alles ohne Probleme. Kann ich Konqueror dazu bewegen kein NTLM zu verwenden bzw. woran kann es liegen, dass der Zugriff mit Firefox funktioniert nicht aber mit Konqueror. Dominik
Am Dienstag, 7. Juni 2005 17:25 schrieb Dominik Fritz:
wenn ich versuch mit Konqueror (KDE 3.4.1) auf die Weboberfläche unseres MS Exchange 2003 Servers zuzugreifen scheint es Probleme mit der Authentifizierung zu geben. Mit Firefox funktioniert alles ohne Probleme. Kann ich Konqueror dazu bewegen kein NTLM zu verwenden bzw. woran kann es liegen, dass der Zugriff mit Firefox funktioniert nicht aber mit Konqueror.
Die NTLM-Authentifizierung ist eine Funktion des Exchange 2003 oder ISA-Servers und muss deshalb dort ausgeschaltet werden, wenn Konqueror damit nicht umgehen kann. Wahlweise kann man auch einen NTLM-Proxy einsetzen, ich weiss aber nicht mehr, woher man den bekommt. wolfgang
Am Dienstag, 7. Juni 2005 17:50 schrieb Wolfgang Denda:
Am Dienstag, 7. Juni 2005 17:25 schrieb Dominik Fritz:
wenn ich versuch mit Konqueror (KDE 3.4.1) auf die Weboberfläche unseres MS Exchange 2003 Servers zuzugreifen scheint es Probleme mit der Authentifizierung zu geben. Mit Firefox funktioniert alles ohne Probleme. Kann ich Konqueror dazu bewegen kein NTLM zu verwenden bzw. woran kann es liegen, dass der Zugriff mit Firefox funktioniert nicht aber mit Konqueror.
Die NTLM-Authentifizierung ist eine Funktion des Exchange 2003 oder ISA-Servers und muss deshalb dort ausgeschaltet werden, wenn Konqueror damit nicht umgehen kann. Wahlweise kann man auch einen NTLM-Proxy einsetzen, ich weiss aber nicht mehr, woher man den bekommt.
Das interesante ist ja, dass Firefox problemlos authentifizieren kann und ich glaube nicht, dass Firefox NTLM kann. Ich hatte vermutet, dass NTLM optional ist und Konqueror versucht dies zu verwenden. Ich glaube auch, dass es früher, dass heißt in einer Version ohne NTLM unterstützung, ging. Dominik
Dominik Fritz schrieb: Hallo Dominik,
Das interesante ist ja, dass Firefox problemlos authentifizieren kann und ich glaube nicht, dass Firefox NTLM kann. Ich hatte vermutet, dass NTLM optional ist und Konqueror versucht dies zu verwenden. Ich glaube auch, dass es früher, dass heißt in einer Version ohne NTLM unterstützung, ging.
Mozilla konnte/kann NTML es schon seit längeren. Meine seid ca. vor einem guten Jahr wurde das Feature eingebaut. Denke das Firefox dies geerbt hat von Mozilla. Gruss Patrick
Am Dienstag, 7. Juni 2005 18:22 schrieb Dominik Fritz:
Am Dienstag, 7. Juni 2005 17:50 schrieb Wolfgang Denda:
Die NTLM-Authentifizierung ist eine Funktion des Exchange 2003 oder ISA-Servers und muss deshalb dort ausgeschaltet werden, wenn Konqueror damit nicht umgehen kann.
Das interesante ist ja, dass Firefox problemlos authentifizieren kann und ich glaube nicht, dass Firefox NTLM kann.
Den Glauben will ich mit langweiligen Tatsachen keinesfalls widerlegen. Grüße, wolfgang der eben die Releasenotes zu Firefox 0.8 gelesen hat. http://weblogs.mozillazine.org/asa/archives/004853.html http://nixdoc.net/files/forum/about35886.html KDE 3.4 and Konqueror now support NTLM (transparent) authentication if you configure the default user name and password in KDE's "Control Center" under "Internet & Network -> Local Network Browsing". Once again, you'll need to use the "domain\userid" notation here too. If you don't set up these defaults with a valid account, it will "fall-back" to basic-auth.
Am Dienstag, 7. Juni 2005 21:28 schrieb Wolfgang Denda:
Am Dienstag, 7. Juni 2005 18:22 schrieb Dominik Fritz:
Am Dienstag, 7. Juni 2005 17:50 schrieb Wolfgang Denda:
Den Glauben will ich mit langweiligen Tatsachen keinesfalls widerlegen.
Grüße,
wolfgang der eben die Releasenotes zu Firefox 0.8 gelesen hat.
ok, das hat mich überzeugt...
http://nixdoc.net/files/forum/about35886.html KDE 3.4 and Konqueror now support NTLM (transparent) authentication if you configure the default user name and password in KDE's "Control Center" under "Internet & Network -> Local Network Browsing". Once again, you'll need to use the "domain\userid" notation here too. If you don't set up these defaults with a valid account, it will "fall-back" to basic-auth.
leider verhält sich mein Konqueror eben nicht so. Ich wäre ja schon zufrieden wenn er auf basic zurückfallen würde. Aber obwohl dort nichts eingetragen ist versucht er es mit NTLM. Wenn ich testweise den richtigigen Account als Default User eintrage wird es jedoch auch nicht besser. Dominik
On Tuesday 07 June 2005 11:25, Dominik Fritz wrote:
Hallo,
wenn ich versuch mit Konqueror (KDE 3.4.1) auf die Weboberfläche unseres MS Exchange 2003 Servers zuzugreifen scheint es Probleme mit der Authentifizierung zu geben. Mit Firefox funktioniert alles ohne Probleme. Kann ich Konqueror dazu bewegen kein NTLM zu verwenden bzw. woran kann es liegen, dass der Zugriff mit Firefox funktioniert nicht aber mit Konqueror.
Dominik
Sollte eigentlich gehen. Jedenfalls als ich den Patch gemacht hatte, ging's. Das war allerdings noch für KDE 3.2 oder so und in der Zwischenzeit haben etliche Leute da auch noch ihre Finger mit drin gehabt. Du kannst mal das Folgende in ~/.kde/share/config/kdebugrc tun: [7103] AbortFatal=true ErrorFilename=/tmp/kdebug.dbg ErrorOutput=0 FatalFilename=/tmp/kdebug.dbg FatalOutput=0 InfoFilename=/tmp/kdebug.dbg InfoOutput=0 WarnFilename=/tmp/kdebug.dbg WarnOutput=0 [7113] AbortFatal=true ErrorFilename=/tmp/kdebug.dbg ErrorOutput=0 FatalFilename=/tmp/kdebug.dbg FatalOutput=0 InfoFilename=/tmp/kdebug.dbg InfoOutput=0 WarnFilename=/tmp/kdebug.dbg WarnOutput=0 Dann Konqueror starten, versuchen zu dem Server zu verbinden, Error abwarten (oder was immer da passiert) und beenden. Danach kannst Du mir das File /tmp/kdebug.dbg zuschicken (wenn's nicht übermässig gross ist, bitte keine zig-MB Mailbombe). Dann kann ich mal schauen, was da eigentlich passiert. Karsten. -- One monk said to the other, "The fish has flopped out of the net! How will it live?" The other said, "When you have gotten out of the net, I'll tell you."
Am Dienstag, 7. Juni 2005 20:47 schrieb Karsten Künne:
On Tuesday 07 June 2005 11:25, Dominik Fritz wrote:
Hallo,
wenn ich versuch mit Konqueror (KDE 3.4.1) auf die Weboberfläche unseres MS Exchange 2003 Servers zuzugreifen scheint es Probleme mit der Authentifizierung zu geben. Mit Firefox funktioniert alles ohne Probleme. Kann ich Konqueror dazu bewegen kein NTLM zu verwenden bzw. woran kann es liegen, dass der Zugriff mit Firefox funktioniert nicht aber mit Konqueror.
Dominik
Sollte eigentlich gehen. Jedenfalls als ich den Patch gemacht hatte, ging's. Das war allerdings noch für KDE 3.2 oder so und in der Zwischenzeit haben etliche Leute da auch noch ihre Finger mit drin gehabt. Du kannst mal das Folgende in ~/.kde/share/config/kdebugrc tun:
habe ich versucht, aber die Datei /tmp/kdebug.dbg wird nicht angelegt und es passiert auch sonst nicht ungewöhnliches. Wenn ich versuche auf den Server zuzugreifen geht der Passwort Dialog auf und anschließend bekomme ich die Meldung: "Authentifizierung fehlgeschlagen Möchten Sie es nochmals versuchen?" Dominik
On Tuesday 07 June 2005 15:41, Dominik Fritz wrote:
Am Dienstag, 7. Juni 2005 20:47 schrieb Karsten Künne:
On Tuesday 07 June 2005 11:25, Dominik Fritz wrote:
Hallo,
wenn ich versuch mit Konqueror (KDE 3.4.1) auf die Weboberfläche unseres MS Exchange 2003 Servers zuzugreifen scheint es Probleme mit der Authentifizierung zu geben. Mit Firefox funktioniert alles ohne Probleme. Kann ich Konqueror dazu bewegen kein NTLM zu verwenden bzw. woran kann es liegen, dass der Zugriff mit Firefox funktioniert nicht aber mit Konqueror.
Dominik
Sollte eigentlich gehen. Jedenfalls als ich den Patch gemacht hatte, ging's. Das war allerdings noch für KDE 3.2 oder so und in der Zwischenzeit haben etliche Leute da auch noch ihre Finger mit drin gehabt. Du kannst mal das Folgende in ~/.kde/share/config/kdebugrc tun:
habe ich versucht, aber die Datei /tmp/kdebug.dbg wird nicht angelegt und es passiert auch sonst nicht ungewöhnliches. Wenn ich versuche auf den Server zuzugreifen geht der Passwort Dialog auf und anschließend bekomme ich die Meldung: "Authentifizierung fehlgeschlagen Möchten Sie es nochmals versuchen?"
Merkwürdig, das Debuggen sollte eigentlich immer klappen. Vielleicht solltest Du mal die gesamte Session beenden und Dich neu anmelden. Evtl. schlummert ja da noch ein preloaded Konqueror irgendwo und deshalb werden die Debug-Settings nicht gelesen. Ansonsten kannst Du auch mit "kdebugdialog --fullmode" nochmal überprüfen, ob 7103 und 7113 wirklich auf Output to File und /tmp/kdebug.dbg gesetzt sind. Karsten. -- Fats Loves Madelyn
Am Dienstag, 7. Juni 2005 22:02 schrieb Karsten Künne:
On Tuesday 07 June 2005 15:41, Dominik Fritz wrote:
Am Dienstag, 7. Juni 2005 20:47 schrieb Karsten Künne:
On Tuesday 07 June 2005 11:25, Dominik Fritz wrote:
Merkwürdig, das Debuggen sollte eigentlich immer klappen. Vielleicht solltest Du mal die gesamte Session beenden und Dich neu anmelden. Evtl. schlummert ja da noch ein preloaded Konqueror irgendwo und deshalb werden die Debug-Settings nicht gelesen. Ansonsten kannst Du auch mit "kdebugdialog --fullmode" nochmal überprüfen, ob 7103 und 7113 wirklich auf Output to File und /tmp/kdebug.dbg gesetzt sind.
In der Tat sehr merkwürdig. Ich habe die Einstellungen mit kdebugdialog überprüft und den Rechner mal neu gestartet aber es tut sich immer noch nichts. Ich werde das ganze morgen mal noch auf einem anderen Rechner versuchen. Ansonsten schon mal vielen Dank für deine Tipps. Dominik
Karsten.
On Tuesday 07 June 2005 16:26, Dominik Fritz wrote:
Am Dienstag, 7. Juni 2005 22:02 schrieb Karsten Künne:
On Tuesday 07 June 2005 15:41, Dominik Fritz wrote:
Am Dienstag, 7. Juni 2005 20:47 schrieb Karsten Künne:
On Tuesday 07 June 2005 11:25, Dominik Fritz wrote:
Merkwürdig, das Debuggen sollte eigentlich immer klappen. Vielleicht solltest Du mal die gesamte Session beenden und Dich neu anmelden. Evtl. schlummert ja da noch ein preloaded Konqueror irgendwo und deshalb werden die Debug-Settings nicht gelesen. Ansonsten kannst Du auch mit "kdebugdialog --fullmode" nochmal überprüfen, ob 7103 und 7113 wirklich auf Output to File und /tmp/kdebug.dbg gesetzt sind.
In der Tat sehr merkwürdig. Ich habe die Einstellungen mit kdebugdialog überprüft und den Rechner mal neu gestartet aber es tut sich immer noch nichts. Ich werde das ganze morgen mal noch auf einem anderen Rechner versuchen. Ansonsten schon mal vielen Dank für deine Tipps.
Habe mir gerade SUSE's Source-RPM's angeschaut und die KDE-RPM's sind alle mit "--disable-debug" gebaut :-(. Da wird das dann leider nichts mit kdebugdialog. In dem Fall hilft dann wohl nur noch, auf dem Netz zu lauschen mit ethereal oder tcpdump oder ähnlichen Mitteln, oder die KDE-Pakete neu bauen mit "enable-debug", das ist aber wesentlich aufwändiger. Ohne zu wissen, was Konqueror und der IIS so miteinander reden, kann ich da leider auch nicht viel helfen. Ich habe auch noch mal in die Sourcen reingeguckt und das NTLM-Zeugs ist definitiv noch drin und es sieht auch meinem Patch von damals sehr ähnlich. Ein Unterschied ist, dass es jetzt eine Class KNTLM in den kdelibs gibt, während ich damals noch mit der libntlm rumhantiert habe. Ich gehe aber mal davon aus, dass KNTLM funktioniert. Karsten. -- We may not return the affection of those who like us, but we always respect their good judgement.
Hallo Karsten, hallo Leute, Am Mittwoch, 8. Juni 2005 01:14 schrieb Karsten Künne: [...]
Habe mir gerade SUSE's Source-RPM's angeschaut und die KDE-RPM's sind alle mit "--disable-debug" gebaut :-(.
Schuss ins Blaue: Helfen die debuginfo.rpm-Pakete vom SuSE FTP-Server? Gruß Christian Boltz PS @sig: Notfalls gibt es ja noch --rebuild-tree *SCNR* --
vorweg: Hier war gerade Stromausfall. Da hat der Sturm wohl irgendwo einen Baum auf die Leitung geworfen... ext3 hat mich zwar anscheinend vor größeren Schäden bewahrt. Mit reiserfs stände der Baum noch. :-) [> Christian Boltz und Ratti in fontlinge-devel]
On Wednesday 08 June 2005 18:08, Christian Boltz wrote:
Hallo Karsten, hallo Leute,
Am Mittwoch, 8. Juni 2005 01:14 schrieb Karsten Künne: [...]
Habe mir gerade SUSE's Source-RPM's angeschaut und die KDE-RPM's sind alle mit "--disable-debug" gebaut :-(.
Schuss ins Blaue: Helfen die debuginfo.rpm-Pakete vom SuSE FTP-Server?
Nein, das hilft nichts. Ich weiß nicht genau, was es mit diesen Paketen auf sich hat, aber soweit ich sehen kann, sind das nur die ungestrippten Binaries und die Sourcen. Man muß aber die kdelibs- und kdebase-Sourcen mit "--enable-debug" übersetzen, damit die kdDebug-Funktion vorhanden ist. Ansonsten ist kdDebug nur eine Dummy-Funktion, die gar nichts tut. Karsten. -- "I am returning this otherwise good typing paper to you because someone has printed gibberish all over it and put your name at the top." -- English Professor, Ohio University
On Tuesday 07 June 2005 16:26, Dominik Fritz wrote:
Am Dienstag, 7. Juni 2005 22:02 schrieb Karsten Künne:
On Tuesday 07 June 2005 15:41, Dominik Fritz wrote:
Am Dienstag, 7. Juni 2005 20:47 schrieb Karsten Künne:
On Tuesday 07 June 2005 11:25, Dominik Fritz wrote:
Merkwürdig, das Debuggen sollte eigentlich immer klappen. Vielleicht solltest Du mal die gesamte Session beenden und Dich neu anmelden. Evtl. schlummert ja da noch ein preloaded Konqueror irgendwo und deshalb werden die Debug-Settings nicht gelesen. Ansonsten kannst Du auch mit "kdebugdialog --fullmode" nochmal überprüfen, ob 7103 und 7113 wirklich auf Output to File und /tmp/kdebug.dbg gesetzt sind.
In der Tat sehr merkwürdig. Ich habe die Einstellungen mit kdebugdialog überprüft und den Rechner mal neu gestartet aber es tut sich immer noch nichts. Ich werde das ganze morgen mal noch auf einem anderen Rechner versuchen. Ansonsten schon mal vielen Dank für deine Tipps.
So, ich habe jetzt auch noch mal meinen IIS angeworfen und Konqueror mit NTLM getestet, also das funktioniert bei mir problemlos (habe allerdings inzwischen auf das inoffizielle KDE 3.4.1 für SUSE 9.3 upgegraded, aber das sollte eigentlich keinen Unterschied machen). Dabei habe ich auch gleich mal ethereal ausprobiert, also damit kann man sehr schön auch den Inhalt der NTLM-Pakete anschauen und sehen, was da passiert. Ich würde empfehlen, damit mal die Unterhaltung mitzuschneiden und zu schauen, was da schief läuft, evtl. auch mal mit dem Firefox-Verhalten vergleichen. Karsten. -- Finagle's Creed: Science is true. Don't be misled by facts.
Am Mittwoch, 8. Juni 2005 02:44 schrieb Karsten Künne: [konqueror und NTLM mit Exchange 2003 Server]
So, ich habe jetzt auch noch mal meinen IIS angeworfen und Konqueror mit NTLM getestet, also das funktioniert bei mir problemlos
Eventuell muss man die Browseridentifikation vom Konqueror auf die des IE oder Firefox stellen. Klingt verrückt, aber manchmal hilft sowas. wolfgang
Am Mittwoch, 8. Juni 2005 02:44 schrieb Karsten Künne:
On Tuesday 07 June 2005 16:26, Dominik Fritz wrote:
Am Dienstag, 7. Juni 2005 22:02 schrieb Karsten Künne:
On Tuesday 07 June 2005 15:41, Dominik Fritz wrote:
Am Dienstag, 7. Juni 2005 20:47 schrieb Karsten Künne:
On Tuesday 07 June 2005 11:25, Dominik Fritz wrote:
So, ich habe jetzt auch noch mal meinen IIS angeworfen und Konqueror mit NTLM getestet, also das funktioniert bei mir problemlos (habe allerdings inzwischen auf das inoffizielle KDE 3.4.1 für SUSE 9.3 upgegraded, aber das sollte eigentlich keinen Unterschied machen). Dabei habe ich auch gleich mal ethereal ausprobiert, also damit kann man sehr schön auch den Inhalt der NTLM-Pakete anschauen und sehen, was da passiert. Ich würde empfehlen, damit mal die Unterhaltung mitzuschneiden und zu schauen, was da schief läuft, evtl. auch mal mit dem Firefox-Verhalten vergleichen.
ich habe jetzt mal mit ethereal mitgehorcht was da an Kommunikation zwischen Konqueror und Exchange Server abläuft und das ganze auch mal mit Firefox verglichen. Firefox scheint in der Tat auch NTLM zu verwenden und da funktioniert es wunderbar. Was genau bei der Authentifizierung schief läuft kann ich noch nicht so genau sagen. Mir ist jedoch aufgefallen, dass Ethereal das Authentifizierungspacket des Konquerors nicht richtig dekodieren kann. Jedenfalls steht da bei Username nur ??? drinn. Wenn ich den Firefox verwende finde ich dort den von mir angegebenen Usernamen. Dominik
On Wednesday 08 June 2005 04:18, Dominik Fritz wrote:
Am Mittwoch, 8. Juni 2005 02:44 schrieb Karsten Künne:
On Tuesday 07 June 2005 16:26, Dominik Fritz wrote:
Am Dienstag, 7. Juni 2005 22:02 schrieb Karsten Künne:
On Tuesday 07 June 2005 15:41, Dominik Fritz wrote:
Am Dienstag, 7. Juni 2005 20:47 schrieb Karsten Künne:
On Tuesday 07 June 2005 11:25, Dominik Fritz wrote:
So, ich habe jetzt auch noch mal meinen IIS angeworfen und Konqueror mit NTLM getestet, also das funktioniert bei mir problemlos (habe allerdings inzwischen auf das inoffizielle KDE 3.4.1 für SUSE 9.3 upgegraded, aber das sollte eigentlich keinen Unterschied machen). Dabei habe ich auch gleich mal ethereal ausprobiert, also damit kann man sehr schön auch den Inhalt der NTLM-Pakete anschauen und sehen, was da passiert. Ich würde empfehlen, damit mal die Unterhaltung mitzuschneiden und zu schauen, was da schief läuft, evtl. auch mal mit dem Firefox-Verhalten vergleichen.
ich habe jetzt mal mit ethereal mitgehorcht was da an Kommunikation zwischen Konqueror und Exchange Server abläuft und das ganze auch mal mit Firefox verglichen. Firefox scheint in der Tat auch NTLM zu verwenden und da funktioniert es wunderbar. Was genau bei der Authentifizierung schief läuft kann ich noch nicht so genau sagen. Mir ist jedoch aufgefallen, dass Ethereal das Authentifizierungspacket des Konquerors nicht richtig dekodieren kann. Jedenfalls steht da bei Username nur ??? drinn. Wenn ich den Firefox verwende finde ich dort den von mir angegebenen Usernamen.
Der Username sollte eigentlich drin stehen, bei mir ist er jedenfalls da. Konqueror sollte auch ein Fenster aufgemacht haben, wo er nach Username und Passwort fragt. Ohne Username kann das Ganze natürlich nicht richtig funktionieren. Ich habe die ganze NTLM-Geschichte hier auch nur gegen IIS getestet, wir haben leider (oder besser "Gott sei Dank" ;-)) keinen Exchange-Server. Bei mir sieht das letzte Paket (Typ: NTLMSSP_AUTH) ungefähr so aus (ein paar Details weggelassen): NTLMSSP NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_AUTH (0x00000003) Lan Manager Response: Empty NTLM Response: E28588B9CF49D93785B5D6444791A43C0101000000000000... ... Domain name: MYDOMAIN ... User name: kuenne ... Host name: NULL Bei Firefox sind "Lan Manager Response" und "Host name" nicht leer, aber das sollte eigentlich egal sein. Karsten. -- Quality Control, n.: The process of testing one out of every 1,000 units coming off a production line to make sure that at least one out of 100 works.
Am Mittwoch, 8. Juni 2005 18:35 schrieb Karsten Künne:
On Wednesday 08 June 2005 04:18, Dominik Fritz wrote:
Am Mittwoch, 8. Juni 2005 02:44 schrieb Karsten Künne:
On Tuesday 07 June 2005 16:26, Dominik Fritz wrote:
Am Dienstag, 7. Juni 2005 22:02 schrieb Karsten Künne:
On Tuesday 07 June 2005 15:41, Dominik Fritz wrote:
Am Dienstag, 7. Juni 2005 20:47 schrieb Karsten Künne: > On Tuesday 07 June 2005 11:25, Dominik Fritz wrote:
Der Username sollte eigentlich drin stehen, bei mir ist er jedenfalls da. Konqueror sollte auch ein Fenster aufgemacht haben, wo er nach Username und Passwort fragt. Ohne Username kann das Ganze natürlich nicht richtig funktionieren. Ich habe die ganze NTLM-Geschichte hier auch nur gegen IIS getestet, wir haben leider (oder besser "Gott sei Dank" ;-)) keinen Exchange-Server.
Bei mir sieht das letzte Paket (Typ: NTLMSSP_AUTH) ungefähr so aus (ein paar Details weggelassen):
NTLMSSP NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_AUTH (0x00000003) Lan Manager Response: Empty NTLM Response: E28588B9CF49D93785B5D6444791A43C0101000000000000... ... Domain name: MYDOMAIN ... User name: kuenne ... Host name: NULL
Bei mir sieht das ganze so aus: NTLMSSP NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_AUTH (0x00000003) Lan Manager Response: Empty NTLM Response: 444D9AD001E4FC52E869E737D4D978AE... Domain name: ?? User name: ????? Host name: NULL Domain name und Username hatte ich angegeben und ich finde sie auch im übermittelten Packet wieder wenn ich in Ethereal auf User bzw. Domainname klicke. Allerdings scheinen sie irgendwie an der falschen Stelle zu stehen. Wenn ich auf Username klicke markiert Ethereal im Packet den Username um 1 Byte versetzt. Da scheint wohl irgendein Offset nicht zu stimmen. Dominik
On Thursday 09 June 2005 02:13, Dominik Fritz wrote:
Am Mittwoch, 8. Juni 2005 18:35 schrieb Karsten Künne:
On Wednesday 08 June 2005 04:18, Dominik Fritz wrote: ...
Der Username sollte eigentlich drin stehen, bei mir ist er jedenfalls da. Konqueror sollte auch ein Fenster aufgemacht haben, wo er nach Username und Passwort fragt. Ohne Username kann das Ganze natürlich nicht richtig funktionieren. Ich habe die ganze NTLM-Geschichte hier auch nur gegen IIS getestet, wir haben leider (oder besser "Gott sei Dank" ;-)) keinen Exchange-Server.
Bei mir sieht das letzte Paket (Typ: NTLMSSP_AUTH) ungefähr so aus (ein paar Details weggelassen):
NTLMSSP NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_AUTH (0x00000003) Lan Manager Response: Empty NTLM Response: E28588B9CF49D93785B5D6444791A43C0101000000000000... ... Domain name: MYDOMAIN ... User name: kuenne ... Host name: NULL
Bei mir sieht das ganze so aus:
NTLMSSP NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_AUTH (0x00000003) Lan Manager Response: Empty NTLM Response: 444D9AD001E4FC52E869E737D4D978AE... Domain name: ?? User name: ????? Host name: NULL
Domain name und Username hatte ich angegeben und ich finde sie auch im übermittelten Packet wieder wenn ich in Ethereal auf User bzw. Domainname klicke. Allerdings scheinen sie irgendwie an der falschen Stelle zu stehen. Wenn ich auf Username klicke markiert Ethereal im Packet den Username um 1 Byte versetzt. Da scheint wohl irgendein Offset nicht zu stimmen.
Den Domain Name gebe ich eigentlich nie an, da der ja sowieso in der Challenge steht und der Server automatisch das Richtige macht. Die Challenge vom Server sieht bei mir in etwa so aus: NTLMSSP NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_CHALLENGE (0x00000002) Domain: MYDOMAIN .... Flags: 0x02810205 .... NTLM Challenge: 161774B005F729FD Reserved: 0000000000000000 Address List .... Konqueror fragt daraufhin nach Username und Passwort und ich tippe da nur den Usernamen (ohne Domain) und das Passwort rein. Vielleich läuft ja bei der Challenge schon was schief? Oder Konqueror mag das mit dem Domainnamen nicht. Wie gesagt, bei meinen Tests habe ich den Domainnamen immer weggelassen. Karsten. -- Bugs, pl. n.: Small living things that small living boys throw on small living girls.
Am Thursday 09 June 2005 19:18 schrieb Karsten Künne:
On Thursday 09 June 2005 02:13, Dominik Fritz wrote:
Am Mittwoch, 8. Juni 2005 18:35 schrieb Karsten Künne:
On Wednesday 08 June 2005 04:18, Dominik Fritz wrote: [...]
Den Domain Name gebe ich eigentlich nie an, da der ja sowieso in der Challenge steht und der Server automatisch das Richtige macht. Die Challenge vom Server sieht bei mir in etwa so aus:
NTLMSSP NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_CHALLENGE (0x00000002) Domain: MYDOMAIN .... Flags: 0x02810205 .... NTLM Challenge: 161774B005F729FD Reserved: 0000000000000000 Address List ....
Konqueror fragt daraufhin nach Username und Passwort und ich tippe da nur den Usernamen (ohne Domain) und das Passwort rein. Vielleich läuft ja bei der Challenge schon was schief? Oder Konqueror mag das mit dem Domainnamen nicht. Wie gesagt, bei meinen Tests habe ich den Domainnamen immer weggelassen.
Den Domainnamen habe ich sowohl schon angegeben als auch weggelassen ohne einen Unterschied zu bemerken. Ich habe mir jetzt auch die Challenge noch mal angeschaut und ich kann da eigentlich nichts ungewöhnliches entdecken. Anscheinend läuft es erst beim NTLMSSP_AUTH schief. NTLMSSP NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_CHALLENGE (0x00000002) Domain: IRF Flags: 0x02810205 NTLM Challenge: D1D8875EBD13AE96 Reserved: 0000000000000000 Address List Length: 132 Maxlen: 132 Offset: 62 Domain NetBIOS Name: IRF Server NetBIOS Name: I61MS1 Domain DNS Name: [...] Server DNS Name: [...] List Terminator Content-Length: 27\r\n Content-Type: text/html\r\n \r\n Line-based text data: text/html Dominik
On Monday 13 June 2005 03:29, Dominik Fritz wrote: [....]
Den Domainnamen habe ich sowohl schon angegeben als auch weggelassen ohne einen Unterschied zu bemerken. Ich habe mir jetzt auch die Challenge noch mal angeschaut und ich kann da eigentlich nichts ungewöhnliches entdecken. Anscheinend läuft es erst beim NTLMSSP_AUTH schief.
NTLMSSP NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_CHALLENGE (0x00000002) Domain: IRF Flags: 0x02810205 NTLM Challenge: D1D8875EBD13AE96 Reserved: 0000000000000000 Address List Length: 132 Maxlen: 132 Offset: 62 Domain NetBIOS Name: IRF Server NetBIOS Name: I61MS1 Domain DNS Name: [...] Server DNS Name: [...] List Terminator Content-Length: 27\r\n Content-Type: text/html\r\n \r\n Line-based text data: text/html
Das sieht eigentlich gut aus. Dann kann ich nur noch raten. Es sieht danach aus, als ob die KNTLM-Klasse das letzte Paket falsch generiert. Leider bin ich kein Experte in NTLM-Authentifizierung, ich habe das nur so mit drangebacken als ich Negotiate-Authentifizierung implementiert habe. Merkwürdig ist, dass der Username um 1 Byte verschoben ist, als ob irgendein Offset nicht stimmt. Wie gesagt, ich kann da leider nicht gross weiterhelfen. Der Autor von KNTLM ist gyurco@freemail.hu, vielleicht hat der noch eine Idee. Ansonsten gibt's in der Distribution von libntlm (von der KNTLM glaube ich abstammt) ein kleines Test-Programm, dass ein AUTH-Paket aus einer Challenge berechnen kann. Und auf der libntlm-Webseite (http://josefsson.org/libntlm) gibt's auch jede Menge weiterführende Literatur zu dem Thema. Ich kann hier als Referenz und zum Vergleich auch noch mal die auseinandergepflückte NTLM-Response aus meinem AUTH-Paket einfügen (interne Namen ersetzt): NTLM Response: E28588B9CF49D93785B5D6444791A43C0101000000000000... Length: 288 Maxlen: 288 Offset: 64 NTLMv2 Response: E28588B9CF49D93785B5D6444791A43C010100000000000 0... HMAC: E28588B9CF49D93785B5D6444791A43C Header: 0x00000101 Reserved: 0x00000000 Time: Jun 7, 2005 20:50:57.000000000 Client challenge: 0BEED186F0CAB2AA Unknown: 0x00000000 Name: NetBIOS domain name, MYDOMAIN Name type: NetBIOS domain name (2) Name len: 14 Name: MYDOMAIN Name: NetBIOS host name, SOMETH-74BF20F1 Name type: NetBIOS host name (1) Name len: 30 Name: SOMETH-74BF20F1 Name: DNS domain name, mydomain.rentec.com Name type: DNS domain name (4) Name len: 36 Name: mydomain.rentec.com Name: DNS host name, someth-74bf20f1.mydomain.rentec.com Name type: DNS host name (3) Name len: 68 Name: someth-74bf20f1.mydomain.rentec.com Name: End of list Name type: End of list (0) Name len: 0 Domain name: MYDOMAIN Length: 14 Maxlen: 14 Offset: 352 User name: kuenne Length: 12 Maxlen: 12 Offset: 366 Host name: NULL Eigentlich sollte das "End-of-List" ja das Ende der Response kennzeichnen, so dass ich mir gar nicht erklären kann, wieso Domainname und Username verschoben sind. Ich hoffe, Du findest noch eine Lösung des Rätsels, würde mich ja auch interessieren. Gruss, Karsten. -- The human animal differs from the lesser primates in his passion for lists of "Ten Best". -- H. Allen Smith
On Monday 13 June 2005 23:50, Karsten Künne wrote: [....]
Ich kann hier als Referenz und zum Vergleich auch noch mal die auseinandergepflückte NTLM-Response aus meinem AUTH-Paket einfügen (interne Namen ersetzt):
NTLM Response: E28588B9CF49D93785B5D6444791A43C0101000000000000... Length: 288 Maxlen: 288 Offset: 64 NTLMv2 Response: E28588B9CF49D93785B5D6444791A43C010100000000000 0... HMAC: E28588B9CF49D93785B5D6444791A43C Header: 0x00000101 Reserved: 0x00000000 Time: Jun 7, 2005 20:50:57.000000000 Client challenge: 0BEED186F0CAB2AA Unknown: 0x00000000 Name: NetBIOS domain name, MYDOMAIN Name type: NetBIOS domain name (2) Name len: 14 Name: MYDOMAIN Name: NetBIOS host name, SOMETH-74BF20F1 Name type: NetBIOS host name (1) Name len: 30 Name: SOMETH-74BF20F1 Name: DNS domain name, mydomain.rentec.com Name type: DNS domain name (4) Name len: 36 Name: mydomain.rentec.com Name: DNS host name, someth-74bf20f1.mydomain.rentec.com Name type: DNS host name (3) Name len: 68 Name: someth-74bf20f1.mydomain.rentec.com Name: End of list Name type: End of list (0) Name len: 0 Domain name: MYDOMAIN Length: 14 Maxlen: 14 Offset: 352 User name: kuenne Length: 12 Maxlen: 12 Offset: 366 Host name: NULL
Eigentlich sollte das "End-of-List" ja das Ende der Response kennzeichnen, so dass ich mir gar nicht erklären kann, wieso Domainname und Username verschoben sind. Ich hoffe, Du findest noch eine Lösung des Rätsels, würde mich ja auch interessieren.
Vielleicht noch als kleine Ergänzung, Offset+Länge der NTLM-Response sollte gleich dem Offset für den Domainnamen sein und Offset+Länge des Domainnamen muss den Offset des Usernamen ergeben. Wenn diese Gleichungen nicht erfüllt sind, dann ist irgendwo bei der Berechnung des AUTH-Paketes in KNTLM was schiefgelaufen. Dann am Besten einen Bugreport bei KDE aufmachen (das Paket ist kdelibs) und/oder den Maintainer anmailen. Gruss, Karsten. -- "I used to get high on life but lately I've built up a resistance."
participants (5)
-
Christian Boltz -
Dominik Fritz -
Karsten Künne -
Patrick Klaus -
Wolfgang Denda