Skip to content

HOWTO Best Practices

OS 12

Initial Testing without UMS

Security / Password

  • Password

    Provides details on the user types and their roles in IGEL OS. You can configure passwords for the user types to protect your endpoint devices against unwanted changes.

  • Logon Settings

    Provides options for logon settings are available in IGEL OS.

  • Active Directory/Kerberos

    Shows how to configure the options for Active Directory with Kerberos in IGEL OS.

  • Single Sign On (SSO)

    IGEL SSO will work with identity provider (IdP) that supports OpenID Connect.

UMS

Initial setup for UMS can be done with embedded database with plans to migrate the embedded database to external database once devices reach a certain number.

NOTE: For small installations, a single UMS Server instance (standard UMS) with an embedded database is usually sufficient. If required, a single-instance installation can be easily extended anytime to a Distributed UMS installation by installing additional servers (and in the case of an embedded database, by switching preliminarily to an external data source).

ICG vs. Reverse Proxy

  • IGEL Cloud Gateway vs. Reverse Proxy for the Communication between UMS 12 and IGEL OS Devices

    With the launch of IGEL Universal Management Suite (UMS) 12, the Unified Protocol used for all communication between the UMS and IGEL OS 12 devices was introduced. The Unified Protocol is a secure protocol that uses TCP 8443. However, depending on the structure of your UMS environment, company's security policies, etc., it may be insufficient, and the use of the IGEL Cloud Gateway (ICG) or reverse proxy may be required.

Remote Security Logging in IGEL

The remote security logging feature for the IGEL Universal Management Suite (UMS), the IGEL Cloud Gateway (ICG) and the IGEL Management Interface (IMI). The remote security logging feature logs security relevant events in a separate log files that can be picked up by a configured log collector/SIEM.

Collect IGEL information for input into CMDB

Instead of installing a 3rd party agent onto IGEL OS, use data collected by UMS to feed into your CMDB.

If the data needed is not currently being collected, then use IGEL UMS Device Attributes to collect the information.

Now that you have the information in the IGEL UMS, create view and administrative task that will generate data file used in ETL Job.

Now use the data file as input for your ETL job into your CMDB. Follow guidance from your CMDB vendor for setting up ETL job.

Use IGEL Profile Templates

These profiles are available as templates for assisting with configuration of the different supported workflows.

Azure Application Gateway for UMS Reverse Proxy

Checklist of items to collect

  • Public FQDN (fully qualified domain name) and Port of the Reverse Proxy:
  • FQDN / IP and Port of the configured listener for Device onboarding:
  • Set Public Address and Port of the UMS Process Configuration:

Note: In case the public address of the UMS differs from the UMS address, the public address and port must be set. This option can be set under UMS Administration > UMS Network > Server.

  • Private FQDN address used by the Azure Application Gateway for UMS connection:
  • Export UMS Web Certificate Chain as Export certificate chain to keystore:
  • Export EST CA Client Certificate Chain from UMS Administration > Server Network Settings > Export Client Certificate Chain:
  • Export UMS Web Root Certificate for Azure from UMS Administration > Global Configuration > Certificate Management > Web . Export Certificate:
  • Define UMS endpoint paths for Reverse Proxy integration. The used/required paths for OS 12 and UMS Web App:

The paths required for OS 12 device connections to the UMS (via a Reverse Proxy) are:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
The root path is:

/device-connector/device/*

in more details it would be:

/device-connector/device/ws-connect
/device-connector/device/portforwarding
/device-connector/device/.well-known/est/*

and also the appproxy path is required:

/ums-appproxy/*

The device communication is always TLSv1.3.

In case the UMS Web App should be used via a Reverse Proxy the following paths are required:

/wums-app/*
/webapp/*

Here TLSv1.2 or TLSv1.3 is used.