Auth Zextras

By adminUncategorized

Describe Zextras Auth

The Zextras Suite module known as Zextras Auth affects several aspects of accessing a Zextras instance after the Login Page, including:

  1. the mode of access. The access mask varies depending on the specified authentication backends, allowing users to submit their credentials using any backend. The ZxAuth for users (Auth Zimlet) also reflects this.
  2. Customisations. Describe the appearance of the login page. For a list of customizable elements, see the dedicated section Custom Login Page.

All of the Zextras-supported Authentication Strategies (user/pwd, SAML, 2FA, MobilePwd, and QrCode) and Service Authorizations may be managed with Zextras Auth.

This section is arranged as follows and is separated into three main sections. The description of each supported authentication method can be found immediately below; the next two sections are devoted to administration tasks, which need privileged access and are typically completed from the CLI, and daily tasks, which can be completed by both administrators and users from the Web GUI, respectively. Finally, a reference list of every CLI command is provided, along with links to each command.

Approved Authentication Techniques

Backends that Zextras Auth supports include:

  • Management of self-service credentials
  • Management of mobile passwords
  • password for the software
  • individual login page
  • Integration of SAML
  • OTP token for 2FA authentication
  • Management of Credentials via CLI
Management of Self Service Credentials

Every user has the ability to generate new passwords and QR codes for third parties—such as team members or personal assistants—to access their email accounts and Zextras Applications from mobile devices thanks to self-service credential management.

You may access the Team and Drive Zextras Apps in particular by scanning QR codes.

Section ZxAuth for users (Auth Zimlet) has further details and step-by-step instructions.v

Unique Login Page

The login page for Zextras allows users to access all of the software’s features and may be personalised in a number of ways, such as by adding a company’s logo or other components of its corporate identity.

Because this functionality operates through the CLI, administrator credentials are required; further details and instructions are provided in the section on Custom Login Page.

The Security Assertion Markup Language (SAML), an open standard data format based on XML, is used to exchange authentication data. It makes it possible for web-based authentication and authorization situations like cross-domain Single Sign-On (SSO), which lets users access several apps using the same login information.

An external IDentity Provider (IDP), to which a user authenticates, is used in Zextras’ SAML implementation. The IDP subsequently transmits authorization credentials to a service provider (SP). The process of confirming a user’s identity and credentials is known as SAML authentication. SAML configuration for Zextras Suite is minimal since an administrator may create it by importing SAML information from the ISP. Both SDP and IDP SAML authentication are enabled, and each domain is allowed to have its own unique SAML endpoint.

The fundamental ideas of SAML authentication are as follows:

The organisation offering the service is called a service provider (SP).

The organisation supplying IDs is known as an identity provider (IdP).

The Service Provider creates a SAML Request to “request” an authentication.

The Identity Provider generates the SAML Response, which provides the user’s assertion of authentication.

Additionally, in accordance with partner requirements, the SSO tokens are transmitted to the Assertion Consumer Service (ACS) endpoint.

In Section Setting up SAML Configuration, instructions are provided for configuring SAML and integrating other apps with Zextras Suite.

Two Factor Authentication (sometimes abbreviated as 2FA) adds an extra layer of protection to the login process, decreasing the likelihood that unauthorised access may occur. In Zextras, this extra layer is provided through a One Time Password (OTP), which a mobile device may read as a QR code.

When 2FA is enabled on a Zextras domain, entering just a username and password will not allow you to log in; you must also have an OTP. Additionally, for 2FA to function successfully, the domain must be defined with the attribute zimbraAuthMech.

By using the trusted_device or trusted_ip parameters, 2FA may be set up at the device, IP, or IP range level and only applies to protocols or apps that enable it, such as HTTP and HTTPS but not IMAP and SMTP. When an IP address or range is trusted, 2FA will work for any login coming from there, but the trusted_device only works when the same app or browser is used; for example, if a 2FA login is performed on Chrome, viewing the same page with Firefox will require a new login.

The site administrator must set up a domain (see QR Code Requirements) before users can utilise the OTP; users may do this by using the Auth Zimlet.

Admins can use ZxAuth.

The tasks administrators may perform to monitor and keep up Zextras Auth are covered in this section. The prerequisites for the various authentication techniques are listed here, followed by installation instructions for administrators. After managing credentials, there is an opportunity to design the login page.

Conditions QR Code Conditions

The following settings must be specified at the domain level in order for the QR Code Application Password functionality to work:

  • zimbraPublicServiceHostname
  • zimbraPublicServicePort
  • zimbraPublicServiceProtocol

A message will be sent to the administrator if one or more of the attributes are not set, listing the affected domains and their unset properties.

2FA Conditions

The zimbraAuthMech property must be specified at the domain level in order to correctly set up 2FA:

In order to enable 2FA, you must also:

  • Using the command: Enter the addresses of each mailbox and MTA as ZimbraMailTrustedIp.
  • All services must have a specified trustworthy IP range.
  • All services must have the ip_can_change property verified on true and 2fa_policy set to 1.

Because these header attributes are necessary to create the whole URL request, the Zextras Backend processing must be changed before allowing SAML login: both X-Port and Protocol X.

The templates are the files impacted by this change:

  • nginx.conf.web.http.default.template
  • nginx.conf.web.http.template
  • nginx.conf.web.https.default.template
  • nginx.conf.web.https.template
  • The /zx/ code position has to be altered in each of them.

The Zextras Auth Zimlet installation

Run zxsuite auth doDeployAuthZimlet as the zimbra user on any mailbox server in your environment to install the Zextras Auth Zimlet.

Unique Login Page

The Auth module offers the option to alter how other users perceive the Login Page.

The login page’s title, logo, background, and favicon can all be changed at the domain level.

Setting up the Login Page

Set the configuration keys for zimbraWebClientLoginURL and zimbraWebClientLogoutURL to enable the Login Page for a domain (in this case, example.com). By adding the next two values from the GUI, you may do this:

The following CLI command, which configures the authentication mechanism (zimbraAuthMech) as well, can accomplish the same task:

Making the Login Page Your Own

The loginPage Auth CLI command may be used to modify the Login Page.

Sizes and Locations of Image Files

Custom image files used by the Login Page can be hosted locally or embedded from a remote location using Zextras Auth. You may utilise image files for your logo, background, and favicon.

A logo picture should be 320×80 pixels in size. Other sizes can be utilised, but doing so may cause the logo image to be stretched or scaled, which would degrade its quality. Aspect ratios should always be kept at 4:1.

Although the ideal background image size depends on the client’s screen resolution, it is strongly advised to avoid using images that are any smaller than the current standard monitor resolutions in order to prevent vertical or horizontal bars from appearing on screens with a resolution higher than the background image.

Page Title for Login

Either of the following commands can be used to change the title of the login page:

Using zxsuite auth loginPage setTitle global to access the global level

using the zxsuite auth loginPage setTitle domain at the domain level

viewing the setup as it is now

The zxsuite auth loginPage getConfig domain command may be used to see the current Login Page settings for a domain:

Making Policy Management for 2FA Configurable

The second factor was introduced by Zextras Auth as a component of the service authentication technique. Each service has two options, either at the domain or global level:

  • be switched on or off for the 2FA
  • possess independent Trusted Networks

When enabled, a connection can only be made if the source is trusted. Depending on the 2FA policy set up for the service, this means that the connection comes from either a trusted network manually configured by the admin for the service, or from a previously trusted IP or device.

The service must request the OTP, which is utilised as the second factor, if none of the aforementioned requirements are true. The authentication procedure fails if the service cannot interface with the user for the second factor or does not support it. For instance, 2FA cannot be utilised with IMAP since it is a service that does not allow OTP. In the absence of a valid OTP, the device and IP of the current user are saved in the Trusted Device table.

Additionally, if the IP has been trusted by another service, the connection should still be legitimate based on the service policy.

When an authentication request comes from a device that is already listed in the Trusted Networks or Trusted Devices tables, 2FA Policy Management, an advanced approach, never uses OTP.
There are various CLI commands that may be used to configure and administer 2FA Policies.
Establishing SAML Configuration
You need to configure the SAML IDP (IDentity Provider) using the Zextras SAML SP data in order to link a SAML application with Zextras. In our hypothetical example, we would like to add SAML authentication to the website example.com, which is reachable at SP_URL.

An IDP provider handles the SAML configuration, which is subsequently imported into Zextras Suite by means of a specific command.
The following setup choices are the most crucial. They need to be set up on the SAML IDP side.

sp.entityid
https://SP_URL/zx/auth/samlMetadata?domain=example.com

sp.assertion_consumer_service.url
https://SP_URL/zx/auth/saml

sp.nameidformat urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

Make sure that the Name of the property that is used as NameID is set to mailPrimaryAddress in order for Zextras to validate the data.

Now, there are two methods to integrate a SAML application in Zextras: automatically or manually. Details on each technique are provided in the sections that follow.
Make sure that the Name of the property that is used as NameID is set to mailPrimaryAddress in order for Zextras to validate the data.

Now, there are two methods to integrate a SAML application in Zextras: automatically or manually. Details on each technique are provided in the sections that follow.
Automatically import SAML configuration
If the URL provided by the SAML IDP is https://my-saml-provider.org/simplesaml/saml/idp/metadata.php, you may import the settings by issuing the command:
You’re finished now! The LOGIN SAML button is shown on the login page.

You will be sent to the SAML IDP login page if you click it.
Manually import the SAML configuration
Follow this 4-step process if you need to manually update the SAML setup. Briefly said, you must edit the default SAML settings, export them, save them, and then import them back.
Set up SAML Logout
Certain SAML IDP providers demand that the logout process be signed as well. If you already have SAML setup, you might follow the steps outlined in the previous section by exporting the configuration, making the necessary changes, and then reimporting it.

By altering the configuration file saml.json provided in the previous section, we demonstrate how to add signed logout to the settings used there.
The SAML IDP logout service URL must first be set up (line 7, sp.single_logout_service.url). The URL will be similar to https://mycompany.okta.com/app/test/app_id/slo/saml as Okta is used as an example SAML IDP provider.
The service provider’s certificate, sp.x509cert (line 8), which should already be present, is then configured.

You should be finished at this stage and ready to import the changed configuration file.

Please do these extra procedures, however, if the SAMP IDP stipulates that the requests must also be signed or if you need to sign the requests for security reasons.
  • New X509 certificates should be generated and registered with the SAML IDP. To create one using openssl, execute a command identical to the one below.
  • Lines 8 and 9 of the configuration file to be included for the certificate (sp.x509cert) and the private key (sp.privatekey).
  • Set security by enabling signature creation.line 30, “logoutrequest_signed to true”
  • By adjusting security, you may also choose to activate the signature for the login request.line 32: authnrequest_signed to true
SAML Access to a Service
After the SP and IDP sides of SAML authentication have been correctly established, there are several ways to access Suite resources:

  1. When you are logged in, go to the IDP portal and select the resource you wish to use.
  2. Visit the service’s website directly, and then click the SAML LOGIN button that displays next to the username and password boxes.
  3. Use the direct URL to the service’s SAML authentication. For instance, if you have a Suite installation (the Service) at mail.example.com, you may access the mailbox by clicking the URL https://mail.example.com/zx/auth/startSamlWorkflow?redirectUrl=https://mail.example.com/suite/mails provided you have already authenticated to the IDP.
Permanent Auth Link
Giving a new coworker or employee access to the company’s infrastructure for the first time is a common user management task that an administrator must complete.

A temporary link (auth link) that enables the user to access and setup 2FA is provided when 2FA is enabled on the mailstore in order to allow new users to login instantly.

  1. From the Administration GUI, administrators may quickly create an authentication link:
  2. Click the Create a temporary link button in the user’s General Information section’s Temporary link box.
  3. A URL link will appear in an overlay window, and by selecting the button next to it, you may copy it.
  4. The new user can then be emailed the URL.
  5. Before the link expires, the user has 12 hours to access the mailbox.
Users’ ZxAuth (Auth Zimlet)
To handle all user-side credentials and features, including account and EAS mobile passwords, mobile app QR codes, and OTP for two-factor authentication, Zextras Auth has a separate zimlet (see Fig. 10).
The “Zimlets” component of the Zimbra Web Client provides access to the Zextras Auth Zimlet. Users can utilise the Zextras Auth without having any CLI access.

By creating a new credential, you may grant others access to your account, perhaps including the Zextras Mobile Apps, without disclosing your own credentials.
When using the zimlet, the user can:
  • Password-changing for the person who is currently signed in
  • You may reach the specialised sites by choosing Exchange ActiveSync, Mobile Apps, or OTP Authentication. There, you can add new credentials.
  • Verify the creation status and other details for each credential produced for Exchange ActiveSync and Mobile Apps. The label of the password, its status, the service it is valid for, and its creation date are all displayed next to each entry in the list in each section.
  • Verify the status and other details for each One Time Password that has been created. Each entry in this table includes a description, its status, any unsuccessful attempts, and the date it was created.
  • Verify the status and other details for each One Time Password that has been created. Each entry in this table includes a description, its status, any unsuccessful attempts, and the date it was created.
  • Control the 2FA logins. Unless its usage has been enabled or disallowed at COS, domain, or global level, each user may decide whether to impose access via 2FA.
  • Delete any generated credentials.
The rest of this section provides instructions on how to add or remove credentials as well as an overview of the many options for creating new credentials.

Alter your password
Access the Auth zimlet and choose update Password to update your password. You must first input the current password here before twice entering a new one.
Click the blue CHANGE PASSWORD button to save the new password.

EAS Create New Credentials
Open the Zextras Auth Zimlet, choose Exchange ActiveSync, then NEW AUTHENTICATION + to set a new password for the EAS service.

Here, in the Authentication description section, type a password identification that is simple to remember.
The new mobile password will then appear after clicking CREATE PASSWORD.

To copy the password to the clipboard, click the COPY PASSWORD button at the end.

To exit the Zextras Auth window, click DONE. The Active Passwords list of the Zextras Auth Zimlet now includes a listing for the new Mobile Password.

Create New Credentials: Zextras Auth can manage and speed up logins for Zextras Applications like the Team Mobile App and Drive Mobile App.

To do this, a QR Code is generated, which the user may scan from the app’s login page to log in. The process is fairly similar to the one that was explained in the part before.
Open the Zextras Auth Zimlet, choose Mobile Apps, and then click NEW AUTHENTICATION + to create a new QR code for a mobile application.

Here, fill up the Authentication description field with a password that is simple to remember.

The new QR code for Mobile Application will appear when you click CREATE PASSWORD. To frame the code and allow access to the app, utilise the Zextras mobile app.
To exit the Zextras Auth window, click DONE. In the list of Active Passwords in the Zextras Auth Zimlet, there is now a listing for the new Mobile Application.

OTP for New Credentials Creation
Open the Zextras Auth Zimlet, choose OTP Authentication, and then NEW OTP + to launch a dialogue where you must specify a special label to distinguish the One Time Password access.
The QR code and a set of PIN numbers for authentication will be displayed to you.

To print the codes on paper or to a file, use the PRINT PIN CODES button after that. The printed page contains all the codes, their legitimate usernames and email addresses, as well as usage instructions.

In order to close the Zextras Auth window, click DONE at the end. The list will display an entry for the new OTP entry.
Discard Credentials
Simply choose the desired credential from the Active passwords or OTPs list, then click the DELETE x button _images/delete_credential.png.
To confirm the removal of the credential, click YES.
Credential administration
A credential inside Zextras Suite is anything that grants entry to one of its services or modules.

Suite Zextras The Zimbra WebClient, Team, and Drive mobile applications, as well as other services, may all have their own unique passwords created using Auth’s credential management system.
Without having to disclose the password, it is also feasible to grant access to a service to other coworkers, team members, or even unaffiliated individuals by simply developing a new authentication method (such as a QR code for mobile access). When access for these individuals is no longer required, it is sufficient to remove the authentication method to revoke access.

Additionally, this suggests that users may control who has access to the same services they do, offering a high degree of granularity also at the user level.

The duties that an administrator can perform are demonstrated in the following paragraphs.
Services offered
For the following services, Zextras Auth enables the creation or updating of bespoke passwords:
Administrators may set up a variety of simple to complicated situations by combining various services, such as:
  • disable all but WebAccess
  • disable SMTP and enable IMAP
  • only for managed clients (pre-setup without the user) should IMAP/SMTP be enabled.
  • Create SMTP passwords for automation or external services that are not enabled for Web, Soap, or IMAP access.
For some instances, refer to the following section.
Update your credentials
When they generate the credentials, administrators can set the password for any user account using the command line. They do not have access to the password under any other circumstances, not even to modify it.
The zxsuite auth credential add command may be used to add new credentials for each of the active authentication services:
This cmdlet use EAS (Exchange ActiveSync) by default. Services can be added in groups using commas. The examples that follow include the first with a commented output.

For user john@example.com who has access to service eas (mobile password), construct a password and a label.
  • created: 0 indicates that the credential was indeed randomly generated, while 1 indicates that it wasn’t.
  • created – the timestamp of creation
  • label – The label is helpful for recalling the credentials’ intended usage or owner.
  • Id is a required field when editing or updating credentials since it is unique.
  • the services to which access is permitted
  • the hashed credential itself, or hash
  • enabled – Whether or not the credential may be used in reality.
  • algorithm: the used hashing algorithm
  • password – the secret phrase chosen or produced at random. As previously stated, this is the only time the administrator has access to a user’s password.
For jane@example.com, create a password that can only be used for web access (both ClassicUI and Zextras Login Page).
Make an IMAP and POP3-only password for alice@example.com (no SMTP) for this account.

For bob@example.com/SMTP_Service_Credential, create a password that may be used to 
If QR code support has been enabled, the qrcode argument is crucial for creating new QR codes that can be utilised by mobile devices. When used with the –json option, it will also display the payload of the QR code. Among them is:
List of current credentials
The zxsuite auth credential list command allows system administrators to obtain a comprehensive list of all current credentials for a given account:
Because it displays all of the credentials specified on an account together with other data, the result of this operation can be fairly lengthy. Let’s look at an illustration and determine which details are pertinent:
  • The credentials’ individual ID, which is required in order to update the credentials (see the part after this one), is
  • services that the certificate is accepted for.
How to Change a Credential
Using the zxsuite auth credential update command, the System Administrator can alter the credential’s label and attributes, including the services for which it is valid, even if the credential (password) itself often cannot be changed:
Using the aforementioned example as a guide, we wish to modify the label of the credential id Fr2jM that belongs to the user john@example.com. This is possible by using:

The preceding command’s output will show the updated credential along with a summary of all its characteristics.
Using Zextras Auth CLI
The index of all zxsuite auth commands is included in this section. ZxAuth CLI Commands has a section dedicated to it called Full Reference.
credentials add, remove, list, and update, doDeployAuthZimlet, restart Service, start Service, and stopenforce2FA service create an account and use 2FA acquire because of 2FA configure accounts with 2FA set cos login for Serviceslogon to the page getBackgroundImage domainglobal login page getBackgroundImageLogin to the page getColorPalette domainpage global login getColorPalettelogin to the page getConfig domainpage global login getConfiglogin to the page getFavicon domainpage global login getFavicongetLogo domain login pageGlobal page getLogo loginlogin to the domain getSkinLogoAppBanner pageglobal login page getSkinLogoAppBannerlogin to the page getSkinLogoURL domainpage global login using getSkinLogoURLLogin to the page getTitle domainPage getTitle – Login globallyPage login domain setBackgroundImageglobal login page setBackgroundImageLogin to the page setColorPalette domainPage global login setColorPalettelogin page setFavicon domainglobal Page setFaviconloginlogin to the page setLogo domainpage global login setLogologin to the page setSkinLogoAppBannerglobal login page setSkinLogoAppBannerlogin page setSkinLogoURL domainpage global login setSkinLogoURLSet a pageLogin to the title domainSet a pageGlobal policy set domain policy list global policy list establish cli domain policy worldwide policy set by Cli Set Dav domain policy Global policy set by Dav establish EAS domain policy establish EAS global policy Set IMAP domain policy Global IMAP policy established domain policy for mobile apps established Global policy for mobile apps set Set pop3 domain policy worldwide Pop3 policy set Set SMTP domain policy global policy specified for SMTP establish domain policy in WebAdminUI collection of global policies in WebAdminUI establish WebUI domain policy global policy established for WebUI Domain policy established for ZmWebUI Trusted worldwide policy on ZmWebUIDevice gettrusted expiration domain policyDevice getExpiration trusted worldwide policygadgets settrusted by the expiration_domain policyDevice saml delete saml get saml import saml update saml validate token invalidate token list totp delete totp generate totp list trustedDevice delete trustedDevice list policy trustedDevice setExpiration global

Leave a Reply

Your email address will not be published. Required fields are marked *