Repository |
|
Repository |
|
Many repositories can be connected to a single Swivel server. Every Swivel has a pre-configured XML repository. This screen allows you to define new Repositories and delete existing repositories.
For each repository, you need to set the following:
Additional settings on this page are:
Delete users with server: If set to Yes, when a repository is deleted from Swivel, all users imported from that repository will also be deleted.
Allow user repository to change: If set to Yes, then on User Sync, if a username already exists in a different repository, the user account is transferred to the current repository. If set to No, an error is logged and the user remains unchanged.
Server to use to attempt to authenticate non-users:
This option allows you to specify which repository server is used to authenticate unknown users.
Currently, this is only supported with two-stage RADIUS authentication, but it allows unknown users
to authenticate using just the repository password.
This screen allows new repository types to be configured
Identifier: The name associated with the repository-type.
Class: The class file that implements the interface between Swivel and the Repository. This file needs to be installed on the Swivel server
The way that groups are configured has changed since version 3.3.
There are three elements to configuring user groups on Swivel
Swivel comes with two named groups, one for user and one for administrators.
As an example to add a group of users that will authenticate via an IIS filter using pinless SMS.
We then tick the boxes for Dual Channel and PINless and click apply.
NOTE: for LDAP-based repositories, assuming that the repository server has already been set, the simplest way to set group definitions is to browse the LDAP structure (by clicking the appropriate Browse button). For writeable LDAP (including ADAM) repositories, you can create new groups on the fly.
For database repositories, the group definition corresponds to the value of the group field in the membership table.
Once this group has been defined it will appear as an option from a drop down list whenever there is an option to set a group; for example when configuring a transport or an agent
Only one destination attribute can be defined per transport, therefore the same attribute needs to be used across all repositories for destination attributes such as mobile phone number / email address. If this is not possible then a transport class has to be defined for each repository, using different attributes.
For Active Directory and LDAP repositories, group names must be fully distinguished and are sensitive to both case and internal spaces. For example:
CN=SwivelUsers,CN=Users,DC=swivelsecure,DC=com
For the XML repository groups names are freely customisable.
Synchronisation
Config sync type: This list is shown when the attribute 'Synchronise configuration' of Synchronisation Administration --> Configuration parameters is activated.
NOTE: If the repositories are different in the other appliances the value of the repositories will not be updated.
Sync now: This button appears when the config sync type of the current section is Automatic or Manual. It allows you to synchronise the whole section with the other appliances configured with the config sync type Automatic or Manual.
This page is used to configure which administrative users may manage user accounts.
It is only relevant if the Policy -> Helpdesk option "Helpdesk Users can administer editable repositories"
is enabled.
Type: There are 4 types of group rights assignments:
Whichever option is selected above, accounts with administrator rights can manage all user accounts. Helpdesk accounts cannot manage or create administrator accounts.
If the third option above is selected, then the group rights matrix comes into effect. Across the top of the matrix is a list of repository groups with helpdesk rights. Down the left of the matrix is a list of all non-admin repository groups. Tick checkboxes to indicate which helpdesk groups can manage which user groups.
If any other option is selected, the group rights matrix has no effect. Clicking Apply after changing the drop-down option will alter the check boxes to reflect the effective rights applied, as follows:
Filename: The name of the XML file used to store users in this repository. This name will be generated automatically when the repository is created, so there should be no reason to change it. Be aware that changing the filename will result in existing users being lost, and that if two XML repositories have the same name, they will effectively be the same repository.
Synchronization schedule: Synchronization schedule for the synchronization of this repository with Swivel. You configure here how often changes to the repository are updated to the Swivel database. Typically for the XML and other editable repositories this will be set to NEVER, and instead you perform a manual synchronization whenever you make changes to the repository. However, for non-editable repositories, such as Active Directory, you should set this to an appropriate value depending on how often the repository changes. Typically, this will be once a day for infrequent changes, or once an hour for repositories that change frequently.
Mark missing users as deleted:
If this is set to Yes then when a sync job runs and an existing Swivel account is not found within the repository, rather than immediately deleting the account, the account is disable and marked as deleted. The account can then be subsequently purged (deleted permanently) or undeleted. An account that is marked as deleted that is then detected during a subsequent sync job will be re-enabled. Note that accounts marked as deleted still count towards the total number of users for licensing purposes. The main advantage to using this option is that if users are deleted in error, their credentials are unchanged when they are restored.
Initial PIN attribute: Name of the repository attribute that stores the initial PIN for the user. Can be used for manually setting specific initial PINs or for user migration from Swivel v2.x. Rather than setting the attribute name, it is also possible to set a fixed initial PIN for all users by prefixing the value here with a # symbol, for example #1234 sets the initial PIN for all new users to 1234. This option is provided due to pressure from some customers. Swivel Secure does not recommend that you use it, as having the initial PIN for all users set to the same value is a security risk.
Initial password attribute: Repository attribute that stores the initial password for the user. Can be used for manually setting specific initial passwords or for user migration from Swivel v2.x. As with initial PIN, this can be set to a fixed value, rather than reading from the repository, and as before, this is not recommended for security reasons. Be aware that this is a Swivel password, not a repository password. Setting a Swivel password is an additional security feature, but not all of our integrations support it: many assume the Swivel password is empty, and rely on the target system having its own password.
Import disabled users: If this option is set to No then users marked as disabled in the repository will not be imported into Swivel at all.
Import Disabled State: Enable/disable the importing of users' disabled state from the user repository. When enabled the user repository will be consulted as to whether or not an account is disabled. Currently, Active Directory supports this functionality. Simple LDAP will support it if the name of the disabled attribute is entered in the appropriate settings. When enabled, it will no longer be possible to manually set the disabled state of the user within the Swivel administration interface. If Import disabled users is set to No, then this option has no effect, as disabled users will not be imported at all.
Reformat Phone Number: if this option is set to Yes, then any phone number imported from the repository is reformatted by removing all non-digits (including spaces), and removing or adding a prefix, according to the following two options.
Prefix to remove: If Reformat Phone Number is enabled and this option is not empty, then the first occurrence of the specified prefix is removed.
Prefix to add: If Reformat Phone Number is enabled and this option is not empty, then the value of this option is added to the beginning of the number. A typical example of usage for phone number reformatting, in the UK, would be to set Prefix to remove to "0" and Prefix to add to "+44". This will ensure that phone numbers imported as, for example, "01937 582 020" will be stored in Swivel as "+441937582020"
Add domain qualifier: This option and the next allow you to add a fixed prefix or suffix to all usernames in this repository. This option specifies whether it should be a prefix, a suffix or neither. The prefix or suffix can be used to ensure uniqueness where there is a danger of having the same username in multiple repositories. It can also be used to ensure (for example in Active Directory) that the format of the username is correct for the target authentication platform. Be aware that if a prefix or suffix is used, users must always use them when authenticating to Swivel.
Repository Domain Qualifier: This option allows you to specify what prefix or suffix should be added to users in this repository, as described in the previous option. If you use this option, make sure that any separator characters are included. For example, if usernames should be in the form domain\username, the prefix should be domain\.
Active Directory has many of the same configurable options as an XML repository. It has the following additional options.
Hostname/IP: Hostname or IP address of Active Directory server.
Username: Username with appropriate permissions to connect to the repository. This should be a domain qualified username such as user@swivelsecure.com or SWIVELSECURE\user. For other LDAP-based repositories, this will typically be a fully-qualified distinguished name, for example cn=user,dc=swivel,dc=local.
Password: Password for the user given above.
Port: Port number used to connect to Active Directory.
Allow self-signed certificates: Enable/disable the ability to connect via SSL to an Active Directory server whose certificate is not signed by a recognised certificate authority (e.g. if it is self-signed).
Username Attribute: Repository attribute that stores the username a user will use to login. For Active Directory this could be �userPrincipalName� for a qualified username such as �user@swivelsecure.com�, or sAMAccountName for the pre-Windows 2000 name such as �user�. For other LDAP repositories, the attribute is typically "uid".
Ignore FQ Name changes: LDAP repositories such as Active Directory have a concept of fully-qualified names and account names. The fully-qualified name uniquely identifies the object within the repository and the account name is an attribute, such as sAMAccountName, that the user then uses as a username.
For example the fully qualified name may be
CN=test, CN=User, OU=IT, DC=swivel, DC=com
but the Swivel account name will be created using the sAMAccountName, test.
If the account is moved within the repository, the fully qualified name changes, eg
CN=test, CN=User, OU=Admin, DC=swivel, DC=com
If you set Ignore FQ name changes to Yes, Swivel will ignore
this change and the associated Swivel account will not be modified. If
Ignore FQ name change is set to No, then the existing Swivel account will be deleted (or marked as deleted)
and a new Swivel account will be created for that user. If "Mark as deleted" is enabled, this might well result in
an error, since the old user will still exist.
An ADAM repository is very similar to Active Directory, with the additional ability of being able to create new users and modify existing ones directly in the Swivel admin console. Additional options here support that ability.
Port: For LDAP repositories other than Active Directory, the port is entered as a number.
Use SSL: For Active Directory, SSL is automatically enabled for ports 636 and 3269, and disabled for 389 and 3268. For other LDAP repositories, you can manually specify whether or not to use SSL, and if enabled, whether to allow self-signed certificates (more generally, to ignore certificate validation) with this option.
First name attribute: The attribute used to store the user's first name. This is stored in the repository only: it is not stored by Swivel itself, so has no practical use at present.
Surname attribute: The attribute used to store the user's surname. Like the first name, this attribute is not stored in Swivel. It can, however, be used to search the repository.
Group name attribute: the attribute used to store the name of a group.
User Container FQDN: the fully-qualified name of the container in which users will be stored within the repository. Users may be stored directly within here, or in sub-containers of this container. It is possible to enter this directly, but it is easier to browse for it, as long as you have already entered the server details. You can create a new container while browsing.
Group Container FQDN: the fully-qualified name of the container in which groups will be stored within the repository. The same comments apply as for user container.
Expiry Date Attribute: the attribute used to store the account expiry date. This is an optional feature. You can specify an expiry date for any writeable repository and the account will automatically be deleted (or marked as deleted) when that date occurs.
New user password: You can specify whether or not to set a password for new users, and if a password is set, whether it is set manually or randomly generated. The repository password is used to authenticate to LDAP, and is distinct from the Swivel password. If you are only using the LDAP repository for Swivel, you do not need to know what the password is. However, be aware that in ADAM, the default policy requires that user accounts cannot be active unless they have a password. This means that users with no password will always be disabled in ADAM, so if you are importing the disabled attribute, they will be disabled in Swivel. The randomly generated password option is useful in this case: you do not need to know what the password is, but the user must have one.
A simple LDAP repository has the same configurable items as an Active Directory repository but with the following additions:
Base DN: the base distinguished LDAP name for the repository. Typically, this can be left blank unless doing so causes problems accessing the repository.
Base Search Context: the base DN used when searching the repository. Again, this can normally be left blank unless you have difficulty synchronizing the repository.
Group ObjectClass Name: the objectClass attribute value to be used for groups. Only groups with this object class will be searched when synchronizing. For writeable LDAP repository, this is the objectClass that will be used when creating new groups. It must therefore be a valid LDAP objectClass. Required parent classes will automatically be added.
User ObjectClass Name: the objectClass attribute value to be used for users. The same comments apply as for Group ObjectClass.
Member attribute name: the attribute used when locating or setting group membership for a user.
Member group attribute name: the attribute used when locating group membership for a sub-group. Typically, this need not be set, as it is the same as for users, but some LDAP implementations use a different attribute.
User disabled flag name: the attribute used to indicate that a user account is disabled. This is an optional attribute: if empty, all users are treated as enabled. Values must be of boolean type.
User enabled flag name: the attribute used to indicate that a user account is enabled. This has the same use as the User disabled flag name, but with opposite logic: true indicates that the account is enabled, rather than disabled. No repository has been encountered so far that requires this attribute, but it is provided in the event that such a repository occurs.
This type of repository is a writeable version of Simple LDAP. As such, it has the configuration items of Simple LDAP, plus some others in common with ADAM, and the following additions:
Membership attribute name: the attribute on a user account indicating membership of specific groups.
Password attribute name: the name of the attribute in which the account password is stored. Note that for LDAP writeable, passwords are stored in plain text.
Container objectClass: the objectClass attribute value used when creating new container objects.
Container attribute name: the name of the attribute in which the name of a new container object is stored.
Database repositories are used where Swivel needs to read user information from an existing database. At present, there is no writeable version of this repository. Some configurable items for this repository are common to XML repositories. The following are the additional configurable items:
JDBC Driver: the full class name for the JDBC driver class used to access this database. Swivel can only access databases through JDBC drivers (the same as for Swivel's own database), so the appropriate JDBC driver jar file must be copied to the pinsafe/WEB-INF/lib folder.
Database URL: the JDBC URL for the target database. This must include the database / namespace.
Database login user: the username for the database account. This must be an account on the database server that has read writes to the appropriate database tables. Note that JDBC does not support Windows Integrated Authentication for MS SQL databases, only built-in database accounts.
Database login password: the password for the above account.
User details table: the name of the table containing usernames that are to be imported into Swivel.
User ID field: the name of the field in the users table containing user IDs. See the next value for details.
Username field: the name of the field in the users table containing usernames as Swivel will use them. The user ID and username field can be the same field, and typically they will be, but if the database contains distinct unique fields, you can specify different fields.
Group membership table: the name of the table containing group membership information. This table must contain at least the user ID and a group name column. If you already have such a table, then fine. Alternatively, you may find that the users table contains a category column which matches the required group membership information, in which case the group membership table can be the same as the users table. Failing that, if you will only be using one group in Swivel, and all users will be in that group, or you can write a SQL query to select the members of that group, then you can create a View in the database to represent the list of User IDs required, with a constant value for the group name.
Membership userid field: the field in the group membership table containing the user ID. Note that this must correspond to the user ID value in the users table, not the username value, if they are different.
Membership group field: the field in the group membership table containing the group name. The values in this table must correspond to values in the Repository Groups definitions for this repository.
