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.

Answer 1

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.