Does *anyone* have Windows SVNServe authenticating to AD/Kerberos via SASL/GSSAPI?

Question

Scenario: Windows server in a AD domain hosting a Subversion repository using SVNSERVE only (no Apache), and not VisualSVN.

Objective: Authenticate users to the Subversion repository via SASL through GSSAPI to a Windows domain via Kerberos.

Frequent postings in multiple sites indicate users often dead-end in this configuration with a "Could not obtain list of SASL mechanisms." I've not seen any instance where this is actually running. Does anyone have this running?

I ask this question as a result of a 2011 posting in a Gentoo forum in which someone in precisely this scenario reviewed the relevant source tarballs and concluded that while, at one time, such a configuration probably worked, the files necessary for it are no longer in the source.

GEntoo forum discussion where poster claims svnserve+gssapi+sasl worked at one time, but no longer does.

Now, I don't assert that claim to be accurate, but I do know I am stuck at precisely the same point, and I've not yet seen any posts that claim "victory" over such a setup. If you have, please advise details!

Many thanks in advance.

Selestina

Answer 1

After earning a "tumbleweed" badge for this unanswered question, and considerable additional research on my own, I've come to the conclusion that the subject combination for Subversion under Windows is, in fact, not possible under the current code base. I believe something in the SASL authentication layer is the problem here, with some source removed or significantly changed to "break" what did, I believe, work at one point.

My solution has been to add Apache to the mix with mod_auth_sspi, and while it does slow down the repository some, the authentication works perfectly. This appears to be the "fix" for the authentication requirement.

Selestina

Answer 2

I've just managed (after close to 30 hours of head scratching, compiling, and sourcecode-less debugging to get decent error codes) to get svnserve+SASL+GSSAPI to work! My setup is as follows:

• AD server is Samba 4.1.0 on Debian 7.2 (built from source).
• Subversion server is subversion 1.8.5 on Solaris Express (SunOS 5.11 snv_151a i86pc i386 i86pc). Built for x64 from source using native (Sun) SASL.
• Client is Windows 7 x64 with TortoiseSVN 1.8.2 (x64 binary release) and Heimdal 1.5.1 (x64 binary from secure-endpoints).
• As with anything involving Kerberos, you need to have forward and reverse DNS working smoothly, clocks synchronized, etc.

Steps on a Windows box with domain creds:

• Create a "svnserve" user account (not computer account) for the Subversion server.
• Run "ktpass -princ svn/[email protected] -mapuser DOMAIN.LOCAL\svnserve -crypto RC4-HMAC-NT -pass password -ptype KRB5_NT_PRINCIPAL -out svnserve.keytab". You do not want to turn on DES for this account or Windows 7 will refuse to authenticate to it. I turned it on earlier (following the recipes) and had to turn it off again to get it to work.

Steps for the Subversion server:

• Set up /etc/krb5/krb5.conf

  [libdefaults]
      default_realm = DOMAIN.LOCAL
  
  [realms]
      DOMAIN.LOCAL = {
          kdc = pdc.domain.local
          admin_server = pdc.domain.local
      }
  
  [domain_realm]
      .domain.local = DOMAIN.LOCAL
      domain.local = DOMAIN.LOCAL
  
  # Other defaults left as-is.
  

• Set up repo/conf/svnserve.conf:

  [general]
  anon-access = none
  authz-db = authz
  realm = DOMAIN.LOCAL
  
  [sasl]
  use-sasl = true
  min-encryption = 0
  max-encryption = 256
  

• Set up repo/conf/authz:

  [aliases]
  
  [groups]
  
  [/]
  * =
  # Still investigating whether access to the server can be controlled through an AD group.
  # Below is for [email protected], the realm appears to get lost.
  user = rw
  

• Set up /etc/sasl/svn.conf:

  mech_list: GSSAPI
  

• Drop svnserve.keytab in to /etc/krb5/krb5.keytab (keytab in the sasl configuration doesn't seem to do anything).

• Start svnserve.

Steps for the client:

• Install TortoiseSVN and Heimdal.
• Edit C:\ProgramData\Kerberos\krb5.conf to be like /etc/krb5/krb5.conf on the Subversion server. There's some other defaults in there that I left alone.
• Do a checkout, no password required!

One issue with this setup is that the svnserve process has to be able to read /etc/krb5/krb5.keytab, so permissions on that need to be wound back a bit. svnserve is going in to its own zone though so this isn't an issue for me. I also had mslsa_cc.dll crashing while testing things, but I haven't seen any crashes once I got everything sorted out.

With some wrangling, you might be able to get this working for svnserve on Windows as well. I tried MIT Kerberos on the Windows client but it crashed every time on startup so I gave up on it. You might have better luck.

Update: Figured out the crash issue - it's a bug in mslsa_cc.dll (similar to https://github.com/krb5/krb5/commit/7acb524f5aa00274771dbbfac19d2dd779aad409, which also gets it slightly wrong as nOutStringLen needs to be divided by 2 for the way that ANSIToUnicode is called). Binary patch on mslsa_cc.dll is:

• Offset 0xB46: Change from FF 15 04 69 00 to D1 EE 0F 1F 40.
• Offset 0xB5E: Change from 77 to EB.

Conflagrant

"One issue with this setup is that the svnserve process has to be able to read /etc/krb5/krb5.keytab ..." -- If svnserve does not have a configuration option to set its own keytab, you can do this by setting the environment variable KRB5_KTNAME. That is used directly by the underlying Kerberos libraries on Unix (MIT or Heimdal). You don't generally want to share the keys which are in the system keytab with arbitrary other servers. – Locular

Answer 3

I have done authentication against AD with SASL+LDAP, but not SASL+GSSAPI, and with a small caveat: I have to use and run svnserve from Cygwin in Windows.

1) It was quite easy to get svnserve authenticate users via SASL+LDAP/AD in Linux ( I know the question is about svnserve in Windows, but bear with me ). The important part to get the authentication working against LDAP/AD is saslauthd, and test the authentication using testsaslauthd.

Using Ubuntu as an example:

1a) /etc/sasl2/svn.conf

pwcheck_method: saslauthd
mech_list: PLAIN

This tells subversion / svnserve to use saslauthd to do the authentication on its behalf.

1b) /etc/saslauthd.conf

ldap_servers: ldap://yourADserver.dept.org
ldap_search_base: DC=dept,DC=org
ldap_bind_dn: cn=bindaccount,dc=dept,dc=org
ldap_bind_pw: passwordOfbindaccount

ldap_deref: never
ldap_restart: yes
ldap_scope: sub
ldap_use_sasl: no
ldap_start_tls: no
ldap_version: 3
ldap_auth_method: bind
ldap_filter: sAMAccountName=%u
ldap_password_attr: userPassword
ldap_timeout: 10
ldap_cache_ttl: 5
ldap_cache_mem: 32768

1c) Do a test via testsaslauthd

testsaslauthd -u myusername -p mypassword

1d) If successful, then run saslauthd, and start svnserve. and use whatever svn client to test the authentication.

2) Problem is, there is no native port of Cyrus' saslauthd to Windows, and probably never will be. Answer is to use Cygwin, which has svnserve, testsaslauthd, and saslauthd.

Just repeat the above steps .. but the location of svn.conf may be different.

Hardness

Thank you so much for the detailed information, @jmsjr. Fantastic stuff, and its gratifying to know that there at least some way of making this all work. Unfortunately, the target environment for which my original question evolved is one in which I seriously doubt the use of Cygwin would be sanctioned (for lots of primarily if not exclusively bureaucratic reasons that are largely out of my control). – Selestina

@DavidW I know your pain. The only reason I had it running in Cygwin was that the support and backup contract where I work is only for Windows. Nevertheless, I also have the same setup in a Linux VM acting as a mirror to the SVN repositories in the Cygwin environment. Couple the above with the need to authenticate against two ADs, wherein I then have to use OpenLDAP as a proxy ( using slap-meta ) to the two ADs, and have SVN/saslauthd authenticate via SASL+LDAP against the OpenLDAP proxy. – Hardness