tiCrypt

System Settings

Prerequisites

User Role:

Sub-admin, Admin, Super-admin

Permission Requirements

• System Settings
  • View system settings, such as the login logo
• System Settings Administration
  • Change system settings

System Settings is the Management page where you change deployment-wide settings, such as the login logo, the inactivity timeouts and the terms of service, without editing the deployment file. Each setting also has a key in the deployment file, and a value you save here takes priority over it (see Saved Values and the Deployment File). System Settings is not System Settings History: the history page lists every change saved here, with the old and new value.

How System Settings Work

Where it is. System Settings is in the Settings section of Management, together with System Settings History (Super-admin only) and Custom Fields.

Who can use it. The System Settings item appears for anyone with the permission View system settings, such as the login logo. Saving a change also requires Change system settings; the backend refuses the save otherwise. The page has no reset button: the permission Reset system settings to the deployment file's values is not used by this page. These permissions control only this page. The saved settings apply to every user, whatever their permissions.

Layout. The page has a category list (Login, Servers, Timeouts, User, Caching, Files, Notices, Drives, VMs) and a settings list that shows the name and a one-line description of each setting in the selected category. Selecting a category opens its first setting. The arrow keys, Home and End move through either list.

Saving. A save bar appears at the bottom only after you change something. It reads "A change has been made to this setting." or, if a value is not valid, "The value provided is invalid.". Click Save to store the change. A successful save shows "Updated <setting> setting successfully!"; a failed save shows "Failed to update <setting>". The setting stays marked unsaved, with its save bar, until the server accepts the change, so a failed save can be retried without entering the value again. While a setting saves, its fields are locked, so edits made meanwhile cannot be lost.

• Save is disabled while a value is not valid.
• Selecting another setting or category before you click Save discards the change, without a warning.
• The backend does not check the values. The checks described on this page, made by the page itself, are the only ones.

Previews. Login Logo and Login Message show a live preview of your change. Other settings show an illustration.

Records of a change. Every successful save adds an entry to System Settings History, with the old and the new value. The backend also writes an Audit Logs line of type GIWR for every save attempt, including refused ones.

Saved Values and the Deployment File

Each setting has a key in the deployment file (see Deployment File Keys). A value saved on this page takes priority over the file's value:

• A saved value replaces the file's value for every user.
• A saved list (SFTP Inbox Endpoint Servers, XSS Headers, User Helpdesk) replaces the file's list as a whole. A list saved empty stays empty, even if the file has entries.
• A setting saved with no value falls back to the file's value, or to the built-in default when the file has none. This happens when you save an empty Login ID RegEx, Update URL, Private Key Timeout, Session Timeout, Default File Share Duration, maximum inbox duration or Inbox URLs list, and when you untick Enable Windows domain for RDP connections.

The page shows only values saved here

The fields show the values saved on this page, not the values users get. An empty field, or a preselected choice such as Nobody under Copy Settings, can hide a value that comes from the deployment file. Check the deployment file before you rely on what an unsaved setting shows.

When a Change Takes Effect

A saved change applies in your own browser tab as soon as the save succeeds, for the settings the app reads. It does not reach other users' sessions that are already open. The following table describes when each setting is read.

Settings	Read by	Takes effect
Login Logo, Login Message, Login ID RegEx	The login and registration pages, when they load	At the next load of the login page.
Update URL	tiCrypt Connect, when a user opens the deployment	At the user's next opening of the deployment in tiCrypt Connect.
External Servers (the server lists), XSS Headers	tiCrypt Connect, when a user opens the deployment, to build the app's Content Security Policy	At the user's next opening of the deployment in tiCrypt Connect. Reloading an open app is not enough.
Inbox Settings in External Servers	The app, when it loads and at login	At each user's next login or app load.
Windows VM Domain	The app	In your own session as soon as the save succeeds; for other users at their next login or app load.
All other settings	The app, when it loads and at login	In your own session as soon as the save succeeds; for other users at their next login or app load.

If tiCrypt Connect cannot reach the backend when a user opens the deployment, it uses the deployment file alone for that session.

The following table describes the settings by category.

Category	Setting	Default	What it controls
Login	Login Logo	The tiCrypt logo	The image at the top of the login page.
Login	Login ID RegEx	Not set	Which login IDs people can register with.
Login	Login Message	Off	A message above the login box.
Servers	Update URL	Not set	Where tiCrypt Connect checks for frontend updates.
Servers	External Servers	Empty; inbox token 365 days	The SFTP inbox endpoint and survey servers the frontend may contact, and the inbox settings: the upload pages users pick from and the longest inbox token.
Servers	XSS Headers	Empty	Links and image sources allowed through tiCrypt's XSS protection.
Timeouts	Private Key Timeout	20 minutes	Inactivity before the private key is cleared from memory.
Timeouts	Session Timeout	15 minutes	Inactivity before the screen locks.
User	Copy Settings	Nobody	Which roles can use copy-to-clipboard buttons and select text.
User	User Helpdesk	Empty	Helpdesk links and phone numbers in the user menu.
User	Password Strength	Passwords must be strong	The minimum password strength.
User	Admin Session Downgrade	Disabled	Whether admins can log in with a reduced user profile.
Caching	Private Key Caching	Never	Whether encrypted private keys are kept in browser storage.
Caching	MFA Caching	Never	Whether MFA tokens survive closing the browser.
Files	Default File Share Duration	30 days	The prefilled expiration when sharing files.
Notices	CUI Disclosure	Off	The CUI banner and the CUI dialog at login.
Notices	Terms of Service	Every month, no text	The terms of service dialog and how often it appears.
Drives	Track Drive Backup	No	Whether drives carry a backup designation.
VMs	Windows VM Domain	Off	The domain used in RDP connection files for Windows VMs.

Legend

• Some settings have a Places this appears button that lists where the setting shows in the system.
• Login Logo and Login Message preview your change at the top of the panel.
• Use the category list and the settings list to navigate the system settings.

Add a Login Logo to the Login Page

Location: Management > Settings > System Settings > Login > Login Logo

1. Under Image URL, paste the link to the login logo image.
2. Check the preview at the top of the panel.
3. Click Save.

Result: The login page shows the new logo at the next page load.

Where the image can come from

Each user's browser loads the logo from the URL. tiCrypt Connect lets the app load images only from the app itself, the tiCrypt backend, data: URLs and the hosts listed under XSS allowed image sources. To use an image hosted elsewhere, such as on your institution's website:

1. Add the image's host under XSS allowed image sources and save.
2. Open the deployment again in tiCrypt Connect, so the new image source applies.
3. Set the Image URL and check that the preview shows the image.

note

• The preview shows the logo above the tiCrypt, Escrow and Sitekey tabs, as on the login page.
• An empty Image URL saves an empty address, and the login page then shows no logo. To go back to the tiCrypt logo, enter /assets/images/logo-blue.svg.

Minimum Size and Format for the Login Page Logo Picture

The minimum logo size is 600 x 280 px (width x height) in a web-supported format. Vector image files such as .eps and .svg are preferred. The Image URL field does not check the link, so use the preview to confirm the image loads.

Set Pre-Defined Login IDs for New User Account Registration

Location: Management > Settings > System Settings > Login > Login ID RegEx

1. Under Regular Expression, enter a regular expression that defines valid login IDs for new user accounts.
2. Optionally, under Test Login ID, enter a login ID to test. The hint reads "The test input matches the regex" or "Regex does not match input".
3. Review the Unmatched Login IDs block, if it appears.
4. Click Save.

Result: New registrations must use a login ID that matches the expression. Existing accounts are not changed.

info

Login ID Regular Expression controls which IDs are valid when people register their own account. If a login ID does not match the regular expression, the user cannot register. It does not apply to existing accounts.

• tiCrypt adds ^ at the start and $ at the end if you leave them out, so the expression must match the whole login ID.
• A registration ID that does not match shows the error "Must be a valid Login ID".
• If the expression is not valid, the browser's error message appears under the field. A saved expression that is not valid is ignored at registration, and the default rule applies.
• The Test Login ID hint, the error message and the Unmatched Login IDs block update one second after you stop typing.
• Unmatched Login IDs compares the expression with the login IDs of all the accounts the app has loaded.
• An empty field saves no value. The deployment file's loginIDRegex then applies, or, when the file has none, the default rule: up to 120 characters, made of letters, digits and the characters !, #, $, %, &, ', *, +, _, the backtick, {, |, }, ~, @ and .. An ID that breaks the default rule shows "Must be a valid ID or email".

caution

When the expression rejects login IDs that already exist, the Unmatched Login IDs block appears with "The regex you inputted conflicts with existing user accounts." and up to three of those IDs. Saving still works; check that the expression is the one you want.

tip

• You should restrict login ID regular expressions to your institution's domain. Example: for users with the @ticrypt.com domain, enter the expression ^[^@]+@ticrypt.com$.
• You may also exclude certain characters while keeping the standard expression for your institution's domain. Example: [a-zA-Z0-9!_~\.]+(@ticrypt\.com|@nowhere\.com).

Display a Global Login Message

Location: Management > Settings > System Settings > Login > Login Message

1. Tick Show a login message.
2. Fill in the fields described in the table below.
3. Check the preview at the top of the panel.
4. Click Save.

The following table describes the fields of the login message.

Field	Description
Icon	The icon next to the message: check, close, alert, alert-decagram, bell, calendar or calendar-alert.
Severity	The color of the message: None, ok, warn or error.
Expiration	The date the message stops showing. An entry that is not a date shows "Enter a valid date".
Message	The text of the message. Markdown is supported.

Result: The message appears on the login page, above the login box, from the next page load.

info

• The login message appears only on the login page, for everyone who opens it.
• The message stops showing at midnight at the start of the expiration date, in the time zone of the computer you saved it from. The date is checked when the login page loads. If you do not set an expiration date, the message remains until you untick Show a login message.
• To hide the message, untick Show a login message and save. The icon, severity, expiration and text are kept, so ticking the box again brings them back.

Specify a Front-End URL for Automatic Updates to the Latest tiCrypt Version

Location: Management > Settings > System Settings > Servers > Update URL

1. Under Update URL, enter the URL for automatic updates to the latest version.
2. Click Save.

Result: tiCrypt Connect checks this URL for frontend updates.

How tiCrypt Connect uses the Update URL

• The Update URL allows tiCrypt Connect to check for updates in the front-end.
• Each time a user opens the deployment, tiCrypt Connect reads the Update URL from the backend. When it differs from the URL stored for that deployment, Connect stores the new one and checks it for updates from then on.
• The URL must start with http:// or https://; otherwise the field shows "Must be a valid URL".
• An empty field saves no value. tiCrypt Connect then keeps the URL it already stored, so clearing the field does not stop updates on computers that already have a URL. To move users to another update source, save the new URL instead.

tip

Point the URL to a JSON file containing the latest version number and download URL for the latest front-end version.

Specify External Server URLs for SFTP Inbox Endpoint Encryption

Location: Management > Settings > System Settings > Servers > External Servers

1. Under SFTP Inbox Endpoint Servers, enter the server URL, for example https://sftp.example.com.
2. Click Add, or press Enter.
3. Click Save.

Result: The server is allowed in tiCrypt Connect's CORS configuration for SFTP inbox uploads.

note

This operation is necessary for the front-end to communicate with first-party external servers for SFTP inboxes. The servers must support SFTP and be able to encrypt and forward data to tiCrypt inboxes.

Server URL format

As of front-end 2.18, each entry must be a server URL, not a bare domain or IPv4 address:

• It must start with http:// or https://.
• It may include a port, such as https://sftp.example.com:8443.
• A path must end in /, such as https://example.com/sftp/.
• It cannot contain a query, a fragment, spaces, ; or ,.

An entry that breaks these rules shows "Must be a URL such as https://server.example.com (a path must end in /)" and blocks Save. A valid entry left in the box is added when you click elsewhere, without clicking Add.

How External Servers work

• What "CORS configuration" means here. When a user opens the deployment, tiCrypt Connect adds every server in both lists to the connect-src sources of the app's Content Security Policy. The app can only send requests to the tiCrypt backend and to the servers listed there.
• SFTP Inbox Endpoint Servers are the choices of the SFTP Server list when users create an SFTP inbox. The Vault also loads the inbox portals of each server.
• tiCrypt adds a missing trailing / to each URL and ignores duplicates.
• The Inbox URLs in the same panel are not added to the Content Security Policy. They are only the start of the links senders open, and the app never sends requests to them.
• When it applies. The SFTP Server list changes at each user's next app load. Requests to a new server are allowed only after the user opens the deployment again in tiCrypt Connect.
• These lists are not the External SFTP Servers table under Miscellaneous, which holds the servers users can push Vault files to.

Specify Survey Deployment Server Domains or IPv4 Addresses for Submitting Encrypted Surveys

Location: Management > Settings > System Settings > Servers > External Servers

1. Under Survey Deployment Servers, enter the server URL, for example https://surveys.example.com.
2. Click Add, or press Enter.
3. Click Save.

Result: The server is allowed in tiCrypt Connect's CORS configuration for public surveys.

note

This operation is necessary for the front-end to communicate with first-party external servers for public surveys. The servers must host a web interface for filling out and submitting E2E-encrypted surveys. Entries follow the same server URL format as SFTP inbox endpoint servers.

Remove Server Domains or IPv4 Addresses for Encrypted SFTP Inbox Endpoints and Public Surveys

Location: Management > Settings > System Settings > Servers > External Servers

1. Under SFTP Inbox Endpoint Servers or Survey Deployment Servers, find the server URL to remove.
2. Click the trash icon next to it.
3. Click Save.

Result: The server is no longer allowed in tiCrypt Connect's CORS configuration.

Set Inbox URLs for Non-User Uploads into the Vault

Location: Management > Settings > System Settings > Servers > External Servers

1. Under Inbox Settings, in Inbox URLs, enter the URL of an inbox upload page, for example https://inbox.example.com/upload.
2. Click Add, or press Enter. Repeat for each upload page users can pick from.
3. Click Save.

Result: Users pick one of these URLs when they create a URL inbox, and the links they copy start with the URL they picked.

info

• Use a fully qualified URL where the web interface for uploading to an inbox is hosted. See Inbox Upload Page.
• The inbox link users copy is the URL followed by ?cert= and the access point's certificate. Do not end the URL with a query, such as ?lang=en.
• Test a copied inbox link after you save.
• An empty Inbox URLs list falls back to the inbox URL in the deployment file.

Inbox URL format

As of front-end 2.18.3, each entry must be a URL:

• It must start with http:// or https://.
• It may include a port and a path, such as https://inbox.example.com:8443/inbox/index.html.
• It cannot contain ?, # or spaces.

An entry that breaks these rules shows "Must be a URL such as https://inbox.example.com/upload (without ? or #)" and blocks Save. A valid entry left in the box is added when you click elsewhere, without clicking Add. URLs saved before 2.18.3 are not checked again.

How users pick an inbox URL

• The first URL is the default. It is preselected in the inbox form, and the form shows no choice when the list has only one URL. A new URL goes to the end of the list; to make another URL the default, remove the ones above it and add them again.
• Each access point keeps its URL. The link to share in Manage inbox uses the URL picked when the access point was created. Access points created before front-end 2.18.3, and those whose URL you have since removed, use the first URL.
• One Save, two settings. Save saves the SFTP Inbox Endpoint Servers and the inbox settings together, but only the ones you changed. System Settings History lists them as External Servers and Inbox Settings.
• Older front-ends use only the first URL. Saving this setting from a front-end before 2.18.3 keeps only the first URL and drops the rest of the list.

Remove an Inbox URL

Location: Management > Settings > System Settings > Servers > External Servers

1. Under Inbox Settings, in Inbox URLs, find the URL to remove.
2. Click the trash icon next to it.
3. Click Save.

Result: Users can no longer pick the URL when they create a URL inbox. Links to share for access points that used it start with the first URL in the list.

Links already sent keep the removed URL

Senders who already received a link still open the removed URL. Keep that upload page online until the access points that used it expire, or ask their owners to send new links.

Set Maximum Allowed Inbox Token Duration for Non-User Uploads into the Vault

Location: Management > Settings > System Settings > Servers > External Servers

1. Under Inbox Settings, in Maximum allowed inbox token duration (days), enter the maximum inbox token duration, from 1 to 3650 days. A value outside that range shows "Must be between 1 and 3650 days".
2. Click Save.

Result: Users cannot create inbox access longer than this many days. The default is 365 days.

note

• The Inbox URLs and the maximum duration save together, as one setting (Inbox Settings in System Settings History).
• An empty duration falls back to 365 days.
• The maximum is the latest date the expiration picker offers when users create or change an inbox access point. Access points that already exist keep their expiration.

Specify URLs Allowed Through tiCrypt's XSS Protection

Location: Management > Settings > System Settings > Servers > XSS Headers

1. Under XSS allowed links, enter the domain or IPv4 address to allow through tiCrypt XSS protection.
2. Click Add.
3. Click Save.

Result: The entry is saved in the XSS allowed links list.

note

The XSS Headers lists do not check the format of an entry. Check each entry before you save it.

How XSS Headers work

When a user opens the deployment, tiCrypt Connect builds the app's Content Security Policy, the browser rule that decides what the app may load. The two lists add sources to it:

List	Policy sources	What it allows	Always allowed
XSS allowed links	child-src and frame-src	Pages shown inside the app in frames, such as embedded help or videos.	The app itself, blob:, https://accounts.google.com, https://ticrypt.com, https://challenges.cloudflare.com, https://player.vimeo.com
XSS allowed image sources	img-src	Images, such as a Login Logo hosted elsewhere.	The app itself, data:, blob:, the tiCrypt backend

• Write each entry as a source of the policy, such as https://images.example.edu or https://*.example.edu.
• A change applies when each user next opens the deployment in tiCrypt Connect. Reloading an open app is not enough.

Saved lists replace the deployment file's XSS headers

Once you save XSS Headers, tiCrypt Connect uses only the saved lists, and ignores the xssHeaders of the deployment file, including any other policy sources the file sets. Copy any entries from the file that are still needed into these lists before you save.

Specify Image Sources Allowed Through tiCrypt's XSS Protection

Location: Management > Settings > System Settings > Servers > XSS Headers

1. Under XSS allowed image sources, enter the domain or IPv4 address to allow through tiCrypt XSS protection.
2. Click Add.
3. Click Save.

Result: The entry is saved in the XSS allowed image sources list.

Remove Server Domains or IPv4 Addresses from tiCrypt's XSS Protection Whitelist

Location: Management > Settings > System Settings > Servers > XSS Headers

1. Under XSS allowed links or XSS allowed image sources, find the entry to remove.
2. Click the trash icon next to it.
3. Click Save.

Result: The entry is removed from the list.

Edit the User Inactivity Period Before Their Private Key is Cleared from Memory

Location: Management > Settings > System Settings > Timeouts > Private Key Timeout

1. Under Minutes, enter the number of minutes, from 1 to 1440, before the user's private key is cleared from memory. A value outside that range shows "Must be between 1 and 1440 minutes".
2. Click Save.

Result: Each user's private key is cleared after this many minutes without use: in your own session right away, and for other users from their next login.

info

• The timer runs from the last time the private key was used. An operation that is still running, such as a transfer, keeps the key in memory until it ends.
• Clearing the key does not lock the screen. Users can still browse; the password prompt appears when they next do something that needs the key, such as connecting to a VM, viewing or sharing a file, or creating anything.
• The default is 20 minutes. An empty field saves no value: the deployment file's purgeKeyTimeout then applies, or 20 minutes when the file has none.

Edit the User Inactivity Period Before Their Screen Locks

Location: Management > Settings > System Settings > Timeouts > Session Timeout

1. Under Minutes, enter the number of minutes of inactivity, from 1 to 1440, before the screen locks. A value outside that range shows "Must be between 1 and 1440 minutes".
2. Click Save.

Result: Each user's screen locks after this many minutes without activity: in your own session right away, and for other users from their next login.

How Session Timeout works

• Activity means clicking, typing, scrolling or moving the pointer in tiCrypt, file-transfer progress, and input in a VM console.
• Lock. After Session Timeout minutes without activity, the screen locks and hides the app. The user unlocks it with their private key password.
• Locked too long. If the screen stays locked for another Session Timeout period, the server session is ended. Unlocking then performs a full login, including MFA unless a cached MFA token is still valid.
• Automatic logout. The user is logged out 60 minutes after the screen would lock (last activity plus Session Timeout plus 60 minutes; the 60 minutes are fixed). The lock screen also shows its own countdown, "You will be logged out automatically in", which runs from the moment the screen locked (60 minutes by default, set by refreshPageWhenLockedTimeout in the deployment file). The user is logged out when either timer runs out.
• Session Timeout is not Private Key Timeout. Private Key Timeout clears the key but leaves the app visible; Session Timeout locks the whole screen.
• The default is 15 minutes. An empty field saves no value: the deployment file's lockSessionTimeout then applies, or 15 minutes when the file has none or sets 0.

Allow Copy to Clipboard for User Roles

Location: Management > Settings > System Settings > User > Copy Settings

1. Under Copy to clipboard, select Nobody, Super-Admins only, Admins or higher, Sub-admins or higher, or Everybody.
2. Click Save.

Result: Users at or above the selected role can use the copy buttons and select text in the app: in your own session right away, and for other users from their next login.

note

The Copy to clipboard setting covers these copy buttons:

• Vault: the inbox URL and the SHA-256 hash.
• Virtual machines: the VM startup username and password, VM SFTP, VM XML, the drive ID in drive details, the timestamp in the video previewer, and the JSON viewer.
• Management: the API key and the mass user email.

Users below the selected role also:

• cannot select text anywhere in the app;
• cannot copy with Ctrl+C or Cmd+C in the app;
• cannot use the copy or paste shortcuts of a VM terminal (Ctrl+Shift+C and Ctrl+Shift+V, or Cmd+C and Cmd+V), which show "Clipboard access is disabled for your account. Contact your administrator."

The setting does not apply to the login page. The default is Nobody.

Add User Helpdesk Resources in the Top-Right Menu

Location: Management > Settings > System Settings > User > User Helpdesk

1. In one of the five rows, under Label, enter the display text for the helpdesk resource.
2. Under Link (optional), enter the URL of the helpdesk resource, or leave it empty for a phone number.
3. Repeat for up to five resources.
4. Click Save.

Result: The resources appear in every user's menu from their next login.

note

• Helpdesk resources appear in the user menu in the top-right corner of the interface, after Change Password. Each opens in a new tab.
• A row without a label is discarded.
• A row without a link is treated as a phone number: the link becomes a tel: link made of the letters and digits in the label. A phone link you enter yourself must begin with tel:. While Link (optional) is empty, it shows the tel: link the label would produce.
• The links are not checked. Enter full addresses, such as https://help.example.edu.
• The entries you save here replace any helpdesk entries in the deployment file. Saving all five rows empty removes every helpdesk entry, including those in the file.

Edit the Global Password Strength Requirements for New Users

Location: Management > Settings > System Settings > User > Password Strength

1. Select one of the following:
   • Anything goes, no matter how weak
   • Passwords may be weak
   • Passwords must be decent
   • Passwords must be strong (the default)
   • Passwords must be very strong
2. Click Save.

Result: New passwords must meet the selected strength.

info

• The requirement applies to account registration, Escrow account registration, Site Key creation and password changes.
• New users must meet the new requirement from the next page load. Existing users are subject to it only when they next change their password.

tiCrypt rates each password with the zxcvbn library, which estimates how many guesses an attacker would need, and gives it a score from 0 to 4. A password whose score is below the selected level is refused. The following table describes the levels.

Option	Minimum score	Passwords refused
Anything goes, no matter how weak	0	None
Passwords may be weak	1	Those guessable in under about 1,000 guesses
Passwords must be decent	2	Those guessable in under about 1,000,000 guesses
Passwords must be strong (the default)	3	Those guessable in under about 100,000,000 guesses
Passwords must be very strong	4	Those guessable in under about 10,000,000,000 guesses

The password protects the user's private key, so a stronger level makes a stolen encrypted key harder to open.

Enable Admin Session Downgrades for a Limited Time

Location: Management > Settings > System Settings > User > Admin Session Downgrade

1. Select which admins can downgrade their session: Super-Admins only, Admins or higher, or Sub-admins or higher.
2. Click Save.

Result: At their next login, eligible admins can choose a user profile with fewer permissions for that session.

What admins see

• After login, an eligible admin sees the notice "Admin session downgrade enabled. You can temporarily assume a role with reduced privileges..." and a list with Your existing account and the user profiles they can use. They pick one and click Login.
• The list holds user profiles that answer Yes to Can user profiles be used for session downgrades? (under the advanced options of the user profile) and whose role and permissions do not exceed the admin's own. If no profile qualifies, the admin goes straight into the app.
• A downgraded session shows the banner "Your session has been downgraded to <profile>". The downgrade lasts until the admin logs out.
• If the switch fails, the admin sees "Failed to swap profile" and is logged out.

info

To disable admin session downgrade, select Disable admin session downgrade under the same settings. This is the default.

Set the Frequency for Caching Users' Private Keys in Browser Local Storage

Location: Management > Settings > System Settings > Caching > Private Key Caching

1. Select Always cache the user's private key upon successful login, Never cache the user's private key, or Let the user decide if their private key gets cached.
2. Click Save.

Result: From the next login, encrypted private keys are cached according to the selected option.

note

This setting controls whether users' encrypted private keys are cached in browser-local storage. Local storage persists through browser restarts and computer reboots.

• Let the user decide adds the checkbox Remember ALL imported keys even through computer restarts to the login page.
• The default is Never.

Enable or Disable Multi-Factor Authentication (MFA) Caching Upon Login

Location: Management > Settings > System Settings > Caching > MFA Caching

1. Select Always cache multi-factor tokens upon successful login, or Never cache multi-factor tokens.
2. Click Save.

Result: From the next app load, MFA tokens are cached according to the selected option.

info

• MFA tokens are always kept in the browser's session storage, which is cleared when all tiCrypt tabs, or the application window, are closed.
• Always also stores the tokens in the browser's local storage, so they survive closing the browser. Never removes any stored copy when the app starts. The default is Never.
• A cached token is reused until 5 minutes before it expires. How long a token lasts is set on the backend by the factor's token-ttl. See the MFA configuration.

Globally Set a Default File Share Duration

Location: Management > Settings > System Settings > Files > Default File Share Duration

1. Under Days, enter the number of days, from 1 to 1440, that the share expiration date picker starts at. A value outside that range shows "Must be between 1 and 1440 days".
2. Click Save.

Result: When users share files with users and groups, the expiration date is prefilled this many days ahead.

note

This value is only the prefilled expiration date. It is not a minimum, users can change it, and it does nothing when the user chooses Does not expire. The default is 30 days.

Enable CUI Disclosure On-Screen

Location: Management > Settings > System Settings > Notices > CUI Disclosure

1. Tick where the CUI disclosure appears:
   • Display a banner on the top of the page
   • Pop up a dialog forcing the user to acknowledge every time they log in
2. If you ticked the dialog option, edit the dialog's text in the Markdown editor, and click Test dialog to preview it.
3. Click Save.

Result: From their next login, users see the banner, the dialog, or both.

note

• All ticked options are shown at the same time. To turn the CUI disclosure off, untick both options. Both are off by default.
• The banner reads "THIS SYSTEM CONTAINS CUI" across the top of the app.
• The dialog is titled "FOR USERS OF CUI" and appears at every login, before the terms of service. Accept continues into the app; Decline logs the user out.
• If you leave the dialog text empty, users see a default text on handling CUI that refers to "university policies". The editor starts with that text when no text is saved. Replace it with your institution's wording.
• Unticking the dialog option hides the editor, but the text is kept and saved with the setting.
• Test dialog appears only when the dialog option is ticked. With no text entered, it shows "You have not entered any markdown".
• The test dialog behaves exactly as users see it: Accept closes it, and Decline logs you out.

info

Front-end versions before 2.18.0 also offered Display a banner on the bottom of the page. That option never showed a banner, and was removed.

caution

When the CUI disclosure appears as a modal, all users must accept the CUI disclosure to continue using tiCrypt.

Implement Terms of Service into the System

Location: Management > Settings > System Settings > Notices > Terms of Service

1. Enter the terms of service in the Markdown editor.
2. Under How often to display, select Once, Every year, Every month (the default), Every day, Every time or Never.
3. Click Save.

Result: From their next login, users see the terms of service dialog according to the selected frequency.

note

• The terms of service are displayed to all users at least once when active. All users, regardless of role, must agree to the terms of service before they can use tiCrypt. Never turns the dialog off.
• The dialog appears after login, after the CUI dialog if that is on. It does not appear if the user's last acceptance is newer than both the last change to the text and the selected interval. When you change the text, the terms are displayed again regardless of the interval.
• Accept records the date. It shows in the TOS Accepted column of the Users table and as "Last accepted TOS on" in the user's details.
• Decline logs the user out. Pressing Esc or clicking outside the dialog shows "You must accept the terms of service".
• There is no default text.

The following table describes when each frequency shows the dialog.

How often to display	The dialog appears at login when
Once	The user has never accepted the terms, or the text changed since they last accepted.
Every year	The user's last acceptance is more than 365 days old, or the text changed since.
Every month	The user's last acceptance is more than 30 days old, or the text changed since.
Every day	The user's last acceptance is more than one day old, or the text changed since.
Every time	Always, at every login and app load.
Never	Never. The text is kept.

info

• The date of acceptance is stored with the user's account, not in the browser, so it applies on every computer the user logs in from.
• Saving a new frequency without changing the text does not count as a change of the text. Users see the terms again only when their last acceptance is older than the new interval.
• Saving the same text again does not show the terms again. Any change to the text, even a single character, does.

caution

Saving the terms with no text and a frequency other than Never shows users an empty terms of service dialog that they must still accept. Select Never to turn the terms off.

Test the Terms of Service Display

Location: Management > Settings > System Settings > Notices > Terms of Service

1. Click the Test dialog button to preview the terms of service.
2. Click Accept to close the preview. Decline logs you out, exactly as it does for users.

Result: The preview shows the terms of service as users see them. With no text entered, tiCrypt shows "You have not entered any markdown" instead.

Download the Terms of Service

Location: Management > Settings > System Settings > Notices > Terms of Service

1. Click the Test dialog button.
2. In the terms of service pop-up, click Download.
3. In the local prompt, select the download destination folder.
4. Click Save.
5. Click Accept to close the preview.

Result: The terms of service are saved as a plain-text file named <deployment name>_terms-of-service_MM-DD-YYYY.txt.

note

Users can download the terms of service the same way from the dialog they see at login.

Configure Track Drive Backup

Location: Management > Settings > System Settings > Drives > Track Drive Backup

1. Select Yes to enable or No to disable track drive backup. The default is No.
2. Click Save.

Result:

With Yes, the drive create, edit and upload-config forms show Backup settings, with the options Never back up this drive and This drive may be backed up, and the Drives table shows a Backup column.

note

• The external API adds backup information for the drives. This does not enable tiCrypt backup; it only tracks backup information for external use.

Set a Windows Domain for RDP Connections

Location: Management > Settings > System Settings > VMs > Windows VM Domain

1. Tick Enable Windows domain for RDP connections.
2. Under Windows Domain, enter the Windows domain name to use for all Windows VMs. The field is required while the box is ticked ("Windows domain is required when the setting is enabled.").
3. Click Save.

Result: Generated RDP connection files for Windows VMs use this domain. It applies once the setting is saved: in your own session right away, and for other users at their next login or app load.

note

To go back to each VM's own domain, untick Enable Windows domain for RDP connections and save. When the setting is off, RDP files use the domain or host name that each VM reports. If the deployment file sets windowsDomain, unticking the box brings back that domain instead.

Deployment File Keys

Each System Settings value is stored under a key of the deployment file, and a value saved in System Settings overrides the key's value in the file (see Saved Values and the Deployment File). The same keys appear in the Field column of System Settings History. Two related keys can be set only in the deployment file.

The following table describes the deployment file keys behind the settings on this page.

Key	Setting	Default
loginLogo	Login Logo	/assets/images/logo-blue.svg
loginIDRegex	Login ID RegEx	Not set
loginBanner	Login Message	Not set
updateURL	Update URL	Not set
externalServers	External Servers: the server lists	Empty
xssHeaders	XSS Headers	Empty
mailbox	External Servers: Inbox Settings	Maximum duration 365 (days)
purgeKeyTimeout	Private Key Timeout	20 (minutes)
lockSessionTimeout	Session Timeout	15 (minutes)
copyClipboardAccess	Copy Settings	Nobody
helpdesk	User Helpdesk	Empty
requiredPasswordStrength	Password Strength	3 (Passwords must be strong)
sessionDowngrade	Admin Session Downgrade	Disabled
storeEncryptedPrivateKey	Private Key Caching	"no"
storeMultifactorToken	MFA Caching	Not set (Never)
daysSharingExpires	Default File Share Duration	30 (days)
cuiBanner	CUI Disclosure	Banner and dialog off
termsOfService	Terms of Service	Not set
allowAuxiliaryDriveBackup	Track Drive Backup	false
windowsDomain	Windows VM Domain	Not set
refreshPageWhenLockedTimeout	Deployment file only: the lock-screen logout countdown.	60 (minutes)
passwordLength	Deployment file only: the maximum password length.	64 (characters)

Related

• System Settings History: every change saved on this page, with the old and new value and who made it.
• Custom Fields: the other item in the Settings section, for extra fields on teams and projects.
• Session Lock: what users see when Session Timeout locks their screen, and how they unlock it.
• User Profiles: where you mark a user profile as usable for admin session downgrades.
• MFA configuration: the backend settings that decide how long MFA tokens last.