When Subversion used neon until 1.8 was released it supported the Windows Integrated Security Scheme called 'NTLM'. This same scheme was also supported in the ra_serf authentication framework we used before requiring Serf 0.7. (Read: Before Subversion 1.7). But now after releasing Subversion 1.8 we found out that this scheme is broken.
Many Subversion repositories on Windows now use a configuration like:
<Location /svn>
AuthName "My Subversion Repositories"
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIDomain MyDomain
SSPIOmitDomain On
SSPIOfferBasic On
SSPIUsernameCase lower
Require valid-user
SSLRequireSSL
DAV svn
SVNListParentPath on
SVNParentPath D:/Databases/Subversion/repos
AuthzSVNAccessFile D:/Databases/Subversion/etc/subversion.xs
</Location>
But this configuration that worked fine in Subversion 1.5, 1.6 and 1.7
doesn't provide automatic login any more in 1.8.
(See the 'Automatic windows authentication using serf/svn 1.8' thread on
users@s.a.o).
Subversion 1.8 just asks for a username and password with this configuration
and after that works correctly... but that is not an automatic login.
Ivan suggested adding the flag 'SSPIPackage Negotiate' in the config as that
would fix Subversion 1.8.
I can confirm that adding this flag fixes the configuration above in at
least 1 setup, but it also completely breaks all Subversion 1.7 and older
clients that depend on neon.
While this may be caused by bugs in mod_auth_sspi (as Ivan) suggests I don't
think we should just break this existing scenario.
(The 'Buy Visual SVN Enterprise option' or 'develop a new mod_auth_sspi'
options are not really viable to me)
The patch to serf 1.2.1 attached to this mail is a (tiny bit cleaned up)
hack based on the old code in ra_serf, some code from an old serf branch and
the new in serf auth_kerb code, which re-enables the NTLM authentication
scheme in serf.
I think we should work to get this code cleaned up for releasing in a new
serf, to resolve this regression in Subversion.
Bert
serf-ntlm.patch
Description: Binary data
