Apache OpenOffice (AOO) Bugzilla – Issue 112709
webdav NTLM authentication newly (re-)broken
Last modified: 2016-10-29 18:58:55 UTC
As of 320m18 (9502), I get "general internet error has occurred" when trying to access a document via WebDAV + NTLM (v1) authentication, where I am logged into Windows XP in one Active Directory domain, and the remote webdav server authenticates against a different domain (I'm accessing via vpn). I do not get the option to type in a username/password, nor to use system credentials, it fails before that. This happens both when OO.o is launched from the command- line with a URL, and when the URL is accessed via the OO.o open-file dialog ("use openoffice dialogs", not the windows ones.) The problem does not exist when accessing documents protected in the same manner, but using client & server machines authenticating against the same domain. (i.e. I can access my test system, inside my domain, from my laptop, and I can access the production system from a machine in the client's network, but it won't let me authorize between them.) The problem also did not exist with 320m12 (9483), I haven't tested versions in-between to be more precise. With 320m12, I would be prompted for username/password, then it worked (my passwords differ on each domain, so I could tell it was correctly asking for the remote password, not the local one.) I've tested this while having multiple versions installed simultaneously, showing that the version upgrade is itself sufficient to cause the difference in behavior, it's not a VPN connectivity issue, etc. I've made mention of NTLMv2 in other bug reports and in communication with Kai (kso), but this is still running NTLMv1. As this is probably an unusual scenario, let me know if you need me to test different combinations. If there's somewhere I could look to give me a better error than the one I'm seeing, I'd be happy to go digging.
Additional testing: discovered that the "save passwords" checkbox was set in the options (but not the one below it about master passwords, which is weird because you can't get into that state, that I can tell, by clicking around?). So the password box not showing up at all was the result of OO.o thinking it already knew my password. Sorry about that part. However, with that unchecked, I still can't login across domains, which I used to be able to do. I tried both "username" and "domain\username" formats. I get "general internet error" after two failed attempts, with no apparent differentiation between made-to-fail (fake username/password) and should-have- worked attempts. I can talk to the exact same server, with auth, as long as I do it from OO.o on a machine already on that domain -- even if it prompts me and I enter username/password manually instead of using system credentials.
Hi Kai, can you please have a look at this issue, and reassign accordingly. Thanks, Matthias
> As of 320m18 (9502), I get "general internet error has occurred" when trying to [...] > between them.) The problem also did not exist with 320m12 (9483), I haven't > tested versions in-between to be more precise. With 320m12, I would be prompted [...] Very strange. To my best knowledge there where no(!) changes in the relevant source code modules (ucb/source/ucp/webdav, uui/source, neon). Have you already tried cleaning your password container (Tools/Options/OO.o/Security/Connections)?
Kai, you rock. The [x] for that section was disabled; so I re-enabled it, went into connections, saw there was one existing entry with a URL for one specific document (yet the problem seemed to affect that whole domain). I cleared the list, re-unset "Persistently save passwords for web connections" and tried again -- this time it worked like a charm. So it's fixed for me, but that leaves a couple of open questions: a) should an entry with a specific document URL affect all documents on that domain (I mean the URL domain, not the AD domain)? Am I crazy, did I test that poorly? b) should this have affected me, when the [x] was unchecked for "persistently..."?
a) The password container choose the best fit for a given url. Does OpenOffice prompt you a Username/Password dialog in case the password container entry has a wrong password? So, you can overwrite the wrong password manually? Perhaps b) has something to do with issue http://www.openoffice.org/issues/show_bug.cgi?id=101104
a) No, it skips directly to "general internet error", no password prompt.
New testing: - On Windows XP, I'm no longer having problems with NTLMv1. But I do get "general internet error" if OOO 3.2.1 is launched on a Windows 7 or Windows Server 2008 machine, against that same WebDAV server. MS Word, talking to that same server, has no issues. I'm using jCIFS's HTTP filter for NTLMv1. The bad behavior looks like this: request/response, prompt, request/response, request/ response (start over?), prompt, request/response, general internet error. Server-side, I don't see any failures, other than OOO just not following- through with a third request/response to finish the challenge. Good behavior (from Windows XP clients) looks like: request/response, prompt, request/ response, request/response - PROPFIND, HEAD, GET, PROPFIND. - I've tried switching to NTLMv2 on the WebDAV server, in the hopes that this is caused by Windows' minimum security level (lmcompatibilitylevel) though I haven't been able to either replicate the problem in XP, nor make it disappear in 2k8, by increasing/decreasing this setting from its defaults. I use Jespa (IOPlex) for NTLMv2, and I found that Jespa had an update as of "1.1.0b2 July 23, 2010" that might have fixed the "not a type 1 message" errors I was seeing previously when accessing jespa 1.0.4 from OOO 3.2.1, which originally caused me to stick with NTLMv1. So I updated to jespa 1.1.2, but I still get "not a type 1 message" when using OOO 3.2.1, regardless of the version of Windows I try from. It errors out at java.io.IOException: Not a Type 1 message. at jcifs.ntlmssp.Type1Message.parse(Type1Message.java:232) at jcifs.ntlmssp.Type1Message.<init>(Type1Message.java:88) at jespa.ntlm.NtlmSecurityProvider.acceptSecContext (NtlmSecurityProvider.java:1045) Again, MS Word has no problem accessing that same WebDAV server, with either NTLM v1 or v2. I don't see any difference in behavior in OOO when either explictly entering username/password, or using [x] system credentials. I'm going to try OOO 3.3 beta when I get a chance, and we'll also try slightly older (3.2.0-ish) versions to see if this is a regression. All of this new testing was done from inside the network, from other machines in the same Domain (not cross-domain). My original report was related, but I hadn't really pinned the problem down.
Possibly fixed on my end. Upgraded to jCIFS 1.3.14 after noticing that JESPA requires 1.3.11 or above. I was using 1.3.10. The release notes for 1.3.11 only state the following: "The nTOWFv2 computation for NTLMv2 authentication was slightly wrong in that it upper-cased the domain. This had no effect on JCIFS but it has been corrected for technical accuracy." Just this upgrade seems to have caused NTLMv2 to start working when accessed from OpenOffice 3.2.1; previously, no other client apps (various browsers, MS Word) seemed to have a problem with it, so it looks like this "purely academic" fix is more important (for OpenOffice usage, at least) than the jCIFS team realizes. Not apparent effect on the NTLMv1 issues. Will continue to test NTLMv2 for now, it's the better long-term solution anyway.
As there has been no activity in over 6 years I am closing this as obsolete.