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.schaber_at_codesys.com> wrote:
> Hi,
>
> Von: Markus Schaber [mailto:m.schaber_at_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.schaber@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
>
Received on 2014-01-13 14:31:04 CET