Identity Collector: ISE and AD continually over-writing each other on the PDP

[phlrnnr]

@PhoneBoy- This is related to the question I asked on the IA tech-talk that you gave on Tuesday.

@Royi_Priov  - I hope this thread interests you!

@gpasikowski and @Jason_Buranen thanks for your assistance in troubleshooting this issue!

Overview

In our environment we are currently using Identity Collector to send Active Directory (AD) learned identities to the PDP GW.  This is working well.  However, we want to also connect Cisco ISE to Identity Collector so it can help us identify certain groups of non-AD connected devices.  The thought here is that all devices must use ISE to connect to the network (we are doing NAC, so every device must auth to join the network).  We can then tie a security group (SGT) to the specific types of devices we want to identify and use identity tags inside of access roles in our firewall policy.  

Problem

The problem we have run into is that AD and ISE learn about many of the same endpoints (for example, a domain-joined laptop), and therefore when identity collector forwards the identities as they are learned, the PDP continually over-writes the identity it has learned for a specific IP address.  This causes several issues:

• When ISE overwrites an identity previously learned from AD, the access roles that are tied to AD are lost for that identity until identity collector receives and forwards another AD login event for that user/IP address.  This means the user no longer matches any identity-based rules tied to their AD userID.  (In our case, this would break access to almost all Internet sites)
• Adds performance load to the PDP.  This is because identities are continually over-written on the PDP as they are learned from the two different sources.

Potential Solution

I would like to encourage Checkpoint R&D to develop a filtering mechanism within Identity Collector such that I can forward to the PDP only the identities that match a particular SGT / Security Group.  This would allow me to only send identities learned by ISE for the non-AD connected devices, and not all the other devices that AD already knows about.  This would allow the firewall policy to work as designed for AD joined devices, and allow me to configure rules with Access Roles containing ISE Identity tags for the non-AD joined devices.  This also will improve performance on the PDP because it would no longer have to manage all the un-necessary identities learned by ISE that I cannot filter out.

Specific Example

I hope the following example can clarify what is going on here:

1. Laptop connects to network port (no user logged in).  ISE learns the identity and forwards to the PDP (note, in this example, ISE assigns the laptop an SGT named ‘Employees’):
   
   

   Note: If ISE learns the identity via 802.1x, identity collector forwards it as a “user” identity and not a machine identity.  In this example, ‘sh263886’ is the CN of the computer cert used for the 802.1x authentication.

2. I login to the laptop.  AD logs the login event, and Identity Collector forwards it to the PDP (both machine and user identities).  PDP replaces the ISE identity with the AD identities.  My AD groups are learned and access roles provisioned:
   
   

   I can now surf as a normal authenticated user.  Everything works.

3. If I disconnect from the wired network (eg. I become undocked to go to a meeting), ISE detects that I have logged off, and Identity Collector sends a logoff event to the PDP.  The PDP removes my identity completely from it’s database:
   
4. When I reconnect to the network, ISE learns the identity, but without any AD Group information.  Due to 802.1x auth, the user identity is now learned as the computer name (sh263886@sh-qa.org).  This results in the user losing Internet access until a new AD login event is generated.  Sometimes this happens quickly, sometimes it can take 15-30+ minutes, depending on what applications are running on the computer. 
   
   Here is the ISE login on the PDP:
   
   Here is the UserCheck page that shows the ISE identity that was learned (basically, the PDP only knows about the ISE identity, and because there is no AD info, the user is denied Internet access):
   
   
   
5. Eventually, AD logs a login event, the ISE learned identity is overwritten, and things begin to work normally as they should:
   

This behavior definitely occurs when a laptop is docked/undocked.  It also occurs as ISE performs re-auths periodically throughout the day.  So, this could lead to 'intermittent' issues for end users.

Please let me know your thoughts, and any potential workarounds or solutions!  Again, I think the best solution might be adding functionality to Identity Collector to filter based on ISE SGT/Security Groups.

[PhoneBoy]

Maybe Captive Portal with Kerberos would be a potential solution here.
The idea being that the Captive Portal can request the Kerberos ticket from the PC and associate the AD user with the IP address.

Likely, the best approach would be to deploy the Identity Agent on the end user PC.

[phlrnnr]

I really don't want to have to deploy the identity agent on 30,000+ PCs.  I'm not sure I could even get the buy-in from management to have to deploy another agent on our workstations.  A centralized solution would be much preferred here.

[PhoneBoy]

I can totally understand that which is why I suggested Kerberos + Captive Portal as an option.
I know you and/or your account team had a side conversation with R&D about adding the desired function to Identity Collector or similar.

[_Val_]

@Peter_Elmer Can you add anything here?

[assafal]

Hey,

R80.40 contains new mechanism called PDP conciliation. 

The mechanism allows to support multiple associations per IP instead of keep overriding the existing one.

Therefore, two associations coming from the same collector will live together, in your case ISE and AD.

Assaf,

[phlrnnr]

I don't think PDP conciliation will help here.  The problem is both identities come to the PDP from Identity Collector.  According to "Example 3" in the IDA Admin Guide, multiple identities from Identity Collector will always override each other:

-------------------------

Example 3

The PDP received an Identity Collector session, and then received a new identity from Identity Collector on the same IP address.

The conciliation decision is to override the existing Identity Collector session based on the TTL factor and because only a single Identity Collector session can exist per IP address.

-----------------

Also, I would want the identity to be over-written if IDC learns a new AD login for a device.  The problem here is Identity Collector learns the same identity from multiple sources (AD and ISE), but for PDP conciliation the "source" of the identity is the same (Identity Collector).

Filtering at the Identity Collector level would also alleviate the PDP from expending processing power to do the conciliation of the identities.  This is beneficial since the PDP is not yet a multi-threaded process.

[assafal]

Hey,

Are those user sessions?

If yes, you can try the following command,

'pdp conciliation idc_multiple_users'

[Benedikt_Weissl]

Maybe you can install a second IDC exclusivly for ISE events, then contact support to reconfigure the PDP to prioritze events from the AD IDC to events from the ISE IDC. According to sk146835 support should be able to change the default behaviour.

[phlrnnr]

@assafal Some of them are user sessions and some of them are machine sessions.  I've noticed that ISE treats it as a user session if it was captured via 802.1x authentication and treats it as a machine session if it uses MAB (MAC address based) authentication.  So, ultimately, it is both.

@Benedikt_Weissl thanks for finding that.  I'll open a TAC case and see what info I can glean from that.  I'll do some testing in my lab as well to see if this could be a good workaround.

Ultimately, though, it would be nice to filter the identities closer to home on the identity collector.

[phlrnnr]

@Benedikt_Weissl I confirmed with TAC that having ISE and AD configured on different identity collector servers would not fix this.  Because they both have a source of identity collector, identity conciliation will continue to overwrite the identities.  You can't prioritize one identity collector server over another one.

[Benedikt_Weissl]

Dang it, I've really hoped a second IC would fix that. Thank you for the feedback!

[assafal]

Identity session conciliation behavior can be change by using the following command:

'pdp conciliation idc_multiple_users'

It will append IDC sessions instead of override them

Thanks,

[Hrvoje_Brlek]

Hi,

So how many multiple users can IDC append using the conciliation? All the users can be from the same IDC?

As Identity Collector is supposed to replace the AD Query, why isn't this implemented by default as in AD Query:

• 'machine_multi_users_threshold' (default: 7[users])

The number of users concurrently connected from a single machine (IP) before designating this as a multi-user host, and stopping tracking it. As AD Query (ADQ) cannot differentiate between users on the same machine, and the given permissions are commutative, it prefers to ignore the machine if it reaches this threshold.

Note: setting 'machine_multi_users_threshold' to "0" will disable this feature. The value "0" is supported only from R75.10.

Regards,

Hrvoje

[Jan_Kleinhans]

Hello,
have you found a solution for your problem?

Regards,

Jan

[phlrnnr]

@Jan_Kleinhans Development has written a "Group Filter" into version indigo build B990050018, version 81.018.0000 but it is not yet working as expected. The Group Filter seemed to work in our "test" environment, so the problem may not be specifically with the group filtering, however, there seems to be a bug where the identity source goes "Disconnected" when doing the bulk import.  It may be related to the PxGrid support introduced in the 81.x code train.

We have an open TAC case with development on it.

[abihsot__]

I see it's been year since this issue first appeared. Were there any improvements to this problem?

Could you let us know how group filter can improve situation? Is this filtering AD groups? Wouldn't it filter out events from ISE?

[David_Brodin]

I ran practically the same setup with IDC and ISE pxGrid+AD as identity sources. A difference was I also had Identity Agent on a couple hundred computers and a gate that was sharing with other gates. But I don't think that would have mattered. The plan was to move towards ISE dot1x only identities and turn off both AD and IAgent at some point.

Anyway, I also ran into the issue of machine identities being added as user identities. The TAC said that pxGrid was sending the wrong information. I'm not sure, but {"isMachineAuthentication": "true"} is kinda definitive.

I ended up writing my own pxGrid subscriber that sends identities to gateways via API. In it's current form it's only for machine identities, but it's very easy to extend to users too. I know my previous colleague has rewritten the scripts to include users, and also other optimizations. I'm pushing him to publish his rewrite, but it's going slow.

A big issue though is radius account updates that don't seem to be sent out on pxGrid, at least not on the topic I subscribe to. I know IDC handles this by asking ISE about IP-addresses every few hours. But creating a database was out of scope for the script.

Another issue is that I don't have access to a setup anymore and can't investigate or develop anymore.

[Nir_Rephael]

When machine is authenticated with 802.1x, ISE PxGrid send isMachineAuthentication":"true"
Identity collector should parsed isMachineAuthentication":"true" (which is part of PxGrid information) with machine name and present it as a machine and not as user (currently identity collector presents machine and user  802.1x authentication as a user and there is no way to distinguish between them).
Currently identity collector is parsing only MAC as machine (MAB authentication) when receiving information from ISE.

[CheckPointerXL]

hello, any news on this?

[abihsot__]

This issue was affecting us too. TAC -> RFE -> /dev/null

[CheckPointerXL]

great, so no JHF is needed, i already have that path 😄

[Chris_Atkinson]

@Royi_Priov Is this a scenario that we are familiar with / have a solution for?