Identity Conciliation behavior

[David_C1]

Question about identity conciliation. I was under the impression that a PDP can only have two identities associated with an IP address under certain circumstances (e.g. Terminal Server). I am running some tests in our lab. Background:
Gateway/management R80.20 with JHFA 134
Identity Collector: v80.97.0000 (using ActiveDirectory as identity source)

I also have RADIUS server set up as an identity source for a test user.

I log on to the (virtual) desktop, the identity collector correctly sees my logon and appropriate AccessRole is applied. I test the rule where this AccessRole is used and traffic goes through.
I then open up a Captive Portal window and log on with a different username and authenticate against the RADIUS server. The AccessRole for this user is applied. I test the rule where this AccessRole is used, and traffic goest through.

Here's the kicker: traffic for the AccessRole based in the identity collector based role is also allowed. Traffic based on both identities is allowed. The traffic is matching the corresponding rules for each identity. My understanding was that once I authenticated to Captive Portal (against RADIUS) this would "overwrite" the identity association based on the Identity Collector. Is that actually occurring, and then the Identity Collector is re-mapping my AD based identity, and then combining the two? Is that what is occurring?

On a side note, though the R80.40 IA guide has a section about identity conciliation and references "Confidence, Locality" etc. as parameters to determine how identities are reconciled on a single IP, more information about this process, e.g. what has most confidence, would be appreciated.

Dave

[Vince_Marinov]

Hello David,

If I am understanding your question correctly I would say that you can have multiple sources of authentication and your identity will be stored on the PDP no matter if it's coming from IDC, radius accounting, wifi certificate, identity agent and etc. 

Vince

[Timothy_Hall]

By default a secondary login name becoming associated with an IP that already has one mapped will be appended to that IP address, subject to the conciliation priorities you mentioned, because the checkbox "Assume that one user is connected per computer" under AD Query is not set by default.  If you'd like the behavior to change just check the box and the secondary login name mapping will replace the first one completely.

[David_C1]

My attempts to reply to this were lost in the ether, so I will try again.

I understand you can have multiple identity sources, but outside of Terminal Services, you can only have one identity per IP.  From sk131792:

"Most of Identity Awareness sources (except for AD Query, which is configurable) are overwriting existing information regarding the same IP.

Therefore, once a new user association is received by PDP, the old data on this IP will be overwritten and a log of "A secondary session request was received from the same IP. This caused logout of the current session" will be presented in SmartLog.

The PDP flow is:

Identity information is received for IP x.x.x.x
PDP checks if we already have information for IP x.x.x.x on our database.
IP x.x.x.x contains information for different user name / machine name.
New user name / machine information will overwrite the old one.
Log message "A secondary session request was received from the same IP. This caused logout of the current session" will be presented on SmartLog."

So I log in to my desktop and Identity Collector sees the events in the AD logs and maps my name to the IP. I then authenticate in Captive Portal with a RADIUS account, which according to the above, should overwrite my Identity Collector/AD identity. Now in R80.40 at least (I am on R80.20), there is a capability for Identity Awareness to combine different identities to one IP address ("Identity Conciliation"). However, based on sk146835, identities gathered from Identity Collector and Captive Portal cannot co-exist on one IP address:

"Some identity sources such as Identity Agent, Terminal Server, Captive Portal, and Remote Access VPN cannot be appended to others. In these cases, the conciliation decision is only override or reject.

Identity sources such as ADQuery, Radius Accounting, Identity Collector, and Web-API can be appended to each other. In these cases, the conciliation decision is append."

Note in my Captive Portal, I am using RADIUS authentication, I do not have RADIUS accounting enabled. Yet in my logs, I see both identities (from Identity Collector and Captive Portal). AccessRoles from these identities are both applied to the user logged on to the same IP.

[Royi_Priov]

Hi @David_C1 ,

In R80.40, the default behavior is allowing one identity per IP (except for MUH agent, of course).

Even before R80.40, as soon as you just open the captive portal in your PC, the PDP would remove all saved sessions under this IP and open a new one - by design.

Therefore, the fact that opening the portal keeps your "old" acquired identity sounds weird.

How did you verify it's the IDC identity which appends to the captive portal one? It might be (and in most cases it is) that both IDC and portal will produce same identity with identical access roles.

As for the conciliation feature: In previous versions, we had a hard time to expect which identities will be saved in pdp / pep databases, as it was very related to the sequence of associations and sharing. For example, if a customer is using both Identity Agent and AD Query, if the agent's association would  arrive first to the GW and the ADQ after, the entry will include both associations. If the sequence would be the opposite (ADQ first and than agent), the session will include only the agent session.

We have decided to provide our customers all the abilities to decide which session is "stronger" including identity source, source pdp, and many other categorizations.

There is no good overall answer for all customers in my point of view for this question, therefore the decision is up to you according to your environment.

I hope it helps.

[David_C1]

Royi asked:

"How did you verify it's the IDC identity which appends to the captive portal one? It might be (and in most cases it is) that both IDC and portal will produce same identity with identical access roles."

I'm not sure which identity is appending to which, but both are active. The IDC identity and the Captive Portal identity are two different usernames, each mapped to a different AccessRole. I have one rule which allows ICMP to the gateway for the IDC based AccessRole, and one rule which allows TCP 4434 to the gateway for the Captive Portal based identity. I can both ping the gateway and connect to it over TCP 4434 (once I authenticate to the Captive Portal). Also, in my logs it shows two usernames:

The first two lines above are my IDC based identity, the third line is the Captive portal based identity.

Dave

[David_C1]

"Even before R80.40, as soon as you just open the captive portal in your PC, the PDP would remove all saved sessions under this IP and open a new one - by design"

I have confirmed this behavior.

It looks like what is happening is that soon after I authenticate with Captive Portal, IDC "re-learns" my AD based identity (I assume based on some background activity by my logged in account which creates logs on the DC) and appends it to the IP of the host, and both AccessRoles are active.

In the above logs:

7:58:10 - logon to the desktop, IDC recognizes identity.

8:01:09 - Captive Portal is opened. IDC identity is logged off

8:02:15 - Logon to Captive Portal

8:03:11 - IDC recognizes identity

Dave

[David_C1]

Can someone from Check Point (Royi maybe) confirm what I describe above is expected behavior? We are getting ready to roll out IDC and Captive Portal in production and I need to know what to expect.

Thanks,

Dave

[assafal]

Hey David,

The conciliation mechanism presented in R80.40 will detect two different identity sources that send report regarding the same host. The mechanism uses pre-defined set of behaviors that determine the priority for each.

In your case, Captive Portal (Direct authentication by the end-user) is much stronger then events coming from Identity Collector (3 Party that report to us). Therefore, between those two, the conciliation will choose to keep the Captive Portal session and reject the Identity Collector (Captive is much stronger)

You will still see the Collector sending those event in the logs for visibility reasons, however inside the PDP only the Captive Portal session is presented and being used (using the command 'pdp monitor <IP>')

The conciliation pre-defined set of behaviors can be changed according to the customer needs.

For more information, please review IA Admin guide R80.40 -> Conciliation section.

[David_C1]

This makes sense, and I understand that this is how it is supposed to work (keep in mind I am on R80.20, so things may behave differently). But I am able to produce circumstances where I get this:

[Expert@pwksec227t:0]# pdp monitor ip 10.39.71.8

Session: 39992ef7
Session UUID: {E856F844-30E1-79C8-6C5B-C2A77C71E5F6}
Ip: 10.39.71.8
Users:
dcharnon.lab {9d3e3c68}
Groups: RSA_Test;All Users
Roles: IT-Lab_Admins-VDI_Portal
Client Type: portal
Authentication Method: User & Password
Distinguished Name:
Connect Time: Thu May 21 11:35:02 2020
Next Reauthentication: Thu May 21 23:36:31 2020
Next Connectivity Check: Thu May 21 23:36:31 2020
Next Ldap Fetch: -

a.dcharnon.lab@atc.lab {e353abcf}
Groups: ad_branch_AdminAccounts;All Users;
Roles: IT-Lab_Admins-VDI
Client Type: Identity Collector (Active Directory)
Authentication Method: Trust
Distinguished Name: CN=Charnon\, David Admin,OU=AdminAccounts,OU=Administrative,OU=ATCLAB,DC=atc,DC=lab
Connect Time: Thu May 21 11:41:39 2020
Next Reauthentication: Thu May 21 23:42:09 2020
Next Connectivity Check: -
Next Ldap Fetch: Thu May 21 14:28:55 2020

Packet Tagging Status: Not Active
Published Gateways: Local
************************************************************************************

[Expert@pwksec227t:0]#

Does this make sense based on what you expect to happen? Two users from two different identity sources are associated with the single IP.

Dave

[assafal]

Hey David,

Indeed in R80.20 version this is the expected behavior.

Additionally, if you try to do the authentication in the opposite direction (Collector and then Portal)

The Captive Portal source will override the existing Collector session.

The conciliation mechanism was integrated to R80.40 version.

Trying to do the same will not work and only the Captive Portal will remain.

However, there are some identity sources that can be appended to each other.

Basically, from 3-party sources that report to us (IDC ,radius, WebAPI, etc.) because they were not initiated directly by the end-user. For the complete list you can review the section 'identity conciliation' in R80.40 admin guide.

[David_C1]

Thank you for this explanation. Just so I am clear:

In 80.20:

An identity from IDC can be appended to an identity from Captive Portal

In 80.30:

?????

In R0.40:

An identity from IDC cannot be appended to an identity from Captive Portal

Could you confirm that I have the above correct? And what is the behavior in R80.30?

For my particular use case, allowing the identity from IDC to be appended to the identity from Captive Portal would be a great benefit (in all versions). Any chance this will change or allowed to be changed by a setting in future JHFA?

Thanks

Dave

[assafal]

Hey Dave,

Sorry for the late response.
This behavior is new in R80.40.
Therefore, R80.30 is the same as R80.20.

Could you please elaborate regarding your particular use case?

[David_C1]

Sure, here is a basic scenario:

User A logs into his Windows desktop and has an Access Role assigned to him via AD group membership. Identity Collector is the method used for this Access Role. This Acces Role gives him access to Systems A, B, and C.
User A is also an authorized user of System D, but this is a more critical/sensitive system. Before he can access this system, he needs a new Access Role assigned. This Access Role is granted via Captive Portal using RADIUS (MFA) as the authentication mechanism. We want this so that his access to System D is open only when needed, and we want the use of MFA for heightened security. His Active Directory account and RADIUS account are two different accounts. In R80.40, once he authenticates through Captive Portal, his access to Systems A, B, and C are cut off. This is not practical the user's work activity.
With R80.20 and R80.30, his Captive Portal identity overwrites his IDC identity, but regular user activity on the Windows desktop will soon re-register his IDC identity and it is appended to his Captive Portal identity (and therefore both Access Roles are enforced).

Hope this makes sense. If not, please ask and I will try and elaborate further.

Dave

[assafal]

Hey Dave,

I'll consult with my colleagues and post back soon as possible

[assafal]

Hey Dave,

I've consulted with my colleagues and there's something unclear.
Are you able to the the described use case with R80.20?
It's not yet supported to select a specific Identity Source inside Access Role object.
Therefore, identities created using Collector and Captive Portal will get the same Access Roles.

[David_C1]

The identity (username) collected by the Identity Collector and the identity (username) collected by Captive Portal are two different usernames. They are just "owned" by the same actual person.

Dave

[assafal]

Hey Dave,

I'd like what you have done here.
Anyway, this is no longer supported in R80.40.
Identity Collector session can not joined to Captive Portal session.

However, you've presented a good use case that needs to be consider. I'll forward this case and take it further .

Thanks Dave!

[David_C1]

Thank you for your attention to this. We will not be able to upgrade to R80.40 unless this behavior is changed to align with R80.20/R80.30.

Thanks,

Dave

[assafal]

Hey Dave,

I'll take this case further and see what can be done.
Let's keep this thread running

[David_C1]

Thank you,

Am I correct to assume the conciliation behavior is only dependent upon the version of the Gateway, not of Management? In other words, I could have my management on R80.40, and my gateways on R80.20 or R80.30, and the identities would append as I need them to?

Thanks,

Dave

[assafal]

Hey Dave,

Correct, only gateways.
Not related to the Management.

[Schafi]

Hi, we have a quite similar use case to Davids one:

David wrote: "

---

User A logs into his Windows desktop and has an Access Role assigned to him via AD group membership. Identity Collector is the method used for this Access Role. This Acces Role gives him access to Systems A, B, and C.
User A is also an authorized user of System D, but this is a more critical/sensitive system. Before he can access this system, he needs a new Access Role assigned. This Access Role is granted via Captive Portal using RADIUS (MFA) as the authentication mechanism. We want this so that his access to System D is open only when needed, and we want the use of MFA for heightened security. His Active Directory account and RADIUS account are two different accounts. In R80.40, once he authenticates through Captive Portal, his access to Systems A, B, and C are cut off. This is not practical the user's work activity.
With R80.20 and R80.30, his Captive Portal identity overwrites his IDC identity, but regular user activity on the Windows desktop will soon re-register his IDC identity and it is appended to his Captive Portal identity (and therefore both Access Roles are enforced)."

Currently we are using IA and Legacy Authentication (Client Auth) together. This means that for "normal" access we use IA and for more critical access the user has to authenticate additionally via the legacy captive portal. A so-called step-up authentication. This works fine because legacy auth policy does not mix with IA and we can achieve our goal of step-up authentication for critical access.

However, we would like to move away from legacy auth and use IA instead. Therefore we have the same requirement as Dave. With the difference, that we want to use the Identity Agent and the Captive Portal as source.

assafal wrote:

---

"It's not yet supported to select a specific Identity Source inside Access Role object."

This could be a way to fulfill our requirement.

It would be great if a client IP-Address could have multiple identity roles from different identity sources. And the behavior of the identity conciliation should be customizable by the customer according to their needs. This for all identity sources within IA.

Any progress on this topic?

[Royi_Priov]

Hi @Schafi,

Adding Access Role object the ability to be assigned for specific Identity Sources is something we PoC'ed and it is on our road map.

As I always recommend, having RFEs for such features will help us with our prioritizations.

[David_C1]

---

@Schafi wrote:

Currently we are using IA and Legacy Authentication (Client Auth) together. This means that for "normal" access we use IA and for more critical access the user has to authenticate additionally via the legacy captive portal. A so-called step-up authentication. This works fine because legacy auth policy does not mix with IA and we can achieve our goal of step-up authentication for critical access.

However, we would like to move away from legacy auth and use IA instead. Therefore we have the same requirement as Dave. With the difference, that we want to use the Identity Agent and the Captive Portal as source.

Circling back to this...

Schafi's description above is exactly the same scenario we are in. We still use client authentication for "step-up" authentication, and cannot move from it until we can replicate this functionality with Identity Awareness and captive portal.  At the very least, allowing the customer to control conciliation would be ideal.

Dave