AdminConnect Setup
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.
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.
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:
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).
Certificates for AdminConnect
AdminConnect relies on PKI certificates for relationship-based access control of workloads.
The feature uses the same certificate infrastructure enabled for SecureConnect. If you have not set up certificate for SecureConnect, see Configure SecureConnect to Use Certificates and Requirements for Certificate Setup on Workloads for information.
The same prerequisites and limitations for certificate set up apply for AdminConnect. Additionally, because you can use AdminConnect to control access for laptops, certificates on laptops must meet these additional requirements:
The certificate must have a unique Subject Name and Subject Alt Name.
The certificate must be enabled with all extended key usage to check trust validation.
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.
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. For information, see Enable AdminConnect for a Rule in Security Policy Guide.
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. See Add an Unmanaged Workload in Security Policy Guide for information.
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.