AdminConnect
Relationship-based access control rules often use IP addresses to convey identity. This authentication method can be effective. However, using IP addresses to establish identity in certain environments is not advisable.
When you enforce policy on servers for clients that change their IP addresses frequently, the policy enforcement points (PEPs) continuously need to update security rules for IP address changes. These frequent changes can cause performance and scale challenges, and the ipsets of protected workloads to churn.
Additionally, using IP addresses for authentication is vulnerable to IP address spoofing. For example, server A can connect to server B because the PEP uses IP addresses in packets to determine when connections originate from server A. However, in some environments, bad actors can spoof IP addresses and impact the PEP at server B so that it mistakes a connection from server A.
Illumio designed its AdminConnect (Machine Authentication) feature with these environments in mind. Using AdminConnect, you can control access to network resources based on Public Key Infrastructure (PKI) certificates. Because the feature bases identity on cryptographic identity associated with the certificates and not IP addresses, mapping users to IP addresses (common for firewall configuration) is not required.
With AdminConnect, a workload can use the certificates-based identity of a client to verify its authenticity before allowing it to connect.
Features of AdminConnect
Cross Platform
Microsoft Windows provides strong support for access control based on PKI certificates assigned to Windows machines. Modern data centers, however, must support heterogeneous environments. Consequently, Illumio designed AdminConnect to support Windows and Linux servers and Windows laptop clients.
AdminConnect and Data Encryption
When only AdminConnect is enabled, data traffic does not use ESP encryption. This ensures that data is in cleartext even though it is encapsulated in an ESP packet.
The ESP packets are encrypted when AdminConnect and SecureConnect are enabled for a rule.
Ease of Deployment
Enabling AdminConnect for identity-based authentication is easy because it is a software solution that does not require deploying any network choke points such as firewalls. It also does not require you to deploy expensive solutions such as Virtual Desktop Infrastructure (VDI) or bastion hosts to control access to critical systems in your data centers.
AdminConnect Prerequisites and Limitations
Prerequisites
You must meet the following prerequisites to use AdminConnect:
Limitations
You cannot enable AdminConnect for the following types of rules:
Rules that use All services
Rules with virtual services in sources or destinations
Rules with IP lists as sources or destinations
Stateless rules
AdminConnect is not supported in these situations:
AdminConnect does not support “TCP -1” (TCP all ports) and “UDP -1” (UDP all ports) services.
You cannot use Windows Server 2008 R2 or earlier versions as an AdminConnect server.
Windows Server does not support more than four IKE/IPsec security associations (SAs) concurrently from the same Linux peer (IP addresses).
Enabling AdminConnect for a Rule
AdminConnect is supported on workloads in the Visibility Only and Full enforcement.
From the PCE web console menu, choose Rulesets and Rules > Rulesets.
The Rulesets page appears.
Create a new ruleset or open an existing one.
In the ruleset, select the Scopes and Rules tab.
If necessary, create an intra-scope or an extra-scope rule. See Rule Writing for information. To edit an existing rule, click the edit icon at the end of the row.
To enable AdminConnect for the rule, select Machine Authentication from the drop-down list.
Note
AdminConnect is displayed as Machine Authentication in the services drop-down lists.
Click the Save icon at the end of the row.
The page refreshes, and the Providing Service column indicates that AdminConnect is enabled for that Rule.
To apply the changes to the applicable workloads, provision the changes.