We’ve done the hard work of designing our ISE deployment, now comes the fun part: the implementation! In this scenario, we assume that we have designed a medium-size distributed ISE deployment, leveraging VMware virtual ISE appliances. If you recall from our previous blog entry, in a medium-size deployment the PAN and MnT roles/personas are combined and dedicated PSN’s are deployed. Our goals at this point are to get the virtual ISE appliances installed and to establish the necessary communication between them to cluster our ISE deployment. For reference, you can assume our deployment will look similar to the below diagram. For the sake of this post, we will be deploying the three nodes; the primary PAN/MnT, the backup PAN/MnT, and a PSN. So....let’s go!
Ok, so we’ve got multiple ISE virtual appliances to deploy with varying personas. Based on our deployment design, the virtual machine specifications for compute and storage may vary. Cisco has packaged the recommended virtual machine compute/storage combinations into unique OVA files to make things easy for us and to avoid unsupported virtual machine configurations. The installation of the virtual machines can technically happen in any order as the clustering/persona configuration does not take place until after the virtual appliance has been deployed and powered on. That being said, deploy the ISE virtual machines in any order you see fit.
Step 1 – Download the OVA
Download the OVA file for the node you are deploying from cisco.com
Step 2 – Deploy the OVA
Login to VMware vSphere -> Select host -> Deploy OVF Template
Select the OVA file you downloaded from the “Local file” option and click Next. Follow the wizard to complete the OVA deployment by selecting the correct VMware host/resource pool, network port group, and storage (thick provision it!).
Step 3 – Power-On the ISE VM
After powering on the ISE node, we’ll have some initial setup to complete via the console. Go ahead and repeat steps 1 - 3 to install all of your ISE nodes being deployed before continuing on to the initial setup below.
After the virtual machine image is deployed, we have some initial configuration to perform in the setup wizard. This setup is done in the VMware console. Again, this setup can occur in any order as we still aren’t to the point of distinguishing between our ISE node roles/personas.
Step 1 – Run “Setup” CLI
The first time the ISE nodes are powered on after installation, they will prompt you to run ‘setup’. Do it now!
Step 2 – Complete “Setup” CLI
Here we configure the ISE node’s IP settings and peripheral network services such as DNS and NTP. Be sure that you have your DNS records created! We recommend to deploy all ISE nodes using the same time zone to minimize any confusion when performing event correlation. The default UTC is recommended by Cisco for ISE deployments where nodes span different time zones. All my nodes are PST, so we went with that here.
Step 3 – Wait for Setup to Complete
Here ISE is customizing the node installation with your setup information, this will take about 15 minutes. After it is completed, you will land on a login screen. Reproduce steps 1 - 3 for each node being deployed. After setup completes, it will take some additional time for the ISE application to initialize. Wait for the “show application status ise” to indicate the “Application Server” is running before proceeding to the next section. This will take another 10 minutes or so.
Ok, we’ve installed and completed setup on all of our ISE nodes being deployed. Next, we will get into the initial cluster creation and role/persona specific configuration. We will begin with the provisioning of the Primary Administration Node (ise-pan-1 from our example topology).
Step 1 – Login to the GUI!
The glorious first login to the GUI! Open up your favorite web browser and navigate via HTTPS to the hostname/IP of your ISE PAN. ISE will let you know if your favorite browser is supported or not. I use Chrome, it works well with ISE. You’ll login using the credentials provided during setup, HOWEVER, keep in mind that going forward the GUI login account is a separate account from the shell login account – it was merely duplicated during setup to simplify things. After we login, we’ll see a couple disclaimers pop-up regarding Cisco’s Smart Call Home and Licensing. We’ll ignore those for now (you immediately get a 90-day demo license) and simply click through them.
Step 2 – Certificates
How do the ISE nodes gain initial trust? How do they establish an encrypted communication channel? Like anything else these days, certificates of course! ISE uses certificates for a variety of purposes, but for the sake of our example in creating the ISE cluster, we are only concerned about the “Admin” certificate. By default, each ISE node generates a self-signed certificate as a part of the installation and one of the usages assigned to this certificate is “Admin”. Before we can establish communications between the ISE nodes we have installed, we must prepare them to trust each other’s “Admin” certificate in one of two ways.
× Option 1
Export each nodes self-signed Admin certificate and import it as a trusted CA on every other ISE node. This is OK for a small lab environment (like ours), but for any production environment you should choose option 2 as outlined below.
√ Option 2
Generate a certificate signing request on each node, have the CSR signed by an external certificate authority, and then upload the signed certificate for “Admin” usage. If the external CA certificate is not in the list of default trusted CA’s certificates on ISE, upload that as well. To make this process even easier, you can use a wildcard certificate or multi-SAN certificate so that you only have to generate one signing request, and subsequently import the same certificate onto each ISE node.
We’ll walk through option 2 in this blog since that is what you should do in the real world. On the primary admin node, navigate to Administration > System > Certificates > Certificate Signing Request. Click on “Generate Certificate Signing Request”.
To make things simple, we’ll use a wildcard certificate in our lab here. We filled out the CSR as follows. By checking “Allow Wildcard ...” we are letting ISE know that the signed certificate will come back as a wildcard (and that we intend to apply it to all of our nodes). If using a wildcard certificate in production, as a best practice the wildcard should be assigned to a sub-domain specific to your ISE deployment to minimize security exposure (should the wildcard certificate private keys become compromised). Click “Generate” to complete the CSR. Then click “Export” to download it.
Secret Sauce: You will see that the common name is set to $FQDN$ by default. This will be replaced with the nodes FQDN in the CSR (as you would imagine). I like to replace that default with what I’ll call an ISE CUBE FQDN (that’s my name – not a Cisco term). I like this since the certificate will be applied to all nodes and having a specific ISE node FQDN in the common name can be confusing. Also, never ever, ever, use a wildcard character in the common name field. The support for validation of wildcards in the common name field varies dramatically from device to device. Always make sure the wildcard character only shows up in the subject alternative name field, which base on our experience is pervasively supported. You will need to work with your signing CA to make this happen, and they will make it happen, you just have to know to ask! And... now you know.
Ok, behind the scenes I’ve gone off and had our certificate signed by a CA – great! Now, let’s upload our signed CA cert to ISE. First, we’ll navigate to Administration > System > Certificates > Trusted Certificates and click Import.
Browse for the root CA certificate of your issuing CA, give it a friendly name if you wish, and click submit. Do the same for any intermediate CA certificates as well.
Next, we’ll bind our signed certificate to the CSR we created on the primary administration node. Navigate to Administration > System > Certificates > Certificate Signing Requests and select the checkbox next to the CSR. Finally, click Bind Certificate.
Browse for and select your signed certificate, then click Submit!
Click through a couple warnings related to modifying the certificate. The ISE appllication will restart...I’ll go grab a coffee. You? You can just keep reading!
Ok, now for the secondary nodes (remember secondary nodes are ALL other nodes aside from the primary administration node). First, upload the CA certificates to the trusted certificates list on the secondary nodes the same as we did on the primary node above. For the secondary nodes, instead of binding the signed certificate to the CSR, we are going to export a copy of the certificate from the primary node, including the private key, and import it straight away! First on the primary admin node, navigate to Administration > System > Certificates > System Certificates and check the box next to our recently uploaded Admin certificate. Next, click Export and include the private key (create a password when prompted).
Now on each of the secondary nodes navigate to Administration > System > Certificates > System Certificates and click Import. Browse your PC from the certs you recently exported from the primary admin node.
The secondary nodes will now restart! Once the secondary nodes are back online, lets move onto completing our ISE cluster configuration!
Step 3 – Promote Primary Admin
Login to the primary administration node GUI. The first thing we want to do is promote this node to the Primary Admin persona. Navigating to Administration > System > Deployment, we get welcomed with this informational pop-up.
Click OK to get through that pop-up and let’s take a look at the default deployment state of a freshly installed ISE node.
As we can see above, by default and newly installed ISE node is in the standalone role, with all three major personas enabled. Let’s change this node to a Primary administration node to indicate to the deployment that we intend to add additional ISE nodes. After we click in on the hostname, we can select the big “Make Primary” button! Let’s do that.
After selecting “Make Primary” above, we now have the option too disable the Policy Service persona, which you must do in a distributed deployment. We’ll leave the Monitoring persona enabled as this is a medium-size distributed deployment which by definition means the Administration and Monitoring personas are co-located. Here we go! Let’s save it as well! Oh, and this will cause the ISE application to restart...so take a 10-minute break!
While we wait, a word on ISE “Roles”. In an ISE deployment there are three possible values for ISE roles; standalone (one node deployment), primary, or secondary. The standalone role is self-explanatory. The primary role can only belong to one of two nodes that have the Administration persona enabled. The node with the primary role assigned is where you will manage all other nodes from (via the GUI). All other nodes in the deployment will assume the role of secondary. The main purpose of these roles is to determine how the database replication/data replication will occur within the ISE deployment. That is all. Now, back to our regular scheduled programming!
Step 4 – Register Secondary Nodes
Alright, quick review: we installed ISE, we have created an “Admin” certificate trust between all nodes, and we promoted one node to primary admin. The next step is to begin registering secondary nodes to the deployment. Let’s begin with our secondary administration node! Login to the primary administration node GUI and navigate to Administration > System > Deployment > and click on Register ISE node.
Enter the requested details and click Next!
Select the appropriate personas for the node you are registering. In our case, this is the secondary admin node, so we’ll select Administration and Monitoring.
Next, we’ll repeat the same registration process for our policy services node, but this time we only select the Policy Service persona.
Give the nodes time to sync-up (Be patient! This can take some time...) and then, Voila! We now have a functional ISE cluster – commonly referred to as an “ISE Cube”. From here on out, we will manage all aspects of the system from the Primary Administration Node!
Now that we have our ISE Cube deployed, we’ll continue in the next entry with some of the basic provisioning tasks, such as provisioning our EAP certificate for 802.1X and integrating with an Active Directory. Stay tuned!
Written By: Dominic Zeni, LookingPoint Consulting Services SME - CCIE #26686