cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3669
Views
10
Helpful
9
Replies

ISE 2.4 Authentication Policy - Multiple Rules and Options

Anubis71
Level 1
Level 1

Hi, 

 

I am wanting to configure multiple Authentication Policy rules under a policy set, allowing for different certificates authorities. There is already a policy with a certificate authority (Legacy AD Domain) configured but we need to add a new one for a new AD domain as well. If I add a another rule to the Authentication Policy and unfortunately can only place above the current rule, and it matches this rule then all good but if it doesn't does it move to the next rule automatically or do I need to configure the options to be 'continue' rather than 'reject'/'drop'?

 

Need this during the transition stage between the AD domains.

 

I hope this makes sense if not please ping me and I will add more information.

 

Thanks in advance

3 Accepted Solutions

Accepted Solutions

Yes, that is correct.

*** please remember to rate useful posts

View solution in original post

No, that is not correct. As @Marcelo Morais states in his previous message, the CONTINUE option for 'If user not found' results in the session 'falling-through' the Authentication Policy to be evaluated in the Authorization Policy.

This is basically bypassing Authentication for any session that matches your AuthC Policy conditions. This is a pretty big security gap for an 802.1x session, so it should only be used temporarily if needed. The 'If user found = CONTINUE' option is typically used for MAB endpoints to fall-through the AuthC policy to hit the AuthZ policy for profiling.

With your scenario, you need to look at what conditions would be different between the sessions for your different use cases. If you have different CAs, you should have something different in the certificate that you can match on (Issuer CN, SN, etc) to create differentiated AuthC Policies. Those AuthC Policies could have different CAPs, use different Identity Source Sequences using the different AD join points, etc.

View solution in original post

9 Replies 9

Hi @Anubis71 ,

 you can have many Rules in an Authentication Policy.

 Each Rule has a Condition and the following Options: If Auth Fail, If User Not Found and If Process Fail.

 Each Option can have the following "suboptions":

. Continue: jumps to Authorization Policy, not to the next Rule of the Authentication Policy.

. Reject: sends back a reject request

. Drop: drop the packet.

 

Note: for future reference take a look at ISE Administration Guide 2.7, search for Authentication Failures - Police Result Options for details of the actions: Continue, Reject and Drop.

Hope this helps !!!

Hi Marcelo,

 

Thanks for the response.

Hi,

What I suggest is to put all actions as continue (if auth fail, if user not
found, if process fail). This will ensure that users are evaluated against
both ADs until your migration is completed.

Otherwise, it won't move to next rule automatically.

***** please remember to rate useful posts

Hi Muhammed,

 

Just to confirm the continue action is added to the first rule so that if not matched will move to the second rule?

 

Thanks.

 

Andrew

Yes, that is correct.

*** please remember to rate useful posts

Thanks Mohammed.

No, that is not correct. As @Marcelo Morais states in his previous message, the CONTINUE option for 'If user not found' results in the session 'falling-through' the Authentication Policy to be evaluated in the Authorization Policy.

This is basically bypassing Authentication for any session that matches your AuthC Policy conditions. This is a pretty big security gap for an 802.1x session, so it should only be used temporarily if needed. The 'If user found = CONTINUE' option is typically used for MAB endpoints to fall-through the AuthC policy to hit the AuthZ policy for profiling.

With your scenario, you need to look at what conditions would be different between the sessions for your different use cases. If you have different CAs, you should have something different in the certificate that you can match on (Issuer CN, SN, etc) to create differentiated AuthC Policies. Those AuthC Policies could have different CAPs, use different Identity Source Sequences using the different AD join points, etc.

Thx @Greg Gibbs for correcting me.

Thanks @Greg Gibbs that changes my AuthC policy quite a bit. Will look into this.

 

Thanks for your help.