Identity Group as a policy set condition

[srikkulk]

Hello,

A separate Policy Set for Alcatel IP Phones is created in a customer environment. The Alcatel devices are profiled correctly and all MAC addresses are listed in an Endpoint identity Group. The idea is to configure the Policy Set Condition to match the Alcatel Identity group. However it is not and matching Default Policy set.

I have tried with other conditions/attributes like Location, NAS IP, etc it works. I am trying to figure out the reason why identity group is not matched. I have put the condition as "Internal Endpoint Identity Group: EQUALS Alcatel-Devices". The name is just a string and doesn't match any identity group in the search field. I have attached the snapshot of the condition.

Any ideas are appreciated. Thanks.

[hslai]

This is expected for two reasons:

1. Many attributes are accessible at this stage of the policy evaluation;
2. Internal Endpoint Identity Group does not work -- CSCuo05180

[Craig Hyps · Accepted solution]

Policy Sets are used to direct Authentication requests to proper ID store and method and then determine proper authorization post Authentication.  Therefore, Policy Set conditions typically limited to those attributes accessible in the RADIUS transaction, not resulting from identity lookup.  In ISE 2.3 we have made some changes that make this even more clear cut.  There are specific use cases where it may be desirable to direct auth flow to specific policy set by extracting data associated with the MAC address in Calling-Station-ID, such as profile or ID group, but need to add customer to enhancement request via Cisco account team.  The PM for this would be Tal Surasky.

Craig

[scott.pendleton]

That explanation would make perfect sense in the authentication stage, but not the authorization stage of the policy set. I can for example match a user name that was extracted form a certificate passed during Authentication against an Identity Group pulled in from AD. That's all post processing after the RADIUS exchange. If I can do that with an external ID store, I should at least be able to do it with an Internal one. In my particular case I have a subgroup of devices that I want to execute a different auth profile, but no matter what I try it won't match on an internal endpoint ID group.  This is something that could be done back in ISE 1.2. In fact there are even blog post in how to do in 2.2, but the ruleset is different enough in 2.3 that it won't let you construct the same kind of rule. 

[Craig Hyps]

It is no longer possible to "hop" policy sets under ISE 2.3 and even under prior versions, the policy set conditions cover both Authentication and Authorization, so can not have condition that can only apply to Authorization phase.

In any case, to match on ID group, it must be done within the authorization policy rules.  ISE 2.3 example for matching Endpoint Identity Group:

This will allow application of a specific Authorization Profile based on Endpoint ID group match.   However, this condition would not to apply to the Policy Set condition (the conditions used to select a specific Policy Set).

Craig

[scott.pendleton]

No one said anything about hopping over authentication.  In RADIUS authentication and authorization are part of same transaction. However, RADIUS is not doing the evaluation of the data. RADIUS Is simply accepting attributes and sending responses. The actual evaluation of what is received (conditions) and what result is be returned is done outside of RADIUS by a policy engine.

Your assertion about conditions is false. There are two parts within the same transaction. Within the Policy set there are conditions for what type of authentication was requested, which can determine how the credentials are evaluated. At this point it is only determining if the request was made with an allowed protocol, the credentials exist, and are valid.  If at least one set of conditions evaluates to true, then all the attributes that were received in the authentication request are sent to what is essentially a finite state machine that can have numerous complex conditions that apply ONLY to authorization. The FSM exits with one state, which determines the RADIUS message type to return and any additional attributes to attach to the message. It is a 2 step process that occurs in the same RADIUS transaction. Authentication is the who,  Authorization is what, when, where. There is no why. That is handled by the guy/gal in the suit that judges what people should be able to do on their network.

Besides that point, the example you give is an authorization condition that should do exactly what both the original poster and my example want it to do but does not.  I also found it last night that is actually related to a registered bug that is stated above. The work around is that endpoint groups only will evaluate true using a 'Matches' operator.  None of the other boolean operators llke Equals or Contains will evaluate to a true result.

[Craig Hyps]

The point about auth policy hopping was specific to older use cases with policy sets where a reauth could allow a different policy set to be selected for the same session (separate transaction).   Apologies if that led to confusion.

Yes, I am fully aware the stages of RADIUS transaction.  The original problem statement was expressed as and inability to match Endpoint Identity Group in a Policy Set Condition.  If that was the wrong interpretation, then certainly response may not apply.   

What I explained for ISE 2.3+ behavior is accurate.  At the policy set level, we are assessing conditions which are assumed known prior to proxy or protocol decision.  There is no option to select Endpoint ID group at this level.  We do not perform lookups prior to authorization to an unknown ID store, or before we even know whether to proxy the request.  There could be some logic to allow such behavior, but this is not the current logic in ISE.

I am happy if root cause determined to be with the condition operator, but it still stands that such a condition can only be defined in the Authorization Policy Rule under ISE 2.3+.  This should also be the behavior under prior releases, but it is possible we exposed attributes which were not applicable prior to authentication phase completion--again, based on the logic implemented in ISE.

[scott.pendleton]

OK.  Yes. that was the point of confusion. You were commenting on something that might have been erroneously select-able in a previous release. The condition to select a policy set is limited to only values passed in the initial RADIUS request. I had not come across a version that allowed you to select otherwise at that level, so my assumption was that he must have been referring to an authorization condition within a policy set.

Hopefully our back and forth would clarify that for a future reader.