Permalink:
| Table of Contents |
|---|
| Child pages (Children Display) |
|---|
This chapter covers the common initial tasks each namespace administrator must do before using the namespace in production. The tasks are covered in sections, one larger task per section. The presented order of execution is not enforced, but it is recommended.
Planning for a new namespace
Namespaces are quite fixed constructions. Their descriptive names may be changed, but the namespace code each namespace has is meant to be permanent. This is why rather than having a company name or something there, it is customary to use a rather random string. An example is "ns1357924680".
...
Changing the username for a user account is possible, so this is not very critical. Administrators just need to plan this, and define a policy on how these details are handled.
Namespace general settings and policies
Before creating many permanent user accounts to a new namespace, it is recommended to consider policy settings. These determine much of the “look and feel” of the namespace. Select “Namespace” on the Main Menu to start exploring the options. Some items are covered next. Note, we are not covering all tabs, options, and selections here, only some key ones. It is still important for the namespace administrator to review them all.
Define the naming policy for sign-in accounts in tab Core. Although other policies are available, we generally recommend using email addresses as usernames for user accounts. Users remember their email address.
It is possible to change the email address and thus sign in username later if the email address changes. This change is part of normal user account editing process. It is one of the editable fields.
Enabling email address as username requires just the following two one-time setup steps:
Define all valid email domains for any user account in the namespace. When entering this list, please note the list is later presented in the order you enter the domains. Please have the default / most common domain as first on the list. If the namespace is used for running a public service where the users may have any email address as sign in username, it is possible to use an asterisk (*) to allow any domain. However if this is not needed, it is advisable to limit acceptable email addresses by listing the domains here due to security reasons. For example if a namespace is used by several organisations, list the email domains used by the organisations here.
On the drop-down list of username policies, select "Email address" as the policy for new user accounts.
Please remember sign in username policy only affects user accounts which are created after policy change. This is one important reason to review policies early.
Check the settings on tab User Interface. It is possible to allow for using nicknames (a.k.a. aliases) instead of official names. In some cultures using nicknames is very common. Each user account can opt-in to prefer their nickname on screen and in reports, etc.
User accounts often forget their passwords. An important policy decision is whether to allow for self-recovery of passwords, or not. On very high security environments, self-recovery should not be allowed.
Define the LDAP and SMS settings on tab Features. If enabling LDAP authentication, it is recommended to limit LDAP only for a certain user account group of the organisation and not for all user accounts. This is especially important if there are certain service accounts in the namespace, which must not have LDAP authentication enabled. Please refer to on screen instructions on details.
Define the settings for sending SMS messages. Please refer to on screen instructions on details.
Open tab Branding and customise your namespace by uploading the logo(s) of your organisation. The following logos may be uploaded in bitmap format (PNG, JPEG, GIF) here:
Top-bar logo which is shown to all users at all times in top left corner of
Sign-in logo which is shown in the sign in window for all users
General logo which is used in various uses including reporting. As reports are often printed on paper, this logo should be of high quality to ensure satisfactory print quality.
If you wish to use an alternative sign-in address for private sign-in, define it here. Please refer to on screen help on details.
Miscellaneous tab contains the setting for Event log sensitivity. Value Debug is the most sensitive setting, i.e. a lot of event information is written to the Event log, whereas setting Error means logging only errors. Warning is the recommended setting. You may also use this setting for changing the logging sensitivity setting momentarily, for instance for troubleshooting purposes.
The logging settings and options which are described in detail in chapter “Event Log (a.k.a. Audit Trail)”.
Define whether the users have to accept Privacy Policy and/or Terms and Conditions. Review the texts if either will be used. If necessary, modify the texts as necessary. Also, make translations if necessary.
Binding legal data location: some legislations require certain types of personal or other data to be processed in a certain country or geographical area. Define the country where data is handled and stored. The default value for this is defined in the Default Group Policy, but can be changed in other Group Policies. Obeying this setting normally requires organisation private
...
Trivore Identity Service platform deployment, so if you are using this feature, please contact sales or support before expecting it will work.
Check the Available namespace administrators on tab Management. Left pane shows the list of Multi-namespace. Select which of them may manage this namespace. This tab is visible only to Portal Admin.
Define the email address to which personal data removal requests are sent to on tab Personal data.
Namespace Default Group Policy: Verify and customise
Default group policy contains the default settings for all users in the namespace. Therefore it is advisable to check all the settings of default group policy before creating large amounts of user accounts. Especially security settings should be thought of carefully and set according to your company policy.
Use of NIST SP 800-63-3 recommended values is advisable. These settings can be selected by simply selecting the “Set NIST SP 800-63-3 recommended values” button on Security tab. The use of these values forces the users to create passwords long enough to be secure.
Current common consensus on passwords and their change interval is to:
Use long and complex passwords of more than 15 characters; even 40 characters or more is not an overkill if users are using password manager applications.
Use password manager application to securely store the long passwords.
Do not require changing the password. Current NIST SP 800-63 recommendations define password lifetime as indefinite. If you still want to require changing, do not do it too often. Maybe every 1 or 2 years only to let users to learn their password so it is not written to paper notes next to the computer.
Lock user account for minimum 5 minutes so after 5 failed sign in attempts in 5 minutes to very effectively slow-down any brute-force attacks down to 1 per minute.
Indefinite or long password change intervals are possible due to long or very long passwords. 40 character generated complex random passwords are extremely difficult to crack. This is almost impossible due to aggressive account locking due to failed sign in attempts.
If the LDAP Server feature is enabled, these security settings are also enforced when signing in via LDAP.
Use of Two Factor Authentication (2FA) is also advisable.
Create other namespace administrator user accounts
Instructions in this section can be used to create user accounts with other role combinations, too.
Sign in as an administrator account with role Account admin.
Go to "Accounts", and select "Add account". This will be repeated for all organisation administrators, including yourself if you are one.
When creating user accounts, tab "Core" is the main tab where the most important information is entered.
Also go to tab "Access", and select at least the following roles for other namespace administrators:
Account Admin
Group Admin
Group Policy Admin
Role Admin
Authorisation Admin
Namespace Admin
All other admin roles, like Location Admin, Contact Admin, Target Admin, etc. are optional for all other but one user account in an namespace. It is customary, there is only one or two user accounts with Role Admin role assigned. Assignment of roles like Incident Admin depends on the enabled applications and user cases. If you are not using Incident Management application, there is no benefit, nor harm in assigning role Incident Admin or Incident Auditor for administrator user accounts.
Note, the password for user account is not entered anywhere when creating an account. It is sent directly to the user. One of the policies above defines the password transmission method.
If you will be creating more than one account, select
for “Continue creating new user accounts”.Select “Save” to save and create the new user account.
In the end, after creating the last user account, select “Close”.
Create groups in the namespace
Groups are used to effectively manage many users together. Groups exist only in the namespace they are created in.
Sign in as an administrator account with role Group admin.
Go to "Groups", and select "Add group". This will be repeated for all groups you are going to create.
When creating groups, enter group name and optional description on tab "Core".
Go to tab "User accounts" to define which user accounts are members in a group. In tab “Groups” you may add an existing group to be part of this new group.
If you will be creating more than one group, select
for “Continue creating new groups”.Select “Save” to save and create the new group.
In the end, after creating the last group, select “Close”.
It is also possible to import groups from CSV, ODS, XLS, or XLSX file. This is beneficial when creating many groups. Import function is available in "Actions" menu.
Create “normal” user account
“Normal” user accounts do not have any particular roles.
Below is shown the Core tab when creating a new user account. It is normally unnecessary to go to the other tabs when creating new user. As a new namespace administrator, you should, however familiarise yourself with the other tabs, too.
...
It is recommended at this point to create at least one user account if for nothing else than for verifying what permissions that user account has, and to learn more about
...
Trivore Identity Service. Also, this account is very practical for testing role and group policy behaviour. After tests, you can either delete or lock the account.
Sign in as an administrator account with role Account admin.
Go to "Accounts", and select "Add account". This will be repeated for all namespace administrators, including yourself if you are one.
When creating user accounts, tab "Core" is the main tab where the most important information is entered.
Note, the password for user account is not entered anywhere when creating an account. It is sent directly to the user. One of the policies above defines the password transmission method.
If you will be creating more than one
groupuser account, select
“Continue creating new user accounts”.Select “Save” to save and create the new user account.
In the end, after creating the last user account, select “Close”.
It is also possible to import user accounts from CSV, ODS, XLS, or XLSX file. This is beneficial when creating many user accounts. Import function is available in "Actions" menu.