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:
-
Open the IGEL UMS Console, and go to the UMS Administration section.
-
Navigate to UMS Network > Server.
-
Right-click the UMS server you wish to adjust, and select the Edit... button.
-
Enter a unique identifier into the Display Name field (this does not impact functionality, just how it appears in the UMS Console).
-
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.
- You can either leave the Public Web Port field empty, or enter the default of 8443.
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.
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.
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.
- Cluster Address
- igelrmserver address
- 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.