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.

Viewing all users¶

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

The list of users and contacts will then be displayed.

The list of all the existing users and contacts

Important

TrustView distinguishes between a user and a contact. A contact in TrustView is an identity you can check out a certificate to without remembering the e-mail and phone number of the contact. A contact cannot log in to TrustView.

Management of local users¶

Adding a local user¶

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

Deactivating a local user¶

Select the user from the list of users and click Deactivate.

Management of AD-based users¶

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. 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 create the user.

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.

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.

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.

Step 1¶

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

Configuration in TrustView.groovy¶

    adloginUpnsuffix="domain.com"
    adloginAdPort=636
    adloginAdHost="127.0.0.1"
    adloginSearchbase="dc=domain,dc=com"
    grails.plugin.springsecurity.auth.loginFormUrl = '/login/adauth'
    adloginAdHostUseSSL = true

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.

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:

    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.

Important

From the stable version - v5.18.104 and onwards, it’s possible to set up AD-login with a fallback domain controller.

The new setup in the TrustView.groovy file must include the following 5 lines, instead of the 6 lines above:

    adloginUpnsuffix="domain.com"
    adDomainName="domain.com"
    adloginSearchbase="dc=domain,dc=com"
    grails.plugin.springsecurity.auth.loginFormUrl = '/login/adauth'
    adloginAdHostUseSSL = true

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¶

    adloginUpnsuffix="domain.com"
    adDomainName="domain.com"
    adloginAdPort=636
    adloginAdHost="127.0.0.1"
    adloginSearchbase="dc=domain,dc=com"
    grails.plugin.springsecurity.auth.loginFormUrl = '/login/adauth'
    adloginAdHostUseSSL = true

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

Step 2¶

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:

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

Important

Ensure that the path of the Tomcat directory is correct.

Step 3¶

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¶

    C:\Program Files\Eclipse Adoptium\jdk-17.0.8.1-hotspot\bin>" .\keytool.exe -import -keystore path\cacerts -storepass changeit -file path\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¶

    C:\Program Files\Eclipse Adoptium\jdk-17.0.8.1-hotspot\bin>" .\keytool.exe -import -trustcacerts -keystore path\cacerts -storepass changeit -file path\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.

Step 3b [Optional]¶

Change the password of the keystore with PowerShell:

Change password for keystore¶

    .\keytool.exe -storepasswd -keystore \path\cacerts
    Enter keystore password: changeit
    New keystore password: new-password
    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.

Step 4¶

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

Step 5¶

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

To create a new AD group link, enter the name of the AD group and 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 will be happy to help you with setting up AD-login, if needed.

Test the configuration for AD-login¶

Go to Global settings, then click AD autodetect configuration.

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.

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.

Note

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 the other 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

Management of user groups¶

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

Tip

Our 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.

Step 1 - 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 certificates. So 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.

Step 2 - 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.

Step 3 - 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).