In this post, I'm going to review the PassiveID features of ISE that are new as of ISE 2.2 and 2.3. In this particular post, I'll be doing it all from ISE 2.3 but bear in mind that you can do all this from ISE 2.2 as well. In ISE 2.0, there was a feature added called EasyConnect which utilized WMI logs from the Active Directory Domain Controller to check for login events. Based on those login events, ISE would make a decision to grant access. This allowed ISE to grant network access beyond the typical 802.1x and profiling methods. This functioned well but required a LOT of backend work to prepare Active Directory to share the WMI logs and if you read my earlier post here, you will see what I mean The creators of ISE decided to revamp this process and create a better way to do this in ISE 2.2 and later.
With the revamped PassiveID, ISE seeks to solve two problems:
1) Ensure that EasyConnect is now easier to setup
2) Have ISE function as the context directory agent for other Cisco and pxGrid partners
For #2, I will expand on that: In the past, ISE had to see an authentication to share the user and context information with third party systems via pxGrid. This meant that you had to have ISE deployed everywhere to have full identity mapping on ISE, other Cisco Security tools, and ISE Ecosystem Partners. This was a bit of a problem: If the customer is rolling out ISE or it's not deployed everywhere, pxGrid really isn't getting a full picture of who is on the network to share with other tools. By adding other ways to add identity information to ISE, this solves the problem and allows ISE to share the username-to-IP mapping with pxGrid.
PassiveID is set up through the PassiveID WorkCenter. There are a few tabs I want to walk through:
- Overview - This is where you can get a list of steps on how to set up PassiveID, view the dashboard, and Live Sessions
- Providers - This is where you set up the "Providers" of the identity information. This can be done via Active Directory WMI, an agent that runs on the domain controllers, API provider, SPAN port looking for Kerberos logins, and syslog providers
- Subscribers - These are the pxGrid "subscribers" who will be receiving the identity information from PassiveID. You can also generate self-signed certificate here from a built-in pxGrid Certificate Template if you're using self-signed certificates for ISE under the Certificate tab
- Certificates - This tab is useful if you're using a CA-signed certificate and you need to import it or issue a CSR for the ISE node. This is the same menu as Administration>System>Certificates
- Troubleshoot - This is a screen where you can do a TCP dump to troubleshoot PassiveID issues and that you're getting packets from your Providers
- Reports - This is where you can generate and schedule reports based on PassiveID-related events
Now that I've laid the groundwork of what each menu consists of, I'm going to go back to the Providers tab to explain how to configure some of the different options. On this tab, you can see the various provider types. Let's walk through the configuration of each:
Active Directory - This is for joining a domain and configuring WMI on the domain controller with easy. If you have not already joined the domain, click on the Add button to join ISE to the domain:
After clicking Add, you will need to enter the join point name and domain name. It will then prompt you to ask if you would like to join the domain. You would need administrator credentials or credentials of an account that can join a computer to the domain.
After ISE is joined to the domain, you will want to navigate to the PassiveID tab under the Active Directory domain.
On here, you would indicate which domain controllers you would like to use for PassiveID. You can add new ones or use the existing one you just joined. Check the box next to the domain controller that's currently there and click Edit.
On the pop-up, you would want to ensure that a domain admin account's username and password is configured and choose WMI from the dropdown. The next thing that you would do which is brilliant because it took a LOT of the manual work out of it is click Configure right next to WMI. This will cause ISE to reach out to the domain controller you selected and make the changes necessary to view the WMI logs. This greatly simplifies a task that used to be incredibly tedious.
After you configure it, you can click the button next to it to test that it works. You should get a popup saying it works.
Now let's say you don't want to use WMI and would rather use an agent? That's fine. Close out of the popup window and click on the Add Agent button.
A new pop-up box will come up with the option to deploy an agent to the domain controller. You would need to give the FQDN of the domain controller and administrator credentials. After you do so, you would click the Deploy button and ISE would silently install it on the domain controller to run as a service in the background.
After you have deployed the service, edit the domain controller again in the same window:
From the popup window, choose Agent under Protocol and choose the name of the agent you previously deployed. Then click Save.
Whether or not you decide to use WMI or an Agent, the deployment is made very simple compared to having to manually change registries and do a ton of backend work on your domain controllers. Not to mention the risk of human error that's involved. If you've followed my instructions up to this point, navigating to Work Centers>PassiveID>Overview>Live Sessions and you should see authentications coming in from endpoints that aren't just authenticating to the network via 802.1x.
Note: In order to use EasyConnect, you would need to deploy a PassiveID provider using either WMI or the Agent. All other forms of PassiveID are used just for sharing context information between various other systems with pxGrid.
Agents - This is just another tab where you can deploy the agent or you can download it to register it manually later. This can also be done from the Active Directory screen. Since we configured it both ways above, I won't rehash the same thing.
API Provider - This is so one can gather user identity information from another application that might be running somewhere in the environment and sharing information via a REST API with ISE. The user information should be sent via JSON and include the following information:
- Username
- IP Address
- Port range
- Domain
To configure it, you would configure the IP or FQDN of the application and the username and password for the REST API.
SPAN - This would have to be enable on a specific NIC port on ISE that you specify and it would be looking for Kerberos messages from the switch. Probably the best way to make this scalable is to filter what type of packets would be spanning to ISE's interface. The important things that ISE needs to see is:
- Username
- IP address
- Domain
Syslog Providers - This one is a fun one because there's almost no limit to what you can configure as a syslog provideras long as the syslog message is sending the following details:
- Username
- IP address
- MAC address
- Domain
Thankfully, the creators of ISE made it easy to use common syslog providers by adding templates of common syslog formats from familar systems:
But in the event that does not work for you, you can click New and add your own syslog template for whatever system you are using.
Now that we've gone through the majority of the providers, you can understand a little better how to send information to ISE for identity mapping. I've taken the below picture from the ISE configuration guide to illustrate it a little better:
Now that we've gone through the configuration of PassiveID, let's move onto our next subject that ties into it...
EasyConnect
EasyConnect is an option for enterprises who want to authenticate uses before granting access but do not want to utilize 802.1x. It's another option or tool in the toolbelt of ISE. There are pros and cons to this approach:
Pros:
- No supplicant configuration to make it work
- No PKI needed
- CoA is done AFTER user authenticates to ISE
- You can configure this as a fallback to 802.1x is you want. It's definitely not an all-or-nothing approach
Cons:
- Access is largely restricted post-login or at least the default ACL is a bit more liberal than you might be comfortable with
- Only supports Windows endpoints at the moment
- Does not see a "logoff" event from Microsoft Server. ISE knows the session has ended either by the endpoint disconnecting from the network (RADIUS session ends) or another user initates a new login to the endpoint
Again, there is no hard and fast rule you can only run PassiveID or 802.1x. If you are deploying ISE and have a mixed environment, you can have PassiveID be your fallback method.
Now we are going to configure basic EasyConnect. In my deployment, I've already configured the AD service which is running on my AD controller as you can see here:
For the purposes of this configuration, I am going to spare the switch and basic ISE configuration. Nothing has changed from previous posts in regards to that. I'm just going to walk through the policy setup for EasyConnect.
First I am going to navigate to Policy>Policy Sets and create a new Policy Set in ISE 2.3 by clicking the + button:
For my top-level condition for this policy set, I'm going to choose Device:Device Types equals Switches and just use Default Network Access. Click Save and then go into the newly created policy set.
For the Authentication policy, we're going to choose Wired_MAB as the condition and Internal Endpoints (essentially anything seen by MAB) as the endpoint group. Remember: We're not authenticating via the network - we're waiting to see an authentication event via Active Directory.
Under the Authorization Policy, I'm going to create a condition of PassiveID_Groups EQUALS AD1:securitydemo.net/Users/Domain Users to look for authentication for anyone part of the Domain Users group as part of PassiveID.
Next, click the + button next to Results Profiles to create a new Authorization Profile on the fly.
On the Authorization Profile, name it whatever you would like and then check the box next to Passive Identity Tracking to indicate this will be used with PassiveID. Then choose whatever common tasks you want.
Under that authorization rule, create a rule with the condition of Wired_MAB and grant it enough access to login to AD. In this case, I just created an Authorization Profile to allow enough access to login to AD and checked the box again for Passive Identity Tracking in the Authorization Profile. In the end, this is what my authorizationrules looked like:
After you have saved the policy set, you should be able to test out a login attempt and first see the endpoint profiled and getting AD access and then move to user access after a successful login. This is a screenshot of another deployment I did showing the successful login.