You're still vulnerable to the "Linux clients store passwords in clear-text in $HOME/.svn/ by default" security issue, and if you have your Subversion password authentication tied to your AD accounts, it enhances the risk. It only takes one internal environment with poor home directory security, or NFSv3 home directories and internal IT people who say "if someone has network access, we have much bigger problems" to leave people's home AD accounts wide open. The Windows clients are generally much better about this, although the CygWin subversion client still has the issue.
The "kwallet" and gnome-keyring utilities for storing passwords more securely, locally, can help. What I'd give a *lot* to see is a Kerberos based authentication, tied to svn+ssh or tied to svnserve, that would correctly allow Kerberos based tickets (such as those uesed for genuine SSO solutions, like AD and NTLM), and correctly record Subversion commits tied to the identity of the relevant Kerberos ticket. Has anyone pursued, or gotten further, with a purely Kerberos baed authentication approach for HTTPS or svn+ssh? I'd consider that much cleaner and much less complex than the full-blown NTLM toolkit. And since Subversion has its own internal access management protocols, I've found those to provide much finer grained and trackable access than passing that task off to AD based group management. Also, Markus? If you want to pursue a full Linux system, my backports of Samba 4 full-blown AD replacements for RHEL or CentOS or Scientific Linux 6 was just updated to the new Samba 4.1.4 release, at: https://github.com/nkadel/samba4repo On Mon, Jan 13, 2014 at 4:02 AM, Markus Schaber <m.scha...@codesys.com> wrote: > Hi, > > Von: Markus Schaber [mailto:m.scha...@codesys.com] >> I know that this problem is not strictly SVN specific, but maybe one of the >> users here has experience with this and knows a solution: >> >> I'm currently trying to set up an SVN server on linux which authenticates >> against an Windows domain using NTLM - we want a single sign-on solution. >> >> The version of SASL is the debian libsasl2-2 package in version 2.1.25.dfsg1- >> 6+deb7u1 (debian wheezy on amd64) running with SVN 1.6.17 (but upgrading to >> SVN 1.7 or 1.8 is an option.) >> >> The configuration on the server side seems to be correct, but the >> authentication fails with the following message: >> NTLM: error in NEGPROT response parameters >> >> As far as I could google it[1], there seems to be a workaround (disabling SBM >> signing via group policy), but said workaround is not acceptable for our >> network administrators. The SMB Signing seems to be a security feature which >> is enabled by default on windows servers since 2003. >> >> Is there any other solution or workaround for this problem? > > Just as a little clarification: > Our intention is to have a single sign on solution working with (most) > windows clients, but the SVN server needs to run under (Debian) Linux. > > It is not a must that we use NTLM, any other mechanism (like Kerberos) is > also okay. > > Best regards > > Markus Schaber > > CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH > > Inspiring Automation Solutions > > 3S-Smart Software Solutions GmbH > Dipl.-Inf. Markus Schaber | Product Development Core Technology > Memminger Str. 151 | 87439 Kempten | Germany > Tel. +49-831-54031-979 | Fax +49-831-54031-50 > > E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: > http://store.codesys.com > CODESYS forum: http://forum.codesys.com > > Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade > register: Kempten HRB 6186 | Tax ID No.: DE 167014915 >