Why Add Endpoints to Unknown Endpoint Store When They Fail Authentication

[Patrick Lloyd]

Hi Team,

I'm working with a customer who has posed a question, that I think would be valuable to articulate the logic in our approach to.  When an endpoint joins a wired NAD it attempts to authenticate, in ISE we have a "If authentication fails = Reject" and "If user not found = Reject" in the authentication policy to which credentials are compared against.  However, when we visit context visibility, we see that despite the failure authentication, the MAC is still present in the endpoint identity store, and therefore will be able to be used in future authentications.  This opens a risk of the endpoint profiling correctly in authorization, and being permitted onto the network erroneously unless an authorization policy matching the unknown group of endpoints is used to prevent the endpoint in the authorization policy (If endpoint identity group = unknown, deny). 

The question to this approach is why are we even evaluating the authorization policy on reconnect if the authentication failed on first connect?  Asked another way, why are we adding failed authentications to the endpoint identity group to cause more work the ISE server needs to do when the device connects the second time?

Thanks for your help!

[Mike.Cifelli]

My opinion on your questions:
-My customer wants to know of any/all endpoints attempting to attach to the network. I personally like the fact that ISE adds the endpoint to the internal db as soon as an endpoint is seen for a visibility standpoint. If you setup your authz policies you could have the unknowns hit your default that is essentially a parking lot/dead end. Something else you could do is run scans (if ISE is integrated with tenable; etc.) against these "unknowns" to gather more information on the endpoint & generate reports for customers. That is under the assumption you have a parking lot & ISE integrated with a scanning tool.

This opens a risk of the endpoint profiling correctly in authorization, and being permitted onto the network erroneously unless an authorization policy matching the unknown group of endpoints is used to prevent the endpoint in the authorization policy (If endpoint identity group = unknown, deny).
If you are driving authz policy to your endpoints based on profiled groups I suggest adding additional conditions to match in order to avoid your statement above from occurring. I would also recommend developing your own profiles with higher MCFs to avoid usage of the default profiles. Using your own profiles will allow you to profile based on certain attributes that you can utilize to stay clear of your unknowns getting on the network. One simple one I can think of that you could use in a parent policy (if integrated with AD) is from AD probe (AD HOST exists True/False). Then underneath develop child policies as you wish.

Curious to see other opinions. Thanks

[Johannes Luther]

There are use cases for this, why it's important to store all endpoints:

- Guest endpoints which should use the guest portal

- Endpoints, which are not profiled yet. So you need some type of "store" where the attributes are populated.

....

---

@Patrick Lloyd wrote:

The question to this approach is why are we even evaluating the authorization policy on reconnect if the authentication failed on first connect?  Asked another way, why are we adding failed authentications to the endpoint identity group to cause more work the ISE server needs to do when the device connects the second time?

---

I don't quite get the point here - sorry. First of all, an authentication attempt by a NAS is not distinguishable in initial and reconnects. And "failed authentications" are not added to any "endpoint identity group". The "unknown" group should not be used as an indicator for failed attempts. For example, typically all your 802.1X clients (if your not doing any profiling with group assignment) are in the unknown group as well.

[Patrick Lloyd]

> I don't quite get the point here - sorry. First of all, an authentication attempt by a NAS is not distinguishable in initial and reconnects. And "failed authentications" are not added to any "endpoint identity group". The "unknown" group should not be used as an indicator for failed attempts. For example, typically all your 802.1X clients (if your not doing any profiling with group assignment) are in the unknown group as well.

This was the same impression I was under, however it is incorrect.  Even with an authentication policy that rejects unknown or failed authentications, in version 2.3 and above (from my current testing) the failed endpoint, which was rejected from authentication due to the failure, is still added to an unknown profile in ISE.  The answer I've received is to have a default deny in the authorization policy or match on unknown and specifically deny that as the first rule, but my question remains: The end endpoint fails authentication, why do we add it to an internal database.  It *failed*, it should not be added to ISE whatsoever in my opinion, and if you want to add them to the internal database for visibility purposes, you should be using "if user not found, continue" so it would add the endpoint to the internal database and then an authorization could be used to deny or redirect, whatever the use case entails.

@hslai or @Jason Kunst Any input on why we do this?

Edit: This as a result causes bugs like the following, so it introduces additional risk: CSCvp33593

[hslai · Accepted solution]

There is due to a design change for the context visibility feature in ISE 2.1. See CSCva32803

[Patrick Lloyd]

@hslai The bug that was noted here is related to 2.1 and in the tac repro of it, step 3 is that the endpoint is authenticated correctly.  This scenario is specific to the authentication failing, but still being added to the unknown database store when the node is unlicensed for profiling, and thus should be off.  Is this the same scenario?

Tac Repro:

1. Clean install of ISE 2.1;
2. Disable all profiling probes;
3. Authenticate the endpoint (I used MAB)
4. Endpoint will be profiled and added to the database.

[hslai]

IIRC it does not matter that Step-3 failing auth or not. The default RADIUS probe always adds the endpoint for visibility.

[MahmoudFathy11609]

I agree with you. This is very strange behavior ! in MAB authentication policy what is the benefit of "if user not found:Continue" if the endpoint will be added to the internal identity store though? And as a result, they will pass authentication in next attempt !