I have been set the task of setting up SVN and connecting Authentication and Authorization to our MS Active Directory system. The SVN is now running on a Debian Linux server. I have successfully set up Authenticated to authenticate users who have access to the SVN system based on a Security Group in our AD.
The next task is where I am encountering the difficulty is in Authorizing individual users to read and write to the individual repositories. From what I have seen I need I to do this I need a AuthzSVNAccessFile file. However I have not been able to find any documentation on how to accomplish this using AD groups. Below is a simple example.
Let the following users exist. UserA, UserB, UserC, UserD.
Let the following user groups exist. canAccessSVN, canOnlyReadReop1, canReadWriteReop1, canOnlyReadReop2, canReadWriteReop2.
Users UserA, UserB, and UserC In group canAccessSVN.
Let the following SVN repositories exist. (repo1, repo2, sandbox).
UserA is in groups canAccessSVN, canReadWriteReop1, canReadWriteReop2.
UserB is in groups canAccessSVN, canReadWriteReop1.
UserC is in group canAccessSVN, canReadWriteReop2, canOnlyReadReop1.
UserD has access to nothing (this part I have solved using the canAccessSVN in the dav_svn.conf file.
All users should have Read and Write access to the sandbox repository,
UserA should have Read and Write access to both reop1 and repo2 and sandbox.
UserB should have Read and Write access to only repo1.
UserC should have Read and Write to repo2, and read access to repo1.
The trick is I want to do this with the AD groups. I have searched and have not found any reference do controlling this with AD groups in the AuthzSVNAccessFile file.
Any help or pointers to a reference would be very helpful.
Lee
Last time I checked, you can't do authorization via LDAP/AD. Just
authentication. Hence the lack of documentation on the subject.
--
Aaron Turner
http://synfin.net/ Twitter: @synfinatic
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
-- Benjamin Franklin
"carpe diem quam minimum credula postero"
Various wrapper scripts exist which generate an authz rules file
from data pulled from LDAP/AD directories. I agree that it would
be nice to have built-in support for this in mod_authz_svn though.
Stefan
Do you have a link to such a script? I've occasionally looked for one
and never found it... was planning on writing one someday, but no
point in reinventing the wheel.
Google "svn authz ldap" says:
http://www.thoughtspark.org/node/26
This patch to apache httpd also looks interesting:
http://mail-archives.apache.org/mod_mbox/httpd-dev/200912.mbox/%3C4B22C...@gmx.net%3E
Though I didn't check what became of it.
Stefan
Ah, I was hoping to put path/repo information in the LDAP too. More
work, but I'm going to have to basically do the same thing for our
TACACS+ server.
> This patch to apache httpd also looks interesting:
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200912.mbox/%3C4B22C...@gmx.net%3E
> Though I didn't check what became of it.
Interesting... I might have to ping Christian to find out what happened.
Few months ago I was experimenting with this and I found out that it can easily work.
My Apache configuration for the repository contained "AuthzLDAPAuthoritative off" and "AuthLDAPRemoteUserAttribute name". I'm not sure you need AuthzLDAPAuthoritative but it's AuthLDAPRemoteUserAttribute that allowed me to write the access file like this
[groups]
developers = Giulio Troccoli, Harpal Panesar
[svn-test:/]
* = r
svnsync = r
[svn-test:/trunk]
@developers = rw
I'm pretty sure it worked but, as I said, it was few months ago so maybe I just saved this configuration for further investigation rather than for immediate use.
Giulio
Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851 VAT Reg No 778499447
##
## Define the alias of LDAP authentication
##
<AuthnProviderAlias ldap ldap-test>
AuthLDAPURL "ldap://*******/OU=Users,OU=London,OU=North Europe,OU=Regional,DC=ad,DC=linedata,DC=com?SAMAccountName,name?sub?(objectClass=*)"
AuthLDAPBindDN "CN=SA_Subversion,OU=Service Accounts,OU=Global,DC=ad,DC=linedata,DC=com"
AuthLDAPBindPassword ********
AuthzLDAPAuthoritative off
AuthLDAPRemoteUserAttribute name
</AuthnProviderAlias>
##
## Define the alias for SVN Admins authentication
##
<AuthnProviderAlias file svn-admins>
AuthUserFile /usr/local/apache2/etc/svn-admin.passwd
</AuthnProviderAlias>
<Location /svn-test>
DAV svn
SVNPath /data/TestRepositories/svn-test
# Name of the repository
AuthName "Subversion Testing Repository"
# What authentication to use
AuthType Basic
AuthBasicProvider ldap-test svn-admins file
# How to authenticate extra people
AuthUserFile /usr/local/apache2/etc/svn-test.passwd
# Always requier an authenticated user
#Allow from all
Order deny,allow
Require valid-user
# Access Control Policy
AuthzSVNAccessFile /usr/local/apache2/etc/svn-test.access
</Location>
[groups]
developers = Giulio Troccoli, Harpal Panesar
I want to be able to say
developers = CN=*****,OU=Security Groups,... A group I have defined in LDAP.
The groups and user permissions are already defined for other applications
and services and I do not want to have to manage them in LDAP and SVN. Know
of any way of doing that?
> =
Yes, sorry, I misunderstood you. I thought you meant "group" as in "a group in the access file", like the developers group I have.
No, I don't think it's possible. The only way I can think of is the script that Stefan already suggested.
Are you on windows. I think that VisualSVN server supports doing this. However, I'm not sure if the free version supports it. But, I am pretty sure they added this feature... it looks like starting with version 1.5.
Ah yes, from their web site:
---
Configure access permissions
Using VisualSVN Server Manager you can grant or revoke access to specific Subversion sub-trees with the respect to Active Directory accounts. VisualSVN Server is the only Subversion server package that lets you to leverage Active Directory groups (such as standard "Domain Users" or custom "Project Managers").
From a user perspective, access control in VisualSVN Server looks close to the similar functionality in the Windows file system. However, there are significant differences which may cause difficulties for novice Subversion administrators. For detailed description of VisualSVN Server authorization please consider the KB33 article.
When VisualSVN Server is initially installed, access is permitted for all Windows users. So you're requested to grant access to selected users while keeping others from accessing confidential files in your repositories.
---
Once again, I'm not sure if this is in the free version... I'm guessing it is not.
BOb
Works fine for us!
The example below gives all authenticated users access to the "Publications" repository, but only members of the AD group "SOMEAdingGroup" have read-write access.
<Location />
AuthName "Subversion Server"
AuthType Basic
AuthBasicAuthoritative On
AuthBasicProvider ldap
# If ldap checks are to be used with non-ldap checks (like "valid-user"), set this to off
AuthzLDAPAuthoritative off
AuthLDAPURL ldaps://ad.company.com:3269/DC=ad,DC=company,DC=com?sAMAccountName?sub?(objectCategory=user)
AuthLDAPBindDN CN=SOMEADMIN,OU=Users,DC=ad,DC=company,DC=com
AuthLDAPBindPassword secret
</Location>
<Location /svn/Publications>
DAV svn
SVNPath \Repositories\Publications
SVNPathAuthz off
# The following users/groups will have read-write permission
Require ldap-group CN=SOMEAdminGroup,OU=Groups,DC=ad,DC=company,DC=com
<Limit GET PROPFIND OPTIONS REPORT>
# For any read-only operation, allow these additional users/groups
Require valid-user
</Limit>
</Location>
-----Original Message-----
From: Giulio Troccoli [mailto:Giulio....@uk.linedata.com]
Sent: Thursday, April 01, 2010 10:02 AM
To: 'Lee Kaufman'
Cc: us...@subversion.apache.org
Subject: RE: LDAP Group Configuration in AuthzSVNAccessFile
Giulio
-----Message Disclaimer-----
This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to Con...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.
Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.
While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.