Swivel Core V4 User Administration

User Administration

This is the page that most administrators and helpdesk users will make most use of. It provides the ability to search for users, and to manage them.

Search Options

• Max No. Users: this limits the number of users that will be displayed in total. It is user-configurable, and has nothing to do with the number of licenced users. The actual number of users in the current repository is displayed next to it.
• Users per page: the maximum number of users displayed on a single page. If the current view contains more than this number, additional controls will be displayed, allowing you to view other pages of users.
• Repository: This drop-down shows all the available repositories, plus All Repositories. All repositories in the database are shown, not just the ones that are defined on the current server. Selecting a repository will restrict the current view to users in that repository.
• State: This drop-down allows you to show only users in a particular state. The options are All, Active (i.e. not locked, disabled, inactive or deleted), Inactive, Locked, Disabled and Deleted.
• User search: this option allows you to search on any defined attribute, either starting with or containing a particular sub-string.
• Members of group: allows you to restrict the view to members of a particular group.
• View: controls what information about the users is shown. The default, as shown above, is Rights. The other options are

Groups

Transport

Attributes

Repository

Controls

Not all of these buttons are available in all circumstances: some only relate to writeable repositories, and most only apply to single repositories, so are not available if All Repositories is selected. Similarly, some are not available if a repository that is not defined on the current server is selected.

• Search: Applies the current search criteria and shows the results. Some drop-downs invoke the search automatically.
• Reset: Clears all the search criteria.
• Purge (Only available for a single repository): permanently delete all users currently marked as deleted. This option is not available to helpdesk users.
• Undelete (Only available for a single repository): removes the deleted flag from all users. This option is not available to helpdesk users.
• Add User (Only available for writeable repositories): Invokes the Add User screen to add a new user.
• Import... (Only available for writeable repositories): Invokes the Import Users screen to import a number of users. This option is not available to helpdesk users.
• Bulk Provision (Only available for a single repository, if enabled by policy): Get a list of users that need to be provisioned. These users must
  • have the Mobile App right,
  • not currently be provisioned,
  • not have a valid, pending provision code,
  • have a valid alert transport
• Confirm Provision: this option is shown once the Bulk Provision check has been run. If selected, sends a provision code to every user identified by the Bulk Provision check.
• Cancel Provision: this option is shown once the Bulk Provision check has been run. If selected, clears the pending bulk provision.
• User Sync (Only available for defined repositories): Run a user sync on the current repository.
• Sync Count (Only available for defined repositories): Run a dummy user sync on the current repository and report how many users would be added/deleted/modified.

Single-User Management

Once you have selected a single user, the buttons shown above will appear. Not all the buttons are available, depending on the repository type etc.

• Edit (for writeable repositories only): Shows the Edit User page to edit user details.
• Policy: Shows the User Policy page to modify user policy settings.
• Reset PIN: Shows the Reset PIN page to manually set a user's PIN.
• Reset Password (only if enabled by policy): Shows the Reset Password page to manually set a user's Swivel password.
• View Strings: Shows the View Strings page to show the user's current security strings. Available if the user has single-channel, dual-channel or mobile app rights.
• Send String: If the user has the dual channel right, sends the user a new security string.
• Resend: Generates a new, random PIN for the user, and sends it to them using the alert transport.
• App Provision: Sends the user a mobile app provision code. Immediately de-provisions the user if they have previously provisioned.
• Lock: Manually lock the user. Only shown if the user is not already locked.
• Unlock: Unlock the user. Only shown if they are currently locked.
• Undelete: Undelete the user - remove the deleted flag. Only shown if they are marked as deleted.
• Purge: Permanently delete the user. Only shown if they are marked as deleted.
• Remove (only available for writeable repositories): Remove the user from the repository. This does not remove them from the Swivel database - a User Sync must be run to complete the removal.
• History: Shows the User History page, to review the user's recent activity.
• Remove Fingerprint (Available since 4.0.5 and only in Attributes View): Removes the user Biometric Fingerprint.

Add User

This form allows you to enter the details for a new user in an XML repository. Only the username is compulsory. The number of custom attributes shown depends on how many have been defined in Repository Attributes.

The form for ADAM and writeable LDAP is slightly different, in that you can select the location of the user within the LDAP directory structure.

When you click OK, the user is added to both the repository and the Swivel database.

Edit User

This form allows you to modify the details of an existing user. The only difference from the Add User page is that the username cannot be changed.

Again, the changes are automatically synchronized to the Swivel database when you click OK.

Import Users

This page allows you to import a number of users into a writeable repository in bulk. The user details must be in a text file: either XML or CSV, as detailed below. Optionally, the text file can be compressed into a zip file: this is recommended for large numbers of users.

The import options are as follows:

• Groups:
  • Import Groups: the import file must contain the group information.
  • Groups as below: all users will be imported into the groups as selected by the check boxes.
• File Type: CSV or XML. See the file structures below.
• File to Import: Browse to import file
• File is zipped: Tick if the file is zipped. For more than 100 users, a zip file should be used to import the users.
• Delete imported users: if this option is selected, rather than importing the users, they will be deleted from the repository.

Note that clicking Import only imports the users into the repository. You need to run User Sync in order to import the users into the database.

Importing a PIN number

It is recommended that Swivel generate a random PIN number that is sent to the user on account creation. However it is possible to import a PIN number for a user as detailed below:

Under Repository -> Attributes, create a new attribute in the empty space at the bottom, called "pin". You need only enter a name for this attribute for the repository you are trying to import into. If this is an XML repository, the attribute name should be "pin". If it is an ADAM or LDAP repository, use the attribute name set as initial PIN attribute. Next, you need to add "pin" (or the appropriate attribute name) as the header field for the appropriate CSV column, and enter the initial PINs for the imported users.

CSV File format

The CSV file should have as its first line the field names to be imported, then the data, with one line per entry, fields separated by a comma. Example:

username,first-name,last-name,email,disabled,phone
psampr,Pete,Sampras,user1@email.com,FALSE,12345678
aagass,Andre,Agassi,user2@email.com,FALSE,12345678
rnadal,Rafael,Nadal,user3@email.com,FALSE,12345678

If groups need to be imported too, the field names for the group should be group_1, group_2 etc:

username,first-name,last-name,email,disabled,phone,group_1,group_2
user1,Pete,Sampras,user1@email.com,FALSE,12345678,group-1,group-2
user2,Andre,Agassi,user2@email.com,FALSE,12345678,group-1,group-2
user3,Rafael,Nadal,user3@email.com,FALSE,12345678,group-1,group-2

XML File Format

The XML file format is the same format as used by the XML repository. A simple example is shown below:

<?xml version="1.0" encoding="UTF-8"?>
<users xmlns="http://swiveltechnologies.com/xmlrepository">
 <user>
   <username>admin</username>
   <groups>
     <group>SwivelSMTP</group>
     <group>SwivelAdmin</group>
   </groups>
   <agents/>
   <disabled>false</disabled>
   <dirty>true</dirty>
   <email/>
 </user>
</users>

User Policy

This page allows you to set the following policies for a user:

• Disabled: the user's account is disabled, and they may not log in.
• Change PIN at first login: the user must change their PIN after the first time they log in. Failure to do so will result in their account being locked.
• PIN never expires: if set, this user is not subject to the default policies on PIN expiry.

Reset PIN

Enter the user's new PIN, then enter the same value again to confirm.

Or click Generate Random (from 4.0.5) to generate a random PIN code.

Reset Password

Enter the user's new Password, then enter the same value again to confirm.

View Strings

This page shows the user's current single-channel, dual-channel and mobile app strings, if relevant. This can be a useful tool for a helpdesk to provide users with a security string if they do not have their phone with them.

This page also provides the ability to Invalidate the current security string. Some customers use a long-term single channel string as a workaround when the customer is unable to use other methods. However, the user cannot subsequently use any other authentication method until the string has been invalidated.

User History

This page shows the user's recent activity. The drop-down allows you to select the activity type to show.

Note that this page gets its information from the user Audit table. However, this only keeps records for 30 days, by default. Therefore, if a user has not logged in for the last 30 days, it shows the last time the user did log in. This information is taken from the Activity table, which maintains the most recent record of each activity type.