Skip to content

Get UMS Ready to Support OS 12

Migrating from OS 11 to OS 12 may require some additional updates / configuration changes to your UMS configuration, as well as your DNS / network configurations.

This document outlines some of the basic tasks that need to be performed before migrating devices from OS 11 to OS 12.

UMS Configurations

Set the Correct Public Address and Public Web Port for Each UMS Server

It is required to set the public address for your UMS servers in order for OS 12 devices to properly communicate with. These are the names that your devices will use to locate and validate your UMS servers.

Public Address Requirements

Please note that your public address names need to meet the following requirements:

  • The public address must be all lower case
  • The public address must be a fully qualified domain name (FQDN)
  • You should use a short, addressable name
Examples

Valid
- ums01.igel-lab.local
Invalid
- ums01
- ums01.qtwjsjznsauvxhsxwmvsmdhta.eastus.cloudapp.azure.com
- UmS01.igel-lab.LOCAL

The steps below will need to be performed once for each UMS server in your cluster:

  1. Open the IGEL UMS Console, and go to the UMS Administration section. image-20240829083124859.png

  2. Navigate to UMS Network > Server.

  3. Right-click the UMS server you wish to adjust, and select the Edit... button.

  4. Enter a unique identifier into the Display Name field (this does not impact functionality, just how it appears in the UMS Console).

  5. Enter the Fully Qualified Domain Name of your UMS server that the IGEL will connect to from your local network into the Public Address field.

  6. You can either leave the Public Web Port field empty, or enter the default of 8443. image-20240829083353316.png

Web Certificate Configuration

Now that we have your public address properly configured, we need to make sure that your UMS Web Certificates support the public address.

Self-Signed vs Public vs Internal CA

I personally recomend using the internal, self-signed, certificates for the UMS web certificates. This is because the root / intermediate certificate chain is used for authenticating devices, and if the root certificate expires before a new one is imported into or created by UMS you will lose the ability to manage your IGEL fleet.

You can use public or internal CA certificates safely on a reverse proxy for managing internal and external devices, or your ICG for external devices.

Two Root Certificates at all Times?

It is recommended to keep two root certificates in UMS, at least one of them being a self-signed / UMS generated certificate, which can be used to recover devices if the main root certificate expires before it is updated or replaced, as all root / intermediate certificate public keys are stored and trusted by IGEL devices connected to UMS.

Wildcard

If you are using a self-signed certificate, and your company does not have restrictions against using wildcard certificates, this is the simplest method for making sure that all addresses are covered.

Multi-Domain Wildcards

You can even create a self-signed certificate with wildcard entries for multiple domains.

image-20250528095527431

Single Certificate with All FQDN

If you are cannot use a wildcard certificate, you can utilize a single certificate for all UMS servers in the cluster. This certificate will need to contain the public address for all UMS servers in your cluster.

You can include both internal and external FQDN's for your UMS if you are forwarding your UMS traffic externally.

Certificate SAN

You do not need your ICG, reverse proxy, cluster address, device enrollment address, or igelrmserver to be in the list, and you should NOT have the IP addresses for your UMS servers in this.

image-20250528095713739

Individual Endpoint Certificates Per UMS Server

Another option is to create a unique endpoint certificate for each UMS server, created from a single root / chain. This is more complicated to manage, but guarantees each server has its own, unique certificate.

DNS Configuration

DNS plays a critical role for OS 12 devices. Devices will perform both forward and reverse lookups of your UMS DNS names to validate and authenticate.

Internal Forward Lookup Zone Entries

You will need to configure forward lookup addresses for the following items in your environment"

  • UMS Public Address
  • UMS Cluster Address (If Using a Reverse Proxy)
  • igelrmserver (if using DNS Auto-Registraion)

Reverse Lookup Entries

You will also need pointer (PTR) records setup. These will be used for to look up the UMS FQDN addresses when the device cannot locate UMS via the direct FQDN, like when using the igelrmserver entry.

Examples

Internal

In the example below, the IGEL devices have all UMS servers available, as well as an internal reverse proxy / load balancer (Cluster Address), and the igelrmserver address. They will connect in the following order, and if they are unable to, they will try the next on the list.

  1. Cluster Address
  2. igelrmserver address
  3. UMS Public Addresses
---
title: Internal Enterprise
---
graph LR;

%%% Definitions
IGELINT([IGEL Endpoints]) 
%% UMS Devic Connectors
UMS01([<b><u>Public Address</u></b><br/>ums01.igel-lab.<font color=blue>local])
UMS02([<b><u>Public Address</u></b><br/>ums02.igel-lab.<font color=blue>local])
%% Special Device Connectors
rmserver([igelrmserver.igel-lab.<font color=blue>local])
LBINT([<b><u>Reverse Proxy</b></u><br/>ums.igel-lab.<font color=blue>local])
%% UMS IPs
10[10.1.10.10]
11[10.1.10.11]

%%% Grouping
%% Global
IGELINT

%% Sub Graphs
subgraph DeviceConnectors[Device Connectors]
    rmserver
    LBINT
    subgraph UMS Servers[UMS Servers]
        UMS01
        UMS02
    end
end
subgraph IP[UMS Server IP]
    10
    11
end

%%% Connections
%% DNS 
UMS01 <-.->|A Record / PTR Record| 10
UMS02 <-.->|A Record / PTR Record| 11
rmserver -->|DNS Round Robin| IP

%% Reveser Proxy Connection
LBINT -->|LB VIP| IP

%% IGEL Endpoint Connections
IGELINT -->|8443| DeviceConnectors

Internal DNS Records

Address Type Resolution
ums01.igel-lab.local A - 10.1.10.10
ums02.igel-lab.local A - 10.1.10.11
10.1.10.10 PTR ums01.igel-lab.local
10.1.10.11 PTR ums02.igel-lab.local
igelrmserver.igel-lab.local A Record (Round Robin) - 10.1.10.10
- 10.1.10.11
ums.igel-lab.local N/A Your Load Revser Proxy IP(s)

UMS Web Certificate Subject Alternative Names

Your UMS Web Certificates will need to have the following entries in the SAN Name:

  • *.igel-lab.local (Wildcard) OR
  • ums01.igel-lab.local
  • ums02.igel-lab.local

What about the Reverse Proxy and igelrmserver‽

The other entries are not required as long as the reverse proxy is configured to use the web cert for device authentication / SSL termination, and the devices can perform a reverse-lookup on the UMS IP addresses when accessing igelrmserver.igel-lab.local.

Reverse Proxy (LB) Certificates

The reverse proxy should use a Public or Internal certificate chain for its web certificate. It should not use the UMS Self-Signed chain. However, will need the private key, and EST keys imported to your reverse proxy server in the appropriate way.

For more information on this, please reference the "Configure the UMS to Integrate Reverse Proxy with SSL Offloading" KB article.

External Devices (Reverse Proxy)

In the example below shows how external devices would connect to an enterprise environment using an external reverse proxy, and implementing igelrmserver for internal connections.

---
title: External Reverse Proxy w/ Internal Devices Direct
---
graph LR;
%%% DEFINITIONS

%% igel devices
IGLINT((IGEL Devices))
IGEL((IGEL Devices))

%% special connectors
LB([<b><u>Reverse Proxy</u></b><br />ums.igel-lab.<font color=red>com])
rms([igelrmserver.igel-lab.<font color=blue>local])

%% ums public addresses
UMS01([<b><u>Public Address</u></b><br/>ums01.igel-lab.<font color=blue>local])
UMS02([<b><u>Public Address</u></b><br/>ums02.igel-lab.<font color=blue>local])

%% ums ips
10[10.1.10.10]
11[10.1.10.11]

%%% GROUPINGS

%% main

%% sub graphs
subgraph Internal[Internal]
    IGLINT
    subgraph DMZ[Demiliterized Zone]
        LB
    end
    subgraph Datacenter[Datacenter]
        subgraph DNS[DNS]
            UMS01
            UMS02
            rms
        end
        subgraph IP[UMS Server IP]
            10
            11
        end 
    end
end
subgraph External[External]
    IGEL
end

%%% CONNECTIONS
%% external connections
IGLINT -->|Reverse Lookup| rms

%% connetions to ums servers
LB -->|LB VIP| UMS01
LB -->|LB VIP| UMS02
IGEL -->|8443| LB

%% dns resolution
UMS02 <-.->|A Record / PTR Record| 10
UMS01 <-.->|A Record / PTR Record| 11
rms -.->|DNS Round Robin| IP

External DNS Records

Address Type Resolution
ums.igel-lab.com A External Load Balancer IP

Internal DNS Records

Address Type Resolution
ums01.igel-lab.local A - 10.1.10.10
ums02.igel-lab.local A - 10.1.10.11
10.1.10.10 PTR ums01.igel-lab.local
10.1.10.11 PTR ums02.igel-lab.local
igelrmserver.igel-lab.local A Record (Round Robin) - 10.1.10.10
- 10.1.10.11

UMS Web Certificate Subject Alternative Names

Your UMS Web Certificates will need to have the following entries in the SAN Name:

  • *.igel-lab.local (Wildcard) OR
  • ums01.igel-lab.local
  • ums01.igel-lab.local

What about the Reverse Proxy and igelrmserver‽

The other entries are not required as long as the Load Balancer is configured to use the web cert for device authentication / SSL termination, and the devices can perform a reverse-lookup on the UMS IP addresses when accessing igelrmserver.igel-lab.local.

Reverse Proxy (LB) Certificates

The reverse proxy should use a Public or Internal certificate chain for its web certificate. It should not use the UMS Self-Signed chain. However, will need the private key, and EST keys imported to your reverse proxy server in the appropriate way.

For more information on this, please reference the "Configure the UMS to Integrate Reverse Proxy with SSL Offloading" KB article.