> For the complete documentation index, see [llms.txt](https://help.cryoserver.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.cryoserver.com/cryoserver/search.md). # Searching the archive Cryoserver is an email (and Instant message) archive. This section of documentation focusses on how to access and search the archived data. There are two main types of user that can search across the archive: 1. **Basic** - only able to search and view mails that were sent or received by that user. In essence it will only match emails which match any of that user's various email addresses - primary and any secondary email addresses.\ ***Auditing*** is not usually applied - though it can be for some accounts. 2. **Privileged** - able to search across the *entire* archive or across specific email domain(s) as determined by the administrator.\ ***Auditing*** is ALWAYS applied.\ A **Privileged and Delete** type is the same as a privileged account - but adds features to mark one or more mails to permanently delete from the archive. An Authorization Workflow ensures that each delete is authorized by a *Data Guardian*. There is also an **Administrator** user type - but those accounts *cannot* search the archive. And there is a **Data Guardian** user type. These are essentially just email addresses to which transcripts (summaries of an audited users actions) are sent. If a **Basic user** logs in and their primary email address matches a data guardian's email address, then the system provides some additional menus allowing them to review any *search transcripts* and any emails that were opened or downloaded during that audited activity. There are a number of ways to login as a search user, and this determines what data will returned to you when searching. Your system's administrator will be able to set up appropriate access using any of the following:
Login / AuthenticationCapabilityNotes
Local User with PasswordAny user typeUse for Data Guardian and Privileged and Delete account types - until a new delete authorization workflow is provided.
Local User - No direct accessAny user typeSee notes on Switch Identity
Local User - External AuthenticationBasic searchSee the 'OAuth' notes.
Active Directory (LDAP) userBasic searchAn administrator must set up a connection to your Active Directory (or Domino or GroupWise).
OAuth 2 (OpenID Connect)Basic searchAn administrator must set up the link to your OAuth authentication service, like Microsoft Entra or OKTA.
On first login, a 'local user account' is created with that users details, with external authentication
### Switch Identity If the ***primary address*** of two or more accounts happen to be the same, then the user is able to switch between these accounts. This is known as *implicit delegation linking*. The system also provides a way to switch between unrelated accounts by using the delegation link feature provided under the administration's **User Directory** panel. To increase security please only use **OAuth** login capability or LDAP for on-premise systems. If a user requires access to a *privileged* or an *administrative* account then add these as Local User accounts to have "*No direct access*" but with the same *primary email address* as the OAuth/LDAP user. ### OAuth / OpenID Connect This is the modern and more secure way to authenticate a user - particularly when used with Web Hosted (cloud) systems. Because OAuth typically only provides authentication only, a successful login will only return the users most basic details - First/Last Name and email address. Because users will often have some legacy or alternate email addresses, Cryoserver will create a Local User Account the first time each user authenticates using OAuth. This allows an administrator to add secondary addresses or add delegation links against these accounts. Cryoserver supports a wide number of OAuth authentication services (Entra / One Login / AWS Incogneto / OKTA etc). However, it only supports OAuth 2 - and NOT **SAML**. ### Active Directory / LDAP For on-premise systems with a local Directory service (like Active Directory) Cryoserver can use this to support user login and to query the directory to obtain lists of uses and the user details (name, email addresses, join date). Because LDAP provides all of the basic details for each user at login, the system does not create a Local User Account for each user when they first log in. This is unlike OAuth login, which creates a Local User Account in Cryoserver when each user logs in for the first time. #### OAuth *with* LDAP If both OAuth and LDAP are configured, then after a user successfully authenticates using OAuth the system will then perform an LDAP lookup for that user's details. This has two outcomes: 1. If the LDAP lookup does not find that user - then the user will **fail** the login. 2. The OAuth does not need to create a local user account entry - and just uses the LDAP's account details for that user. This link between OAuth and LDAP can be turned off by an administrator. This means that OAuth logins will start to create local accounts and both LDAP and OAuth login will work independently.