1. Users, Groups and Roles#

TrustView supports two types of users, local users and Active Directory (AD) integrated users. Local TrustView users are added and managed directly from TrustView, whereas AD integrated users requires no handling in TrustView but are created and managed based on the assigned AD security groups. Users in TrustView are assigned one of several pre-defined roles. Depending on the assigned role, parts of the functionality and features are disabled for the user, such as modifying the configuration or check-out of certificates.

A user is always assigned to a specific group in TrustView. All users in a group manages the same set of certificates. Usually a single group in sufficient for most cases, but there are situations where multiple groups is a better setup. One such situation is an organization where management of SSL certificates and management of MitID Erhverv certificates is strictly separated. With a two-group configuration in TrustView, users handling MitID Erhverv certificates does not have access to any SSL/TLS certificates and vice versa.

1.1. Viewing all users#

Select Users, organizations and contacts in the left menu under the Management section.

The list of users, organizations and contacts will then be displayed.

The list of all the existing users and contacts

Important

TrustView distinguishes between a user and a (external) contact. A contact in TrustView is an identity you can checkout a certificate to, without remembering the e-mail and phone number of the contact. An (external) contact cannot log in to or gain access to TrustView.

To get an overview of all the deactivated users, add ?advanced at the end of the browser URL, without removing anything, which should look like this:

https://trustview-instance-url/users/list?advanced

After that, a new advanced menu will be visible, showing all of the deactivated users of TrustView (if any).

1.2. Management of local users#

1.2.1. Adding a local user#

Click New user from the user list and fill out the information.

Adding a new local user

1.2.2. Deactivating or changing the role of a local user#

Select the user from the list of existing users and click Deactivate to deactivate the user.

Important

In TrustView, you can only deactivate a user, not delete a user. This is done to preserve the full history of user events registered by TrustView, such as placed certificate orders and checkouts. A deactivated user does not have access to TrustView.

Deactivating or changing the role of a local user

On the detail page for the user, it is also possible to change the role of the user if needed.

Important

The role of the user can never go above the role of the user, currently logged into TrustView. This means that a user with the role of Superuser, could never grant the user a role of Global admin.

1.3. Management of AD-based users#

1.3.1. Adding an AD integrated user#

A user can log in to TrustView as soon as the user has been assigned to one of the required AD security groups. There is no additional configuration on a per-user basis required from TrustView.

Important

Note that the user is not visible in TrustView before the first login, so simply assigning the user to the AD security group, will not alone create the user before the first login.

1.3.2. Modifying an AD integrated user#

You can change the assigned user role to the user, by assigning another AD security group to the user. During the next login by the user, the role of the user is automatically updated.

1.3.3. Deactivating an AD integrated user#

You can remove an AD integrated user’s access to TrustView by removing the user from the AD security group. This does however not immediately deactivate the user in TrustView, because the state of the user is only updated during login attempts. You can however deactivate the user explicit by selecting the user on the list of all users and clicking Deactivate.

Important

In TrustView, you can only deactivate a user, not delete a user. This is done to preserve the full history of user events registered by TrustView, such as placed certificate orders and checkouts. A deactivated user does not have access to TrustView.

1.4. Configuration of AD-based user management (AD-login)#

Using AD-based user management requires an initial configuration of AD communication and mapping of security groups in AD to groups in TrustView.

To set up AD-login in TrustView, these 5 lines must be included in the TrustView.groovy file:

Configuration in TrustView.groovy#
1  adloginUpnsuffix="domain.com"
2  adDomainName="domain.com"
3  adloginSearchbase="dc=domain,dc=com"
4  grails.plugin.springsecurity.auth.loginFormUrl = '/login/adauth'
5  adloginAdHostUseSSL = true

If you need the Searchbase to be expanded, to search in more than one location of your Active Directory, you need to replace your adloginSearchbase line with the following:

1  adloginSearchbase=["OU=Users,DC=adtest,DC=local","OU=Users2,DC=adtest,DC=local"]

In the above example, Users and Users2 will be searched for any users and groups in the Active Directory. It’s possible to add additional search locations, but they must be contained within the [ ] brackets, to comply with the syntax.

This new setup will enable TrustView, to locate the domain controller automatically. If you want to enable a domain controller for fallback, the following lines must be used instead:

Example of Domain Controller used for fallback#
1  adloginUpnsuffix="domain.com"
2  adDomainName="domain.com"
3  adloginAdPort=636
4  adloginAdHost="127.0.0.1"
5  adloginSearchbase="dc=domain,dc=com"
6  grails.plugin.springsecurity.auth.loginFormUrl = '/login/adauth'
7  adloginAdHostUseSSL = true

The fallback domain controller used, will be 127.0.0.1:636, which is specified as adloginAdHost.

Note

Change the lines to fit your setup. Port 636 is for SSL. To run without SSL, change adloginAdPort to port 389 and set adloginAdHostUseSSL to false.

Add the following 3 lines to the Java Options, under the Java tab in the Tomcat configuration, by opening trustvieww.exe, located in the bin directory of the Apache tomcat installation folder:

1  -Djavax.net.ssl.trustStore=C:\Program Files\Apache Software Foundation\Tomcat 9.0_TrustView\conf\cacerts
2  -Djavax.net.ssl.trustStorePassword=changeit
3  -Djavax.net.ssl.trustStoreType=JKS

Important

Ensure that the path of the Tomcat directory is correct.

Copy the cacerts file from the Java library (the Java currently used by TrustView) to the desktop or another directory. Then export the CA root certificate to the same place as the cacerts file. Run the PowerShell command:

Add root certificate to keystore#
1  C:\Program Files\Eclipse Adoptium\jdk-17.0.8.1-hotspot\bin>" .\keytool.exe -import -keystore path\cacerts -storepass changeit -file pathto\rootca.cer

Use the following command when adding a certificate to the keystore to be trusted for Citrix ADC:

Add a trusted certificate to the keystore#
1  C:\Program Files\Eclipse Adoptium\jdk-17.0.8.1-hotspot\bin>" .\keytool.exe -import -trustcacerts -keystore path\cacerts -storepass changeit -file pathto\rootca.cer

Important

Ensure that the path of both certificates and the keytool.exe are correct.

When the command has been run, move the modified cacerts file (which should now include the root certificate) to the conf folder of the Tomcat directory and restart the Tomcat Windows service.

Change the password of the keystore with PowerShell:

Change password for keystore#
1  .\keytool.exe -storepasswd -keystore \pathto\cacerts
2  Enter keystore password: changeit
3  New keystore password: new-password
4  Re-enter new keystore password:  new-password

Important

If the password is changed, it also needs to be updated in the Tomcat configuration file TrustVieww.exe, under the Java tab, which can be found in the bin directory.

Go to Global settings and fill out the fields, to set up the AD synchronization user.

Go to Users, organizations and contacts, then click Manage AD settings.

Example of setting up the AD group link

To create a new AD group link, enter the name of the AD group, search for it and then choose a role from the dropdown, to give the groups the desired user permissions.

When an AD group link is created, it will be listed on the page and users from that group, should now be able to log in to TrustView with AD-login.

Under AD synchronization job schedule click Run synchronization job now to perform a sync with the AD.

Tip

Our Support will be happy to help you with setting up AD-login, if needed.

1.5. Test the configuration for AD-login#

Go to Global settings, then click AD autodetect configuration under the Autodetect AD configuration section.

Fill out the required and/or optional fields, to perform a range of tests to see what the optimal configuration would be, for the AD-login in TrustView.

From the results, it can be established how the configuration in the TrustView.groovy configuration file should look like.

1.6. Overview of roles#

Each user in TrustView is assigned one of the following pre-defined roles:

  • Superuser

  • User

  • Read-only

  • Certificate requester

  • Global administrator

The Global administrator role allows the user to configure setups across TrustView groups.

Tip

It is recommended to have at least one user with the role of Global administrator to be able to update TrustView and manage all the global settings of TrustView.

The following table lists the functionality enabled for all the roles:

Global administrator

Superuser

User

Read-only

Certificate requester
Update configuration
(e.g. network scans)

Yes

Yes

No

No

No

Add, modify and remove users

Yes

Yes

No

No

No
Add, modify and remove
monitored objects
(e.g. SSL and MitID Erhverv certificates)

Yes

Yes

Yes

No

No

Check-out of certificates

Yes

Yes

Yes

No

No
View details of all
monitored objects

Yes

Yes

Yes

Yes

No
Receive e-mail notifications
about expiring monitored objects

Yes

Yes

Yes

Yes

No

Place certificate orders

Yes

Yes

Yes

No

Yes

Update the TrustView application

Yes

No

No

No

No

Manage user groups

Yes

No

No

No

No

1.7. Management of user groups#


Click here for detailed steps

To manage and see the user groups in TrustView, a user must have the Global administrator role, to get the complete overview.

Tip

Our Support will be happy to help, if none of your users are assigned the Global administrator role, or you are experiencing issues with user roles in general.

Under Users, organizations and contacts, all user groups can be seen listed, if the user logged in has the Global administrator role.

Create user groups

Start by creating the desired groups in your Active Directory (AD).

Example:

Create the following groups:

  • LetsEncryptCertificates

  • DigicertCertificates

  • SSLEndpoints

  • OcesCertificates

Create the following AD users:

  • letsencrypt_user

  • digicert_user

  • sslendpoints_user

  • ocescertificates_user

In this example, the groups are created to be able to separate users into groups, that only has access to the specified type of monitored objects. So in this example, the users in the DigicertCertificates group, will only have access to the certificates issued from DigiCert and no certificates from the other issuers.

The user roles still apply to this, so the Read-only role e.g. can still be applied to any of the groups created in the example above. See AD Integrated User Management for details on delegating roles to user groups.

Link users to user groups

Once the desired groups has been created, then go to Users, organizations and contacts New user and here you can link users to any of your new groups under the User group by selecting a group from the dropdown.

Important

This can currently only be done in the TrustView for new users. For existing users, you would have to link it manually in the database, used by TrustView or delete your existing user and create a new new user, with the correct link.

Next step is to go to Manage AD settings and set up your group link(s) to your Active Directory (AD) groups. Once that has been completed, log out of TrustView and back in again with the user that was a member of at least 2 user groups. When you have been logged in, you should be able to see a dropdown in the top navigation of TrustView, where you can switch between your available groups.

Separate monitored objects into groups

To separate monitored objects (certificates, endpoints, CRL´s etc.) into groups, go to the list view or the detail page of the monitored object, that you wish to move to another group (inside TrustView).

Use the dropdown Move to another user group to select the group you wish to move the monitored object to.

Important

The dropdown will not be available or visible on the list view or the detail page of the monitored object, if the user currently logged in, is not part of at least 2 groups - the group where the monitored object is currently located and the group of the new location.

Once the monitored objects have been moved to the new group, you may remove the origin group for the user, so the monitored objects can’t be moved back if you so wish.

Doing this from the list view and not the detail page, will allow the action to be performed as a bulk operation.

At the top navigation in TrustView, there is a dropdown which can be used to switch between the groups that the user, currently logged in, is a member of (only available if the user is a member of at least 2 groups).