Preston's picture
Preston - Tue, 2017/01/24 - 01:00

Hello,

I find myself lost in the myriad pages on how to set up svnserve and ldap. I don't understand how the pieces fit together to even understand where I am missing things. So, I would like to ask for your tribal knowledge and experience in helping me figure this out. Here's the scenario:

First, I have an active directory (AD) server running at server.local. All users are authenticated from this AD by the Windows machines on the network. I have only a vague idea of how this actually works, and I very little knowledge on how AD should be set up so that a Linux client can authenticate from the service. For example, a brand new Windows machine connected to the small business domain can authenticate any user already on the AD to the new machine even if the new machine has never seen the user before. How can I get Linux to do that (and is it even related to what I'm trying to do?...questions for later perhaps).

I have a fresh install of TKL Redmine 14.X on the network. Happily it works out of the box. I'd now like to use LDAP to allow users to log into Redmine AND SVN without having to create a user record on TKL Redmine. SVN access is handled by TortoiseSVN clients on Windows machines. 

My research has led me to understand that I must install SASL support for svnserv to talk to LDAP/AD. So I have installed:

apt-get install sasl2-bin libsasl2-modules libsasl2-modules-ldap

I then need to modify /etc/default/saslauthd to use:

MECHANISMS="ldap"

Next I create the file saslauthd.conf in /etc/, which contains the following information:

ldap_servers: ldaps://server.local
ldap_use_sasl: yes
ldap_mech: DIGEST-MD5
ldap_auth_method: fastbind

I created a directory at "/var/run/saslauthd/" and gave it 755 permissions. I restarted the sasl server using "/etc/initd/saslauthd restart" and try to test the connection:

testsaslauthd -u testuser -p testpassword -f /var/run/saslauthd/

to which I get a "connect() : Connection refused". What's the significance of that socket path? The testuser and testpassword exists on the AD just as a normal user would be. So, I must have the AD or SASL incorrectly configured. Any ideas here? I would like to assign a property such as "SVN" to each user in AD who needs read/write access to svn so that this could be a group policy rather than an individual user policy.

Assuming testsaslauthd actually connected to the AD (and gave a "SUCCESS" notification), where do I go from here? How is this related to /var/repos/svn/.../svnserv.conf?

Thanks in advance!

Forum: 
Support
Tags: 
tklbam
svn
ldap
active directory
sasl
subversion
Jeremy Davis's picture

Jeremy Davis - Tue, 2017/01/24 - 03:06
Back in my days of Win Admin I only used Windows, so AD authentication was relatively straight forward. Just before the end of that, I had started using LDAP to authenticate third party stuff.

Since I've switched to Linux, I have very little to do with Windows, so my experience with AD & LDAP is very rusty (and was pretty poor to start with). Also my Linux knowledge tends to be broad rather than deep. Much general OS stuff I'm pretty handy with, but many specifics (especially stuff that relates to complex authentication systems) I have little to no experience with.

I've only ever used SASL to authenticate against Google accounts (for sending mail via Google's SMTP relay service), but I assume that your approach should work ok too.

I've just had a quick google and by my reading, when you run 'testsaslauthd' it appears that by default you need to specify (using the '-s' switch) the service you would like to authenticate against. If it's not explicitly stated, SASL will fall back to authenticate via local PAM (i.e. normal local Linux user authentication). Assuming I read right, that might explain why your test is failing?

OTOH, perhaps it uses the socket to communicate with a running SASL server (on your Redmine instance)? In which case, if the socket doesn't exist where it's looking for it (e.g. path wrong, or SASL service not currently running), then it wouldn't be able to use LDAP (and would again fall back to PAM)?

Another possibility is that I note you are using the FQDN of 'server.local'. It might be worth double checking that that is resolving correctly within your Redmine server.

Finally, it might be worth searching on the Redmine forums and docs. Perhaps they already have something written up? If not, perhaps cross post this on their forums too? Maybe someone with deeper knowledge of LDAP/SASL will be able to get you going in the right direction.

I hope my post adds something of value. And hopefully someone else with greater knowledge than me will be along to help you out. If you find answers elsewhere, please post back as no doubt it will help someone else in the future!

Preston's picture

Preston - Tue, 2017/01/24 - 22:23

Thanks for the reply. I think there must be more to this setup than just SASL. I don't necessarily need Redmine, but I do need SVN. Redmine is just a nice interface for me for the moment. 

The server is able to resolve the FQDN without issue. I can't say much about the socket...don't understand how SASL uses the socket. The directory with correct permissions exists, however. 

Here's an alternative approach. I found this post, which looks promising for AD integration with Debain: https://wiki.debian.org/AuthenticatingLinuxWithActiveDirectory

If one can authenticate on the domain using AD, could SVN be set up to use PAM? Here's another post, but the last three paragraphs in it don't make me feel happy. https://psyphi.net/blog/2012/05/svn-server-integration-with-https-active...

 

I'll keep looking...

Jeremy Davis's picture

Jeremy Davis - Wed, 2017/01/25 - 10:12
Assuming you are using TurnKey v14.x; both of the docs you linked to aren't quite 100% relevant.

The first link looks like it was written for Debian Wheezy - the older version of Debian which v13.x was based on. v14.x has Samba4 in the repos and that is actually much better at dealing with proper AD. Samba3 sort of worked with AD, but really only supported old NT style domains, not AD. The config differs but theoretically should support your scenario (I reckon...). Actually, I recall reading that Samba4 still apparently can operate the same as Samba3 used to.

The second is for CentOS. It uses a totally different packaging method and many of the config files are organised in a very different way to Debian (particularly Apache). It still might be useful though.

Not sure why I didn't remember before, but I just recalled hearing about "svnserve" sometime ago and I wondered if that might help? It appears to actually be a component of the "subversion" Debian package so it's probably already available. I've never used it (or even SVN) so I can't vouch for it, so I'm not even sure how secure it is. I gave it a quick google and got a few results that may be worth further investigation? FWIW I just googled "svnserve use ad for authentication". Here's a few links that jumped out at me:

http://www.everville.de/pages/howtos/linux/svnserve/index.html
http://www.dghost.com/techno/internet/setting-up-a-subversion-server-on-...
http://www.dghost.com/techno/databases/simplifying-svn-administration
https://tortoisesvn.net/sasl_howto.html
http://subversion.1072662.n5.nabble.com/SvnServe-with-Windows-AD-Authend...
https://stackoverflow.com/questions/1794242/svn-sasl-activedirectory-how-to

I didn't check any of them thoroughly so apologies if any/all of them miss the mark.

Another thought is that if you aren't attached to Redmine, then our Revision Control appliance includes "webSVN". Perhaps that's also worth a try? Some more random links on that:

https://letitknow.wordpress.com/2012/06/08/websvn-with-bugzilla-and-ldap...
http://www.dhillonblog.com/2009/07/subversion-with-websvn-webdav-and-act...
https://serverfault.com/questions/78315/providing-websvn-with-repo-authe...
https://serverfault.com/questions/13853/how-do-i-restrict-repository-acc...
https://stackoverflow.com/questions/3562420/how-to-have-login-in-websvn

Sorry it's just a bit of a link dump really, but perhaps something in amongst that will be a winner?! I hope so! :)

Cobra_Koral - Fri, 2017/03/24 - 20:35

Hello Preston.

I think a good point to start, is to isolate problems.

Is your AD/LDAP server complete/operational ?

Is it working as expected ?

If you have already validated your AD/LDAP server, I can give you a virtual host conf example that you can create on your turnkey linux like /etc/apache2/sites-enabled/svnserver.conf and it works fine.

http://pastebin.com/HgQ3A3Jy

This example works with SSL and requires a public root CA, a SSL cert for the server and a key.

It forces ssl authentication on 443 port and works very nice.

I use it on a production server, and I made a generic example with some comments you can follow.

A good practice is to always isolate the AD/LDAP server from other appliances.

If you are not using AD solution, but just plain LDAP adjust port from 3269 to 636 and sAMAccountName to uid and ajust LDAP AUth URL accordingly

Let me know if I can be of more help.

Jeremy Davis's picture

Jeremy Davis - Tue, 2017/04/04 - 07:51
That's awesome! Thanks so much for helping Preston out. My knowledge is broad but not very deep. It's also very Linux/TurnKey centric.

Its so awesome when community members who have deeper knowledge, can help each other out! So you rock and thanks again! :)

Add new comment