Re: Guest Vlan Vs AUth-fail Vlan

Superb!! Thanks!

On Tue, Nov 2, 2010 at 11:31 PM, Sadiq Yakasai <sadiqtanko_at_gmail.com> wrote:

> 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
Received on Wed Nov 03 2010 - 10:51:44 ART