What is difference among three status in authentication ise

[interfacedy]

Hi Please see the below authentication session. For each Authentication rule under Authentication Policy, there are three options for the Status. I tried each of them, Enabled, Disabled and Monitor for client authentication. I could not find difference among the three. I always saw hit number was increasing at the Authentication Rule 3, instead of Rule 1. It also means even if I disable the Rule 3, the Rule 3 sitll has function. Anyone can tell why? Thank you

[ilay · Accepted solution]

1. The Options of status:

    - Enabled: This policy condition is active.

    - Disabled: This policy condition is inactive and will not be evaluated.

    - Monitor: This policy condition will be evaluated.(evaluate whether the rule will be matched)

2. "Rule 3" and "Rule 1" use same condition ,  if "Rule 3" is Enabled, only "Rule3" will be matched during authentication. You said that after you disable "Rule3", Rule3 can still work. I think this may match rule1. You can check "AuthenticationPolicy" in "Operations->RADIUS->Live Log" to verify whether this is the case. (The "hit count" in the PolicySet is not real-time data. There is a certain delay in this update. After you change the policy status, it is best to verify it in the LiveLog)

-------------------------------------(ISE 2.7 Patch3)

[Amine ZAKARIA]

Hello @interfacedy ,

Enabled and Disabled are for enabling and disabling the policy (authc/authz).

Monitor means if this policy matched, the enforcement does not take in place, So ISE will keep the lookup for the matched policy, and in the matched policy in Live Log you will see the Enabled policy match + Monitor Policies that matched, the reason behind the monitor is to check if the policy matched without impacting the production authentication.

---

@interfacedy wrote:

I always saw hit number was increasing at the Authentication Rule 3, instead of Rule 1. It also means even if I disable the Rule 3, the Rule 3 sitll has function. Anyone can tell why? Thank you

---

The refresh interval is 15 min you can refresh it manually or reset the hit count either, maybe you have authenticated using Rule 3 within that 15 min interval and when you disabled it the counter incremented from the previous authentication not the new one, i don't rely on the hit counts i always check the Radius Live logs for the real time logs.

FYI the auth Rule 1 you don't need Service-type = Framed Because Wireless_802.1x already has two attributes Nas-port-type = 802.11 which is wireless AND Service-type = Framed which is Dot1x

--

Don't forget to rate helpful posts.

[interfacedy]

Thank you Amine and ilay for sharing your experience! I think you are right

FYI the auth Rule 1 you don't need Service-type = Framed Because Wireless_802.1x already has two attributes Nas-port-type = 802.11 which is wireless AND Service-type = Framed which is Dot1x

---

Two questions:

1. can I understand like this: if request match attributes Nas-port-type and Service-type, then the traffic goes to database to find users?

2. how many attributes we can choose? Based on what standard do we choose these attribute? 

[ilay]

1. There is no problem with this understanding. Match the rules, and then use the corresponding identity source for authentication
2. You can set any number of attributes until these attributes meet the requirements of your rules.

For example:

Requirement: The wireless users whose controller ip address is 10.17.0.62 and device is located in Beijing(BJ) use the "ISE Local Identity" ,Other wireless use in Beijing use the identity source of "dc.local"

That is

"device ip = 10.17.0.62" & "device location = BJ" ==> ISE Local Identity"  

"device location = BJ" ==> dc.local Identity

Note that the more detailed rules should be placed in the front position to ensure that these rules are matched first. If you place the 'Default Rule' in the first one, then the other rules will not take effect.

[Amine ZAKARIA · Accepted solution]

@interfacedy ,

---

Two questions:

1. can I understand like this: if request match attributes Nas-port-type and Service-type, then the traffic goes to database to find users?

2. how many attributes we can choose? Based on what standard do we choose these attribute? 

---

1-If it is Authentication policy will lookup the user based on the Identity Sources configured for that specific AuthC.
If it is Authorization Policy will enforce that Authorization profile/ SGT if trustsec is configured.

2-The attributes are chosen based on what you need for your AuthC/AuthZ rule, the condition used for Wired it won't match for Wireless and vers versa, To create a rule you need specific attributes to identify and differenciate between what type of authentication or for authorization lookup, is it Wired?/Wireless? Login? MAB? or 802.1x? User Exist on AD? LOCAL? and so on...

Hope that helps!

--

Don't forget to rate helpful posts!

[interfacedy]

Thank you!!