1. Introduction

Welcome WANdisco Subversion Access Control admin guide. Subversion Access Control is a network proxy that provides Subversion Administrators with a comprehensive, easy to setup security agent that offers the following capabilities:

• Managing Subversion access across multiple SVNROOTs and modules
• Totally customizable access control using folder-based rules
• Define privileges using hierarchical groups
• Define bundles of privileges using roles
• Ability to limit access on the basis of network masks/IP addresses
• Build access rules using Perl-style regular expressions.
• Reporting available for defined privileges for all users and groups

1.1 Technical Overview

Subversion Access Control works as a proxy between Subversion users and the Subversion server. Subversion users connect to Access Control using the standard port 80. Access Control relays user interactions to the Subversion server using port 81. Subversion users never have direct access to Subversion, allowing administrators to keep control over their Subversion repositories.

1.2 Access Control Model

Access Control uses Apache's 'mod_authz_svn' module to apply path-based authorization of Subversion repositories through an authz configuration file. Path-based authorization uses the repository's directory structure as the basis for permitting or denying specified users or groups of users read and or write access to repository files and folders. Through sets of user-created rules, precise control can be applied to what a user can access or overwrite. The limitation of path-based authorization is that once a user is granted permission to access and write to a particular path (directory), it's only possible to limit authorization to a specific file using rules based on regular expressions.

To some extent, running with path-based authorization should therefore dictate how repository files are arranged, ensuring that sensitive material is secured within subdirectories.

Specific permissions overrule inherited permissions.
Access Control tries to match the path itself, and then the parent of the path, then the parent of that, and so on. The net effect is that mentioning a specific path in the access file will always override any permissions inherited from parent directories.

Authz

Subversion's authz (authorization) implementation requires that your group definitions be defined within the authz file. As authz is unaware of Access Control (or any other third-party data stores), Access Control writes all user grouping and user permissions to the authz file. For more information, read our Knowledgebase article, Introduction to Authz.

How we apply rules when authz is not enabled

authz and regular expression based Access Control rules
If you use authz to manage user authorization through Apache you need to be aware that Access Control rules that use regular expressions to define resources are not supported by authz so won't be written to the authz file.

Access Control rules that contain explicit resource paths will apply only to an exact match of the path.

e.g.

With authz enabled,

/svn/repo_1/folder_a/.* RW (applied to all folders and files)

Will be treated as:

/svn/repo_1/folder_a/ RW (applied to all files but not subfolders)

This rule:
"svn/repo_1/folder_a RW"
applies the read/write privilege ONLY to "folder_a" and will not apply to any subfolders. In order for a rule to also apply to subfolders it must use a regular expression to match all the parent folder's contents, e.g.:

/svn/repo_1/folder_a/.* RW
The wildcard .* will ensure that the rule applies to everything within "folder_a".

Important Clarification on how regular expressions are implmented

The implementation of regular expressions works predictably against "write" operations. However, when performing bulk updates, Subversion will only present the top-most path. So the implementation will not prevent "read" operations from returning repository objects that would be blocked if that path in question had been referenced as a top-most path.

Example

If a rule is coded to prevent an account from accessing "/svn/repo_1/trunk/special_path/.*" and the user requests an "svn checkout" of "/svn/repo_1/trunk" then the "/svn/repo_1/trunk/special_path" (and all descendants) will be included in the checkout.

The only currently available mechanism for limiting read access on bulk updates is the use of the authz module, but the use of regular expressions are not supported when authz is used.

1.3 Important Terms

In this guide we'll refer to a number of concepts that you might not have previously encountered. Reading through this list will help ensure that you understand exactly what we mean when we use them:

Authz

The Authz gives you directory-based control over where each user can access. It's an effective means of securing areas of your Subversion repository from unauthorized access or change. Read Setting up Authz

Login ID

The actual Subversion account name that can be successfully authenticated by Subversion or SSH daemon (if using the ext SSH protocol). The Subversion login id is also the primary key for a user in the Access Control user database.

Principal

Principal can be any valid user or group. After authentication, Access Control maps a login id to a set of rules that include the actual user and all its associated groups and sub-groups.

Resource

Resource is a Subversion repository-based file, directory, module or the SVNROOT itself. Resource patterns can be specified as Perl-style regular expressions that are tied to access rules. All directory paths should be specified in the slash-terminated form. For example, specify /a/b/c/, not /a/b/c.

Alert
The use of regular expressions to define access control patterns is not supported if the authz module is enabled.

IP Mask

A Perl-style regular expression specifying the Subversion client's IP address. It is used in Rules that you wish to apply only to a matching client network, subnet or a machine.

member

A user who is associated with an Access Control team.

Team

An collection of Subversion users who are organized into a group based on some arbitrary criteria such as location, type of work, etc.

subteam

A subteam is a team that is created from members of a parent-team.

Permission

Permissions are resource related privileges needed by a user to execute specific Subversion commands. WANdisco Access Control supports these privileges: List, Read, Write, Copy, Delete, Admin

delegated administrator

It is now possible for a system administrator to give a user sufficient permissions to manage the members of a subteam. In large teams of far-flung developers this is a great boon as it can great reduce the workload of senior systems administrators who can have much of the day-to-day user management handled by team leaders and senior developers.

Node

The node is the server on which the WANdisco Access Control proxy software has been installed.

GUID

Globally Unique Identifier. WANdisco Subversion Access Control assigns a GUID to the Access Control node.

prefs.xml

The preferences files contain information on the Access Control. The preference file is located in svn-security/config.

1.4 Key

Throughout this document we'll highlight things using the following types of information box.

Alert
We use alerts to highlight something we think is important for you to know.

Caution
The stop symbol is used when we want to caution you against doing something.

Tip
Tips are principles or practices that you'll benefit from knowing or using.

Knowledgebase
The KB symbol indicates that you can find out more about the subject in our online Knowledgebase.

uber
Tips that relate using Access Control with WANdisco's ubersvn.

3. Using Access Control

This part of the Access Control Admin Guide will show you how to get started as an Access Control administrator, setting up teams, subteams and Access Rules for your Subversion users.

3.1 Managing Users

This sectio covers how, as an administrator, you manage Subversion users through Access Control. There are three approaches:

• Subversion users are managed through the Subversion password file.
• Allow Access Control to manage the Subversion password file. In doing so, all user changes should be handled using Access Controls browser-based admin console. See 3.1.1 Password file control
• Enable LDAP/Active Directory and handle user changed through your organization's LDAP system. It's also possible to manage.

3.1.1 Password file control

During installation you choose whether to have Access Control take control of each Subversion repository's password file.

If Access Control is managing the password file:
New users entered into Access Control automatically gain access to Subversion using the same authentication details.

If Access Control is not managing the password file:
New users created in Access Control must also have accounts (with identical details) created in Subversion.

If a user reports of getting an Access Denied message on their client, check they have been regisered on both Access Control AND Subversion.

3.1.2 Updating Subversion Passwords

How user's update their passwords will depend on how you set up 3.1.1 Users can update their passwords from the login screen:

• 1. Bring up the admin console in your browser

  http://<Access Control IP>:6444/

• 2. The admin console will appear. Click on Change User Password.
  
• 3. Enter your username, current password and click Login.


• 4. The Change Password box appears. Users can enter their Subversion username, and their password (which is now their email address). Have them enter a new password and confirm it, then click Change Password.
  
  The user's password will now be updated.

3.2 Creating Users

Use this procedure to manually add new Subversion users to Access Control. To add users en bulk, see 3.2 Importing Users.

• 1. Login to the admin console and click create User on the side menu of the Security tab.
  

  



• 2. Enter the new users's details into the form. If you are logged in as a system administrator you are able to create additional users with system administrator privileges by ticking the " Administrator" check box. This option is not availabe to team leaders.
  For more information, see Create Users.
  

  

3.3 Importing Users

The option is available to bulk import users in a comma delimited file, instead of entering them individually using the Create User screen.

Caution importing users to subteams
You can import users straight into teams by including an optional team name field (see the format, below). This will allow you to import to either top level teams or subteams if the subteam has a unique name.

Unique team names are only enforced at the top level and within each parent team. It's therefore possible to have two teams called "QA", so long as they are subteams for different parent teams. Importing a user to "QA" team when there is more than one "QA" team will result in the user being placed unpredictably into one of the teams.

Upgrading Subversion Access Control 4.1 to 4.2

If you are upgrading from 4.1 to 4.2 you will need to convert the access-control.xml file. To do this navigate to the backup folder you created through the System 4.2.9 Export Settings.

Then run perl /opt/svn-security/utils/convertacl41-42.pl access-control.xml. A new file convert-access-control.xml will be created in the same folder. Use this file for the following steps. Please note that running the script from any other folder will not work.

• 1. Create a comma delimited (CSV) file containing your users, using the following format:

  <username>,<first name>,<last name>,<email address>,<password>[,<team name>]

• 2. Log into the admin console and click on Import users on the side menu of the Security tab.
  

  

• 3. Click on the Browse button and navigate to your import file. When selected click the Import button. A growl message window will appear, that indicates the status of the import.

3.4 Creating Teams

Teams are the basic unit of organisation within Access Control. All access policies are applied to teams. TO apply permissions to a single user, you will need to add the user to a team, even if the team is used only for that one user.

• 1. Click on the Security tab and then on the Create Team link.
  

  

• 2. Enter the new team's details, including a name, a description then add users and resources. Click Create Team when you're ready. Read more about the Create Team screen in the Admin Console Guide.
  

  

Team Names Must Be Globally Unique
All teams must have a unique name within Access Control. It's currently not possible to have two teams with the same name, even if they are located within different directories.

3.5 Working with Rules

Team rules are the business end of the Access Control system, they define how a user who is a member of a team can interact with specific repository resource. A single rule can be useful in itself but the real power of Access Control comes for applying complex policies through a number of rules. The procedure below runs through the creation of a rule, and explains how it's applied.

Access Control applies three rules which define how rules are applied and interact:

No Permission by default: Access Control initially does not allow any user access to any resource. By default, all users are denied. This is essential for security: it closes the window of vulnerability that would allow everyone full access between the time WANdisco is first installed and the time it takes an administrator to create access rules. In order to grant access, the administrator has to explicitly create roles, groups (which define resources) and users.

No associated rules, no access
Newly setup users who report that they're unable to access Subversion may simply not have been assigned sufficient permissions.
Unless you associate access rules to a user either directly or through membership of a team they'll have no repository access.

Parent Directory Inheritance: team members automatically gain membership of subgroups created under their team. As a result they'll get access to all resources available to the subteam. So, access is controlled down the directory tree, while inheritance, goes up the directory tree.

Specific permissions overrule inherited permissions.
Access Control tries to match the path itself, and then the parent of the path, then the parent of that, and so on. The net effect is that mentioning a specific path in the access file will always override any permissions inherited from parent directories.

3.5.1 Understanding Permissions

A user will need to have a certain level of permission on a file before they're able to perform a particular Subversion command. Check the table below to see how Access Control permissions correspond with Subversion Commands:

Permission Required = minimum permission needed to execute the corresponding Subversion command.

3.6 Creating Rules

• 1. Login to the admin console, click on the name of the team for which you wish to add a new access rule. In this example we'll create a rule for senior Red Team developers that ensures that they have read/write access to all the Red Team code. For extra security, application of the rule is restricted to the IP range from which only these developers access Subversion.
  


• 2. On the Team screen, click the Rules tab.
  


• 3.On the Rules tab click on the Create Team Rule button.
  


• 4. On the Rules tab, enter the following details:
  
  

  Rule Name*

  (Required Field) A name for the rule. In this example we'll name the rule ReadWriteAllGreenCode. With you are planning on creating a lot of rules it may also be worth adding some reference to which users for which the rule will applied.

  Users this rule applies to:

  Enter or browse for users that this team rule will be applied to. The available users will be limited to the team's members.

  Define Resources/Paths/Regular Expressions for this rule:

  Enter or browse for repository resources, or type in a regular expression that defines the parameters for resources that should be added. In this example all directories within the zelenyj directory are added, along with Read/Write permissions.
  

  authz and regular expression based Access Control rules
  If you use authz to manage user authorization through Apache you need to be aware that Access Control rules that use regular expressions to define resources are not supported by authz so won't be written to the authz file and the regular expressions are not checked by the proxy.

  IP Addresses this rule applies to:

  Enter an IP address or an address pattern defined in a regular expression to appy the rule on the basis of the connecting user's IP address. In the example we'll use a regex that limits application of the rule to a small IP range that corresponds with the assigned users. This ensures that even if unauthorized users gain one of the team member's access credentials, the access rule will not be applied unless they access from the authorized user's IP.

  
  

Once all the rule details have been added, click the Create Team Rule button.

• 5. Check that the new rule now appears on the Rules panel on the team Summary tab.
  
• 6. Team rules can conflict causing unexpected results, so Access Control lets you test that a user has the right access and authorization for a given resource. In this case, one of the user's tied to the rule is checked against the "red" directory. The user's Read/Write access as a result of the application of rule RedTeamLeaders-AllReadWrite is confirmed.
  
  

3.7 Creating Subteams

Subteams are teams that have been created under a parent team. The users and repository resources available to a subteam are limited by those that appear in the parent team (which could itself be a subteam). Subteams allow system administrators to delegate responsibility for managing user access for a segment of their repository resources, without having to hand out total control of the repository to subordinates. This is very helpful for organisations working with satellite development sites where managing day-to-day access changes can be made difficult by the distance and time-zone difference between sites.

• 1. Login to the admin console and click on the Actions drop-down button that corresponds with the team for which you want to create a subteam. From the Actions, select Create Subteam. You can also create a subteam from a team team's screen by clicking on the Subteam tab.
  


• 2. On the Team or subteam screen, click the Create Subteam button.
  


• 3. Complete the subteam entry fields, following the same process that was used for setting up parent teams (See Create Team).


When all the users and resources have been added, click Create Subteam.


• 4. The subteam has now been created. The screen will update to show you the summary tab of your new subteam. Remember, unless you create some rules for the new subteam, it doesn't affect how the team members interact with Subversion. So once a subteam has been created, you'll need to add rules. See Creating Team Rules
  
  

3.8 Testing User Access

A Subversion user environment that requires complex access policies across large numbers of repository resources can require the creation of a lot of team rules. When users belong to multiple teams and have their access controlled by many rules it's possible for a user's access to a particular resource be mistakenly blocked. The Lookup/Search tool lets users identify which rules prevail for a given resource.

• 1. Login to the admin console and click the Lookup/Search link.
  


• 2. Enter the username of the user that you want to test, and the repository resource that you want to check against for access rules. Then click Lookup.
  
  


• 3. The Lookup results will display at the bottom of the screen. They will show whether your selected user has either read or write permissions for the specified resource and from which rule and which team the rule is applied.
  
  

3.8.1 Exporting/Importing Access Control Settings

Subversion Access Control Export Settings tool, situated under the System tab is used to backup all of Access Control's settings (although not the Subversion repository data). This includes the users, teams and rules. See Export Settings.

3.9 Access Control Examples

3.10 Using LDAP/Active Directory

What follows is a an example setup of an LDAP group withing Access Control (this should work much the same for connecting to an Active Directory service).

• 1. First, browse to your LDAP server and confirm that you're users are set up and ready to be sync'ed with Subversion Access Control. In this case we're going to be adding a group called "Dharma Initiative" which has a Distinguished Name of:
  

  cn=Dharma Initiative,dc=wandisco,dc=com





• 2. Login to Access Control's admin console, which will display the Security Tab tab. Click on the Create LDAP Authority link.
  
  
  
• 3. Enter the details for an LDAP search operation that will retrieve your Subversion users from your LDAP server. This is mainly through the LDAP URL which has the format:

  ldap://host:port/dn?attributes?scope?filter?extensions

  In this example we're using the distinguished name of the Dharma Initiative, as described in step 1. See 4.1.6 Create LDAP Authority for a more detailed explanation of the entry fields.
  
  
  
• 4. Click on the Test Connection button to verify that the details that you have entered will successfully connect with your LDAP service.
  
  
  
• 5. Click View Returned Users if you want to confirm that your LDAP query will enter the right user accounts.
  
  You will be presented with a list of users, with their names and email addressed, providing have attribute names that you entered for First Name, Last Name and Email Address match those used on your LDAP server.
  
  In this example we used the following values, obviously these are illustrative as you'll need to ensure that you match with the addressing and attribute names of your own LDAP/AD service. Once confirmed, click the x to close the Retrieved LDAP Users window.
  


• 6. When happy that your settings are correct, click the Create Authority button.
  
  
• 7. You will see an "LDAP Authority ### created." message to confirm that the LDAP settings are in place. You still need to tell Access Control to use the LDAP authority for Subversion authentication. Click the Authenticate using pre-replication LDAP to enable your LDAP settings.
  
  
• 8. The LDAP Authority is now set up to authenticate Subversion users. There are some additional controls and settings available:
  
  

  LDAP admin/team polling frequency: The frequency (in minutes) that MultiSite performs a check of the status of the admins / team members. (Default is 5 minutes)
  
  Continue onto next LDAP authority on user not found: Tick to enable MultiSite to run through all available authorities should a user's credentials are not present on the first authority.
  
  Continue onto next LDAP authority on user authentication: Tick to enable MultiSite to run through all available authorities should a user's authentication fail on the first authority.
  
  Use LDAP authorities to authenticate administrators: Tick to enable MultiSite to authenticate its administrators (users who have access to the MultiSite admin console) via LDAP. This will be automatically be ticked and not editable if System Administrator Group? has been ticked in the authority's settings.
  

  Switching Admin Authorities
  Take note that when you create an additional "Administrator" authority, it will be the exclusive source of system administrators, all previous LDAP or manually specified users will have their privileges revoked.
  
  Disable non-admin users on removal from last LDAP team: Tick to automatically disable users who no longer belong on any available LDAP authority.
  

• 9. Once your LDAP authority is set up you should test authentication of a user to ensure that everything is working as it should.

3.11 Setting up SSL encryption

Subversion Access Control can be set up to use SSL encryption. First you should run through the following steps after extracting the Access Control files (but before running setup).

• 1. Open a terminal and navigate to <INSTALL_DIR>/svn-replicator/config.


• 2. Within /config make a new directory called ssl.
  

  -rw-r--r-- 1 root root  267 May 30 12:01 deletionqueue.ser
  -rw-r--r-- 1 root root  512 May 28 10:38 license.key
  -rw-r--r-- 1 root root 3399 May 14 15:14 log.properties
  -rw-r--r-- 1 root root  763 May 28 11:01 logrotation.ser
  -rw-r--r-- 1 root root  387 May 28 11:00 mailconfig.properties
  drwxr-xr-x 5 root root 4096 May 28 10:40 membership
  drwxr-xr-x 3 root root 4096 May 28 10:40 prefs
  -rw-r--r-- 1 root root 2727 May 14 15:14 prefs-template.xml
  -rw-r--r-- 1 root root 2811 May 28 10:59 prefs.xml
  drwxr-xr-x 3 root root 4096 May 28 10:40 scm
  drwxr-xr-x 5 root root 4096 May 28 10:40 security
  drwxr-xr-x 2 root root 4096 May 28 11:01 sessions
  
  [root@Centos-71 config]$ mkdir ssl



• 3. Go into the new directory.
  

  cd ssl



• 4. Copy your private key into the directory. If you don't already have keys set up you can use JAVA's keygen utility, using the command:
  

  $JAVA_HOME/bin/keytool -genkey -keyalg RSA -keystore <PRIVATE KEY> -storepass <YOUR PASSWORD>

  Knowledgebase
  Read more about the Java keystore generation tool in the KB article - Using Java Keytool to manage keystores

  -genkey

  Switch for generating a key pair (a public key and associated private key). Wraps the public key into an X.509 v1 self-signed certificate, which is stored as a single-element certificate chain. This certificate chain and the private key are stored in a new keystore entry identified by alias.

  -keyalg RSA

  The key algorithm, in this case RSA is specified.

  <PRIVATE KEY>

  This is file name for your private key file that will be stored in the current directory.

  - keystore <YOUR PASSWORD>

  This provides the keystore with a password.

  
  

  If no password is specified on the command, you'll be prompted for it. Your entry will not be masked so you (and anyone else looking at your screen) will be able to see what you type.

  Most commands that interrogate or change the keystore will need to use the store password. Some commands may need to use the private key password. Passwords can be specified on the command line (using the -storepass and -keypass options).
  However, a password should not be specified on a command line or in a script unless it is for testing purposes, or you are on a secure system.
  

  The utility will prompt you for the following information

  What is your first and last name?  [Unknown]:  
  What is the name of your organizational unit?  [Unknown]:  
  What is the name of your organization?  [Unknown]:  
  What is the name of your City or Locality?  [Unknown]:  
  What is the name of your State or Province?  [Unknown]:  
  What is the two-letter country code for this unit?  [Unknown]:  
  Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct?  [no]:  yes
  
  
  Enter key password for <mykey>
  (RETURN if same as keystore password):
  

• 5. With the keystore now in place the setup will automatically pick the file up if you tick the Use SSL checkbox, during or after installation (see 4.2.5 SSL Settings).
  
  Changes in these value require a restart. Any invalid value will restart the replicator and no DConE traffic will flow.

SSLv3 is support (though not enforced). If your browser setting has SSLv3 disabled, you will get a handshake error message. If it has both SSLv3 and TLS enabled, then, depending on the browser, it will try to switch from TLS to SSLv3 during the handshake. If you receive a handshake error message in your browser, make sure that TLS is disabled and only SSLv3 is enabled. All current browsers support SSLv3.

3.11.1 Setting the server key

In the keystore, the server certificate is associate with a key. By default, we look for a key named server to validate the certificate. If you use a key for the server with a different name, enter this in the SSL settings.

3.11.2 SSL Troubleshooting

A complete debug of the SSL logging will be required to diagnose the problems. To capture the debugging, run the java process with:

'-Djavax.net.debug=all' flag.

To enable the logging of SSL implemented layer, turn the logging to FINEST for 'com.wandisco.platform.net' package.

3.11.3 Using SSL for both LDAP and emails

If you're specifying secure email (using a truststore) and LDAP authentication over SSL (using a truststore), the same truststore must be used for both sets of certificates. If different truststores are used then the LDAP truststore will overwrite the email truststore and secure emails will stop working.

4. Admin Console Guide

Welcome to the admin guide for WANdisco's Subversion Access Control. This guide will help you take control and manage the access of your Subversion repositories.

Access Control has a browser-based Admin Console for making user access changes, changing settings or viewing system logs.

Connecting to the Admin Console

Connect to the Admin Console through a web browser, using your server's hostname or IP address, along with the administration port (defaults to 6444).

On connecting you'll be prompted for a login. The default admin username is admin and the password is specified during setup. This section will run through the different screens available in the Admin Console, explaining what they do.

4.0.1 Admin console key

The admin console screen consists of the following elements:
Top menu bar: includes the product license and any expiry date, along with links to documentation and support.

Section tabs: The admin consoles different sections are seperated on tabs. They consist of the following sections:

Alert
The layout and features available in admin console alter depending on your license agreement. So you may not see all the elements described in this guide.

• Security appears if you have a license for the Access Control feature that may be bundled with Subversion MultiSite. If not, the tab is called "Users" and provides functions relating adding and managing Subversion users.


• System: Various housekeeping features are handled withing the System Tab. This includes a log viewer and settings exporter.


• Proxy: The proxy tab is the business end of the admin console. It provides access to the Subversion settings and controls to the Access Control proxy.

Section menu: Appears on the left-hand side and contains links to features that are specific to the tab.

Product version line appears at the bottom of the screen and shows the product version and build, the version of Java installed and the operating system.

4.0.2 Login

On the authentication screen there are a number of links available, even if you don't login.

Quick Links

Proxy Status - Proxy Status Displays the node's status in the tab's main panel.
Change User Password - Follow this link to change the password of a User, it's not used for changing the Admin password.

4.1 Security

The security tab handles all user related functionality.

Tip
The Security tab features product capabilities that are available when the Access Control product has been bundled with Subversion MultiSite. The documentation for using Access Control can be found in the User Guide Section.

4.1.1 Create Team

In Access Control a Team is a group of users who are associated with a resource or collection of resources. Teams underpin how user authorization is managed in Access Control.

Name*

A name by which Access Control will refer to the team. A Team name can consist of letters numbers and spaces.

Team Names Must Be Globally Unique
All teams must have a unique name within Access Control. It's currently not possible to have two teams with the same name, even if they are located within different directories.

Description

A description of the team. This can help distinguish the team, possibly referring to the team's purpose or location.

Add Users

Enter usernames into the "Add Users" entry field, will make the user appear. Entering a letter into the field will result in all users whose usernames begin with that character being listed under the entry field.

If you prefer, instead of entering the username of each user you wish to add to the team, you can click the Browse button and select from all available users by ticking check boxes. Tick those users that you want in the team, or if you're adding a lot of users it maybe be faster to click Select All then untick users that you don't want to add. When you've finished selecting users, click the Save button.

Add Resources

Resources are repository folders. Browse the repository and select a folder, or type in the directory path and click the Add button.

Adding a resource to a team doesn't automatically provide the team's members with authorization to access the resource, first Team Rules must be created that will set the specific permissions for selected team members.

4.1.2 List Team

List Teams is the default screen of the Security tab. All teams and subteams are listed, along with the number of users in the team, the number of sub teams and the number of team rules that apply to the team /sub team.

You can view a team by clicking on it's name. You can edit a team's settings by clicking on the Actions drop down and then clicking Edit.

4.1.3 View Team

The details of a team can be viewed by clicking on the team's name on the List Teams screen. This will show the team's summary tab which shows the teams details. The summary screen doesn't allow any changes to teh team to be made directly, instead, click on the tab that correspond to the property that you wish to change.

Team Leaders

Lists users who have been assigned as Team Leaders to the team. Team Leaders are able to manage the team's settings, adding or removing users, team leaders or repository resources.

Add Team Leaders -
Open a dialog box for adding additional team leaders.

Default Team Leader Permissions.
When you make a user into a team leader, you enable them to change the team's setup. However, they need to be further assigned specific permissions to Create Users, Create Subteams and Disable users. See the next section for how to enable Team Leader User permissions.

Manage Team Leaders
Open a dialog box for changing team leaders' permissions, or removing team leader status.


From the Manage Team Leaders dialog you can remove a user's team leader permissions or enable/disable the following user permissions:
Create Subteam - Enable the team leader to further delegate a team by creating a subteam, assigning users, team leaders and repository resources from those available in the parent team.

Create Users - Enable the team leader to add new user accounts.

Disable Users - Allow the team leader to disable Users. A disabled user will appear within the team's user list, but will be prefixed with a (D). A disabled user will have all SVN permissions removed. It's not possible to selectively disable a user's access, a disabled users will be disabled in all teams.

Team Members

Team Members lists all users who are currently assigned to the team.

Create user - Create a new new users that will automatically be added to the team. See Creating Users for information.

Add Team Members - Add an available user to the team. Only users who are present in the parent team can be added.

Manage Team Members - The Manage Team Members dialog contains tabs to Enable Users, Disable Users and Remove Users.



Manage LDAP Settings - This option is avaible if you have at least one LDAP server added.

Resources

The resources tab lists all repository directories that are associated with the team. Team members do not have access to these resources by defaut; a team leaders or system administrators must first create rules that specify which team members can access the resource, along with a file permission (write access or read-only).

The Resources tab has two buttons:
Add Team Resources -
Opens a browse window to the repository file system from where a directory can be selected.

Delete Team Resources -
Directories can be removed by clicking on the blue crosses, then confirming the deletion.

Rules

The Rules tab shows all existing rules associated with the team. You can view a rule's settings by clicking on the team's name. You can create a new rule by clicking onCreate Team Rule or delete a rule by clicking on Delete Team Rules, then selecting the rules that you wish to delete.

Subteams

The Subteams tab lists all subteams that have been created under the current team. The list of subteams will work as a 'tree view', allowing you to toggle the visibility of subteams by clicking on the parent team.

It's possible to subdivide teams into smaller 'Subteams', which allows you to delegate areas of team resonsiblities to deputies. A subteam can only consist of users from the parent team, plus whatever resources are available in the parent team. Click Create Sub Team if you would like to delegate some of your users

Create Team Rule

Rules are used to control how team members (either all of them, or a subset) are able to interact with the team's allocated repository resources.

Denied by default
In the absense of any team rules, all team members are denied access to all repository resources. This might seem like 'bunker mentality' but it's the only sensible strategy for ensuring that a repository's data is secured against unauthorized access.

Team Setting Tabs

The tabbed side panel lists the team's members, the subteams and the associated Team Rules. It's possible to edit these settings by clicking on the Edit button at the bottom of the main panel.

Edit

Click the Edit button to make changes to the Team. Clicking this button has the same effect as clicking on the Edit Action on the Team List screen.

3.2.2 Edit Team

The Edit Team screen lets you make changes to an existing team.

Team Leadership

Teams and subteams can be assigned Team Leaders with delegated authority over the team. Any number of team leaders can be assigned, but they must themselves first be members of the team.

• Create Sub Team The team leader is able to created a subteam of their team (or subteam). This ability works only within the team, it won't allow the team leader to create a brand new root-level team. Only a user with System Administrator permissions is able to do that.


• Add User The team leader is able to create additional users to add to the team.


• Disable Users The Disable Users facility allows a team leader or system administrator to temporarily remove a user's access to Subversion and the Subversion MultiSite admin console.

  Disable User is universal
  It's important to realise that Disable Users doesn't currently work on a per team basis, and that a team leader who disables one of their team members will also disable the user in all other teams in which the user belongs.

Repositories / Path / Regular Expression

Add repository resources to the subteam. The available resources are limited to those available in the parent team. Resources are added by entering a path or regular expression (if you're not using Authz) in the entry field. It's possible to use the browse button to navigate through the file structure of the available resources. Click Add to add a resource to the subteam.

Team Settings Tabs

The side panel offers tabs for Users, Team Structure and Rules.

Users

• Add User(s) to Team: Click to open a selection window in which all available users are available to pick. Only users who are members of the parent team will be available.
• Remove User(s): To remove users, tick their corresponding check box and click the Remove User(s) button.

Team Structure

• Create Sub Team: Click to create a new subteam which will be a child of the currently viewed team (this will also be the top team on the Team Structure list).

Rules

• Click on a team rule to view or edit its settings.

3.2.3 Create Sub Team

The Create Sub Team screen works the same way as the Create Team screen, except that the resulting team can only draw upon the users and resources that appear in its parent team. The parent team is noted at the top of the screen.

Sub Team Name*

(Required Field) A name for the subteam.

Sub Team Description

A description to help distinguish the subteam.

Add Users

Type in or browse for users to add to the team. The available users are limited to members of the parent team. If you need to add a user who is unavailable to select, you should first add them to the parent team.

Add Resources

Type in or browse for repository resources or enter a regular expression that will select resources based on the expression's parameters. See limitation concerning the use of regular expressions for this, if Authz is used. Click Add to add the resource to the subteam.

3.2.4 Create Team Rule

Team rules are used to specify what permissions that some or all of the team's users have on some or all of the team's available reponsitory resources. Again, you'll only be able to specify users and resources that are available to the team or subteam.

Rule Name*

(Required Field) A name for the rule. Depending on how large and complex your Subversion environment is, it it's possible that you end up with lot of rules. So it's a good idea to give your team rules names that help explain their function.

Users this rule applies to:

Enter or browse for users that this team rule will be applied to. The available users will be limited to the team's members.

Define Resources/Paths/Regular Expressions for this rule:

Enter or browse for repository resources, or type in a regular expression that defines the parameters for resources that should be added, providing that authz is not enabled. The available resources will be limited to those that are included in the team.

IP Addresses this rule applies to:

Enter an IP address or an address pattern defined in a regular expression to appy the rule on the basis of the connecting user's IP address. This feature is useful as it can add an additional check that a logged in user is connected from an authorized computer or network location, but take note that the use of regular expressions in this area is not supported if authz is enabled.

3.3 Create Users

The Create User screen is used to add a new users to the WANdisco MultiSite, which will, providing that MultiSite is managing the Subversion password, also give the user access to Subversion, subject to whatever teams and team rules are applied to the user.

Username*

The user's system name.

Password*

A password that the user will use for authentication.

Confirm Password

Re-enter the password to ensure that it was typed in correctly.

First Name

The user's first name.

Last Name

The user's last name.

Email

The user's email address.

System Administrator

The System Administrator check box is only present when a system administrator is creating the user, it will not be available to team leaders who have the permission to add users. Ticking the box will give the new user permissions to use and modify anything in the WANdisco Subversion MultiSite admin console.

Assign User to Team(s)

You can immediately add a new user to an existing team or teams by entering the team name in the entry box.

User View

Use the Edit User screen to modify the user's account details.

Username*

The user's assigned username. This is shown for reference, it's no longer editable. The only way to change a username is to create a new account for the user, then delete old account.

First Name

The user's first name.

Last Name

The user's last name.

Email

user's email addresse.

System Administrator

Check box to enable the use to have full control over the MultiSite admin console.

User Disable

Check box to disable the user's account. When disabled a user is unable to access any resource, through any of the teams of which they are a member. It's not possible to selectively disable a user; if you want to disable a user from a single team (or subset of teams), remove them from the team instead of disabling them.

Team Membership

Lists all the teams of which the user is a member. You can remove them from a team by deleting the team from the list.

Reset User Password

The Rest User Password lets you change a user's password.

New Password

Enter a new password.

Confirm New Password

Re-enter the new password, then click Save to complete the password change.

The user view is available if you click on a username anywhere in the admin console. It lists all the user's details, the teams to which they belong, as well as their System Administrator status, and whether their accoutn is currently disabled. When viewed as a team leader or system administrator, there will also be an Edit button to enable you to make changes to the user's account.

Edit User

The Edit screen lets you change of the user's account entries, enable or disable System Administrator permission, disable or re-enable the account.

4.1.4 Import Users

It's possible to import users instead of entering them manually through the Create User screen. Use a comma delimited (CSV) format for the import, with the following fields:

<username>,<first name>,<last name>,<email address>,<password>[,<team name>]

Click on Choose File and navigate to your import file. When selected click the Import button. A message window will appear, indicating whether the import was successful.

Caution importing users to subteams
You can import users straight into teams by including an optional team name field (see the format, below). This will allow you to import to either top level teams or subteams if the subteam has a unique name.

Unique team names are only enforced at the top level and within each parent team. It's therefore possible to have two teams called "QA", so long as they are subteams for different parent teams. Importing a user to "QA" team when there is more than one "QA" team will result in the user being placed unpredictably into one of the teams.

4.1.5 Lookup/Search

The Lookup/Search tool lets you test a user's access permissions for a specfied repository resource. For users who are members of multiple teams and to whom numerous team rules are applied, the Lookup/Search greatly simplifies the verification of their access permissions.

Username

Enter a username on which to perform a permissions review.

Resource

Enter a repository resource / path for which you want to test the above user's access

Click Lookup to initiate the test. The results are presented as a Read Results and a Write Results. Each result will indicate whether access is granted or denied, and from which rule the permission was granted, and from which team the rule was applied. This is enough information to help you fine-tune permissions without a lot of blind trial-and-error changes.

4.1.6 Create LDAP Authority

It's possible to set up a number of LDAP authorities, if your organisation is runs from more than one LDAP server. Use the Create LDAP Authoritity screen to define your authorities as well as the order in which they are executed.

Order: The priority given to the LDAP URL. e.g. A Location Order of 1 means that Access Control will look within that defined authority for a user first. If unsuccessful then Access Control will then check the authority with the next order number (e.g. 2).

Regular Expression: The regular expression offers a means of limiting the number of queries that Access Control attempts when searching for a user accross the available authorities. For example, if you set up an authority whose users have a specific top-level domain in their email addresses, you can use a regular expression to match them to a particular authorities.

URL: the URL for the LDAP authority, using the format

ldap://host:port/dn?attributes?scope?filter?extensions

[ldap]

URL scheme name: This is nothing more than a url scheme. It will usually be either 'ldap' or 'ldaps' in the event that you're using SSL for accessing your directory server.

host

Hostname: This is the IP address or hostname of your authority's server.

port

port This is the port the server is listening on for LDAP/Active Directory communication. eg. 389

dn?

Seach Base This is the distinguished name to the path in the directory tree that you want to search for users. e.g. [DC=your,DC=domain]

attributes:

[UserName] This is the LDAP attribute that corresponds with the user's login name. This could be their email address or a dedicated account name.

scope:

scope This tells the directory server what type of query to perform.

Filter: [(objectClass=*)]

This tells the directory server to filter the query for objects matching a particular filter. For more details on constructing an ldap URL, which is a standard and not specific to Apache, view RFC 2255.

Bind User DN: (Optional)
Bind Password: (Optional)
First Name Attribute: (Optional)
Last Name Attribute: (Optional)
Email Address Attribute: (Optional)
Case Insenstive Usernames?: Tick this checkbox if you are using an Active Directory service that has been set up to not recognise character case. You will need Access Control to do the same, otherwise it will treat a username that appears with different case patterns as different users.
System Administrator Group?: Tick this checkbox if the authority will return users who are System Administrators (able to access the MultiSite admin console).

Support for Active Directory Nested Groups

Active directory allows the definition of groups that are themselves members of a parent group. This provides the administrator with a useful organizational structure.

We have a query for that

It is possible to handle Active Directory nested groups using the following query (based on the LDAP_MATCHING_RULE_IN_CHAIN OID). it works as follows:

When we run an ldap query to find all the members of a group, we treat all those members as users.
If a group is returned as a member, we run another query to find out the users that are a member of the included group. ascii example:

sanramon (group synchronized to team in access control)
     +- Jon (user)
     +- Kev (user)
     +- support (group)
          +- Gaz (user)

Looking at the above heirarchy which shows the "San Ramon" (sanramon) team, and set a filter to get all users that are members of the 'sheffield' group. Access control will normally create three users in the team: Jon, Kev and support. What this query does is create three users: Jon, Kev and Gaz (through a recursive search of the 'support' group).

Example Query

The query is :

ldap://10.2.2.45:389/CN=Users,DC=sr,DC=wandisco,DC=com?
sAMAccountname?sub?(memberOf:1.2.840.113556.1.4.1941:=CN=shef_devs_grp,OU=Belfast,DC=sr,DC=wandisco,DC=com)

4.1.7 LDAP Settings

The LDAP settings screen contains all the settings for any LDAP services that you use with Subversion MultiSite. By default, LDAP is not activated. Click on Authenticate using pre-replication LDAP to enable any authorities that you've entered in the LDAP Authorities screen.

When enabled, all LDAP authorities will be listed, along with the following options:

Authority Table

Order: LDAP authorities are listed in the order of execution that you set when defining the authorities' properties.
Regular Expression: The regular expression offers a means of limiting the number of queries that Access Control attempts when searching for a user accross the available authorities. For example, if you set up an authority whose users have a specific top-level domain in their email addresses, you can use a regular expression to match them to a particular authorities.

URL: The URL of the authority.
Admin: Authorities that are set to return Admins will show a tick.

Authority Controls

Delete Authorities Select from the list using the checkbox, then click the Delete Authorities button. Using this method to delete multiple authorities in a single action. You can delete a single authority by clicking on its corresponding Actions button and clicking on "Delete".


Note that should you delete the last remaining active LDAP authority you'll see a warning that LDAP authentication will be switched off if you complete the deletion. This is to ensure that you don't get locked out

Test Authorities Use this to verify that Access Control can talk to authority that you select by ticking their corresponding check boxes. On clicking Test Authorities you get a report on the number of authorities to which Accesss Control can successfully connect. Create Authority: To create a new LDAP authority, click the Create Authority button.

Actions: The following, additional actions can be performed on each authority by clicking on the Actions drop-list.

Edit: Edit the authority settings.
Delete: Delete the authority.
Set as Admin Group/Unset Admin Group: Sets or unsets the authority as the admin group.
Change Order: Change the authority's order number to make it execute earlier or later.
Test Connection: Perform a test connection to the authority.
View Members: Connect to the first matching authority and retrieve the selected group members.
Disable Locally: Disable the first matching authority on the current MultiSite node.
Disable Globally: Disable the first matching authority and replicate the action to all other nodes.

LDAP admin/team polling frequency: The frequency (in minutes) that MultiSite performs a check of the status of the admins / team members. (Default is 5 minutes)

Continue onto next LDAP authority on user not found: Tick to enable MultiSite to run through all available authorities should a user's credentials are not present on the first authority.

Continue onto next LDAP authority on user authentication: Tick to enable MultiSite to run through all available authorities should a user's authentication fail on the first authority.

Use LDAP authorities to authenticate administrators: Tick to enable MultiSite to authenticate its administrators (users who have access to the MultiSite admin console) via LDAP. This will be automatically be ticked and not editable if System Administrator Group? has been ticked in the authority's settings.

Disable non-admin users on removal from last LDAP team: Tick to automatically disable users who no longer belong on any available LDAP authority.

Click SAVE LDAP Settings to save any changes you make on the LDAP Settings screen.

4.2 System

The system tab is used to manage system functions such as viewing the Access Control log or importing and exporting user settings.

4.2.1 System

Log Viewer - View Access Controls log file.

4.2.2 Disk Monitor

Set how Access Control monitors disk usage, warning you if the system's available disk space gets too small.

Use disk monitor: Tick the checkbox to have the disk monitor running.

Interval between checks (in milliseconds): 900000 (15 minutes) is the default interval time between checks.

Determine disk state by: Choose to measure disk usage either by percentage used or bytes free (in bytes, or append KB, MB or GB).

Warn Level: State the level of usage (either as a percentage or bytes free) at which point an alert email will be sent, and resent each time the disk monitor completes a check. So, if you set the Interval between checks to 900000 milliseconds, a warning email will be triggered every 15 minutes.

Critical Level: State the level of usage (either as a percentage or bytes free) at which the node will send an alert email and then shutdown. This will prevent the data on the node from being corrupted.

Click the Save Settings button to save any changes you make.

Alert
You MUST restart the node for any changes you make to take effect.

4.2.3 License Info

The License Info page contains the details of your WANdisco product license, useful for confirming the details of a number of license-specific features.
Company: Your company name.

Product: The product type. This is currently either svn (Subversion) or (CVS).

License Type: This indicated whether the license is either for evaluation or production.

Access Control:
Shows if Access Control has been enabled on the product.
Number of Allowed Nodes: Number of replicator instances that have been licensed.

Licensed IP Addresses: The IP addresses of each node.

Number of Allowed Users: Total number of possible users that are covered under the license.

License Expires: The date on which the current license will expire.

Maintenance Start Date: The first date covered by the current maintenance contract.

Maintenance End Date: The final date covered by the current maintenance contract.

4.2.4 System Settings

The system settings screen provides a number of extra controls that allow you to fine-tune Access Control for potential performance improvements.

Enable Access Control Prevayler snapshot:
Tick this option to enable

Run automated backup:
Tick this option to have Access Control automatically run a backup at the end of each day (at midnight). When ticked you can then specify the length of your backup history, which is set at 30 days by default.
To restore Access Control to one of your backup points, use the Import Settings feature.

Enable Audit Trail logging:
Tick this option to record all Subversion activity in the AuditTrail logs. This feature is switched off by default as it creates some additional overhead in transaction processing.

Enable User Access Tracking:
Tick this option to have Access Control save timestamps against each user indicating the last time they interacted with a repository, which can be useful for user management. This feature is switched off by default as it creates some additional overhead in transaction processing.

4.2.5 SSL Settings

The SSL Settings screen controls all settings related to the keystore and truststore management, used when the secure socket layer protocol is used to encrypt traffic between the replicator and clients.

Keystores and Truststores
You might be familiar with the Public-key system that allows two parties to use encryption to keep their communication with each other private (incomprehensible to an intercepting third-party).

The keystore is used to store the public and private keys that are used in this system. However, in isolation, the system remains susceptible to the hijacking of the public key file, where an end user may receive a fake public key and be unaware that it will enable communication with an impostor. Enter Certificate Authorities (CAs). These trusted third parties issue digital certificates that verify that a given public key matches with the expected owner. These digital certificates are kept in the truststore.

An SSL implementation that uses both keystore and truststore files offers a more secure SSL solution.

Use SSL for replication:
Tick the checkbox to enable SSL encryption for Subversion traffic.

Certificate Alias:
The certificate name of the server.

Key Password:
(Optional) password to control access to keys in the KeyStore. All keys in the keystore must have the same password.

KeyStore Filename:
The file in which private keys are stored. Click on the spyglass icon if you need to browse for the file.

KeyStore Password:
Optional password to control access to keys in the KeyStore. All keys in the keystore must have the same password.

TrustStore Filename:
This is the file in which public keys are stored. This can be the same as the KeyStore. Click on the spyglass icon if you need to browse for the file.

TrustStore Password:
Password to control access to the TrustStore.

For more information about running Subversion MultiSite with SSL, see 2.7 Using SSL.

4.2.6 Log Level

Access Control uses one log, and the default level is info. The levels vary from severe, where you get only the most severe warnings, to finest, which logs every action.

4.2.7 Free Memory

This command frees the memory (GC stands for garbage collection and is only applicable when Access Control is used with the Subversion Multisite.) The command occurs on clicking the Free Memory menu link. The display shows information on the command that was just performed.

4.2.8 Backup

The backup settings offer basic backup and recovery features

4.2.9 Export Settings

This command allows you to export WANdisco settings, including all user related data, making it available for restoration at a later date..



The export routine creates a directory containing the files necessary to import user settings back into Access Control. Backup directories use a name string YYYY-MM-DD.HH-MM-SS::XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX ,
e.g. 2012-01-23.16-21-03::2775e033-45b1-11e1-acb4-21d651998aa9

A typical backup directory will look like this:

File properties                                                                
-rw-r--r-- 1 root root 87232 May 30 14:01 access-control.xml
-rw-r--r-- 1 root root   101 May 30 14:01 ExcludeUsersDB.xml
-rw-r--r-- 1 root root   387 May 30 14:01 mailconfig.properties
-rw-r--r-- 1 root root     6 May 30 14:01 MembershipConfigurationRegistry.xml
-rw-r--r-- 1 root root    87 May 30 14:01 NewUsersDB.xml
-rw-r--r-- 1 root root   809 May 30 14:01 NodeRegistry.xml
-rw-r--r-- 1 root root  2440 May 30 14:01 NonResettableDynamicPreferences.xml
-rw-r--r-- 1 root root  2811 May 30 14:01 prefs.xml
-rw-r--r-- 1 root root   162 May 30 14:01 RepoSettings.xml
-rw-r--r-- 1 root root  1162 May 30 14:01 Repos.xml
-rw-r--r-- 1 root root     6 May 30 14:01 ViewRegistry.xml
[root@10-2-5-145 2012-05-30.14-01-50_41e13ec5-a8ab-11e1-a03f-515d761f3659]#              

On a successful export you'll see a confirmation message that verifies the location and name of an export directory.

4.2.10 Import Settings

This command allows you to import WANdisco settings, including all users.

4.3. Proxy

The Proxy tab handles Access Control proxy settings which alter the way that Access Control works between Subversion and users.

4.3.1 Status

Proxy Status - Displays the node's status in the tab's main panel.

Click on the change proxy or admin port link to change either the port that Subversion clients will use to connect on, ot the admin port that is used to access the admin console (6444 is the default).

uber
When using Access Control with ubersvn, be aware that changing the proxy or admin port will stop the Access Control API from working properly - objects created/linked in uberSVN will stop being carried over into Access Control.

        workaround: After changing the Access Control port (Default:6444), open the file ubersvn/plugins/accesscontrol/uber-plugin.xml and update it to reference the new port number.

4.3.2 Log Viewer

You can view the logs, including the main log - SVNProxyServer-prefs.log.

4.3.3 Node

The Node section deals with settings that apply to the server on which you are running Subversion and the Access Control proxy.

4.3.4 SVN Settings

The SVN Settings section contains many crucial settings for how Access Control will interact with your Subversion server.

Subversion Server Port:

The port on which Subversion is actually running (8080 by default).

SVN Executable

The fully qualified path to the svn executable. On Linux you can run "which svn" to determine the path to the file.

Use authz-based access control?

If you intend to use Apache's authz authorization, tick the check box.

Authorization File:

If you have selected to use authz, enter the path to the authorization file here.

Access Rules when Authz is not enabled
Read how access rules work differently when Apache authz is not enabled - How we apply rules when authz is not enabled

Save Settings

Click to save your settings.

Regenerate Authz File

Should your authz file become Corrupted you can click this button to recreate it using the version stored with the Access Control model.

Regenerate Password File(s)

Should password files become corrupted you can click this button to recreate them using Access Control's database.

Repository List

You can Edit, Delete any of the Subversion repositories that you run behind Access Control - although .

Add Repository: Click to add an additional repositories, either using SVNPath or Parent Path.

Edit Repository

Click on the Edit link to open the repository's settings screen.

The edit repository screen lets you modify a number of repository specific settings:

Directory on File System: This is the fully qualified path to the Subversion repository. Not the URL used by clients. You can seach for the location by clicking on the magnifying glass button.

Manage Password File: There are some big benefits to having Access Control manage the Subversion Password file - with this check box ticked, you can add Subversion users by entering their details via the Create Users screen of the admin console.

Password File: Provide a link to the SVN password file on the local file system.

Authentication Realm: Associate an authentication realm with the repository. You should follow the guidance in the Apache documentation for the AuthName Directive.

DAV Location: the directory in which WebDAV is located.

Multiple SVN Repositories: Choose whether you are using SVNParentPath or SVNPath in the Apache location directive.

If you select Yes, SVNParentPath is used in the apache location directive, you'll be presented with a entry box that allows you to select and edit available Root Names.

4.3.5 Email Settings

The email settings screen stores any settings that you have in place SMTP Authentication: If you select No, you'll need to provide your account.
Username and Password in the following entry boxes.
Use SSL/TLS: Choose yes if you wish to send emails over a secure connection.
Host: Enter the address of your mail server.
Port: Enter the SMTP port, 25 by default.
Send Admin Notification To: The email address (You can only specify a single address, not a comma delimited list) to where notifications will be sent.

Email settings are optional. If you don't need alert emails, click Skip to continue. Otherwise, click Next.

Email settings that Access Control uses to send status alerts.

4.3.6 Stop Proxy

Stops Access Control and prevents client access.

4.3.7 Shut Down Node

Shuts down Access Control completely.

Copyright © 2010-2015 WANdisco, Inc.
All Rights Reserved

This product is protected by copyright and distributed under licenses restricting copying, distribution, and decompilation.