ISE WIred Dot1x Monitor Mode - Behaviour question

[shamax_1983]

Hi All,

I am preparing for a wired dot1x rollout and have some questions around Monitor mode behaviour.

More I read about this, more confusing I get. Specially due to the fact that, no document cleardy states if the Switch Port with the command "access-session open" completely ignores the the Radius reply from ISE, and keep maintaining the access to the attached device(s) as per the configured Data and Voice VLANs (and Access-list if there is one) on the switch port itself or, if it only ignores it if the (ISE/Radius) reply is a REJECT.  What happens if the Radius/ISE Reply is an ACCECPT but with a Authorization change to assign a new VLAN?

So just trying to understand this behaviour. 

I am seeking the answers to following scenarios to fully understand what Monitor mode actually is and how to leverage it.

Switch Port config (remains for all cases):

Dot1x and MAB enabled.

access-session open

switchport access vlan X

switchport voice vlan Y

ISE Setup 1)

ISE Settings

If Dot1x -> Access-Reject (unconditionally)

if MAB   -> Access-Reject (unconditionally)

Default Authz -> Access-Reject

1) What would happen to a PC that gets plugged into this switch port

2) What would happen to a Cisco Phone that gets plugged into the above switch port

ISE Setup 2)

ISE Settings

If Dot1x -> If Auth Success =>  Access-Accept + Assign Dynamic VLAN : Z

If MAB   -> If Auth Success => Access-Accept + Assign Dynamic VLAN : Z

Default Authz  -> Access-Reject

1) What would happen to a Dot1x enabled PC that gets plugged into the switch port? Would it be put into the VLAN Z or would it remain in VLAN X ?

2) What would happen to a PC or some other Device (non-Cisco) that get plugs into the port (with no Dot1x or MAB allowed)?

3) What would happen to a Cisco Phone without MAB or Dot1x configured ?

ISE Setup 3)

ISE Settings

If Dot1x -> If Auth Success => Access-Accept

If MAB   -> If Auth Success => Access-Accept

Default Authz  -> Access-Accept + Assign Dynamic VLAN Z

1) What would happen to a Dot1x enabled PC that gets plugged into the switch port? 

2) What would happen to a PC or some other Device (non-Cisco) that get plugs into the port (with no Dot1x or MAB allowed)?. Would it remain in VLAN X or would it be assigned the Dynamic VLAN Z ?

3) What would happen to a Cisco Phone without MAB or Dot1x configured ?

Thanks in advance for spending time on replying to this. Much appreciated.

[Surendra]

ISE Setup 1)

ISE Settings

If Dot1x -> Access-Reject (unconditionally)

if MAB -> Access-Reject (unconditionally)

Default Authz -> Access-Reject



1) What would happen to a PC that gets plugged into this switch port
Ans: It will have full access to the network.

2) What would happen to a Cisco Phone that gets plugged into the above switch port
Ans: It will have full access to the network.



ISE Setup 2)

ISE Settings

If Dot1x -> If Auth Success => Access-Accept + Assign Dynamic VLAN : Z

If MAB -> If Auth Success => Access-Accept + Assign Dynamic VLAN : Z

Default Authz -> Access-Reject



1) What would happen to a Dot1x enabled PC that gets plugged into the switch port? Would it be put into the VLAN Z or would it remain in VLAN X ?
Ans: It will be put into VLAN Z.

2) What would happen to a PC or some other Device (non-Cisco) that get plugs into the port (with no Dot1x or MAB allowed)?
Ans: MAB is bound to happen if you have configured on the port. If you have not configured MAB, then it will still have full access and Dot1x is going to fail and authentication open allows access to the network in such scenario.

3) What would happen to a Cisco Phone without MAB or Dot1x configured ?
Ans: Same as question 2.


ISE Setup 3)

ISE Settings

If Dot1x -> If Auth Success => Access-Accept

If MAB -> If Auth Success => Access-Accept

Default Authz -> Access-Accept + Assign Dynamic VLAN Z



1) What would happen to a Dot1x enabled PC that gets plugged into the switch port?
Ans: PC will be put into VLAN Z.

2) What would happen to a PC or some other Device (non-Cisco) that get plugs into the port (with no Dot1x or MAB allowed)?. Would it remain in VLAN X or would it be assigned the Dynamic VLAN Z ?
Ans: It will remain in VLAN X.

3) What would happen to a Cisco Phone without MAB or Dot1x configured ?
Ans: It will have full access to the network.

Here is a simple funda. If you have access-session open or authentication open configured under the port, if the authentication and authorization is successful, then server policies are applied. If it is a failure (Access-Reject or device incapable of performing the authentication), the end device will have full access to the network if no ACL is configured on the port. If an ACL is configured on the port, then the traffic is allowed accordingly.

Reference : https://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie4010/software/release/15-2_4_EC/configuration/guide/scg-ie4010_5000/sw8021x.pdf Section : Open1x Authentication

[shamax_1983]

Hi Surenda,

Thanks for your explanation.

Just a bit unclear why you said on Setup3) Q1) that the PC will get the VLAN Z. Shouldn't this remain in VLAN X (Since the DOT1X specific Policy gets hit first )?

Thanks

[Surendra]

Well, your question said that you are pushing VLAN Z from the ISE/RADIUS server and that the PC is dot1x capable . So if it is an Access-Accept, then the policy pushed from ISE, i.e., VLAN Z will be applied.

[shamax_1983]

If the PC is dot1x enabled and ISE has a specific dot1x policy only with an Access-Accept (without any AuthZ configured), wouldn't the switch only receives an Access-Accept?. 

The Dynamic VLAN Z is only associated with the Default Policy. Which I believe is not considered in this case (as it already matched a policy above that). That's why I thought it should remain in VLAN X.  Am I missing something here ?

Thanks again.

[paul · Accepted solution]

The only thing "open" mode affects is:

1. Is traffic allowed preauthentication?
2. Rejects will be ignored.
3. Automatically fails open if ISE is unavailable.

Everything else is the same as closed mode.  So whatever you are pushing from ISE will be taken by the switch.  The only message from ISE that will be ignored is REJECT.

[shamax_1983]

Thanks for that Paul. That sums up everything I wanted to know.

So this means that if I have Guest Access/Portal configured on ISE (facilitated by a Default Access-Accept rule at the bottom of the AuthZ ruleset), there is no difference between using Close mode Vs. Monitor mode (given that I don't have any REJECT rules configured anywhere else).

Also, if I want to use "Monitor mode" effectively, to truly monitor and identify potential issues without "touching" the ongoing access of the end users ( ie. Staff Data access and Voice), I have to make sure that I only have Access-Accepts (without any AuthZ) or Access-Rejects in ISE. Anything else has the potential to cause the switch to change its pre-configured DATA/VOICE VLANs (or Pre-Auth ALC) to something else - basically violating the very nature of the "Monitor" mode.
Which also means that I could never "simulate/test" Guest Access in "Monitor mode" without causing unauthenticated users to actually go into Guest-VLAN ( since the Access-Accept+AuthZ will actually cause the switch to take action).

So if I have everything tested in a lab environment ( 802.1x + MAB + Guest), and I want to roll out the change in production in Monitor Mode, I may have to just substitute the "Guest-Access AuthZ" entry with an Access-Reject during Monitor Stage. So I can just test/simulate 802.1X and MAB. And when I think everything is good with 802.1x and MAB, I would simply have to enable Guest Access later when going into production.

Sorry about the follow-up questions, but that would cement my knowledge about this topic.

Thanks again for taking the time to answer my questions.

[paul · Accepted solution]

This is the biggest misconception I find in ISE. There is really no such thing as "monitor" mode. ISE rules are always being applied the only different between monitor mode and production mode typically is the bottom two rules in your MAB policy set:



If in monitor mode and I don't know what you are then allow full access else

Permit whatever the default access should be for unknown devices



You could create monitor only policy sets that don't do VLAN moves and just accepts. This would allow you to verify everything is hitting the correct rules before taking the switch out of monitor mode.



Also note that once you enable authentication of any kind on the switches the data/voice domain rules will be enforced by the switch. If you don't set the voice domain correctly for your IP Phones in ISE they will most likely stop working. So yes monitor mode can break your IP phones.

[shamax_1983 · Accepted solution]

Thanks for your detailed reply. Exactly what I was thinking. 

The whole "Monitor mode" pitched by Cisco is purely based upon a lot of (not so practical) assumptions.

But in real life, if you want to truly go into Monitor stage without causing "ANY" change/damage to the production traffic, you are going to have to reduce/change the original AuthZ rule set (that you wanted to test in the first place) before going into monitor mode, which makes the whole "monitor mode" a not so useful thing in real life.

[paul · Accepted solution]

It really isn't that bad if you aren't doing VLAN moves or trying to apply restrictive DACLs during the initial ISE rollout. The only exposure you should have in Monitor mode is the voice VLAN issue. If you don't set the profile right for your phones you could cause problems. I usually advocate for not doing VLAN moves and we only apply placeholder "permit ip any any" DACLs during the initial rollout. After everything is out of Monitor mode then we work on DACL lockdown per device class (or leverage SGTs if appropriate).

[shamax_1983]

Yes, I agree. Only if you are not planning on VLAN changes or assigning more restrictive DACLs (than what you have preconfigured on the port).