Installing the ERM module for device management
This describes how to use the ERM Installer to install the ERM module for device management.
As a prerequisite you must have already deployed an ERM virtual machine, and set up the ERM Installer.
To get started, use your browser to go the URL of the ERM Installer. The ERM Installer start screen shows all the products that you have access to via your license key. Currently this is limited to just the ERM module.
On first use you need to the module, and if you later return to the page you can view the current of the module, such as the software version number and also review any warnings that might exist, such as with its certificates, and make changes to the primary configuration.
This topic covers:
Installation settings
The installation settings are a combination of required and optional settings.
Hostname
In this section you specify the Hostname / FQDN of the product and select the SSL certificate to use.
See ERM certificate management for information about generating and uploading certificates.
Locale
The locale settings let you specify the default language (currently English or Swedish) and which timezone to use.
ERM uses the language setting in the web browser for the user interface, if that language is available. Otherwise it uses the nominated default language instead.
Other settings
The other settings let you specify the port on which to listen for proxy clients and the LDAP based phonebook service, and allow you to disable the proxy VM or Incoming LDAP phonebook services.
LDAP authentication settings
You can optionally use an external LDAP / Active Directory database to authenticate users accessing ERM.
The ERM LDAP configuration includes the following elements:
- Access to a service account with read access to the Organizational Units (OUs) used to find user and security group objects.
- A base Distinguished Name (DN) path to provide the starting point for the LDAP search query.
- An LDAP user filter to provide a way to match users within the base DN path who should be provided access to the ERM interface.
- Security groups that can be used to provide permissions for two of the three types of ERM users (Admins and Superusers) and are defined using their LDAP Distinguished Names (DNs).
Three types of users can be granted access to ERM via LDAP with different permissions:
-
Support: these users provide day-to-day ERM support and operations. They can add, remove and configure systems, monitor call operations and statistics, perform firmware upgrades to the endpoints, etc.
By default, users are granted this permission by simply existing within the defined base DN.
-
Admins: these users have all the permissions of Support personnel plus additional permission to configure the ERM core application settings (such as setting base provisioning details and default endpoint passwords), plus the ability to check on proxy clients' connection statuses.
By default, users are granted this permission through a specific Security Group.
-
Superusers: These users have all the permissions of Admins plus the ability to manage the ERM backend system.
By default, users are granted this permission through a specific Security Group.
You can configure the following settings:
| Setting | Description |
|---|---|
| Server | The address of the LDAP server. To override the default port from 389/636 you can specify the address and port number in the format server.example.org:1234 |
| Service account DN/username | The distinguished name (DN) or username of the service account, for example CN=Svc_Pexip,OU=ServiceAccounts,DC=example,DC=org or user@example.org |
| Password | The password for the service account / username. Use dash "-" to set an empty password. |
| Use LDAPS-connection | Select this option to use a secure connection. TLS may be used both with and without an LDAPS connection. |
| Ignore TLS/SSL verification errors | Select this option if you want to ignore TLS/SSL verification errors. |
| Base dn | Specify where in the tree the initial search for results should begin. |
| User filter |
You can define how users are filtered out and displayed. The default user filter allows any user object within the base DN path access to the ERM interface with a minimum of ERM support permissions. While you can control access to the ERM interface at the network level, it is generally considered good practice to ensure access permissions are only granted to users that require them. The default LDAP user filter may not, therefore, suit all enterprises. Please see the example below as to how you could provide more granular access. |
| Admin group DN | Specify which group in the tree has access to admin rights in the system (which enables additional settings and functions for the logged in user). |
| Superuser group DN | Specify which group in the tree has access to superuser status. Use this with caution as these users have full control over the system and should only be assigned to users with high technical knowledge. |
| Customer attribute | Enter attributes for the customer’s shared key in multi-tenant installations. |
| Enable local accounts |
Controls whether to allow login access to users in the local user database: Yes: if the LDAP connection fails or is misconfigured then only local users that were manually added can log in. No: if the LDAP connection fails or is misconfigured then nobody, including "pexip_fallback", can log in. Administrators can use the ERM Installer to test and reconfigure the connection. Unknown: please ignore this option. Note that local users are managed by Superusers through Backend admin settings. |
| Read only | Select this option if you want to disable access to functions such as changing passwords, emails or other user information. |
| Remove optional setting | Select this option to remove this LDAP configuration i.e. to revert to local account access only. |
The ERM Installer has tools to test your LDAP or AD settings to make it easier for you to troubleshoot and get started — see ERM troubleshooting tools for details.
We have also provided a worked example below to help explain how to use the settings in your environment.
Separate domain name for video conference system requests
This is an optional set of configuration for a separate domain name for endpoint HTTP communication (events, firmware, passive provisioning etc). It is typically used by service providers and allows for separate access rules in firewall / load balancers.
Enter the hostname and any settings for the certificates to be used.
SAML SSO settings
ERM can integrate with Active Directory Federation Services (AD FS) to enable single sign-on (SSO) access via SAML.
See Using AD FS for SSO/SAML access to ERM for details.
Initial deployment
After you have gone through and filled in the necessary settings during the configuration and clicked on , you are redirected to the step to deploy your ERM installation.
Start by selecting which version of ERM to install in the drop-down list to the right, then click on to start the installation. You can now follow the installation process in a terminal that appears under the deploy button. When the installation is complete, you may reload the page and then you should see the correct version displayed for ERM.
The next step is to complete the onboarding wizard as described below.
Onboarding wizard
Open a web browser and go to the hostname that you entered for the installation. Note that the hostname you selected for your installation must be a valid record in your DNS.
You are met by the ERM onboarding wizard which takes you through the following configuration steps.
Organization
Enter a name and click continue. This is used as the default organization for your ERM installation.
Add Pexip cluster
The next step is to set up a Pexip video cluster. Start by filling in a description for the cluster followed by choosing Pexip Infinity and specifying the SIP address to use for the cluster.
Note that you can subsequently update the cluster configuration via (requires superuser permissions).
Adding a Pexip cluster and a Pexip Infinity Management Node only applies to self-hosted Pexip Infinity customers. Please skip this step if you are a Pexip Service customer.
Adding the Pexip Infinity Management Node
Add the details of your Pexip Infinity Management Node to your cluster, so that ERM can configure Pexip Infinity via its management API.
This step is only required if you want to register your devices to Pexip Infinity.
| Option | Description |
|---|---|
| Description | A short description for the Management Node. |
| IP address | The IP address for the node. |
| Ev. separate IP/host for API calls | Choose if you want network separation for all API calls, so that traffic goes through a separate hostname if, for example, you want to add firewall rules. |
| DNS Name | The DNS name of the Management Node. |
| Username and password |
The username and password that ERM needs to use to connect to the Management API. Within Pexip Infinity, this username (account) must have the following permissions:
See Managing administrator roles for more information. |
| Prepare event sink and external policy |
These options are currently unused and should not be configured. |
Note that you can subsequently update the Management Node configuration via (requires superuser permissions).
Choose password
Here you may enter a password for the fallback user "pexip_fallback". We recommend that you set a password so you always have a fallback user for recovering the platform. You may skip this step, but you will then have to use one of your LDAP users for future access.
If the password for the fallback user is non-existent or forgotten, and the LDAP integration is down, password recovery is only available via the virtual machine. In this case please contact support for further assistance. A password recovery in this way is a time-consuming process and that is why we always recommend setting a password for the fallback user which you then store in a safe place.
Note that you can subsequently update the fallback user via (requires superuser permissions).
All done!
After completing the onboarding wizard you are now ready to start managing all your video conferencing systems.
Note that the onboarding wizard settings can be updated via the options (requires superuser permissions).
Updating settings after deployment
After the installation of ERM is complete, you still have the option to change settings. To do this:
- Select the installation you want to change from the ERM Installer start screen.
- Click on for the product whose settings you want to change.
- When you have made your changes, click . This takes you back to the deployment of the product.
-
Click on to apply the new settings to your installation.
The module's services will be unavailable for a short period as the changes are applied, and the services restart.
After the installation process is complete you may now reload the page and your update is completed.
If the primary ERM VM runs in online mode with direct access to the license activation services then the button completes the process.
If the primary ERM VM is used offline, then an offline bundle must be prepared from the online ERM VM:
You must ensure that the ERM Installer version is the same on each ERM deployment (online and offline).
-
On the online VM, go to and select to prepare the module image.
The offline file can be large and take several minutes to prepare. Please be patient and do not navigate away from the page.
- Transfer the exported file using your preferred method (for example, a USB stick) to the second offline (air-gapped) VM.
- Using the Installer on the second VM, go to and the file that was just exported.
For full details about offline bundles, see Installing and upgrading ERM in an offline environment.
Example LDAP usage
Here is a worked example of LDAP usage that you can use as a guide and adapt for your own organization.
Worked example The following example is an enterprise using Microsoft Active Directory and a directory domain of example.net. This domain translates into the LDAP root path as being:
DC=example,DC=net
They have created a directory structure that maps their real-world organization and subdivides their users by geographical region and business function. In addition, they have created a base Organizational Unit (OU) called "Business" that contains all the sub-OUs. Their example structure is seen below:
ERM support personnel are located within the IT business function OUs, in the different regions. Their base DN path is therefore:
OU=Business,DC=example,DC=net
The default LDAP user filter is:
(&(|(sAMAccountName=%(user)s)(userPrincipalName=%(user)s)(uid=%(user)s))(objectClass=person))
This filter allows any user within the Base DN search path access to the ERM interface with ERM Support permissions. Therefore, sales, HR, and research users could technically access the ERM interface using the LDAP credentials. You could block these users’ access at the network level, however, we will discuss how access permissions can be tightened by adjusting the LDAP user filter and creating an additional security group later.
Two security groups can be defined within ERM to provide additional permissions for ERM user access. Security groups allow users across different OUs to be gathered together, and permissions can be applied at the group level. For example, our organization uses a separate OU (named “Security Groups”) to contain all of its security groups. It then created two groups for its ERM Admin and ERM Superusers. We can, therefore, extend the directory diagram to show these groups:
The Distinguished Names (DNs) of these groups are then:
ERM Admins: CN=ERM Admins,OU=Security Groups,OU=Business,DC=example,DC=net
ERM Super Users: CN=ERM SUs,OU=Security Groups,OU=Business,DC=example,DC=net
We could limit user access to the ERM interface to users that exist solely within these security groups by extending the LDAP user filter by adding a memberOf property. For example, the LDAP search filter could become:
(&(|(sAMAccountName=%(user)s)(userPrincipalName=%(user)s)(uid=%(user)s))(objectClass=person)(|(memberOf=CN=ERM Admins,OU=Security Groups,DC=example,DC=net)(memberOf=CN=ERM SUs,OU=Security Groups,DC=example,DC=net)))
So, users within the base DN path but are only members of the ERM Admins, or ERM SUs security groups are allowed access.
The LDAP user filter currently has a limitation of 255 characters. The above filter is 215 characters, so it is permissible. However, filters greater than 255 characters are truncated, therefore, will likely give erroneous results.
The result seems OK, however, the organization would like to give some users access to the ERM interface with only the support user permission. We could create an additional security group for ERM Support, but, applying another memberOf property to the LDAP filter would mean that the filter is greater than 255 characters and would be truncated. In addition, the memberOf property does not allow for wildcard matching, so an alternative method is required.
Security groups can be nested, so one group can be added as another group member. For example, our organization creates a general ERM Support Users security group, then adds the ERM Admin and ERM SUs groups to its members list, for example:
We can further extend the directory diagram to show these group relationships:
Lastly, we can modify the LDAP Search filter to extend the memberOf property to search within the ERM Support User groups and any nested group. The numbers added to the memberOf property are an OID called LDAP_MATCHING_RULE_IN_CHAIN, which extends the match to provide a recursive lookup of nested objects within the given DN (see Ldapwiki: LDAP_MATCHING_RULE_IN_CHAIN ), so the memberOf property needs to be exactly as shown below:
(&(|(sAMAccountName=%(user)s)(userPrincipalName=%(user)s)(uid=%(user)s))(objectClass=person)(memberOf:1.2.840.113556.1.4.1941:=CN=ERM Support Users,OU=Security Groups,DC=example,DC=net))
The result is a filter which is 186 characters long, so it meets the current ERM LDAP user filter requirements. In addition, it allows access to users across multiple OUs but who only exist within the ERM Support Users group and its nested group siblings. Further, users are granted additional permissions within the nested ERM Admins or ERM SUs groups.