AdminConnect
Relationship-based access control rules often use IP addresses to convey identity. This authentication method can be effective. However, in certain environments, using IP addresses to establish identity is not advisable.
Overview of AdminConnect
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 as coming from server A.
Illumio designed its AdminConnect (Machine Authentication) feature with these types of 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 datacenters, 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.
When AdminConnect and SecureConnect are enabled for a rule, the ESP packets are encrypted.
Ease of Deployment
Enabling AdminConnect for identity-based authentication is easy because it is a software solution and it 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 datacenters.
AdminConnect Prerequisites and Limitations
Prerequisites
You must meet the following prerequisites to use AdminConnect:
You must configure SecureConnect to use certificate-based authentication because both features rely on the same PKI certificate infrastructure. See the following topics for more information:
Configure SecureConnect to Use Certificates. For information, see PCE Administration Guide.
Configure certificates for AdminConnect. For information, see PCE Administration Guide.
AdminConnect must be used with VEN version 17.3 and later.
AdminConnect supports Linux/Windows IKE v1 (client only) with unmanaged workloads.
Limitations
You cannot enable AdminConnect for the following types of rules:
Rules that use All services
Rules with virtual services in providers or consumers
Rules with IP lists as providers or consumers
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).
Enable AdminConnect for a Rule
AdminConnect is supported on workloads in the Visibility Only and Full enforcement . See AdminConnect Prerequisites and Limitations for the list of rule types that do not support AdminConnect.
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. 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 Providing Service 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.
Secure Laptops with AdminConnect
You can use Illumio to authenticate laptops and grant them access to managed workloads. To manage a laptop with AdminConnect, complete the following tasks:
Deploy a PKI certificate on the laptop. See “Certificates for AdminConnect” in PCE Administration Guide.
Add the laptop to the PCE by creating an unmanaged workload and assign the appropriate labels to it to be used for rule writing
Create rules using those labels to grant access to the managed workloads. See Enable AdminConnect for a Rule for information.
Configure IPsec on a laptop.
To add a laptop to the PCE by creating an unmanaged workload:
To manage a laptop with AdminConnect, add the laptop to the PCE as an unmanaged workload.
From the PCE web console menu, choose Workloads > Add > Add Unmanaged Workload.
The Workloads – Add Unmanaged Workload page appears.
Complete the fields in the General, Labels, Attributes, and Processes sections.
In the Machine Authentication ID field, enter all or part of the DN string from the Issuer field of the end entity certificate (CA Subject Name). For example:
CN=win2k12, O=Illumio, OU=Portal, ST=CA, C=US, L=Sunnyvale
Tip
Enter the exact string that you get from the
opensslcommand output.Click Save.
To configure IPsec on a laptop:
To use the AdminConnect feature with laptops in your organization, you must configure IPsec for these clients.
See the Microsoft Technet article Netsh Commands for Internet Protocol Security (IPsec) for information about using netsh to configure IPsec.
See also the following examples for information about the IPsec settings required to manage laptops with the AdminConnect feature.
PS C:\WINDOWS\system32> netsh advfirewall show global Global Settings: ---------------------------------------------------------------------- IPsec: StrongCRLCheck 0:Disabled SAIdleTimeMin 5min DefaultExemptions NeighborDiscovery,DHCP IPsecThroughNAT Server and client behind NAT AuthzUserGrp None AuthzComputerGrp None AuthzUserGrpTransport None AuthzComputerGrpTransport None StatefulFTP Enable StatefulPPTP Enable Main Mode: KeyLifetime 60min,0sess SecMethods ECDHP384-AES256-SHA384 ForceDH Yes Categories: BootTimeRuleCategory Windows Firewall FirewallRuleCategory Windows Firewall StealthRuleCategory Windows Firewall ConSecRuleCategory Windows Firewall Ok. PS C:\WINDOWS\system32> netsh advfirewall consec show rule name=all Rule Name: telnet ---------------------------------------------------------------------- Enabled: Yes Profiles: Domain,Private,Public Type: Static Mode: Transport Endpoint1: Any Endpoint2: 10.6.3.189/32,10.6.4.35/32,192.168.41.163/32 Port1: Any Port2: 23 Protocol: TCP Action: RequireInRequireOut Auth1: ComputerKerb,ComputerCert Auth1CAName: CN=MACA, O=Company, OU=engineering, S=CA, C=US, L=Sunnyvale, [email protected] Auth1CertMapping: No Auth1ExcludeCAName: No Auth1CertType: Intermediate Auth1HealthCert: No MainModeSecMethods: ECDHP384-AES256-SHA384 QuickModeSecMethods: ESP:SHA1-AES256+60min+100256kb ApplyAuthorization: No Ok.