From: Joseph Saad (joseph.samir.saad@gmail.com)
Date: Mon Jan 07 2008 - 14:50:49 ARST
> * Deepinder Babbar wrote:
> > Lets say I have to configure dot1x on 3560 and I want that if clients
> don't
> > support dot1x then place them in vlan 3, but if they support dot1x and
> fail
> > authentication place them in vlan 4.
>
> This can be accomplished with a guest vlan. By default, only non-802.1x
> end stations are placed there. Network access for end stations that fail
> authentication is denied by default. You can override this behavior and
> grant boxes that fail authentication access to the guest vlan with the
> command 'dot1x guest-vlan supplicant'. This will be the *same* vlan as
> for non-802.1x capable devices based on what was configured on a port
> (so 3, not 4).
!!!! guest-vlan will be used if the client doesn't support dot1x (i.e. EAP
packets aren't detected)
fail-auth VLAN will be used when client fails authentication.
> The 2 kind of vlans could use the same vlan number.
>
> > My doubt is do we have to configure " aaa authorization network default
> > group radius" to enable the change of vlan to guest or restricted
> according
> > to the authentication. Also what are the implications of not giving
> > command "aaa authentication login default line" when dot1x is enabled
> (got
> > confused with a post on GS regarding enabling dot1x and locking yourself
> > out).
>
> Authorization is needed if you want to use attributes stored on the
> authentication server, like VLAN assignments or downloadeable
> access-lists. It is not required to determine whether a client provides
> correct authentication information or not, and if all the decisions
> (VLAN membership for example) shall be done based on the returned
> authentication status with what you have configured statically on the
> switch.
>
> For 'locking yourself out': As soon as you enter aaa new-model, the
> authentication behavior of the system changes, even if you do not
> configure any method. Console and VTY lines get default and predefined
> authentication methods assigned (NONE for con and LOCAL for vty), and
> these apply, even not visible in the config.
>
> For console access, nothing changes. You still get privilege 1 access
> without any additional user authentication, and priv. 15 exec access
> with or without enable password authentication, depending whether a
> enable password is configured or not, so no locking out.
>
> For the VTY lines, local authentication applies immediately after
> enabling aaa new-model. So if you don't have a username in your local
> database, you cannot login anymore.
>
> Assuming that the initial config has line passwords for the VTY and that
> the lab calls you for lets say not changing the login behavior of any
> lines, you break this requirement. You need to take care about this at
> least by reverting to the initial behavior with aaa authen login default
> line, and just to be on the safe side, do a line vty 0 15, login authen
> default.
>
> I highly recommend that you define your own methods besides the default
> one to reflect exactly what you intend to have, like
>
> aaa authen login CON none
> aaa authen login VTY line
>
> line con0
> login authen CON
>
> line vty 0 15
> login authen VTY
>
> This reduces the risk when accidentally changing the default method
> later and break requirements or lock yourself out.
>
!!! this obviously require the definition of "username U password p"
statement ... but I could be stating the obvious.
>
>
>
> Christian
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Feb 01 2008 - 10:37:58 ARST