Hi, Nico,
Von: Nico Kadel-Garcia [mailto:nkadel_at_gmail.com]
>
> 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.
This is why we want single sign on in the style of NTLM. There, the current
windows session of the client (which is part of the windows domain) is
used to authenticate on the server against the domain. No password is
involved at all in this stage, and no credentials are to be saved by svn,
all is done by passing some bacons around between the domain controller, the
client and the server, all the cryptography is already there and used by
the windows domain.
For the few non-windows clients in our setup, we want an alternative username
and password authentication which is not running against the active directory,
but a file. We can either use an appropriate SASL configuration enabling both
authentications in parallel, or a second svnserve running on a different port
or ip. As only a single-digit number of clients is affected (and this won't
change in the forseeable future), this is a manageable workaround.
> The "kwallet" and gnome-keyring utilities for storing passwords more securely,
> locally, can help.
Our few non-windows clients are advised to use such storing mechanisms, and
most (if not all) of them are already using full disk encryption.
> 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.
We don't have any fine-grained access control - every developer should be
allowed full access to the repository, and all other people should have no
access at all.
Our current fallback is a hand-maintained username/password database, but as
most of our clients are windows PCs in the same domain, we wanted to simplify
the setup and administration.
> 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
Most of our infrastructure is currently windows based, and we have appropriate
active directory servers (Windows) already running. As we also run several
windows based services (Outlook and other software), I can't see our admins
switching to a Linux-based solution anywhere soon.
> 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
> >> 6+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 17:01:47 CET