topic Re: Specific profiles for specific locations in Network Access Control

Specific profiles for specific locations

bricrock — Mon, 18 Jun 2018 15:32:22 GMT

An existing, successful ISE deployment is looking to expand to include new departments. However, these departments are reluctant to participate in ISE because they fear disruption. For the purposes of this question, let's consider Departments A-G to be existing participants in the ISE deployment. The new departments will be Departments H and I.

As a first step towards adoption, two new PSN's will be deployed for the purposes of collecting profile/device data from network devices located in Departments H and I -targeting a sort of Monitor Mode configuration.

Understanding that we can create AuthC policies based on authenticating NAD, how can we then profile these endpoints separately from the existing, working endpoint groups/profiles into new, dedicated endpoint groups/profiles specific to these departments?

For example, we don't want a Windows workstation in Department H to be profiled as simply a "Windows10-Workstation"; but, rather, as a "DeptH-Windows10-Workstation". Or an Unknown device to be profiled in a separate "DeptH-Unknown" group so that we can talk to the department admins and develop accurate checks (e.g. they may use a different model of printer than what we've accounted for).

Initial thoughts are to use a parent Profiler Policy for the department. This Parent Policy would include a condition of the authenticating NAD. Child Profiler Policies could then be created, as needed, to refine Unknowns or others. But this doesn't seem to take priority over the other policies. Can something be configured in the Policy Set to force a particular endpoint group and set of profiling policies?

Thank you,

Brian

Re: Specific profiles for specific locations

adarshane — Mon, 18 Jun 2018 18:15:08 GMT

Hello Brian,

Profiling policies are global. For a windows computer to be profiled separately as DeptH-Windows10-Workstation, it needs to send its hostname in a particular format or send some form of dhcp class identifier and you have to match that in a profiling condition on ISE.

The easiest way I think to differentiate building H and I end-devices is,

1) Create new Network device group aka tag for these NADs under Network Devices List > New Network Device

2) Create a separate authorization policy to match this tag and have it assigned built-in Monitor_Profiled authorization

for example,

Rule Name = Monitor_Policy

Condition = Profiled Identity Group (Windows 10, MAC, Printer etc)

Permissions = Monitor_Profiled

This way you can tag NADs separately for building H and I and end devices authenticated on those can have a different authorization policy.

Once the monitoring period is over, you can change the tag on the NADs and bring them under common authorization policy without making a major change.

Hope this helps!!

Regards,

Amod

Re: Specific profiles for specific locations

bricrock — Mon, 18 Jun 2018 18:48:29 GMT

Thanks, Amod.

However, the issue isn't with the Network Device or Policy differentiation; but with the assigned Endpoint Profile and Endpoint Group.

The correct policy is being hit, but the endpoint is receiving the generic Windows10-Workstation Endpoint Profile and, as such, isn't getting placed into the correct/expected Endpoint Group.

Ideally, this is what would happen:

Endpoint authenticates to a switch in Department H via MAB, is assigned the parent profile of DeptH_Device, additional attributes may further profile the endpoint to the child profile of DeptH_Printer, and the device is placed into the endpoint group "DeptH_Printer". AuthZ policy is simply PermitAccess (we're not trying to affect any network control).

I feel like I'm close, but that I'm not taking into account some default behavior of the ISE.

Thanks again,

Brian

Re: Specific profiles for specific locations

bricrock — Mon, 18 Jun 2018 19:05:21 GMT

I figured this out: I had to increase the certainty factor for the custom profile in order for it to supersede the Windows10-Workstation profile. Once that was done, proper group assignment followed, as expected.

Hopefully we don't have too many custom profiles with high certainty factors.

Thank you,

Brian