Univention Bugzilla – Bug 27401
"Fallback" für NTLM Authentifizierung bei Windows Clients funktioniert nicht
Last modified: 2013-07-12 15:12:05 CEST
Umgebung: * UCS DC mit squid und NTLM/BASIC Authentifizierung * Win7, nicht gejoint, Windows Account ist in der Domäne nicht bekannt Wenn man nun über den Proxy versucht ins WWW zu kommen, gibt schlägt die NTLM Auth. mit den Login Credentials richtigerweise fehl. Jetzt fragt der Browser das Passwort ab und man kann einen Domänen-Benutzer angeben. Das funktioniert dann aber nur bis zum nächsten Request und man muss das Passwort wieder eingeben. In cache.log des Squid sieht man, dass der Client zunächst NTLM mit den Login Credentials versucht, dass klappt nicht, dann die Passwort Abfrage, dann klappt NTLM bis zum nächsten Request, dann wieder NTLM mit den Login Credentials etc. Hoffnung war eigentlich, dass der Client dann einfach BASIC macht (wir bieten das als zweite Option im squid an), jedoch nimmt Windows wohl immer NTLM, das es angeboten wird. Stellt man die NTLM Auth. im squid aus, und verwendet nur BASIC, dann klappt es wie gewünscht (Passwort Abfrage -> Passwort speichern -> Surfen bis zur nächsten Session)
Wir haben im Squid (für ucs@school) die Authentifizierung auf NTLM und BASIC konfiguriert. Clients die kein NTLM können verwenden dann BASIC, aber Clients die NTLM prinzipiell können, verwenden immer NTLM. Selbst wenn ich im Windows NTLM deaktiviere, der squid NTLM aber anbietet, nimmt Windows nicht BASIC, sondern sagt gleich das es Probleme mit der Verbindung gibt. ==> der Fallback Basic im Squid ist nur für Linux Clients interessant Windows Clients haben aber auch einen NTLM "Fallback". Wenn die Authentifizierung am Proxy mit den Login Daten nicht funktioniert, wird per popup das Passwort abgefragt. Bei Windows klappt das leidlich. Nach 3 Popups kann man für die Session in Netz. Man hat auch die Möglichkeit das Passwort zu speichern. Dann wird gar nicht mehr nachgefragt. Mit Firefox klappt es gar nicht. Hier kommen ständig Popup die man ausfüllen muss, man kann dort das Passwort auch nicht speichern und normales Surfen ist nicht möglich. Hier eine Ausszug aus einer Session: Zunächst versucht der Firefox NTLM mit den Login Daten, das klappt natürlich nicht und der Proxy sendet wieder "Authentication Required". c->s HTTP GET http://10.200.7.30/icon/ HTTP/1.1 s->c HTTP HTTP/1.0 407 Proxy Authentication Required (text/html) Proxy-Auth: NTLM c->s HTTP GET http://10.200.7.30/icon/ HTTP/1.1 , NTLMSSP_NEGOTIATE s->c HTTP HTTP/1.0 407 Proxy Authentication Required , NTLMSSP_CHALLENGE (text/html) c->s HTTP GET http://10.200.7.30/icon/ HTTP/1.1 , NTLMSSP_AUTH, User: win7pro\winu2 s->c HTTP HTTP/1.0 407 Proxy Authentication Required (text/html) Proxy-Auth: NTLM Hier wird geht nun das Passwort Popup auf. Wenn man das ausfüllt und bestätigt, passiert folgendes: c->s HTTP GET http://10.200.7.30/icon/ HTTP/1.1 , NTLMSSP_NEGOTIATE s->c HTTP HTTP/1.0 407 Proxy Authentication Required (text/html) Proxy-Auth: NTLM Der Client schickt ein GET mit NTLM MSG1 (wahrscheinlich weil das vorherige "Proxy Authentication Required" vom Proxy auch den Header Proxy-Authentication: NTLM gesendet hat, also NTLM angefordert hat). Der Proxy erwartet aber wohl hier wieder ein initiales GET und nicht eines mit NTLM MSG1 (siehe oben, normalerweise gibt es ein GET vom Client, dann eine "Auth Requierd: NTML" vom Server und dann erst ein GET mit NTLM MSG 1 vom Client). Ich vermute hier klappt das Zusammenspiel von Squid und den Clients bei dieser 3 Schritte Authentifizierung nicht. Im Authentication Helper im squid kann man da leider nichts machen, da das oben genannte Problem bereits bei der Initialen Aushandlung der Authentifizierung auftritt.
Beim Zusammenspiel zwischen Kerberos und NTLM gilt IIRC das gleiche. Damit das funktioniert wurde für Squid ein auth_helper für das NEGOTIATE Protokol implementiert. Ich vermute allerdings, dass das nur zwischen Kerberos und NTLM umschalten kann und nicht auf basic/ldap,.
UCS 2.4 mit squid 2 macht diesbezüglich keine Probleme. Auffällig war, dass der squid2 (UCS 2.4) bei der Initialen Antwort (Proxy Authentication Required) die Proxy-Connection über einen entsprechenden Header Eintrag explizit geschlossen hat. Bei squid3 (UCS 3.0) wurde hier immer "Proxy-Connection: keep-alive" gesendet. Wir setzen das keep-alive in der auth-ntlm Konfiguration explizit "auth_param ntlm keep_alive on". Laut manpage kann man das ausschalten, wenn es Probleme macht: "keep_alive" on|off If you experience problems with PUT/POST requests when using the Negotiate authentication scheme then you can try setting this to off. This will cause Squid to forcibly close the connection on the initial requests where the browser asks which schemes are supported by the proxy. Damit funktioniert dann das NTLM Fallback. Es wird also zunächst eine NTLM Auth. mit den Login Credentials gemacht. Das geht schief (Benutzer nicht in der Domäne) woraufhin der Browser das Login Daten abfragt und dann damit NTLM macht. Während der Session wird man auch nur einmal gefragt (FF, IE). Der default für squid/ntlmauth/keepalive wurde nun von "on" auf "off" geändert. SSO Anmeldung über einen Domänenbenutzer klappt ebenfalls noch.
(In reply to comment #3) > Damit funktioniert dann das NTLM Fallback. Es wird also zunächst eine NTLM > Auth. mit den Login Credentials gemacht. Das geht schief (Benutzer nicht in der > Domäne) woraufhin der Browser das Login Daten abfragt und dann damit NTLM > macht. Während der Session wird man auch nur einmal gefragt (FF, IE). → OK > Der default für squid/ntlmauth/keepalive wurde nun von "on" auf "off" geändert. → OK Changelogeintrag ist ok. Getestet mit Samba 4: OS | Browser | keepalive=no |keepalive=yes =========|==========|==============|=========================== Win7 | IE8 | 1 Frage, ok | 3 Fragen unjoined | FF13 | 1 Frage, ok | 6 Fragen | Chrome20 | 1 Frage, ok | 3 Fragen =========|==========|==============|=========================== Win7 | IE8 | ohne Frage,ok joined | FF13 | ohne Frage,ok | Chrome20 | ohne Frage,ok =========|==========|==============|=========================== WinXP | IE6 | 1 Frage, ok | 3 Fragen unjoined | FF13 | 1 Frage, ok | Bei jeder Seite mehrfach | Chrome20 | 1 Frage, ok | 3 Fragen =========|==========|==============|=========================== WinXP | IE6 | ohne Frage,ok joined | FF13 | ohne Frage,ok | Chrome20 | ohne Frage,ok =========|==========|==============|===========================
Getestet mit Samba 3: OS | Browser | keepalive=no |keepalive=yes =========|==========|==============|=========================== Win7 | IE8 | 1 Frage, ok | 3 Fragen unjoined | FF13 | 1 Frage, ok | > 5 Fragen, bei jeder Seite | Chrome20 | 1 Frage, ok | 3 Fragen =========|==========|==============|=========================== Win7 | IE8 | ohne Frage, ok joined | FF13 | ohne Frage, ok | Chrome20 | ohne Frage, ok =========|==========|==============|=========================== WinXP | IE6 | 1 Frage, ok | FAIL bei allen Browsern: es wird versucht unjoined | FF13 | 1 Frage, ok | mit dem angemeldeten Benutzer zu authentif. | Chrome20 | 1 Frage, ok | und nicht mit dem angegebenen Benutzer. =========|==========|==============|=========================== WinXP | IE6 | ohne Frage, ok joined | FF13 | ohne Frage, ok | Chrome20 | ohne Frage, ok =========|==========|==============|=========================== UCS | FF13 | 1 Frage, ok | 1 Frage, ok unjoined | Chrome20 | 1 Frage ,ok | 1 Frage, ok =========|==========|==============|=========================== Getestet wurde in allen Kombinationen mit aktiviertem NTLM- und BASICAUTH-Mechanismus: squid/allow/localnet: <empty> squid/allowfrom: 10.200.18.67 squid/auth/groups: <empty> squid/basicauth/children: <empty> squid/basicauth: yes squid/cache: yes squid/contentscan: <empty> squid/debug/level: ALL,1 squid/httpport: <empty> squid/krb5auth/children: <empty> squid/krb5auth/keepalive: <empty> squid/krb5auth: <empty> squid/ldapauth/groups: <empty> squid/ntlmauth/children: <empty> squid/ntlmauth/keepalive: yes squid/ntlmauth/tool: <empty> squid/ntlmauth: yes squid/parent/directnetworks: <empty> squid/parent/host: <empty> squid/parent/options: <empty> squid/parent/port: <empty> squid/redirect: <empty> squid/transparentproxy: false squid/virusscan: <empty> squid/webports: <empty> Siehe auch Bug 27402: das iPad2 scheint mit ntlmauth/keepalive=yes besser klarzukommen, während dies bei den Windowssystemen je nach Windows-Version nahezu unbenutzbar ist. In einer Samba3-Umgebung mit KRB5AUTH, NTLMAUTH und BASICAUTH bzw. KRB5AUTH und BASICAUTH funktioniert die Anmeldung am Proxy mit beliebigen Windowsclients gar nicht. Der Benutzer wird ständig nach Credentials gefragt. Weitestgehend ähnliches Verhalten in einer Samba4-Umgebung. Der IE6 unter XP begnügt sich dann mit BASICAUTH. Mit S4 sind nicht alle Kombinationen getestet worden.
UCS 3.0-2 has been released: http://forum.univention.de/viewtopic.php?f=54&t=1905 If this error occurs again, please use "Clone This Bug".
Ich habe gerade einen Proxy mit "auth_param ntlm keep_alive off" und das ipad macht im Moment keine Probleme (einmal Proxy mit Benutzer eingerichtet, dann macht das ipad brav NTLMv2 gegen den Proxy)