Administration Guide

This Admin Guide describes how to set up and use Access Control Plus.

1. Housekeeping

1.1 Starting up

To start Access Control Plus:

  1. Open a terminal window on the server and log in with suitable file permissions.
  2. Run the scm-access-control-plus service from the /etc/init.d folder:
    lrwxrwxrwx  1 root root        65 Apr 24 11:43 scm-access-control-plus -> /opt/wandisco/scm-access-control-plus/bin/scm-access-control-plus
  3. Run the script with the start command:
    [root@localhost init.d]#  ./scm-access-control-plus start
    Starting scm-access-control-plus:. [ OK ]
    Access Control Plus starts. Read more about the svn-multisite init.d script.

1.2 Shutting down

To shut down:

  1. Open a terminal window on the server and log in with suitable file permissions.
  2. Run the svn-multisite service, located in the init.d folder:
    lrwxrwxrwx  1 root root        65 Apr 24 11:43 scm-access-control-plus -> /opt/wandisco/scm-access-control-plus/bin/scm-access-control-plus
  3. Run the stop script:
    [root@redhat6 init.d]#   ./scm-access-control-plus stop
    Stopping scm-access-control-plus:.                         [  OK  ]
    The process shuts down.

1.3 Reporting problems: talkback

WANdisco uses a talkback agent to capture log information to help investigate problems. When you report a problem to WANdisco support, you should run talkback and attach the output file.

  1. Run talkback from /opt/wandisco/scm-access-control-plus/bin.
    Talkback retrieves node details and gathers information. You see a message like:
    THE FILE sysInfo/sysInfo_10.2.5.52-20150122-173254.tar.gz HAS BEEN CREATED BY sysInfo
    Please enter your WANdisco support FTP username (leave empty to skip auto-upload process):
  2. Enter your WANdisco support FTP username to upload the file directly to our support team
    Click Enter to skip auto-FTP upload. You must then manually upload the file, e.g. /opt/wandisco/scm-access-control-plus/, to WANdisco support with a description of the issue.

    Do not email the talkback files
    Upload the files fia FTP or attach them via the web ticket user interface.

1.4 init.d management script

The start-up script for persistent running of Access Control Plus is in the /etc/init.d folder. Run the script with the help command to list the available commands:

[root@redhat6 init.d]#  ./scm-access-control-plus help
usage: ./scm-access-control-plus (start|stop|restart|force-reload|status|version)

start         Start Access Control Plus services
stop          Stop Access Control Plus services
restart       Restart Access Control Plus services
force-reload  Restart Access Control Plus services
status        Show the status of Access Control Plus services
version       Show the version of Access Control Plus

Check the running status (with current process ID):

[root@redhat6 init.d]# ./scm-access-control-plus status
Checking scm-access-control-plus:running with PID 29516    [  OK  ]

Check the version:

[root@redhat6 init.d]# ./scm-access-control-plus version

1.5 Password change/recovery

This section describes what to do if an administrator loses their password and needs to regain entry to Access Control Plus. Currently the method uses a script that resets Access Control Plus's authentication. If you have set up to use LDAP, this will be disabled, returning access to local users. A new administrator-level local user is created with credentials that you supply when you run the script.

Disable LDAP/external authentication
If you need to disable LDAP authentication and return your deployment to the default internally managed users, use the following procedure. Your LDAP authorites will not be deleted, only disabled. They can be re-enabled from the Settings screen.

  1. Open a terminal on your node and navigate to the replicator directory:
    $  cd /opt/wandisco/scm-access-control-plus
  2. Run the following command-line utility:
    [root@redhat6 scm-access-control-plus]# java -jar scm-access-control-plus-resetSecurity.jar
    Enter full path to the replicator properties folder: /opt/wandisco/scm-access-control-plus/properties
    Enter your username: temporary
    Enter your new password:************
    Confirm your new password:************
    Enter your first name: Temorary
    Enter your last name: Account
    Enter your email address:
    A new user has been created, in order for this to take effect you will need to restart this node.
    [root@redhat6 scm-access-control-plus]#
  3. Respond to each prompt.
  4. When you've entered everything, restart Access Control Plus to add the new users.
  5. Log in using the orginal authentication form: Login

2. Accounts

An account is a collection of information that tells Access Control Plus which resources the account holder can access and what level of access they should have. Accounts are the fundamental building blocks for Access Control, although the Access Control model actually handles permissions only on a per-team basis, not directly on individual accounts.

Note: Your license allows a maximum number of accounts. If you exceed this, you receive warnings to remove or disable accounts. If you ignore the warnings for 10 days then ACP goes into read-only mode. Then only administrators, or team leads with appropriate privileges, can remove or disable accounts. See Remove an account.

2.1 Create an account

There are three methods for four routes to create an account. This procedure describes steps to follow after clicking Create User on the Accounts pane that appears on the master screen. You can also create an account from within the Create Team procedure. Usually you will add accounts by setting up a query to an available LDAP authority. To add accounts using LDAP, see Connect to LDAP.

In future, you will be able to create accounts using a REST API.

  1. Log in to Access Control Plus. Click the + Create button on the Accounts panel.
  2. An entry table opens. Enter the account holder's details, as described below.
    First Name
    The acount holder's first name.
    Last Name
    The account holder's last name.
    Account Name
    The account name that Access Control Plus will use internally to refer to the account holder.
    The password for the account (obfuscated entry).

    Caution: passwords cannot contain only numbers
    Passwords can be alphanumeric, containing a mix of letters and numbers, or only letters.

    Confirm Password
    A repeat entry of the password to confirm it was correctly entered.
    Email Address
    The email address associated with the account holder.
    Public Key (for Git or SVN access)
    The account holder's public key when running with Git or SVN that is using SSH authentication. When you copy this into the form ensure that you add no breaks. A key is one unbroken line of characters.

    SSH keys
    To enter or change SSH keys, all users need to use their self-service page. Both LDAP accounts and administrative accounts can update the Public Key field for LDAP accounts. An administrator can edit public keys for local users and LDAP users.

    Disabled (Checkbox)
    Use this checkbox to disable the acount. When ticked the account holder is completely locked out. All authorization is disabled. This feature offers administrators a means of removing access without completely removing an account or messing with rules. The account is effectively disabled from the moment the screen is updated, unless you have batched updates.
    User type
    ACP The User type drop-down menu sets one of the following account types:
    A standard account holder supports all levels of access on all available resources, subject to the rules that apply to the teams for which the account is a member.
    Audit User

    Error message:
    Currently you cannot select this user type. If you do, you receive an error message. This is a known error that we will fix in future.

    An Auditor account can never be granted write permissions. This provides administrators with complete confidence when adding accounts for employees who need access to repository data but who are not qualified to make changes.
    Application Administrator
    This account type is specifically for SCM administrators who will themselves manage Access Control Plus. Administrators can access the admin console and have permissions to change all Access Control Plus settings.
    Update (button)
    Use this button to submit the account details entered into the form, or for that matter any changes that are made during the edit of an existing account.
  3. After entering the account holder's details, click Update to save the changes to Access Control Plus's internal database. The account is ready to add to teams, which will then enable you to apply rules to it, which ultimately provide access control for available SCM resources.

Access to nothing by default
All accounts are created with no access to any resources. For an account to gain access to a repository it must first become a member of a team, then that team must have a rule set up that associates repository resources along with permission levels. For more details see the section about Rules.

2.2 Edit an account

To edit an existing account:

  1. Log in to Access Control Plus and find the account that you want to change:

    Search by filter: Click Filter to show a search entry box. You can select from Name, Username, Email) for the search.

    Manual search: Use the page links at the bottom of the Accounts panel to view the available accounts.

    Selecting an account: Click on the Account holder's name to bring up the account screen.

    An account screen shows the account's team memberships and access privileges:
  2. To return to the account's entry form and make edits click Edit. The main panel lists teams of which the account is a member and lists all rules that currently apply to the account.

    Change teams membership: From the Teams table click a Team name to remove the account from that team or subteam.
    Change a rule: Click any rule in the Rules table to remove the account from the rule.
    Audit accounts need an administrator to change SSH key and password settings! Currently, only administrators can update or delete an audit account SSH key, and change a password. A future release will enable audit account self-service options.
  3. When you have finished working with the account screen, click the tab on the left of the panel to close the screen.

2.2.1 LDAP-based users

The Edit screen is renamed Details for LDAP users because you cannot edit an LDAP-based user through Access Control Plus. If you need to modify an LDAP user you need to go through your LDAP service.


Important: When LDAP authority tries to enter in an account that has a username that already exists on the system
When LDAP sync discovers there is already existing account with the same username it will log a warning and not will synchronize this user. The existing username can be local (entered into Access Control Plus directly) or from different LDAP authority. However, if the user exists in LDAP and can authorize against SVN, then it will get in and Authz will apply any rules.

In version 4.2:
As only usernames were used to match users a conflict would not be detected. In this situation users with duplicate usernames would be synchronized.

Solution: If Apache is suitably configured, the local accounts, via the passwd file would get precedence, so it should work OK for local users. However, if the username conflict is between two LDAP authorities then you currently still can get the clash.

2.3 Audit accounts


2.3.1 Logger account

When you install the auditing function, you are asked for the name of the Account Access Logging service account. The logging service account is created during installation. We refer to this as "logger" here but you can call it what you want. The logger account is used to log account access information from monitors on log files where information about accounts accessing the SCM systems is. Logging this information is the only thing that the logger account can do. Even administrative accounts cannot use the logging REST API: only logging service accounts can do so. It is not possible to log in to the UI using the logger account. You will see the message:

For security reasons, the logger user cannot log into the UI, please log in again as a more privileged user.

Best practice is to:

  1. Create a new logging service account.
  2. Update all of the ACP Flume receivers to use the new credentials.
  3. Remove the original logging service account.

Two jar files are delivered with ACP 1.5 that enable the maintenance of the logging service account:

2.4 Query audit database

2.4.1 Using command line

Use curl commands to query the database accounts. For example, to query the last access by a particular user, you need to look up the account's ID via an API query then use the ID:

curl --user admin:pass<account_id>

You see a report similar to:


To query when a user accessed a particular repository:

curl --user admin:pass<user_account_id>/repo/<repo_name>

To query the last access by all users:

curl --user admin:pass

Users who have not accessed the repositories are reported with a timestamp of 0 (with the year 1969 or 1970).

Audit does not monitor SVN commits using file://
Commits over file:// do not generate anything in the logs that auditing monitors. This means that nothing is sent to the auditing mechanism to report to the user.

2.4.2 Using UI

Use the dashboard Reports tab to query the audit database from the UI:


You can choose from the following types of report:


Note: You may see a message warning that the report could take a long time, i.e. a few seconds:


Confirm that you want to continue.

Note: Any conflict report is shown in the Reports menu:


For example, there may be a Priority Conflicts report:


To report on the last access time by an account, as an administrator, from the dashboard Accounts section select an admin, then click View/Edit dropdown for Access Details:


Click View Account Report to show the last access time for a single account:


2.5 Remove an account

Important: Benefits of not removing accounts
Access Control Plus lets you quickly and easily remove accounts, either manually or through LDAP. Many customers prune their Access Control Plus account pools to make group creation and management more managable, especially in large organizations that have a rapid turnover of teams. However, there are some good reasons to avoid the outright removal of accounts:

  • You can free up licenses by disabling accounts instead of deleting them.
  • An account's history is lost when it is deleted. Don't delete accounts if you need to store historical data for all accounts.
  • Should a user return to a team it is easier to re-enable an account than it is to recreate it.
You may need to remove accounts if you exceed the maximum number for your license.
Consider disabling accounts instead of removing them in case the account holder needs access restored in future.

To remove an account from Access Control Plus:

  1. Log in to the admin console. From the management screen, find the account that you want to remove.
  2. Tick the check box to the left of the Account holder's name, then click the - Remove button on the top of the Accounts pane.
    ACP A pop-up warning asks "Are you sure?".

    Important: No undo for account removal
    Be sure that you want to remove the account.

  3. If you are sure, click OK.

The acccount is not completely removed from Access Control. It no longer appears on the accounts list, or in any teams or rules.

If you need to check the account's particulars to ensure that you are removing the correct account, go to the accounts details screen, you'll find a Delete button at the bottom. This does the same thing as the remove link on the main management screen.

Before removing LDAP-based accounts
Before setting out to remove accounts that are generated through LDAP, we strongly recommend that you edit the LDAP property Synchronization Period to make it very large (say 99999) so that LDAP does not perform a refresh while you are removing accounts. This will ensure that LDAP doesn't add users back which have just been manually removed. Don't forget to change the Synchronization Period back once you have completed your cleanup.

2.5 Disable an account

Disabled accounts remain stored in Access Control Plus. They are, however, unable to log in or interact with any repository resources. You can quickly add back a disabled account by re-enabling it.

Disabled accounts are not counted towards the licensed number of users
You can store users in a disabled state even if you need to make room for additional users within the limit of your current license.

  1. Log in to the admin console. From the management screen, locate the account that you wish to disable.
  2. Click the account holder's name to open up the Account page.
  3. Click the Edit button to view the account's basic details. From the accounts details screen, tick the Disabled check box, then click the Update button.

3. Teams

Teams make organizing account permissions much simpler. They allow you to apply rules to many accounts at the same time, rather than for each individual account.

Remove all Audit accounts from teams as soon as possible!
We have a known issue that we will fix in future.

3.1 Create a team

Use this procedure to set up a new Access Control team. This is the same method as for adding accounts manually. You can also manage your team structure through LDAP, setting up a query that filters for the specific account holders that you need for a particular team. For more information see Adding an LDAP-based team.

3.1.1 Adding an LDAP-based team

Follow this procedure to create a team that is populated from an LDAP authority.

Global LDAP
In previous versions of Access Control it was possible to import user accounts from LDAP at the global level, before assignment to a team. Access Control Plus doesn't support the global importation from LDAP (except for "Admin" accounts see below) because team membership is a fundamental requirement of Access Control Plus's model, in which all access control is applied at the team level. There is no concept of free-floating accounts, unless the LDAP Authority is flagged for managing Admin accounts. Admin accounts are handled differently: they are imported from LDAP without needing to be assigned to a team.

Recommended approach for access management
When building your access structure you should think first in terms of teams and the access privileges that they require, then populate teams directly from LDAP using a suitable query. If you really need that global LDAP team, you can create a team called "global" and add all accounts to it.

Expected LDAP account behavior

Mix and match
When LDAP-based accounts have been added to Access Control Plus, they appear within the Accounts pane and can be added to any team. However, it's easier to track and manage LDAP users if they're enabled through their own team, where the team is set up to get its members from an authority. However, so long as you tick the checkbox Allow local users you can also add local users to an LDAP-managed team.

  1. Log in to Access Control Plus. If you have not done so already, add an LDAP authority, in this case the one from which you will be pulling accounts.
  2. On the Teams pane, click the + Create button.
  3. Fill out a Team Name and Team Description, then click the Create button.
  4. The Team is created. Now click the Edit link.
  5. From the Team edit window, enter the relevant details for an LDAP authority that you wish to associate with the team. Select the authority from the dropdown. If your authority query already filters the accounts that you need then you don't need to include a query. If not, you'll need to add one. When you have entered those details, click Update
  6. Click Close.
  7. You are returned to the master screen. The team should now be populated from LDAP.

    Polling for LDAP accounts can take some time.
    When adding teams from an LDAP authority, consider that it may take a little time for the new accounts to be imported. Don't panic if accounts don't appear immediately. You may need to wait a minute before refreshing the team page.

  8. Return to the team by clicking its name. You can now select which users from LDAP are added to the group. Also add any other team components (Resources, Rules, subteams etc) that you need.

3.2 Edit a team

  1. Log in to the admin console.
  2. On the Teams pane, click the name of the team that you want to edit.
  3. The team's screen opens.
    From here you can create additional Subteams, Add more resources, Add/Remove Members or Rules.

3.3 Delete a team

  1. Log in to the admin console.
  2. Click the Team or Subteam that you wish to delete.
  3. Click Edit to view the teams/subteams settings
  4. You are prompted to confirm the deletion. You cannot undo deletions so Access Control Plus always checks before deleting an object.

4. Resources

Resources are the available repository data, they can be in the form of full repositories or small portions of a repositories file tree. It's only possible to add Resources to Access Control Plus when there is at least one account assigned to a team.

4.1 Create a resource

Use this procedure to create additional resources, when not syncing with WANdisco's MultiSite products. If you are connecting to MultiSite then resources are selected from whatever repositories that are automatically added. See Create a resource in a MultiSite Environment.

  1. Log in to the admin console, on the main management screen and click the + Create button at the top of the Resources pane.
  2. The Resources entry form opens. Fill in the form as described below.
    Repository Name
    Enter a name for the resource.
    Repository Location (SVN Only?)
    Enter the file path to the repository data.
    Repository Template lists
    Select from the available Repository Templates that you've added.
  3. Click Save. You are returned to the main screen, with the new resources added to the list.

4.1.1 Create a resource in a MultiSite environment

Use this procedure to create additional resources, if syncing with WANdisco's MultiSite products. If you are connecting to MultiSite then resources are selected from whatever repositories that are automatically added.

Problem: Access breaks when running Access Control with a MultiSite product (Git MultiSite or SVN MultiSite)

In a deployment that is using SSL to encrypt traffic, disabling SSL in your MultiSite product, when it is still enabled in Access Control Plus will quickly result in the loss of access as password files, authorization_keys, etc will no longer be kept in sync between your nodes.

Currently you need to check the log files for WARNING level messages that this is the cause for a loss of access for SVN or Git users.

Example error message

May 26, 2015 8:55:55 PM com.wandisco.acp.repository.integration.RepositoryPollingThread

WARNING: git-polling-thread1:[Error polling repositories from as user
admin, password is set, [com.wandisco.vcs.api.exception.VCSAPIConnectionException:
Unrecognized SSL message, plaintext connection?

Repositories (w/o templates) currently can't be deleted until they are assigned a template.

  1. Log in to the admin console. On the main management screen, click the Assign template button of a repository that has been synced from Git and or SVN MultiSite.
  2. A window appears and lists the available Repository Templates that correspond with the relevant version control system. Select one of the available templates.
  3. Click Save. You are returned to the main screen, with the new resource added to the list.

4.2 Edit a resource

You can easily edit resources by clicking on the resource's name.

Access Control Plus supports repository resources in various configurations:

You can tell the type of a particular resource by checking the text under its title. It says either "Replicated" or "Non-replicated".

  1. Change any of the values, then click Save.

4.3 Refine a resource

You can refine a resource to specify a sub-repository path:

  1. Click the relevant Team, or create a team and add members.
  2. Click Add in the Resources pane.
  3. Click the checkbox to the left of the repository that you want to add a refinement for. A repository shows on the right-side pane.
  4. Click Refine.
  5. Enter the sub-repository path, (/proj-1 in the example above) then click Add. This is confirmed in the Being added list.
  6. Click Finish, then Confirm.

Click Confirm frequently. Do not create more than 10 refinements at a time. If you refine the paths of more than 10 resources then some might not be saved and some might not display. This will be fixed in future.

You can now add this resource to a rule for the team. See the Rules section.

4.4 Remove a resource

You can remove the resource from the main screen. Change any of the values, then click Save.

5. Rules

Use rules to define the parameters for the resources and the permission levels that are applied to accounts. They are applied through the account's team membership, not directly to accounts. Accounts can only have rules applied to them if they are first assigned to a team.

5.1 Using rule lookup

The Rule lookup tool provides administrators with a means of testing what access and permissions apply to specific accounts. Given that Accounts can belong to multiple teams and have multiple rules applied, the Rule lookup tool can useful tool.

If you have two repositories with the same name (also of the same SCM type) then currently a rule lookup that will display them will currently only show one of the repositories (chosen randomly). We'll address this issue in a future release.

  1. Click the Rule lookup link on the top menu bar.
  2. Enter an account name, a repository name and resource path for which you want to test access.
    Click the Lookup button. All rules that apply to the account for the specified resources are displayed in the Permissions table.

5.2 Create a rule

To create a new rule:

  1. Log in to the admin console. As rules can only be assigned to a Team, click the Team's name.
  2. On the Team screen, click the + Create button at the top of the Rules pane.
  3. Enter a name. In the Rule screen click the + Add button to add members to which the new rule will apply.
  4. Next, select the accounts. Note that there is a check box on the right-hand pane Apply to all current and future members. Check this to ensure that the rule is applied automatically to all new members of the team.
    When you've added all the necessary accounts, click the Confirm button.
  5. Finally, you need to add details of what resources and to what level the account holders get access. Click the +Add button to go to the resources screen.
  6. On the left-side pane select from the available resources. When you've finished, click the Confirm button.
  7. Select the permission level for each repository resource. The options are Deny, Read and Read/write.
    Click the Save selection button.
  8. The new rule appears on the list.

5.3 Edit a rule

To edit a rule click its name on the main screen. This opens the Rule so that you can modify any of its settings.

5.4 Delete a rule

To delete a rule click its corresponding check box and then click the - Remove button.

When only DENY rules apply to an account
When troubleshooting user access problems (in deployments that manage htpasswd/sshd files) you may notice that an active account for which only DENY rules currently apply will generate an authentication rather than authorization error on any Git/SVN access attempt. It's as if the account didn't exist or the wrong password was given, instead of not having the appropriate access permissions. This apparent quirk is by design. If an account doesn't have access to any resources at all, we don't bother writing it to the password or sshd rules file. In fact, if the account doesn't have any associated rules then "Deny" rules are applied by default and the account will not be written to the Authz file either.

You should note that this does not occur if authentication is delegated to LDAP/AD or any method which does not use passwd/sshd files.

6. Settings

This section describes how to change application settings.

6.1 Connecting your nodes

If you are deploying multiple Access Control Plus nodes, follow these steps so that the nodes communicate with each other correctly.

Nodes that are not the state machine creator are locked down until they are inducted
You won't be able to create any objects (accounts, teams, rules, etc.) on the non-state machine creator nodes until you have completed the following procedure.

Don't refresh the UI during an induction

Do not reload the browser session or navigate away while you are using the browser to complete an induction. Doing so is likely to cause problems, possibly causing the induction to stall and/or fail.

  1. Repeat the installation procedure on your additional Access Control Plus nodes.

    There can be only one.
    When installing your nodes, remember that the step to assign one node as the state machine creator should only be answered Y on one of your nodes. It can be any node. It does not have to be the first one that you install.
    This procedure refers to the state machine creator node as the induction controller node.

  2. When all nodes have been installed and are running, log in to each node that you did not assign as the induction controller node. These nodes are in a waiting state, locked down until they have been inducted into the replication network.
    Access Control Login 2
    You need to copy the above details into the induction controller node's Inductor entry fields.
  3. Log in to the Induction Controller Node, go to Settings, then click Node Induction, under Node Management.
    Access Control Login 2
  4. Copy the details of each node into the form. Ensure that the Inductor host name does not include the protocol prefix "http:/". When entered, click Confirm. The node appears in the list of pending nodes. Induction completes quickly.

    Permit no actions until induction completes
    Although the induction process is usually very fast, if it takes a while make sure that there is no attempt to interact with the admin console screens until the induction controller node reports that the process has completed. Don't refresh the browser session or navigate away from the UI until the induction is confirmed to have finished.

  5. Repeat these steps for each node until all Access Control Plus nodes have completed induction.
  6. When induction is complete on each node, it should be included in the Nodes list and become "unlocked", allowing you to log in and interact with the admin console, create accounts, teams, etc.

    Stuck in pending state
    If any node gets stuck in a pending state, you can cancel its induction and try again. See Troubleshooting.

6.2 Enable SSL encryption

Access Control Plus supports the use of Secure Socket Layer encrytion (SSL) for securing network traffic. Currently SSL properties are not exposed through the admin console, instead you need to make edits to Access Control Plus's applications properties file.

If you plan to use SSL you need to run through the following steps before going into production.

SSL is enabled for both UI and the underlying Rest API (the administrator's access to HTTP port will automatically redirect to HTTPS) AND for internal communication between nodes on application.port. For this reason the switchover needs to be done on all nodes at once, otherwise those nodes that delayed their switch will no longer be able to talk to those nodes running with SSL.

Using stronger and faster encryption
Java's default SSL implementation is intentionally weak so as to avoid the import regulations associated with stronger forms of encryption. However, stronger algorithms are available to install, placing the legal responsibility for compliance with local regulation on the user.

See Oracle's page on the Import limits of Cryptographic Algorithms.

If you need stronger algorithms, i.e. AES which supports 256-bit keys, then you can download JCE Unlimited Strength Jurisdiction Policy Files that can be installed with your JDK/JRE.

See Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 7

Important: To follow this procedure you will need to create a keystore and a truststore.
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. Certificate Authorities, CAs, are trusted third parties that issue digital certificates that verify that a given public key matches with the expected owner. These digital certificates are kept in the truststore. The truststore is like a keystore file, but used for certificates instead of keys. An SSL implementation that uses both keystore and truststore files offers a more secure SSL solution.

  1. Create a new directory in which to store your key files. This directory can be placed anywhere. In this example it is within the Access Control file structure.
  2. Open a terminal and navigate to /opt/wandisco/scm-access-control-plus/config/.
  3. From within the /config folder make a new directory called ssl.
    -rw-rw-r-- 1 wandisco wandisco 29 Apr  5 16:53 main.conf
    [User@redhat6 config]$ mkdir ssl
  4. Go into the new directory.
    cd ssl
  5. 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:
    keytool -genkey -keyalg RSA -keystore wandisco.ks -alias server -validity 3650 -storepass  <YOUR PASSWORD>

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

    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.
    This is the filename for your private key file that will be stored in the current directory.
    - alias server
    Assigns an alias "server" to the key pair. Aliases are case-insensitive.
    -validity 3650
    Validates the keypair for 3650 days (10 years). The default is 3 months.
    - storepass <YOUR PASSWORD>
    This provides the keystore with a password.

    No password specified
    If no password is specified on the command, you are prompted for it. Your entry is not 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 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, you should not specify a password on a command line or in a script unless it is for testing purposes, or you are on a secure system. When placed into the Access Control Plus properties file you first need to manually encrypt it.

    The utility prompts 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):
  6. With the keystore now in place, you next need to make the edit to the file.
    #content server port
    #Option SSL parameters
    ssl.key.password - SimpleCrypt encrypted
    ssl.truststore.password - SimpleCrypt encrypted
    Switch for enabled SSL. Value: true<./dd>
    debugging mode. Don't enable by default. Value: false.
    The absolute path to the keystore.
    The password for the keystore - this password must be encrypted using the SimpleCrypt class. We've provided a little utility to handle the encryption:
    Use the utility as follows:
    java -jar scm-access-control-plus-cryptPassword.jar password
    Gbwkzxmo70xNNy1/oVMb/7PuE3yB1+fhHX7O9qxIg6k3eNDuU6bzOCKO4Ldi0SJDDycScJjnGq2FxOYYAl0JiBRXIDGRxEVBj <snip>

6.2.1 Optional SSL parameters

These additional parameters support a more robust implementation of SSL that uses trust certification:

ssl.key.alias: Specify an alias for the private key. This is the name used to access the key inside the keystore.

ssl.key.password: Password if the cert is password protected. Encrypt it as described above.

ssl.truststore: Path to the truststore file

ssl.truststore.password: Password for the truststore - must be encrypted as above.

Changes in any of these values require a restart of Access Control Plus. Any invalid value is likely to result in Access Control Plus not running properly.

SSLv3 Support
SSLv3 is supported (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.

6.2.2 Set the server key

In the keystore, the server certificate is associated 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.

6.2.3 Export the certificate

Next you need to export the certificate so that it can be added to the tuststore as the trusted certificate. Again, using Java's Keytool.

keytool -export -alias server -file <Cert-Name>.cert -keystore wandisco.ks
Enter keystore password:
Certificate stored in file <Cert-Name>.cert

6.2.4 Create a Truststore

To create a new Truststore, for each certificate (CA) that you trust, run the following command:

keytool -import -file C:\cascerts\<Cert-Name>.cert -alias <Cert-Name-Alias> -keystore myTrustStore

The first command creates a keystore file named myTrustStore in the current working directory and imports the first certificate into the truststore with an alias of <Cert-Name-Alias>. The format of myTrustStore is JKS. Each additional run of the command adds additional certificates to the TrustStore. When completed, myTrustStore is available to be used as the truststore.

6.2.5 Auditing setting

If auditing is installed:

  1. Update the setting acp_agent.sinks.acpSink.acp_ssl_enabled in the <flume install dir>/receiver/conf/ file to:
    acp_agent.sinks.acpSink.acp_ssl_enabled = true
  2. Restart the Flume receiver:
    <flume install dir>/receiver/
    <flume install dir>/receiver/

6.2.6 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:

'' flag.

To enable the logging of SSL implemented layer, turn the logging to FINEST for the package.

Problem: Access breaks when running Access Control with a MultiSite product (Git MultiSite or SVN MultiSite).

In a deployment that is using SSL to encrypt traffic, disabling SSL in your MultiSite product, when it is still enabled in Access Control Plus will quickly result in the loss of access as password files, authorization_keys, etc will no longer be kept in sync between your nodes.

Currently you need to check the log files for signs that this is the cause for a loss of access for SVN or Git users.

Example error message

May 26, 2015 8:55:55 PM com.wandisco.acp.repository.integration.RepositoryPollingThread logVerboseWarningWhenPollingFails
WARNING: git-polling-thread1:[Error polling repositories from as user admin, password is set, [com.wandisco.vcs.api.exception.VCSAPIConnectionException: com.sun.jersey.api.client.ClientHandlerException: Unrecognized SSL message, plaintext connection?

6.3 Node repair

The Node Repair tool is used to recover from the loss of one or more nodes when replication is set up.

The Node Repair tool efficiently returns a failed node back into production. However, its misuse can worsen the situation. Until we place blocks against potentially destructive actions, we strongly recommend that you don't use the Repair Tool unless under direct instruction from WANdisco's support team.

6.4 Connect to MultiSite

This section describes how to connect Access Control Plus to an existing Git or SVN MultiSite setup:

  1. Log in to the admin console. Click the Settings link on the top menu.
  2. Click the Connect to MultiSite bar in the External Applications section.
  3. Enter the required MultiSite details:
    API IP
    The IP address of the MultiSite node.
    The port used for Rest API traffic (Default is 8082).
    Username for Access Control Plus to use to access the MultiSite node.
    Managing Node (Drop-down)
    Select which Access Control Plus node will manage communication with MultiSite.
    Poll Period
    The frequency (in seconds) that Access Control Plus will check for changes on the MultiSite node. Default = 3600 (1 hour). Minimum = 60. First poll happens immediately on setting this value.

    Do not set this value too low
    If you have a large deployment, sycnchronization will be resource hungry.

    Use SSL (checkbox)
    Enable SSL encryption for the API traffic.
    Password for the MultiSite account.
    Retype Password
    Repeated password entry (to ensure you entered it correctly above.
    Save/Cancel (buttons)
    Click Save to store the details, or Cancel to clear them.
    When you have added all the details, click Save.
  4. Return to the main Access Control Plus screen. If there are Repositories being handled by MultiSite, they'll be automatically synced with Access Control Plus, appearing in the Repositories panel.
    At this point the repositories are known to Access Control Plus, but it still needs to be configured with authentication and/or authorization files for each repository using the Repository templates options.

Return to Getting set up.

6.5 Connect to LDAP

This section describes how to configure Access Control Plus to query one or more LDAP authorities in order to pull in accounts for your Git or Subversion users.

6.5.1 LDAP settings

The settings tell Access Control Plus how to use any available LDAP authorities that you connect up.

Synchronization Period (minutes)
Access Control Plus reruns your LDAP queries with this frequency, picking up any changes that may have occurred within the LDAP service. Default = 60 (1 hour). Minimum = 1. First synchronization happens immediately on setting this value.

TIP: Do not set the period too low, or to zero.
You shouldn't need to constantly hit your LDAP authority. If you have a large deployment, sycnchronization will be resource hungry.

If you perform an import from an earlier version of Access Control you must ensure that Access Control Plus does not poll the LDAP authorities during the process. You can do this by setting the Synchronisation Period to 999 (minutes) just for the duration of the import.

Allow Local Users
This checkbox is ticked by default. When ticked it is possible to field both LDAP-controlled and manually entered Accounts. Some organizations don't permit manually entered accounts because they need to be sure that all accounts are managed through their LDAP. If this is the case, untick the checkbox when your LDAP accounts have been successfully imported.

If you are running with Local Users disabled and your LDAP service fails, you can re-enable local users as part of the account password recovery process. This process automatically re-enables local users, allowing you to gain access to the admin console.

6.5.2 Entering LDAP Authority details

This is the entry form for adding any number of LDAP Authorities. Multiple Authorities are checked in the order that matches their order number (see below). The lower the order number, the earlier the authority is checked.


LDAP Settings

Synchronization Period (minutes)
How long Access Control Plus waits before each poll of the LDAP service for updates. Default:60 minutes
Maximum LDAP team Size before prompting
This property acts as a safety valve for when you create new teams in very large organizations. If an LDAP query generates a team that is larger than this number, you will be asked to confirmation before it is imported. This can be used to prevent the accidental creation of teams that contain hundreds of thousands of accounts that would negatively impact performance during
LDAP Authorities
Lists the existing LDAP services that are connected to Access Control Plus. LDAP authorities are added using the Add LDAP Authority table.

Add LDAP Authority

The priority given to the LDAP URL. For example, 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.
A given name for the authority. Names are only used as labels in Access Control Plus to make it easier to manage multiple LDAP authorities.
Enter a regular expression to set a pattern for matching against the account name for the available LDAP authorities. The expression, is applied locally to limit unnecessary queries against available LDAP authorities. For instance, setting an expression that specifies a top-level domain can ensure that authentication of a user (whose username is their email address) doesn't need to run through all LDAP authorities. Instead it can be checked only against those servers that match the regular expression, in this case, the same top-level domain.
Base URL
The base URL is the point in the LDAP "tree" where you start your searches. Using the format ldap(s)://hostport/basedn?attribute.
Bind Dn
The distinguishing name of the administrator account that ACP will use to query the LDAP authority.
Bind password
Corresponding password for the administrator account.
User DN
Distinguishing name for the account users.
User DN Attribute
The name of the uid attribute for a user in the directory.
User DN Scope
DN Scope determines how deeply into a directory searches are made. Combined with the Base DN and User DN filter to set the limits for which users are matched for authentication. Options are Base, One or Subtree.
User DN Filter
LDAP Search string used to filter the directory for applicable accounts.
Auth DN
the distinguished name of the a directory container that can be queried against for returning valid users.
Auth DN Attribute
The directory attribute name for the the directory container that we'll authenticate against.
First Name Attribute
Attribute used for an account holder's first name.
Last Name Attribute
Attribute used for an account holder's last name.
Email Address Attribute
Attribute that corresponds with a user's email address.
Public Key Attribute
Used with the LDAP service is encrypted, requiring Access Control Plus to be setup with an SSH key pair. As with any public key entry, make sure that no line breaks are introduced to the key, it should be one long string, no breaks.
Managing Node
Identifies the node from which LDAP settings are managed.
Case Insensitive (checkbox)
Tick this checkbox if you need MultiSite to stop distinguishing between usernames that differ only by their case pattern.
For example, with the "Case Insensitive Usernames?" unticked (by default), MultiSite treats username "MelissaJones" and username "melissajones" as two distinct users. Support for username case insensitivity is a feature that may be required when Active Directory.
Admin Group (checkbox)
Tick this checkbox if the authority will return users who are System Administrators (able to access the MultiSite admin console).
Ignore Workstations
This function is no longer applicable in Access Control Plus's current form and will be removed in a future release. This feature allowed calls from workstations such as build servers to be ignored, when Access Control was based on a proxy architecture.
Auth DN Scope
Auth DN Scope determines how deeply into a directory searches are made. Combined with the Base DN and User DN filter to set the limits for which accounts are matched for authentication. Options are Base, One or Subtree. See further explanation of the different scope options.
Auth DN Filter
LDAP string that is used to filter a directory for valid accounts.
Group DN
Group distinguished name identifies a container for applicable accounts in a directory.
Group DN Attibute
The directory attribute that corresponds with the group distinguished name, used to authenticate against.
Group DN Scope
Group DN Scope determines how deeply into a directory searches for groups are made. Options are Base, One or Subtree.
Group DN Filter
LDAP string used to filter for valid groups.
User Request Page Size
This property is only used in conjunction with Group DN-based LDAP queries. It is used to override the system default for the maximum number of user records that can be requested by a single userDN query. A request for a large number of users is split into multiple requests to safeguard server performance and stability.

We strongly recommend that you do not add LDAP-based accounts that use the same account name. Currently you can have two accounts with the same name, because accounts can be distributed across any number of authorities. If you attempt to add two accounts that use the same account name, their addition fails and an error message appears in the logs that warns you: Incorrect result size: expected 1, actual 2.

6.6 Email notification

The mail notification system lets you connect Access Control Plus to an email gateway server. This enables it to send an alert email concerning important system events. It's possible to add as many email gateways as you like, so that the loss of a single mail server need to result in the halting of notifications.

The following procedure shows you have to set up an email gateway.

  1. Log in to the Access Control Plus admin console. Click the Settings link.
  2. Click the Email Notifications bar.
  3. Fill out the entry form for your gateway.
    IP/Hostname of SMTP Server:
    Your email server's address.
    SMTP Server Port
    The port assigned for SMTP traffic (Port 25 etc).
    Encryption Type
    Select your server's encryption type: None, SSL (Secure Socket Layer) or TLS (Transport Layer Security). SSL is commonly used. For tips on setting up suitable keystore and truststore files see Setting up SSL Key pair.

    Running Apache?
    If you're not familiar with the finer points of setting up SSL keystores and truststores we recommend that you read: Using Java Keytool to manage keystores.

    Authentication Required
    Show whether you need a username and password to connect to the server by entering either "true" or "false".
    User Name
    If authentication is required, enter the authentication username here.
    If authentication is required, enter the authentication password here.
    Sender Address
    Provide an email address that your notifications will appear to come from. If you want to be able to receive replies from notifications you'll need to make sure that this is a valid and monitored address.
    Number of Tries Before Failing
    Set the number of attempts SVN MultiSite Plus makes to send out notifications.
    Interval Between Tries (Seconds)
    Set the time, in seconds, between your server's attempts to send notifications.
  4. When you've entered all the details, click the Add button.
  5. When a gateway is in place you need to add a list of email addresses to where Access Control Plus will actually send notification emails.
    Enter addresses on the Add destination entry field and click + Add.
  6. Before notifications can be sent, enable the service by ticking the Enable notifications checkbox.
    You can untick the checkbox if you need to disable the feature, without removing or editing the gateway or destination settings.

6.6.1 Notifiable events

The following events currently trigger notifications when suitably configured:

6.7 Create a repository template

In Access Control Plus's backend, you can manage and replicate the core password and/or Authz files. To do this you need to create a template that will contain the path location for these files, as well as a number of optional parameters. When set up, repositories that are added to Access Control can be assigned the template, telling Access Control Plus how to handle the repository's necessary files.

If you configure repository templates to send files, the files are sent even if they are not linked to repositories.

To create a repository template:

  1. Log in to the admin console. Click the Settings link on the top bar.
  2. Click the Repository Templates bar under in the Applications Settings, near the top of the list. Click the Create button.
  3. Complete the small entry form:
    A useful label for the product to refer to this repository.
    A description of the template to help you distinguish from it from potential others.
    From the dropdown list select your SCM product: Git or SVN.

    WARNING: Never change the Type of a repository template!
    Do not add Generators to a repository template for more than one Type of repository. If you have accidentally started to create the wrong Type of template, always Delete the template and start over.

    Click the Add button to save the entry form.

  4. The screen is parsed, your selection detected and a Generators dropdown list appears. From this dropdown you can select multiple user access assets:
    SSH Key File Generator
    Transports SSH keys between nodes.
    Apache Password File Generator
    Transports Apache password files between nodes.
    SVN Authz File Generator
    Handles the Authz file (under SVN).
    GIT Authz File Generator
    Handles the Authz file (under Git).

    Check that you have just 1 of each type of generator
    Make sure that you create just 1 of each type of generator by navigating away and then back again. Click Remove to get rid of duplicate generators.

    For more information on how these files are managed and distributed see Generic File Replication.

  5. Enter the Target Location. Find location of generated file on target node. Absolute path.
    Click on Show optional parameters to see a number of extra entry fields. When you have completed the entries you need, click on the Update button.
  6. You can create any number of Repository Templates, reflecting how many separate collections of repositories you are running where each requires a different series of user management files.

CAUTION: Take care when creating repository templates with the same paths!
We recommend that you do not configure multiple repository templates with identical files and/or paths. You can do this if your configuration consists of non-overlapping system restrictions. For example, you can use the Advanced features so that repoTemplateA only delivers to systems A, C, E and repoTemplateB only delivers to systems B, D, F.

6.8 Enable/disable batch updates

Follow this procedure to enable Batch mode. Make sure you understand what it does and how it works before you do though.

WARNING: If you are using the REST API for automated configuration of ACP, then we strongly recommend using batch updates.

Batch updates is a mechanism that can improve performance in deployments that have large number of accounts, repositories and rules and/or deliver to many Subversion MultiSite Plus or Git MultiSite nodes. See the Reference Guide for more information about Batch Updates Mode.

  1. Log in to Access Control Plus and click the Settings link.
  2. Click the Access Control Updates bar.
  3. Tick the Enable checkbox. Confirm the switch period (in seconds) and select which node will manage the batching process.
  4. Click on Save.

See Access Control Updates for more details.

6.9 Example configuration

This example sets up authorization using Authz on a per-repository basis, running on SVNServe with SSH encryption. This is an example only, so do not follow it as an actual setup procedure.

Repository template

Access Control Plus Login

These settings set the target location of the Authz file and the common path segment of the SVN repositories:

Target Location
Common Repository Path Segment


svnserve.conf controls the behavior of the SVNServe daemon on a per-repository basis. It is located in the conf subdirectory of the repository, e.g. /opt/svn/repo/conf/svnserve.conf.

anon-access = none
auth-access = write
authz-db = authz
Determines the access level for unauthenticated users. "write" allows all repository operations. "read" allows all operations except committing and changing revision properties. "none" allows no unauthenticated access. The default level is "read".
Determines the access level for authenticated users, using the same access levels as above. The default level is "write".
Controls the location of the authorization rules for path-based access control. filename may be relative to the repository conf directory. There is no default value. If you don't specify an authz-db, no path-based access control will be set.


The following configuration is required on the server:


The following configuration is required for clients:



The server-side authorized_keys file is overwritten later during ACP operation.

Access Control Plus Admin Console settings

An Authz file should be generated, here:


It should look like this:

Example (Team: team1, Account Name: user1, Resource: repo0, Perms: RW)
  # Generated by Access Control Plus, WANdisco.
  # ACP Node Name            : node1
  # ACP Node Hostname        :
  # Generation Audit number  : abab31d2-a266-426b-a578-336b58419130
  # Generation Serial number : 187
  # Template Id              : 97e47269-4b20-40e8-b1a0-fa052d74ecb9
  # Template Name            : svn
  # Template Description     : svn
  # Assignment Type          : svn-authz
  # Assignment Id            : 1de6a9c6-c8ec-4eaa-9391-0a7cd55f8ab3
  # Assignment Modified at   : 2014-05-27 23:32:16.346

  virtual_team_team1_rule_rule1_88b17a89-157b-48ab-a9dd-364912f20b25 = user1

  * =

  @virtual_team_team1_rule_rule1_88b17a89-157b-48ab-a9dd-364912f20b25 = rw

Client-side access

Access the repository using:

svn co svn+ssh://wandisco@<ip address>/repo

Adding additional entries to authorized_keys file

The authorized_keys file that we build can now work with additional entries, added by the user. These entries need to be created in one of two blocks; authorized_keys.prepend or authorized_keys.append.

Using both prepended and appended entries

These blocks, authorized_keys.prepend and authorized_keys.append can be used together, so that custom entries are written to both ends of the authorized_keys file.

Not replicated

This feature works an a per-machine basis, it is not automatically replicated to all servers. To implement a global policy you will need to set up a uniform deployment of the files to all MultiSite nodes.


Entries in the file authorized_keys.prepend are used as the initial contents of the new "authorized_keys" file, generated by Access Control Plus, adding always included entries, after which Access Control Plus generates its own entries.


In the account .ssh directory on your MultiSite machine create a file called authorized_keys.prepend. It should look something like this:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCf/5GZcLFVbDSOV51RoLKgbi8afL9N5zl3Im6MA4MgXt67u5D43+UjeU4vjH6wUW5zGdhK2BWX820qQvCwCYJCL6oEG+Lv/jMu0NgenO/jKYgeDVx4wsffkVYcABsz55cPO+qsM/BSxY00RGEMroVEQhAGVQF++340VRrcZCe6O0vGwLgFrl+Thb0z9RuDzj+a+Swl99dhkKMS1wlAPl0HIUpBYdhtoEc9dnn+mPNUV9CKaPBq79ANJxYEsmPKxUolhuIQH9GNxsAC3v3pmffKVNdy0kLeK6htQ4LPqRd1zmLgq7fNtiFszYJNZk6c0efTEf0yjYUKZvWEu26fnGht prependUserKey@prependUserKey.local

In Access Control Plus, navigate to Settings -> Access Control Updates -> Generate Authorization Files

The authorized_keys file on your MultiSite node should now included your prepended entries before those added automatically by Access Control Plus.


Entries in the file authorized_keys.apend are apended to the newly generated authorized_keys file which is then installed through the GFR system as per usual.


In the account .ssh directory on your MultiSite machine create a file called authorized_keys.prepend. It should look something like this:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCf/5GZcLFVbDSOV51RoLKgbi8afL9N5zl3Im6MA4MgXt67u5D43+UjeU4vjH6wUW5zGdhK2BWX820qQvCwCYJCL6oEG+Lv/jMu0NgenO/jKYgeDVx4wsffkVYcABsz55cPO+qsM/BSxY00RGEMroVEQhAGVQF++340VRrcZCe6O0vGwLgFrl+Thb0z9RuDzj+a+Swl99dhkKMS1wlAPl0HIUpBYdhtoEc9dnn+mPNUV9CKaPBq79ANJxYEsmPKxUolhuIQH9GNxsAC3v3pmffKVNdy0kLeK6htQ4LPqRd1zmLgq7fNtiFszYJNZk6c0efTEf0yjYUKZvWEu26fnGht appendUserKey@appendUserKey.local

In Access Control Plus, navigate to Settings -> Access Control Updates -> Generate Authorization Files

The authorized_keys file on your MultiSite node should now included the appended entries after those added automatically by Access Control Plus.

6.10 Troubleshooting

Problem: Replication runs very slowly while server load and traffic are both light.

It is possible that pending tasks are currently stuck and are therefore holding up further replication. To test if this is what is happening:
  1. Go to Settings/Node Induction.
  2. Check for any pending tasks.
  3. If you find that there are pending tasks then you should consider aborting them.
  4. Recheck replication to see if things improve (it can take a few mins for backlogs to clear).

Problem: Induction never completes (blocked CD port)

Use this work-around for unblocking a deployment which is stuck in an induction This can occur should a second induction be triggered while an induction is still being progressed.


  1. Make sure the CD port is not blocked. Full duplex access is required between all nodes. By default the content delivery port is 6445 unless a different port was specified. You can confirm allocation of the port by checking the content.server.port entry in /opt/wandisco/scm-access-control-plus/properties/
  2. Shut down the replicators at all nodes.
    service scm-access-control-plus stop
  3. Backup then delete the contents of the database directory from all nodes.
  4. Restart the replicator on all nodes.
    service scm-access-control-plus start


  1. On your first node complete the induction form using the details of your second node. You must not refresh the page or make any other changes while the induction is in progress.
  2. You can verify the induction completed succesfully by making a call using the REST API:
    and make sure there are no tasks present.
  3. If tasks remain then you'll need to wait while they complete before you log in to the Access Control Plus UI on your second node. If you are unable to log in then induction is still in progress!

Additional nodes

When the induction of the second node is confirmed as complete, you can repeat the procedure for the third node, running through the procedure for each additional node, one at a time.

7. Wildcards

The Deployment Guide describes how to install ACP and enable wildcard support.

Note: You only have the option to deselect the Use wildcards checkbox before you save changes to the resource you have added. However, this is only likely to be required if you, extremely rarely, need to use the asterisk as a non-wildcard (normal) character.

7.1 How the wildcards work

With Subversion 1.8 you can use the following wildcards with directory entries (files, directories, symbolic links):

From Subversion 1.10 you can mix wildcards. You can use multiple asterisks within a single directory entry rule:

For example:

7.2 Working with Rules

You can create a new rule or edit existing rules.

7.2.1 Wildcard rules in the AuthZ file

Within an AuthZ file, the rules are sorted into a list of sections as follows:

  1. Rules for the same repository and identical path extension collapse into a single section.
  2. Sections at the same priority sort by:
    1. Sections for repositories are supported by repository name in strict <character-set> order.
      1. Shorter paths sort before longer paths where:
        1. Wildcard "sort-specific path subset" is the shortest path that includes no wildcards (e.g. "/a/b/c/" in "/a/b/c/*.suffix").
        2. Wildcard rules with matching "sort-specific path subset" sort via strict <character-set> sort on the remaining path segment (e.g. "/a/b/c/*.suffix") after "/a/b/c/_README_.*") with the caveats:
          1. The wildcard character itself, *, always sorts before every other character in the <character-set> being used.
          2. If the * is not a wildcard then it sorts in its normal location within the <character-set>.
      2. Wildcard rules sort before non-wildcard rules.
  3. Sections at higher priority sort after sections at lower priority and vice versa.

Note: If the wildcard flag is not set then the entire rule must be treated as a non-wildcard so the * is sorted based on <character-set> order only. Priority is still observed.


  • The section header must start with :glob: for wildcards to be honored. All asterisks within that section are considered to be wildcards.
  • Sections without wildcards can have :glob: but with no effect.
  • Sections without :glob: with asterisks (‘*’) mean non-wildcard/literal.

For example:

[:glob:repo:/path/*] [repo:/*]

@group1 = rw         @group2 = r

7.2.2 Create a rule for all .xml files on a branch

You might want to stop users writing to XML files. For example, ...

To create the rule to deny write access:

  1. Make sure that you have refined a resource within a repo.
  2. Go to the Rules page.
  3. Add branches/myBranch/**/*.xml as a Path. Because asterisks are used in the pathname then Use wildcards is automatically checked.
    Access Control Plus Login
  4. Click Add and you see confirmation that the refined resource is wildcard-enabled in the Being added list. It is then listed under Resources.

    Note: Use camel case in path names, e.g. myBranch not my branch.

  5. Go to the Rules and click the rule.
  6. Select the permissions (Deny, Read, Read/Write) and the priority, if you want to change it from the default of 0.
    Access Control Plus Wildcards Change Permissions
  7. Click Save selection.
    If there are wildcard conflicts, the save fails and you are asked to Confirm that you want to create the rule.
    Access Control Plus Login
  8. If you confirm that you want to create the rule, even though there is a priority conflict between this new rule and an existing one, then the rule is saved. The priority chosen for the rules in conflict will depend on the global setting for conflict resolution, by default set to "Highest Wins". The conflict is then included in the count shown on the page header.

You are returned to the Team page.

7.2.3 Create a rule for a specific file on all branches

You might want to stop users committing to a specific file on all branches. For example, to create the rule to deny write access:

  1. Follow the steps above but add branches/*/secret.txt as a Path.

7.2.4 Create a rule for intermediate directories

You might want to stop users committing to a group of files. For example, to ...

To create the rule to deny access:

  1. Follow the steps above but add branches/myBranch/**/private as a Path.

7.3 Setting priorities

To enable policy via wildcards you can specifically order certain wildcard sections before others. To enable this in ACP, each repository path refinement has an associated priority. The priority value ranges between -9 and +9. Default is 0 (zero).

Most rules should not require priority adjustment.

Rules for the same repository and identical path refinements collapse into a single section. Sections for repositories plus path refinements are sorted in strict <character-set> order:

  1. Shorter paths before longer paths
  2. The wildcard asterisk (‘*’) sorts before any character in the <character-set>: a non-wildcard asterisk sorts in its normal order in the <character-set>
  3. Sections at higher priority sort after sections at lower priority
  4. Section collisions between multiple rules with different priorities are sorted using the highest (or lowest) priority of the set, based on a global setting. Default at install is highest priority takes precedence: sorts last in AuthZ file
  5. Conflicts are created by Team Leads or Adminstrators replying "Continue" to “Do you really want to do this?”.

For example:
TeamAlpha: P0 repo1:/a/** Read TeamZed: P3 repo1:/a/** Read/Write Results in:

@TeamAlpha = r
@TeamZed = rw

This section sorts with Priority P3 sections after sections with priority P2 but before sections with P4.

7.3.1 Set priority for resources within rules

You can set a priority from -9 to +9 (0 is default) for every Subversion resource within every rule.

Note: At any time, you can change the priority for Subversion resources from the Rules page.

  1. Set the priority of a resource on the Rules page.
  2. Click Save selection.

7.3.2 Wildcard conflicts

A conflict occurs when multiple rules match the same directory entry. The last matching section in the AuthZ file “wins" the conflict. Ordering of the sections within the AuthZ file is now critical, including non-wildcard sections!

Critical conflicts occur where there is: