Re: Guest Vlan Vs AUth-fail Vlan

Shouldnt be a problem, sir!

In the new code on Cisco switches ( >= 50SE | 33SXI), you can do
"authentication event fail action next_method" which tells the switch to try
the next available authentication method configured on the port. With dot1x,
MAB and WebAuth, thats the default order of operation, although its possible
to re-arrange the order. So with contractors that have supplicants
configured for a their mother company, they fail, yes. But then they can try
MAB and subsequently WebAuth, if configured on the switchport. Now, there
are 2 options here, depending on which aligns most with your setup:

1. If using ACS5.1, you can configure a policy to return an RADIUS Access
Accept for all unknown MAC addresses. Therefore, all unknown devices will
still succeed with MAB on the switch. Now, the trick is to have a default
port ACL that restricts access on the switchpport, to say, Internet only.
For known MAC address (company assets, which are contained in the MAC
database, against which ACS performs lookups), ACS will return a
downloadable ACL to open up the initial port restriction and allow full
network access. Follow me?

2. Unknown device fails dot1x, fails MAB and falls back to local WebAuth.
With this, you can give contractors Internet access by supplying them with a
say, general "Contractor, cisco" credential that will always succeed
authentication. They achieve this using http in their webbrowsers.

Sadiq

On Mon, Nov 1, 2010 at 10:48 PM, emir d souza <emir979_at_gmail.com> wrote:

> Problem is in a scenario where we have guests/contractors and internal
> users sharing desks:
>
> What if the guest has an 802.1x supplicant which will obviously fail
> authentication. He will get dumped into the Auth-fail vlan along internal
> users and have access to remediation resources? Anyway to prevent this?
>
>
>
>
>
> On Tue, Nov 2, 2010 at 8:56 AM, Sadiq Yakasai <sadiqtanko_at_gmail.com>wrote:
>
>> Sorry, back again. :-)
>>
>> Need to add more information to that very last paragraph there.
>>
>> All that scenario is actually with MDA configured on the switchport. And
>> in
>> that last paragraph, when the client is authorized and the IP phone fails
>> (dot1x or MAB), this causes a security violation on the switchport. Hence
>> some more complications for you.
>>
>> Sadiq
>>
>> On Mon, Nov 1, 2010 at 7:13 PM, Sadiq Yakasai <sadiqtanko_at_gmail.com>
>> wrote:
>>
>> > For the most part, true, all.
>> >
>> > You see, technically, MAB failures are just absence of the MAC address
>> in
>> > the ACS DB (or any other LDAP store, if configured on ACS). So the fact
>> that
>> > a RADIUS Reject comes back from the RADIUS server just means that MAC
>> > address is unknown, hence a Guest VLAN. This applies to data or voice
>> > devices that do not have supplicants on them.
>> >
>> > In the case of a dot1x enabled device and invalid credentials (with
>> > supplicants, and hence dot1x case), a RADIUS Reject directly translates
>> into
>> > an AuthFail VLAN.
>> >
>> > Mark you though, today on Cisco switches, there is no support for Guest
>> > VLAN on IP phones. The Guest and AuthFail VLANS all apply only to Data
>> > devices and not IP phones. For example, when you have an IP phone and a
>> PC
>> > (plugged in behind the IP phone) both connected to the switch. The
>> client
>> > has a supplicant and the IP phone is doing MAB (which is my
>> understanding of
>> > your use case), then we have these possibilities:
>> >
>> > 1. IP phone passes and gets on the Voice VLAN (or domain). Client passes
>> > and on the Data VLAN (or domain).
>> >
>> > 2. IP phone passes and client fails. IP phone gets treated like in #1
>> and
>> > client gets placed into the AuthFail VLAN, if configured (similarly the
>> > Guest VLAN for a MAB device). Otherwise re-attempt to authenticate the
>> > client after 60 seconds by default - although we can tune a few things
>> to
>> > change behaviour here though.
>> >
>> > 3. IP phone and client behind it are connected together, the client
>> passes
>> > and IP phone fails. It gets abit nasty here you see. There is a race
>> > condition because the client will make it to the network before the IP
>> phone
>> > (Cisco IP phone anyway, because of CDP and power uo delays, etc). The
>> client
>> > passes and gets placed into the data VLAN. When IP phone fails (MAB in
>> this
>> > case), it would be seeking to be placed into the Guest VLAN. This then
>> means
>> > you will have the Voice VLAN, the data VLAN (where the dot1x client is
>> > already authorized) and the Guest VLAN all potentially needing to
>> forward
>> > traffic from the same physical port. Now, we cant do more than 2 VLANs
>> on a
>> > regular access ports today on Cisco switches, which is the issue.
>> >
>> > Hence there is no support for the Guest and AuthFail VLANs for IP phones
>> > today. Hope that helps abit and not confuse you more. Let us know if you
>> > need more info.
>> >
>> > Sadiq
>> >
>> >
>> > On Mon, Nov 1, 2010 at 2:38 PM, Brian Landers <brian_at_bluecoat93.org
>> >wrote:
>> >
>> >> On Mon, Nov 1, 2010 at 10:22 AM, GAURAV MADAN <
>> gauravmadan1177_at_gmail.com
>> >> >wrote:
>> >>
>> >> >
>> >> > If my clients are non dot1x capable .. ( say VOIP ph etc ) . Hence I
>> >> > intend to use MAB as authentication method ..
>> >> >
>> >> > What will be used ? Auth-fail vlan ?
>> >> >
>> >> >
>> >> If you have MAB configured on an interface and the authentication
>> fails,
>> >> the
>> >> port will be placed into the guest VLAN if it is configured. If no
>> guest
>> >> VLAN is configured, the port will be shutdown.
>> >>
>> >> The restricted/auth-fail VLAN is only used for clients that support
>> 802.1x
>> >> and fail an EAPoL login attempt.
>> >>
>> >>
>> >> --
>> >> Brian C Landers
>> >> http://www.packetslave.com/
>> >> CCIE #23115 (R&S + Security)
>> >>
>> >>
>> >> Blogs and organic groups at http://www.ccie.net
>> >>
>> >> _______________________________________________________________________
>> >> Subscription information may be found at:
>> >> http://www.groupstudy.com/list/CCIELab.html
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > CCIEx2 (R&S|Sec) #19963
>> >
>>
>>
>>
>> --
>> CCIEx2 (R&S|Sec) #19963
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>

-- 
CCIEx2 (R&S|Sec) #19963
Blogs and organic groups at http://www.ccie.net