folgendes Problem: Eine Webapplikation lässt
nur die Authentifizierungsmethoden Kerberos/Negotiate
zu, nicht aber NTLM.
Wenn ich diese Applikation mit dem Mozilla 1.1
aufrufe, erscheint ein Passwortfenster. Nach Eingabe
von Domäne+Username+Passwort komme ich dann auf
die Applikation => alles bestens.
Das gleiche Spiel mit Mozilla 1.4 und 1.5b
funktioniert nicht. Nach der Eingabe von
Domäne+Username+Passwort meldet mir die
Applikation das der request mit NTLM ankommt.
Woran liegt das? Ich habe weder beim 1.1 noch
beim 1.4/1.5b irgendwelche Plugins/patches
installiert. Die Browsereinstellungen sind
ebenfalls gleich.
Bin dankbar für jeden Tip!
Paul
Mozilla benutzt NTLM nur wenn der Server das bei den erlaubten Auth
mechanismen sendet. Mozilla 1.1 unterstützt NTLM nicht wohl aber alle
Versionen ab 1.4 (win32 only)
Du könntest mal ein Http Log erstellen :
http://www.mozilla.org/projects/netlib/http/http-debugging.html
Matthias
--
Please delete everything between "matti" and the "@" in my mail address.
* Matthias Versen wrote:
[...]
> Mozilla benutzt NTLM nur wenn der Server das bei den erlaubten Auth
> mechanismen sendet. Mozilla 1.1 unterstützt NTLM nicht wohl aber alle
> Versionen ab 1.4 (win32 only)
das ist ja genau das Problem. Wenn NTLM nicht unterstützt wird, dann
klappt die clear-text Authentifizierung mit Mozilla und der Kerberos
key
wird weitergereicht (geht mit Mozilla 1.1). Es darf eben nicht NTLM
verwendet werden! Für den Zugriff auf das ASDI (Active Directory
Service Interface) dürfen nur Authentifizierungen ungleich
NTLM verwendet werden. Ich frage das in meiner Webapplikation ab.
Der IE unterstützt drei Methoden: NTLM, NEGOTIATE und KERBEROS.
Wenn der Mozilla hier per default mit NTLM anrutscht und sonst
nichts kann/kennt, hat er schon verloren.
> Du könntest mal ein Http Log erstellen :
> http://www.mozilla.org/projects/netlib/http/http-debugging.html
Ist - denke ich - kein Bug als solcher, wenn als "feature"
ab Version 1.1 anscheinend NTLM als Standard angewandt wird.
Nur sollte man dann auch bitteschön NEGOTIATE und KERBEROS
unterstützen.
Paul
>> Du könntest mal ein Http Log erstellen :
>> http://www.mozilla.org/projects/netlib/http/http-debugging.html
>
> Ist - denke ich - kein Bug als solcher, wenn als "feature"
> ab Version 1.1 anscheinend NTLM als Standard angewandt wird.
> Nur sollte man dann auch bitteschön NEGOTIATE und KERBEROS
> unterstützen.
Wenn es mit Mozilla1.1 klappt, dann ist der Fall eindeutig.
Wenn NTLM nicht verwendet werden soll, dann darf es der Server im Header
auch nicht als akzeptierte Authentification NTLM angeben.
Dann benutzt Mozilla auch den bisherigen Mechanismus.
[...]
> Wenn es mit Mozilla1.1 klappt, dann ist der Fall eindeutig.
>
> Wenn NTLM nicht verwendet werden soll, dann darf es der Server im
> Header auch nicht als akzeptierte Authentification NTLM angeben.
> Dann benutzt Mozilla auch den bisherigen Mechanismus.
Ok, ich habe in der IIS6 Metabase nachgesehen und da wird
NTLM - neben den anderen - tatsächlich akzeptiert. Ich war
bisher der Meinung, das ein Browser NTLM nicht stillschweigend
und automatisch vornimmt, sondern das dieses Verhalten per
Schalter (IE: "Use integrated windows authentification")
am Browser gesteuert werden kann.
Nun muß ich doch wohl oder übel an der IIS Metabase Hand anlegen.
Auf jeden Fall schon mal danke, für die hilfreiche Einkreisung
des Problems!
Gruß
Paul
Der Header vom Server lässt sich wunderbar in dem networking Log sehen
bzw. auch in einem Ethreal Packet Trace (gibt es auch für win32).
Bei IE ist NTLM auch ein wenig anders da er teilweise _automatisch_ die
eigene Domain mitsendet. Ich als User fände das aber nicht unbedingt
besonders nett, bei einer wildfremden Seite.
Bei Mozilla bekommst Du immer ein Auth. Popup und die Doamin muss man
dann so angeben USERNAME:DOAMIN\USERNAME und PASSWORD:Password
Irgendwann soll auch ein eigens Feld für die Domain kommen.
> Nun muß ich doch wohl oder übel an der IIS Metabase Hand anlegen.
> Auf jeden Fall schon mal danke, für die hilfreiche Einkreisung
> des Problems!
Man kann NTLM auch in Mozilla abschalten wenn man ein wenig von Hand
editiert aber Du willst wahrscheinlich eine generelle Lösung.
[...]
> Bei IE ist NTLM auch ein wenig anders da er teilweise _automatisch_
> die eigene Domain mitsendet. Ich als User fände das aber nicht
> unbedingt besonders nett, bei einer wildfremden Seite.
>
> Bei Mozilla bekommst Du immer ein Auth. Popup und die Doamin muss man
> dann so angeben USERNAME:DOAMIN\USERNAME und PASSWORD:Password
>
> Irgendwann soll auch ein eigens Feld für die Domain kommen.
>
>
>> Nun muß ich doch wohl oder übel an der IIS Metabase Hand anlegen.
>> Auf jeden Fall schon mal danke, für die hilfreiche Einkreisung
>> des Problems!
>
> Man kann NTLM auch in Mozilla abschalten wenn man ein wenig von Hand
> editiert aber Du willst wahrscheinlich eine generelle Lösung.
Irgendwie ist konzeptionell der Wurm drin. Entweder beim IIS oder
beim Mozilla, das kann man sich aussuchen. Ich habe jetzt die
IIS60 Metabase editiert und die möglichen Authentifizierungsmethoden
analysiert. Im Prinzip bieten sich nur zwei Parameter:
AuthFlags="AuthBasic | AuthNTLM"
Problem: Setze ich das Flag ausschliesslich auf "AuthBasic",
müssen die IE-User (ungefähr 99% bei dieser Intranet-Applikation)
zukünftig Domäne, Account und Password eingeben und werden nicht
mehr automatisch erkannt :(
Setze ich "AuthNTLM" (zusätzlich oder alleine), bleiben die
Mozilla-User aussen vor. Es gibt im IIS60 leider kein Flag
"AuthKerberos" oder "AuthNegotiate", was das Problem lösen
könnte.
Mein Fazit daher: Problem derzeit nicht lösbar. Natürlich
könnte ich auch die ganze Applikation auf eine andere URL
spiegeln, die nur "AuthBasic" für die Mozilla-ab-Version-1.1-User
spiegelt, aber das erscheint mir ein unverhältnismässiger
Aufwand.
Oder habe ich doch noch was übersehen?
Paul
> Problem: Setze ich das Flag ausschliesslich auf "AuthBasic",
> müssen die IE-User (ungefähr 99% bei dieser Intranet-Applikation)
> zukünftig Domäne, Account und Password eingeben und werden nicht
> mehr automatisch erkannt :(
Ja, IE übermittelt NTLM Infos automatisch.
> Setze ich "AuthNTLM" (zusätzlich oder alleine), bleiben die
> Mozilla-User aussen vor. Es gibt im IIS60 leider kein Flag
> "AuthKerberos" oder "AuthNegotiate", was das Problem lösen
> könnte.
Ich kenne mich nicht besonders mit "AuthKerberos" oder
"AuthNegotiate" aus. Sind das beide erweiterungen von NTLM ?
Mozilla bis 1.3 hat auschließlich BasicAuth benutzt und mit 1.4
NTLM wenn es angeboten wird und sonst BasicAUTH.
Frage:
BasicAuth ist o.k., Kerberos und Negotate auch aber normales
NTLM nicht ?
hattest Du in Mozilla auch bei NTLm richtig den Usernamen als
DOMAIN\USERNAME angegeben (beispiel: "DOMAIN123\Paul" ?
> Mein Fazit daher: Problem derzeit nicht lösbar. Natürlich
> könnte ich auch die ganze Applikation auf eine andere URL
> spiegeln, die nur "AuthBasic" für die Mozilla-ab-Version-1.1-User
> spiegelt, aber das erscheint mir ein unverhältnismässiger
> Aufwand.
>
> Oder habe ich doch noch was übersehen?
Im Notfall könnte ich noch das ausschalten von NTLm via manuellen
editierens einer Zeile in der compre.dat anbieten.
Das stimmt nicht. Schon seit einigen Releases vorher, vielleicht schon
seit vor Mozilla 1.0, wurde auch Digest Auth unterstützt.
[...]
>> Problem: Setze ich das Flag ausschliesslich auf "AuthBasic",
>> müssen die IE-User (ungefähr 99% bei dieser Intranet-Applikation)
>> zukünftig Domäne, Account und Password eingeben und werden nicht
>> mehr automatisch erkannt :(
>
> Ja, IE übermittelt NTLM Infos automatisch.
Flasch. NTLM ist alter Standard, wenn integrierte Windows-
Authentifizierung im Browser aktiviert ist, wird Negotiate
oder Kerberos verwendet. Mit NTLM kannst Du nicht auf das
ADSI zugreifen, das ist der Knackepunkt.
[...]
> Ich kenne mich nicht besonders mit "AuthKerberos" oder
> "AuthNegotiate" aus. Sind das beide erweiterungen von NTLM ?
Zumindet andere Typen der Authentifizierung. Ob es direkt
eine Erweiterung ist, kann ich nicht beantworten. Du brauchst
aber die Kerberos-Keys für den ADSI-Zugriff.
[...]
> Frage:
> BasicAuth ist o.k., Kerberos und Negotate auch aber normales
> NTLM nicht ?
Ja.
> hattest Du in Mozilla auch bei NTLm richtig den Usernamen als
> DOMAIN\USERNAME angegeben (beispiel: "DOMAIN123\Paul" ?
Ja, natürlich.
>> Mein Fazit daher: Problem derzeit nicht lösbar. Natürlich
Da lag ich falsch. Ich habe inzwischen eine Lösung gefunden.
Ok, nicht was ich wirklich toll finde, aber es funkt:
Die eigentliche Applikation liegt auf /meinserver.de/app
Dort ist Basic+NTLM für die IE-Clients eingestellt.
Ich prüfe dort im Script, mit welcher Authentifizierungs-
methode der Browser ankommt. Beherrscht er kein
Negotiate bzw. Keberos, redirecte ich den request
zu /meinserver.de/app/mozilla/
Dieses Verzeichnis ist lediglich ein Mapping auf
/meinserver.de/app, allerdings ist auf dem virt. path
/meinserver.de/app/mozilla/ nur AuthClear erlaubt.
Somit können die Non-IE's nach Eingabe Domäne+User+PWD
auch auf die Applikation zugreifen :)
[...]
> Im Notfall könnte ich noch das ausschalten von NTLm via manuellen
> editierens einer Zeile in der compre.dat anbieten.
Danke für das Angebot, aber die o.g. Lösung ist - denke ich -
weniger aufwendig, da ich die Clients nicht anfassen muss.
Und nochmals vielen Dank für die kompetente & engagierte
Unterstützung bei der Lösungsfindung!
Paul
> * Matthias Versen wrote:
>
> [...]
>>> Problem: Setze ich das Flag ausschliesslich auf "AuthBasic",
>>> müssen die IE-User (ungefähr 99% bei dieser Intranet-Applikation)
>>> zukünftig Domäne, Account und Password eingeben und werden nicht
>>> mehr automatisch erkannt :(
>>
>> Ja, IE übermittelt NTLM Infos automatisch.
>
> Flasch. NTLM ist alter Standard, wenn integrierte Windows-
> Authentifizierung im Browser aktiviert ist, wird Negotiate
> oder Kerberos verwendet. Mit NTLM kannst Du nicht auf das
> ADSI zugreifen, das ist der Knackepunkt.
Ich hoffe das ich nicht nerve aber mich interessiert das :
Ein normaler NTLM Header sieht z.b. so aus :
-709929[7d4eb0]: HTTP/1.0 401 Unauthorized
-709929[7d4eb0]: WWW-Authenticate: NTLM
-709929[7d4eb0]: Content-Length: 644
-709929[7d4eb0]: Content-Type: text/html
-709929[7d4eb0]: X-Cache: MISS from alien.regisbb.com
und Kerberos sieht so aus :
1026[8170628]: HTTP/1.1 401 Authorization Required
1026[8170628]: Date: Fri, 15 Mar 2002 05:19:23 GMT
1026[8170628]: Server: Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6b
1026[8170628]: WWW-Authenticate: Basic realm="kerberos"
1026[8170628]: Keep-Alive: timeout=15, max=100
1026[8170628]: Connection: Keep-Alive
1026[8170628]: Transfer-Encoding: chunked
1026[8170628]: Content-Type: text/html; charset=iso-8859-1
(aus Logs in bugzilla)
Daraus ergibt sich für mich die Frage :
Was sendet Dein Server an den Client ?
Ich will nur verstehen was Mozilla oder der Sever falsch macht und evtl.
einen Bug dafür zu erstellen.
Übrigens : Mozilla benutzt die Win32API für NTLM
[...]
> Ich hoffe das ich nicht nerve aber mich interessiert das :
So sieht der relevante Traffic aus (Server <-> Client mit IE 6.0):
HTTP: GET Request from Client
HTTP: Request Method =GET
HTTP: Uniform Resource Identifier =/xxxxx/xxxxx.html
HTTP: Protocol Version =HTTP/1.1
HTTP: Accept = */*
HTTP: Referer =http://xxx.xxxxxxxx.xx
HTTP: Accept-Language =de
HTTP: Accept-Encoding =gzip, deflate
HTTP: If-Modified-Since =Tue, 01 Jul 2003 08:46:41 GMT
HTTP: If-None-Match ="683aba4aad3fc31:2071"
HTTP: User-Agent =Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.1; .NET CLR 1.0.37
HTTP: Host =xxxxxxxxxxxxxxxxxxx
HTTP: Connection =Keep-Alive
HTTP: Cookie =ASPSESSIONIDACTRQCDD=MLFFJDGDPPOCAJADBGIHEENK
HTTP: Data: Number of data bytes remaining = 821 (0x0335)
HTTP: Response to Client; HTTP/1.1; Status Code = 401 - Unauthorized
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = Unauthorized
HTTP: Reason =Unauthorized
HTTP: Content-Length =1656
HTTP: Content-Type =text/html
HTTP: Server =Microsoft-IIS/6.0
HTTP: WWW-Authenticate =Negotiate
HTTP: WWW-Authenticate =NTLM
HTTP: WWW-Authenticate =Basic realm="xxxxxxxxxxxxxxxxx"
HTTP: X-Powered-By = ASP.NET
HTTP: MicrosoftOfficeWebServer =5.0_Pub
HTTP: Date =Fri, 29 Aug 2003 13:12:53 GMT
HTTP: Data: Number of data bytes remaining = 955 (0x03BB)
HTTP: Response to Client; HTTP/1.1; Status Code = 304 - Not Modified
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = Not Modified
HTTP: Reason =Not Modified
HTTP: Last-Modified =Tue, 01 Jul 2003 08:46:41 GMT
HTTP: Accept-Ranges =bytes
HTTP: ETag ="683aba4aad3fc31:2071"
HTTP: Server =Microsoft-IIS/6.0
HTTP: X-Powered-By = ASP.NET
HTTP: MicrosoftOfficeWebServer =5.0_Pub
HTTP: WWW-Authenticate =Negotiate
oYGhMIGeoAMajhthCwYJKoZIgvcSAQICooGJBIGGYIGDBgkqhk
HTTP: Date =Fri, 29 Aug 2003 13:12:53 GMT
Aufgenommen mit Netmon. Ich habe bisher nicht so in den Tiefen
des HTTP-Protokolls gewühlt, aber für mich sieht das so aus,
als meldet der IIS das der Browser nur zugreifen darf, wenn
er mit NTLM, Negotiate oder Basic ankommt. Der IE "weiss"
dann durch das aktivierte IE Setting "use integrated Windows
Authentication" das ein Negotiate Key gefordert wird und
kein NTLM verwenden soll! Der in diesem Fall "unwissende"
Mozilla fällt auf das NTLM rein und wird prompt auch
abgewiesen (von meiner Applikation, die einen Negotiate
erwartet). Das ist das Fiese an der Situation: Der Server
bietet 3 Auth.-Methoden an, aber nur der IE "weiss" das
er den Negotiate verwenden soll. Zudem ist es nicht
möglich, schon am Server zwingend Negotiate einzustellen,
das wird mit dem IIS-Setting NTLM in Verbindung mit dem bereits
erwähnten IE-Schalter durchgeführt! Im Mozilla müsste
quasi das entsprechende setting parallel zum IE noch
einprogrammiert werden.
Paul
> Aufgenommen mit Netmon. Ich habe bisher nicht so in den Tiefen
> des HTTP-Protokolls gewühlt, aber für mich sieht das so aus,
> als meldet der IIS das der Browser nur zugreifen darf, wenn
> er mit NTLM, Negotiate oder Basic ankommt. Der IE "weiss"
> dann durch das aktivierte IE Setting "use integrated Windows
> Authentication" das ein Negotiate Key gefordert wird und
> kein NTLM verwenden soll! Der in diesem Fall "unwissende"
> Mozilla fällt auf das NTLM rein und wird prompt auch
> abgewiesen (von meiner Applikation, die einen Negotiate
> erwartet). Das ist das Fiese an der Situation: Der Server
Mozilla unterstützt derzeit Negotiate nicht.
Das würde heißen, das Auth Basic und Negotiate zulässig sind aber
NTLM hingegen nicht.
Das Problem entsteht wohl dadurch das Du nur NTLM+Negotiate zusammen
abschalten kannst.Das abschalten wiederum führt dazu, das der IE ein
Login Dialog bekommt weil nur Basic Auth zulässig ist.
Mozilla hingegen wählt NTLM und nicht Negiotate wenn der Server beides
anbietet und dadurch entsteht das Problem.
(Mozilla unter 1.4 hat dann trotzdem Basic Auth benutzt wegen fehlendem
NTLM Suppport)
Negotiate ist übrigens = Kerberus V5
under der entsprechende Bug ist :
http://bugzilla.mozilla.org/show_bug.cgi?id=133939
(Kerberus V5 wird beim Socks5 Support benötigt)
Ich hoffe ich habe das jetzt alles richtig verstanden und nochmals
danke für Deine Zeit !