After playing with the new set of patches, here are my results so far:
Tested, working as expected. Both with IE 7.0 and FF 2.0.0.x (both from Windows and from Linux). With FF you get an authentication popup dialog (unless you set 'network.automatic-ntlm-auth.trusted-uris'), but once you fill it things just hum along
By the way, I've tested both with IIS 6.0 and Apache 2.2.4 (from XAMPP lite 1.6.2), running on W2003 (with neither SP1 nor SR2), running in W2003 Domain Functional Level, in a single domain configuration (not that that should make a difference, but just to make sure anyone can replicate the tests
- On LAN with AD, needing to login as 'admin'
Tested, working as expected. You can do it both using the 'skipntlm_sso=1' parameter to login.php, or by going to the login page once you are authenticated by the NTLM magic.
I guess you say 'without AD credentials automatically sent by the browser'. In this case, I just click 'Cancel' in Firefox's auth popup dialog (IE sends them by default), and after the redirection period I land on the login page with the 'skipntlm_sso' parameter, where I can login normally.
- From Intarwebs, needing to login, no HTTP Digest
- From Intarwebs, using AD login with HTTP Digest
I haven't tested any of these scenarios, as I don't understand what they really mean
. What's 'Intarwebs' and what kind of HTTP Digest configuration are you talking about?
In a related question, if we are using 'AD login' (I assume you mean Integrated Windows Authentication, aka NTLM), what does it mean AD login with HTTP Digest? As far as I know, they are independent, and the browser and the server negotiate using one or the other (but not both), depending on you server settings.
Which in the case of IIS, it means you use NTLM instead of HTTP Digest, in case the client supports it (or more precisely, is configured to negotiate it for that site/URL). I'm not really sure what Apache does in this respect (I have never used more than one authentication schema for the same resource), but I suspect we'll get a similar behaviour (one of the schemas being preferred over the other).
Anyway, even if we use HTTP Digest authentication instead of NTLM, as long as the user authenticates correctly, the code should behave exactly the same under both schemas. As far as Moodle is concerned, the user is already authenticated by the web server and we get the credentials from exactly the same place ($_SERVER['REMOTE_USER']). So from Moodle's point of view, everything stays the same.
There is one missing point in the latest patches that I'd like to address: using the remote IP address as the temporary NTLM session key. As I've said before, there are proxies that can handle NTLM (MS-Proxy/ISA Server, for example), so using $_SERVER['REMOTE_ADDR'] as the key could break havoc in this scenario. I propose to use sesskey() as the NTLM session key (unless there are any gotchas that I don't know about).
I'd like Dan to test it all in a wider environment before blessing the code, but apart from the missing language strings, and a few more things that should be 'translatable' (they are hardcoded in English right now), I'd say we could push the code as is (plus the proposed sesskey() change