host-mode multi-auth with latest IOS 12.2(55)SE BIG problem

[moomoomoo17]

Hi Community, Cisco Guys!

I have a Catalyst 3560G PoE-48 here and wonder why
authentification {fail, no response} options are being ignored.

Port config:
interface GigabitEthernet0/43
switchport mode access
authentication event fail action authorize vlan 221
authentication event server dead action authorize vlan 221
authentication event no-response action authorize vlan 221
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication port-control auto
authentication violation replace
dot1x pae authenticator
dot1x timeout tx-period 5
no cdp enable
no cdp tlv server-location
no cdp tlv app
spanning-tree bpduguard enable
end

Hardware Setup:
Cisco Switch <-> Unmanaged Switch <-> {PC1,PC2}

If the first device (PC1) connecting to the unmanaged switch has no
supplicant installed, the port on cisco switch should be assigned
vlan 9, but this does not happen:

trap log:

Oct  5 14:40:37 192.168.1.1 17785: *Mar  4 23:21:32.581: %AUTHMGR-5-START: Starting 'dot1x' for client (001c.dfdf.123c) on Interface Gi0/43 AuditSessionID AC1000180000011E147061B6
Oct  5 14:40:51 192.168.1.1 17786: *Mar  4 23:21:48.016: %DOT1X-5-FAIL: Authentication failed for client (001c.dfdf.123c) on Interface Gi0/43 AuditSessionID
Oct  5 14:40:52 192.168.1.1 17790: *Mar  4 23:21:48.016: %AUTHMGR-5-FAIL: Authorization failed for client (001c.dfdf.123c) on Interface Gi0/43 AuditSessionID AC1000180000011E147061B6

show auth sess:

Interface  MAC Address     Method   Domain   Status         Session ID
Gi0/43     001c.dfdf.123c  N/A      DATA     Authz Failed   AC100018000001201479037D

Why is this a BIG problem:

everybody who goes the 802.1x way, want's a secure and dynamic network.
host-mode multi-auth enables us to allow people to plug an unmanaged switch
into any 802.1x cisco port and still use 802.1x on their attached computers - as long
as all computers go into the same vlan. However they can also just plug their
computer directly into the 802.1x enabled cisco port.

The authentication events "fail" and "no response" are in place to enable new or unconfigured
machines in a special "provisioning" vlan, for example to redirect all http get's to a capitive portal
giving them information how to install 802.1x supplicants.

THIS does not work anymore with host-mode multi-auth - please, cisco: fix this!

Thanks in advance!

[Tiago Antunes]

Hi,

I am afraid that what you are experiencing is by design...

In the documentation:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_55_se/configuration/guide/sw8021x.html#wp1454875.

There is a Note saying:

"When a port is in multiple-authentication mode, the guest VLAN and the authentication-failed VLAN features do not activate."

Hope this clarifies you.

Thanks,

Tiago

[moomoomoo17]

Designs can be changed - It would really improve dot1x deployment...

[b.julin]

Really?  For me 12.2(55)SE is just plain broken in multi-auth mode.  It will not even assign a vlan to single succesfully authed clients.

Though that may be due to using MAB instead of dot1x.

But you are so right -- flex auth is a huge step up from where this was a year or so ago, but it still needs work.

My other switches by a different vendor (who shall remain nameless) are much less flexible, but at least they get this part right:

1a) If the first client fails RADIUS auth, it should put the port in the auth-fail VLAN (or no-response as seems to be the right one to use for MAB.)

1b) If the first client succeeds RADIUS auth, it should do what the RADIUS server tells it to do, or fall back to the configured VLANs on the port.

2a) If the second client succeeds RADIUS auth and the first one failed RADIUS auth, it should block all access from the first client a-la "port-security restrict", and let the registered system into the configured/RADIUS-provided VLAN.

2b) If the second client failed RADIUS, but the first one succeeded RADIUS, the switch should just block all access from the second client a-la "port-security restrict".

2c) If both clients succeed RADIUS and the RADIUS server tries to put the second client in a different VLAN, then it should block all access from the second client.

3) If both clients succeed RADIUS and the RADIUS server (or port config) assigns them to the same VLAN, then both clients should be allowed on.

The general rule of thumb being: do not interrupt an existing session unless a registered client is being blocked by an unregistered client, in which case, go ahead.  Granted it's a bit more nuanced than the above when you are doing "priority dot1x mab" but still -- I've been tearing my hair out trying to get both these vendors to behave the same way and at the same time do something sane, and the state of flex auth isn't helping things any.

Anyway, the other vendor's equipment has the drawback that if my RADIUS server goes belly up I can't fail open -- it only has two choices for VLAN -- the auth succeeded VLAN and the everything-else-that-could-happen VLAN.  When all you are using dot1x for is virus control, not gubment-level-intrusion security, then that's a bummer.  But still, preferable to what flex auth is doing.

[srv.seguridad]

I am experiencing the same problem. We are deploying 802.1x with 3750-X access switches, guest-vlan, auth-fail vlan and dynamic vlan assigned by RADIUS. There is a phone connected to the switch port and more than one host behind the phone, such as a HUB or a virtual machine hosted by the physical machine.

If we use multi-auth mode we loose guest access.

If we use multi-host mode we loose independant authentication on each of the hosts behind the phone.

I can not understand why is this actually implemented by design. I do not believe it to be a strange case scenario, and wonder if there is any workaround. I have seen the open-port command with ACLs but it seems to be a somehow temporary patch to smoothly migrate to 802.1x rather than a permament solution.

I have configured this same scenario on a switch from other brands without any problems. There was just a standard MAC-to-VLAN assignment where all hosts must authenticate independently.

[b.julin]

Currently I'm running MAB (no 802.1x) on 12.2(55)SE1 and it is working with the following workaround: When a host fails authentication, I have the RADIUS server "succeed" it into a registration VLAN.  This can be done per-switch by name rather than VLAN number, so you can have different "guest" vlans per switch by naming them the same.  What you can't do is configure the "guest" vlan per port unless you want to keep a parallel database on the RADIUS server side or play SNMP tricks in realtime.

However there is another bug in multi-auth mode I am grappling with: at least with MAB, it breaks "authentication control-direction in" so if you have a quiet device (or a sleeping WoL card that isn't sending gratuitous ARPS like the Intel AMT ones do), then you lose connectivity when the MAB session times out or when the port state flaps because ARPs and unicast floods cannot get to the device.  WoL of course would break, too under this condition.

On a certain level this isn't a big deal because we only support AMT for sleepers, and the rest of the quiet devices are all building-integrated stuff which can be put on a "single-host" port.  Still, that is one more per-port setting to keep track of, and it's arguably in the "just plain broken" category, so if you go with the above workaround, consider the impact of that.

P.S.: In defense of RADIUS-installed ACLs rather than VLAN switching, they do fix a problem in that if you have your machine-auths going to a different vlan than your user-auths, that will break RDC, and also make the machine more difficult to locate for WoL.

[srv.seguridad]

Mmm we are doing a machine authentication previous to the user authentication. The first sends the machine to a vlan similar to the registration vlan you mention. But if we let MAB auth fails into that registration vlan, both guest users and legitimate machines would end up on the same vlan and we can not allow that in this scenario.

Regarding the MAB multi-auth related bug, we have the same thing implemented for WoL (though I haven't been able to test it yet) but I think we solved that with a periodic re-authentication of the client. This might vary depending on the switch you are using.

[b.julin]

I'm missing something -- what's the distinguishable difference between a guest user and machine auths?  Your RADIUS server can't tell the difference and send guests to one vlan and machine auths to a different one?

Also take note from earlier in the thread -- even using vlan assignment as a workaround, there's still the detail that a port carrying an unregistered machine will block a registered machine for as long as the unregistered machine has an aaa session, because as far as the switch is concerned that's just two valid clients trying to get assigned to different VLANs.

Using cached reauthentication can indeed keep the port up so that WoL and ARP work correctly despite the control-direction bug, however, you basically have two choices:

1) Don't set an inactivity timer (or set it higher than the reauth timer) in which case until the phone bounces the link (or sends that special LLDP packet they have to tell the switch to reauth the other clients) that client will remain authed forever, or until the switch reboots, regardless of whether they have unplugged and moved to Detroit.  Nobody else plugging in there will be able to get on to any vlan other than the one they authed into.

2) Do set an inactivity timer (lower than the reauth timer) in which case WoL devices and just plain quiet hosts will be completely unreachable by ARP/flood/WoL between the time that they go inactive and the next time they send a packet.  Also, if the switch reboots, they can't be woken until they send a packet.  If the WoL card has AMT configured, that will be on the order of a ten minutes between gratuitous ARPs.  Without AMT it could be forever.

[srv.seguridad]

The machines are authenticating with an 802.1x propietary supplicant, thus being asigned by RADIUS server to a determined VLAN.

Guest users do not have an 802.1x supplicant, and are being placed on a different VLAN with the "guest-vlan" switch parameter.

Its not the same to have a supplicant and fail authentication, than not being able to authenticate due to the lack of a supplicant. In the first case RADIUS parameters can be used, in the second traffic is either discarded or authorized into the defined guest-vlan.

The first authentication method we are using is MAB, where only phones correctly authentice. Machines fail MAB and go to the next authentication method, 802.1x, where they authenticate via the supplicant. What I meant in the previous post was that if we let any machine pass the MAB authentication with a "success", both guest users and machines will end up on the same VLAN.

Note that by guest users, I mean a user that access the network without any credentials nor an 802.1x supplicant. I guess you are treating guest users as a user who connects to the network with temporaryly provided credentials and an 802.1x supplicant?

[b.julin]

Ah, makes sense now that I know you're "order mab dot1x".

Yes, that's a sticky problem.  We aren't to the point of actually using dot1x quite yet.  Guests who haven't been preregistered by someone just get dropped into registration, where they can self-register.  Once their MAC is registered, they get sent explicitly to the guest vlan by RADIUS.

However, since you are using dot1x as the last method in the chain, have you tried playing with the "dot1x guest-vlan supplicant" global command yet, as per the other thread?

Out of interest, how are you dealing with RDC's problems when vlans change during remote login due to user auths?

[srv.seguridad]

I  haven't tryed the "dot1x guest-vlan supplicant" command, didn't even knew about it! is it available on 12.2(55)? all references I have found relate to 12.2(25).What is the difference with "dot1x guest-vlan"? Anyways, I'll give it a try as soon as I can.

If RDC stands for Remote Desktop Connections (sorry, still getting used to English acronyms hehe) we haven't made any tests with that yet, and to be honest, I hope the time never comes!

[b.julin]

The command is in 12.2(55)SE1 at least.  Don't think it will solve your problem, based on what it is described to do, but maybe it has side effects.  Supposedly it allows clients that fail EOPOL to go to guest, even though EOPOL packets were detected.

Yes, Remote Desktop is what I was referring to.  I could live without having to support that mess, too, but not an option as it is very popular here.

[mgraham50]

Was anyone able to get host-mode multi-auth working properly?

We use 3750E switches and multi-auth fails with "no response" (Unknown MAC) on all 802.1x clients