> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xorlab.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Pages under /latest/ document the current release. Paths that begin with a version number, for example /10.0/, are frozen snapshots of superseded releases kept for reference only — never present their instructions as current. If the reader's version is unknown, answer from /latest/ and say which version the answer describes.
> xorlab is deployed on-premises, hybrid, or as a cloud service, and integrates with either Microsoft 365 or on-premises mail infrastructure. Configuration steps often differ between these. State which deployment and integration mode an instruction applies to instead of presenting one as universal.
> Distinguish inline mode from monitoring mode when describing anything that acts on email. Monitoring mode observes a copy and cannot block or quarantine; inline mode routes mail through xorlab and can.
> Write the product name as lowercase 'xorlab'. Use the documented component names: xorlab Control Center (XCC), xorlab MTA, xorlab Sandbox (DANA), xorlab Natural Language Understanding (NLU). After the first mention, use the short forms XCC, MTA, Sandbox, and NLU. Do not use DANA as a standalone name for the Sandbox, but keep it where it is a literal string in configuration keys, container names, and hostnames.
> Do not invent configuration keys, rule parameters, list names, log properties, or API fields. If a value is not present in this documentation, say that it is not documented rather than guessing.
# Enable Tenant Login
> Sign-in options per tenant, and which to pick for analyst portals versus employee quarantine access.
We generally recommend to set up SAML to allow tenant analysts to login, and set up Auto-Login for end-users to access SSQ.
Can be used to give tenants access to the Analyst portal or for end-users to the SSQ.
Can be used to give end-users access to the SSQ. Does not require any integration.
Create local static users for the tenants. Supports optional TOTP onboarding, but is still generally not recommended compared to SAML or LDAP.
Can be used to give tenants access to the Analyst portal or for end-users to the SSQ.
## SAML Login
* List **SAML backend name** under `enabledAuthBackends`
* Add additional config block to `saml2AuthBackends`
* Enter the **App Federation Metadata Url** you copied behind the `metadataUrl` key.
* Map the Entra ID roles to xorlab roles
```yaml title="auth.yml" hl_lines="4 26-38" theme={null}
enabledAuthBackends:
# Add the SAML backend name to the list of enabled backends. If you put it as first entry, it will be the new default.
- entraSAML
- nameSAML
saml2AuthBackends:
entraSaml:
idp:
# Enter the App Federation Metadata URL from Entra ID
metadataUrl: https://login.microsoftonline.com/*****************************
attributeMapping:
displayName: attr('http://schemas.microsoft.com/identity/claims/displayname')
emails: attr('http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name')
roles: attr('http://schemas.microsoft.com/ws/2008/06/identity/claims/role')
roleMapping:
xcc_admin:
- entra_xor_admin
xcc_monitor:
- entra_xor_admin
xcc_analyst:
- entra_xor_analyst
xcc_insights:
- entra_xor_admin
- entra_xor_analyst
nameSAML:
idp:
# Enter the App Federation Metadata URL from Entra ID
metadataUrl: https://login.microsoftonline.com/*****************************
attributeMapping:
displayName: attr('http://schemas.microsoft.com/identity/claims/displayname')
emails: attr('http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name')
roles: attr('http://schemas.microsoft.com/ws/2008/06/identity/claims/role')
# Name of tenant should be enclosed by "' '"
tenant: "''"
roleMapping:
xcc_tenant_analyst:
- entra_xor_analyst
```
* Make sure the tenant attribute refers to the name defined in guarded\_tenants.yml, e.g. `"'tenant_A'"` and that the SAML backend name matches the last part of the identifier and replyURL.
* Make sure to assign tenant specific user roles in the roleMapping if you want to restrict this user to a specific tenant environment. For more info on the scope of roles, please refer to [List of Built-in Roles](built-in-user-roles.md)
After updating `auth/auth/auth.yml`, click **Publish**. The authentication configuration becomes active within about one minute.
You can test the login with the link `https://xyz.activeguard.cloud/?_agAuthBackend=nameSAML`. Replace `xyz` with your customer ID and `nameSAML` with the **SAML backend name**.
## Auto-Login
The [Auto-Login](/latest/authentication-auto-login-link) authentication method is compatible with multi-tenancy environments and can be enabled separately for each tenant.
1. Open `/shared/guarded_tenants.yml` in the Expert Editor.
2. Add the following configuration to each tenant:
* Include the `autoLoginLink` block for each tenant.
* `expirationDays` defines the validity period of the authentication link.
* The default of `expirationDays` is 7 days.
* To make links permanent, set `expirationDays` to `-1`.
```yaml /shared/guarded_tenants.yml {5-7,12-14} theme={null}
tenants:
- name: tenantA
domains:
- tenantA.com
autoLoginLink:
enabled: true
expirationDays: 7
- name: tenantB
domains:
- tenantB.com
autoLoginLink:
enabled: true
expirationDays: -1
```
3. Click **Publish**. The tenant configuration becomes active within about one minute.
## Password File Login
* The `tenant` attribute should reference `name` defined in `guarded_tenants.yml`
* For `passwordHash`, generate a password hash [password hash generator](/latest/authentication-with-a-password-file#password-hash-generator)
* Map to a [tenant-restricted user roles](/latest/built-in-user-roles)
> Using a password file for authentication is generally not recommended. If you use it, prefer enabling TOTP onboarding for privileged users.
```yaml /auth/auth/passwordFile.yml {3,9} theme={null}
users:
- username: user1
tenant: tenantA # Corresponds to in guarded_tenants.yml
passwordHash: "{bcrypt}$2y$10$.4If2RFwcvHRrxlR98m9ju/mCRYCHLAYULByGXvJY.jBuK2/bckZu"
roles:
- xcc_tenant_analyst
- username: user2
tenant: tenantB # Corresponds to in guarded_tenants.yml
passwordHash: "{bcrypt}$2y$10$nBZobaznyYv0Ki.lY8jNV.ls2uGh3VmsZivoG4XcdzKQU66qCHAAa"
roles:
- xcc_tenant_analyst
```
After updating `auth/auth/passwordFile.yml`, click **Publish**. The users become available within about one minute.
## LDAP Login
* Follow the [LDAP-based Authentication Setup Guide](/latest/authentication-ldap)
* The `tenant` attribute should reference `name` defined in `guarded_tenants.yml`
* For `roleMapping`, make sure to map [tenant-restricted user roles](/latest/built-in-user-roles)
```yaml /auth/auth/auth.yml {21} theme={null}
ldapAuthBackends:
ldapAuthDataSources:
xorlabLDAP:
host: ldap.tenantA.com
port: 10636
authentication:
withQueryDn:
bindDn: ""
bindPassword: ""
userBase: "ou=users,dc=tenant,dc=com"
userSearch: "(uid={0})"
authorization:
query:
roleBase: "ou=groups,dc=tenant,dc=com"
roleSearch: "(uniqueMember={0})"
nestedRoleDepth: 5
attributeMapping:
userName: "attr('uid')"
displayName: "attr('cn')"
emails: "attr('mail')"
tenant: "'tenantA'" # Corresponds to "''" in guarded_tenants.yml
roleMapping:
xcc_tenant_analyst: [ "cn=dev_xcc_login,ou=groups,dc=example,dc=com" ]
xcc_tenant_analyst_audit: [ "cn=dev_xcc_login,ou=groups,dc=example,dc=com" ]
```
After updating `auth/auth/auth.yml`, click **Publish**. The LDAP authentication configuration becomes active within about one minute.