8021 X

Alcatel-Lucent OmniSwitch Access Guardian
HANDS-ON EXERCISES
OBJECTIVE
This lab is designed to familiarize you with the Access Guardian security feature on an AOS OmniSwitch. This includes device classification policies, captive portal, User Network profiles as well as Host Integrity check options. Both supplicant and non-supplicants user authentication methods will be configured.
All 802.x ports should have a number of different device classification policies that may be configured together with 802.1x authentication. By classification policy we mean a method, which may end up (terminate) in a devices MAC address being learned on a VLAN or the device being blocked from accessing the port.
This lab will cover the necessary steps needed to manually configure different types of user network access using 802.1x and additional Access Guardian enhancements.
The steps to complete this lab are: 1. 2. Lab 1: Configure basic 802.1x authentication Lab 2: Create and use simple Access Guardian policy definition
ACCESS GUARDIAN
Another element of AOS based security offer provided by an OmniSwitch is Access guardian. An OmniSwitch can be configured so that users can have a network access based on different authentication methods.
Issue 01
Ref. DATA9034H01TEUS
All Rights Reserved 2009, Alcatel-Lucent
HO. 1
905
EQUIPMENT/SOFTWARE REQUIRED
One OmniSwitch Any number of PCs DHCP/RADIUS Server
RELATED COMMANDS
vlan [vid] 802.1x enable, vlan port mobile, aaa radius-server show vlan [vid] port, show aaa [options] show mac-address-table, show aaa-device [options, show 802.1x device classification policies, show 802.1x non-supplicants, show 802.1x users,
SUPPORTED PLATFORMS
OmniSwitch 9000, 6850, 6400, 6855
LAB NETWORK DIAGRAM
Access Guardian Supplicant and Non-Supplicant Authentication

Basic 802.1X Authentication
HO. 2
Issue 01
906
Pod 1
OS 6850 or OS 6400 Or 6855
Vlan 11 192.168.11.1 Vlan 21 192.168.21.1
Vlan 100 192.168.100.1
Pod 2 Pod 3
Vlan 12 192.168.12.2 Vlan 22 192.168.22.2
Vlan 100 192.168.100.2
Vlan 13 192.168.13.3 Vlan 23 192.168.23.3

Vlan 14 192.168.14.4 Vlan 24 192.168.24.4
Vlan 15 192.168.15.5 Vlan 25 192.168.25.5
Vlan 16 192.168.16.6 Vlan 26 192.168.26.6
Vlan 100 192.168.100.3
Pod 4
Vlan 100 192.168.100.4
Radius server 192.168.100.102 key: alcatel-lucent
Pod 5
Vlan 100 192.168.100.5
Pod 6
Vlan 100 192.168.100.6
Issue 01
HO. 3
907
Lab 1: Basic 802.1X Authentication

Basic 802.1x port may be used when only successful authenticated 802.1x devices are allowed in the network without any other requirements. An 802.1x client is classified on default vlan, mobile vlan or authenticated vlan (user vlan returned by Radius server). Mobile rule only can be applied after user authenticates as explained below.
Lab 1. 2. 3. 4. 5.
Steps Configure basic 802.1x authentication Configure a radius server and setup 802.1x authentication on necessary ports Configure initial PC 802.1x client to match the radius server policy Create a simple Access Guardian policy Monitor the authentication process activity
Before you can perform this lab, you must have access to the RADIUS server from your switch. In order to allow multiple groups to access the server simultaneously, well bridge any necessary switches together using VLAN 100 and assign an IP address according to your group number (#): Type the following: -> rm /flash/working/boot.cfg -> reload working no rollback-timeout After having rebooting the switch, login and create a Loopbak0 interface with an IP address according to your group (used for radius server authorization) -> ip interface Loopback0 address #.#.#.# Create a VLAN 100, assign an IP address to VLAN 100 in the 192.168.100.0 subnet according to your group. -> vlan 100 -> vlan 100 port default 1/24 -> ip interface backbone address 192.168.100.# vlan 100 Bridge the switches together and ensure connectivity to the RADIUS Server. Type the following from your OmniSwitch: -> ping 192.168.100.102 If you have connectivity, continue with the remaining steps, otherwise consult your instructor for help.
HO. 4
Issue 01
908
The first method of authentication well use is simple 802.1x authentication. Session can be created that allows a user to enter a username and password for be moved in an authenticated VLAN. First create two Authenticated VLAN with an IP address, be sure to use your group number in place of #. Type the following: -> vlan 1# -> ip interface int_v1# address 192.168.1#.# vlan 1# -> vlan 2# -> ip interface int_v2# address 192.168.2#.# vlan 2# Enable RIP protocol on every switch to advertise all local vlan over backbone vlan. -> ip load rip -> ip rip status enable -> ip rip interface backbone status enable -> ip route-map localtorip sequence-number10 action permit -> ip redist local into rip route-map localtorip status enable Now that we have created the Authenticated VLANs, we must enable 802.1x Authentication on the port your PC is connecting to. Type the following; replacing slot/port with the port your PC will connect to: (1/1 to 1/12) -> vlan port mobile 1/1-12 -> vlan port 1/1-12 802.1x enable Now that we have created an Authenticated VLAN and configured the port for Authentication, we must tell the switch where to forward the Authentication requests, this will be the address of the RADIUS server (192.168.100.102) -> aaa radius-server rad1 host 192.168.100.102 key alcatel-lucent The command above, adds the RADIUS server, called rad1 with an IP address of 192.168.100.102, to the switch. The switch will now know where to send authentication requests. When forwarding requests, the switch will use the shared secret of alcatel-lucent to communicate with the RADIUS server.
The commands above enabled 802.1x authentication on the slot and port. Now we must tell the OmniSwitch to forward 802.1x requests to the RADIUS Server. Type the following: -> aaa authentication 802.1x rad1 You will also enable MAC authentication as follow:
Issue 01
HO. 5
909
-> aaa authentication mac rad1 Optionnaly, you will associate the server (or servers) to be used for accounting (logging) 802.1X sessions. -> aaa accounting 802.1x rad1
The RADIUS server has been configured to return VLAN 1# to the switch # if you authenticate successfully. The switch will then move you into VLAN 1#, the authenticated VLAN. Windows XP 802.1x Setup Perform the following to setup 802.1x authentication on a Windows XP machine. There are other industry standard 802.1x clients available, the steps below work for the built-in XP client. Double-click the Local Area network icon in the system tray. Click Properties. Then Choose the Authentication Tab Click Enable IEEE 802.1x For EAP Type choose PEAP Click Properties then Uncheck Validate Server Certificate Close all dialogue boxes to save changes and enable 802.1x. You should see a balloon popup in the system tray. Click on the balloon and login with the username and password above. No domain information is needed. Use the following username and password for testing purposes: Username user1# / Password user1# -> vlan 1# Username user2# / Password user2# -> vlan 2#
The PC can be set to DHCP, if a valid address has not been applied after authentication, check that your configuration is relevant to your group number . You should see that you have been authenticated using the 802.1x method and your pc has obtained an IP address matching the vlan subnet ip address.
Note:
Windows stores previous authentication information in the registry and uses it for automatically authenticating users. If you are not being prompted for a username/password, follow the instruction below showing how to delete this information from the registry. You should not need to enter your credentials on subsequent connections. When you connect to the network for the first time with Windows XP, you will be prompted for your user credentials. XP will save the credentials you supply and use them for all future connections to the network. You can clear out the credential cache by editing
HO. 6
Issue 01
910
the registry. Fire up the registry editor (START->RUN->REGEDIT) and delete the HKEY_CURRENT_USER\Software\Microsoft\EAPOL\UserEAPinfo registry key.
Issue 01
HO. 7
911
LAB 1 CHECK Lets check connectivity not that you have been authenticated. You should see that your port and MAC address have been moved to VLAN 1#. Type/Perform the following: -> show mac-address-table -> show vlan 1# port -> show 802.1x slot/port -> show 802.1x statistic -> show 802.1x users ping the IP interfaces on the OmniSwitch.
Note: For more information about the displays that result from these commands and others, see
the OmniSwitch CLI Reference Guide and Network Configration Guide
HO. 8
Issue 01
912
Lab 2: Access Guardian Authentication

The Access Guardian provides functionality that allows the configuration of 802.1x device classification policies for supplicants (802.1x clients) and non-supplicants (non-802.1x clients). The policies are configured in chains specifying both the policies and the order in which they will be applied. The first policy in the chain is applied first and if it does not terminate the second policy is applied and so on. A chain may be seen as compound policy consisting of atomic policies. There are two such compound policies that are configured on an 802.1xauthenticated port: supplicant policy and non-supplicant policy. The former policy applies to devices that are 802.1x clients--or supplicants--while the latter applies to all other devices--or non-supplicants.
Access Guardian authentication is configurable via WebView through: Security -> Access Gardian
Several types of policies that when combined together create either a supplicant or nonsupplicant compound policy. Consider the following when configuring compound policies: A single policy can only appear once for a pass condition and once for a failed condition in a compound policy. Up to three VLAN ID policies are allowed within the same compound policy, as long as the ID number is different for each instance specified (e.g., vlan 20 vlan 30 vlan 40). Compound policies must terminate. The last policy must result in either blocking the device or assigning the device to the default VLAN. If a terminal policy is not specified, the block policy is used by default. The order in which policies are configured determines the order in which the policies are applied.
Lab Steps 1. Configure a supplicant authentication policy 2. Configure a non-supplicant authentication policy
Issue 01
HO. 9
913
1. SUPPLICANT POLICY CONFIGURATION

You will now create a policy 1 that will classify a user on port 1/1based on following assumption for port 1/1: If a supplicant is active -> then Authenticate using RADIUS -> If credentials receive a PASS -> Radius returns vlan_id -> user is moved in this vlan -> Radius doesnt return vlan_id -> Group Mobility rules are applied -> if group-mobility fails -> Assign user to the vlan 1000 -> if vlan 1000 doesnt exist then move user to default vlan. -> If credentials receive a FAIL -> User is moved in vlan2x -> if vlan 2x doesnt exist then the user traffic is blocked. For example, type: -> vlan 1000 -> 802.1x 1/1 supplicant policy authentication pass group-mobility vlan 1000 default-vlan fail vlan 2x block -> 802.1x 1/2 supplicant policy authentication pass group-mobility vlan 1000 default-vlan fail vlan 2x block Check your configuration by using the following command: -> show 802.1x device classification policies 1/1
HO. 10
Issue 01
914
LAB CHECK Perform different type of authentication test by using credentials as follow: Login/password: test/test, user1#/user1#, user2#/user2# For non-supplicant test, just disable 802.1x on your client in your Local area connection properties window and make a new port connection. And lets check connectivity every time that you have been authenticated. You should see that your port and MAC address have been moved to different VLAN id. Type/Perform the following: -> show mac-address-table -> show vlan id port -> show 802.1x users -> show aaa-device all-users Note: You can also navigate to the Access Guardian / Device / Users / All Users dialog for a summary of all current connections.
Issue 01
HO. 11
915
2. SUPPLICANT POLICY CONFIGURATION

To create a policy 2 that will classify non-supplicant users on ports 1/1 and 1/2, use the nonsupplicant keyword in order to define a rule based on following assumption: for ports 1/1 and 1/2: If a non-supplicant is active -> then Authenticate using RADIUS -> If credentials receive a PASS -> Radius returns vlan_id -> user is moved in this vlan -> Group Mobility rules are applied -> if group-mobility fails -> Assign to the default vlan -> If credentials receive a FAIL -> Group-mobility is applied -> User is moved in vlan2x -> if vlan 2x doesnt exist then the user is placed in default vlan. For example, type: -> 802.1x 1/1 non-supplicant policy authentication pass group-mobility default-vlan fail vlan 2# default-vlan -> 802.1x 1/2 non-supplicant policy authentication pass group-mobility default-vlan fail vlan 2# default-vlan
Check your configuration by using the following command: -> show 802.1x device classification policies 1/1 LAB CHECK Lets check connectivity not that you have been authenticated. You should see that your port and MAC address have been moved to VLAN id. Verify by following display commands all or specific users with detailed information. Type/Perform the following: -> -> -> -> show show show show mac-address-table vlan xx port 802.1x non-supplicant 1/1 aaa-device all-users
Note: For more information about the displays that result from these commands and others, see the OmniSwitch CLI Reference Guide and Network Configration Guide
HO. 12
Issue 01
916
Summary
Access Guardian is a combination of authentication, device compliance, and access control functions that provide a proactive solution to network security. Implemented through the switch hardware and software, Access Guardian helps administrators:
Determine who is on the network. Check if end users are compliant. Direct what end users can access within the network.
This lab briefly introduced you to our AOS Network Access Control security features based on Access Guardian. In addition to the proactive functionality of Access Guardian, the Traffic Anomaly Detection (TAD) and Quarantine Manager and Remediation (QMR) features provide reactive network security solutions. These additional features are covered through another lesson.
Issue 01
HO. 13
917
HO. 14
Issue 01
918
Alcatel-Lucent OmniSwitch Access Guardian Captive Portal
HANDS-ON EXERCISES
OBJECTIVE
This lab is designed to familiarize you with our Access Guardian security feature on an AOS OmniSwitch. This includes device classification policies, captive portal, User Network profiles as well as Host Integrity check options. Both supplicant and non-supplicants user authentication methods will be configured.
The steps to complete this lab are: 1. 2. Lab 1: Setup basic 802.1X Authentication Lab 2: Setup Captive Portal
In case of you have previously performed the lab 802.1X Authentication and Access Guardian Policies, please skip the lab1 part and start from the previous lab configuration.
Issue 01
HO. 1
919
ACCESS GUARDIAN
RELATED COMMANDS
SUPPORTED PLATFORMS
OmniSwitch 9000, 6850, 6400, 6855
HO. 2
Issue 01
920
LAB NETWORK DIAGRAM

Captive portal Authentication
Issue 01
HO. 3
921
Pod 1
OS 6850 or OS 6400 Or 6855
Vlan 11 192.168.11.1 Vlan 21 192.168.21.1
Vlan 100 192.168.100.1
Pod 2 Pod 3
Vlan 12 192.168.12.2 Vlan 22 192.168.22.2
Vlan 100 192.168.100.2
Vlan 13 192.168.13.3 Vlan 23 192.168.23.3

Vlan 14 192.168.14.4 Vlan 24 192.168.24.4
Vlan 15 192.168.15.5 Vlan 25 192.168.25.5
Vlan 16 192.168.16.6 Vlan 26 192.168.26.6
Vlan 100 192.168.100.3
Pod 4
Vlan 100 192.168.100.4
Pod 5
Vlan 100 192.168.100.5
Pod 6
Vlan 100 192.168.100.6
HO. 4
Issue 01
922
Lab 1: Setup 802.1X Authentication

Lab 1. 2. 3. 4. 5.
Issue 01
HO. 5
923
The commands above enabled 802.1x authentication on the slot and port. Now we must tell the OmniSwitch to forward 802.1x requests to the RADIUS Server. Type the following: -> aaa authentication 802.1x rad1
HO. 6
Issue 01
924
You will also enable MAC authentication as follow: -> aaa authentication mac rad1 Optionnaly, you will associate the server (or servers) to be used for accounting (logging) 802.1X sessions. -> aaa accounting 802.1x rad1
The PC can be set to DHCP, if a valid address has not been applied after authentication, check that your configuration is relevant to your group number . You should see that you have been authenticated using the 802.1x method and your pc has obtained an IP address matching the vlan subnet ip address.
Note:
Windows stores previous authentication information in the registry and uses it for automatically authenticating users. If you are not being prompted for a username/password, follow the instruction below showing how to delete this information from the registry. You should not need to enter your credentials on subsequent connections. When you connect to the network for the first time with Windows XP, you will be prompted
Issue 01
HO. 7
925
for your user credentials. XP will save the credentials you supply and use them for all future connections to the network. You can clear out the credential cache by editing the registry. Fire up the registry editor (START->RUN->REGEDIT) and delete the HKEY_CURRENT_USER\Software\Microsoft\EAPOL\UserEAPinfo registry key.
the OmniSwitch CLI Reference Guide and Network Configration Guide
HO. 8
Issue 01
926
Lab 2: Captive portal Authentication

Captive Portal is a new addition to the Device Classification Policy on an Access Guardian port. End stations are classified based on the Classification Policy defined on the physical port that it is connected to, either directly or via a hub. This Captive Portal provides for Access Guardian a more comprehensive set of classification policies. For example on an 802.1x supplicant fail case, user can in addition to specify a user configured VLAN or to block access to the network. User can now have the option to present an authentication page to request for user credentials. This will be useful for guest or contractor to temporarily gaining controlled network access to the enterprise network.
By using Captive Portal, Access Guardian will determine that a client device is a candidate for Web-based authentication if the following conditions are true: The device is connected to an 802.1x-enabled port. An Access Guardian policy (supplicant or non-supplicant) that includes the Captive Portal option is configured for the port.
Lab Steps 1. Configure an 802.1x device classification policy for Captive Portal authentication 2. Customize Captive Portal components for authentication 3. Test the captive portal
In the following exercise, well manage a way to identify users through a web portal as usually for a guest. First, lets create a new authentication for non-supplicant user PCs.
Type the following: -> 802.1x 1/3 non-supplicant policy authentication pass group-mobility block fail captiveportal -> 802.1x 1/3 captive-portal policy authentication pass vlan 1# -> 802.1x 1/4 non-supplicant policy authentication pass group-mobility block fail captiveportal -> 802.1x 1/4 captive-portal policy authentication pass vlan 1#
Issue 01
HO. 9
927
This way, a supplicant will follow same behavior as in earlier managed policies and a nonsupplicant policy configured with Captive Portal as a pass or fail condition is required to invoke Captive Portal authentication. Use one standard browser available on the client device and access the following URL: http://#.#.#.# (your switch Loopback0 interface address) and follow displayed instructions: Enter credentials as requested on web page and select submit. (login: test1 / password alcatel-lucent) Lets now customize the Captive Portal web page. Customize the captive portal by adding a background image as well as a welcome text and a new logo. Browse to the classroom UBS drive for the logo.jpg, background.jpg and cpLoginWelcome.inc files and copied all of it in /flash/switch directory on your switch. Then renew your connection on port 1/3 or 1/4 and check your new custom captive portal web page. LAB 3 CHECK Lets check connectivity not that you have been authenticated. Display users that were classified using Captive Portal browser-based authentication. Type/Perform the following: -> -> -> -> -> show show show show show mac-address-table vlan port 1/3 802.1x non-supplicant 1/3 aaa-device captive-portal-users aaa-device all-users
Displays the global Captive Portal configuration for the switch Type: -> show 802.1x captive-portal configuration Finally, check the connectivity between the PC and the rest of the network.
HO. 10
Issue 01
928
Summary
This lab briefly introduced you to our AOS Network Acccess Control security features based on Access Guardian. In addition to the proactive functionality of Access Guardian, the Traffic Anomaly Detection (TAD) and Quarantine Manager and Remediation (QMR) features provide reactive network security solutions. These additional features are covered through another lesson.
Issue 01
HO. 11
929
HO. 12
Issue 01
930
Alcatel-Lucent OmniSwitch Access Guardian User Network Profile
HANDS-ON EXERCISES
OBJECTIVE
This lab is designed to familiarize you with our Access Guardian security feature on an AOS OmniSwitch. This includes device classification policies and User Network profiles options. Both supplicant and non-supplicants user authentication methods will be configured.
The steps to complete this lab are: 1. 2. Lab 1: Configure basic 802.1x authentication Lab 2: Associate an User Network Profile to a user
In case of you have previously performed the lab 802.1X Authentication and Access Guardian Policies, please skip the lab1 part and start from the previous lab configuration.
ACCESS GUARDIAN
Issue 01
HO. 1
931
RELATED COMMANDS
SUPPORTED PLATFORMS
OmniSwitch 9000, 6850, 6400, 6855
LAB NETWORK DIAGRAM

Advanced User Network Profile
Simple User Network Profile
HO. 2
Issue 01
932
Pod 1
OS 6850 or OS 6400 Or 6855
Vlan 11 192.168.11.1 Vlan 21 192.168.21.1
Vlan 100 192.168.100.1
Pod 2 Pod 3
Vlan 12 192.168.12.2 Vlan 22 192.168.22.2
Vlan 100 192.168.100.2
Vlan 13 192.168.13.3 Vlan 23 192.168.23.3

Vlan 14 192.168.14.4 Vlan 24 192.168.24.4
Vlan 15 192.168.15.5 Vlan 25 192.168.25.5
Vlan 16 192.168.16.6 Vlan 26 192.168.26.6
Vlan 100 192.168.100.3
Pod 4
Vlan 100 192.168.100.4
Pod 5
Vlan 100 192.168.100.5
Pod 6
Vlan 100 192.168.100.6
Issue 01
HO. 3
933
Lab 1: Basic 802.1X Authentication

Lab 1. 2. 3. 4. 5.
HO. 4
Issue 01
934
The commands above enabled 802.1x authentication on the slot and port. Now we must tell the OmniSwitch to forward 802.1x requests to the RADIUS Server. Type the following: -> aaa authentication 802.1x rad1
Issue 01
HO. 5
935
You will also enable MAC authentication as follow: -> aaa authentication mac rad1 Optionally, you will associate the server (or servers) to be used for accounting (logging) 802.1X sessions. -> aaa accounting 802.1x rad1
The PC can be set to DHCP, if a valid address has not been applied after authentication, check that your configuration is relevant to your group number. You should see that you have been authenticated using the 802.1x method and your pc has obtained an IP address matching the vlan subnet ip address.
Note:
Windows stores previous authentication information in the registry and uses it for automatically authenticating users. If you are not being prompted for a username/password, follow the instruction below showing how to delete this information from the registry. You should not need to enter your credentials on subsequent connections. When you connect to the network for the first time with Windows XP, you will be prompted
HO. 6
Issue 01
936
for your user credentials. XP will save the credentials you supply and use them for all future connections to the network. You can clear out the credential cache by editing the registry. Fire up the registry editor (START->RUN->REGEDIT) and delete the HKEY_CURRENT_USER\Software\Microsoft\EAPOL\UserEAPinfo registry key.
the OmniSwitch CLI Reference Guide and Network Configuration Guide
Issue 01
HO. 7
937
Lab 2: User Network Profile

Lab Steps 1. Configure User Network Profile Mapping Table 2. Configure basic device classification policy 3. Setup complex UNP definition by specifying advanced network access profile 4. Use Mobile Classification rule to associate a user with a specific UNP
a) Configure a User Network Profile unp_sample1 as follow: -> aaa user-network-profile name unp_sample1 vlan 2# -> aaa user-network-profile name unp_sample2 vlan 1000 Verify your UNP parameters: -> show aaa user-network-profile
Lets configure a basic device classification policy using the configured UNP on ports 1/5 and 1/6: -> 802.1x 1/5 supplicant policy authentication pass group-mobility user-network-profile unp_sample1 block -> 802.1x 1/5 supplicant policy authentication fail captive-portal -> 802.1x 1/5 non-supplicant policy authentication fail user-network-profile unp_sample2 block -> 802.1x 1/6 supplicant policy authentication pass group-mobility user-network-profile unp_sample1 block -> 802.1x 1/6 supplicant policy authentication fail captive-portal -> 802.1x 1/6 non-supplicant policy authentication fail user-network-profile unp_sample2 block
Check your configuration: -> show 802.1x device classification policies 1/5
HO. 8
Issue 01
938
LAB CHECK Connect one supplicant on 802.1x port, and make sure the client is classified based on the User Profile Mapping Table. Do the same for a non-supplicant user. Verify that client (supplicant) able to authenticate and classified based on the User Profile Mapping Table. Display by following commands all or specific users with detailed information. Type/Perform the following: -> show mac-address-table -> show vlan port 1/5 -> show 802.1x non-supplicant 1/5 -> show aaa-device all-users
b) Setup complex UNP definition by specifying advanced network access profile You can specify the name of an existing list of QoS policy rules within a UNP definition. The rules within the list are applied to all members of the profile group. Only one policy list is allowed per profile, but multiple profiles may use the same policy list. Lets now configure a policy list that contains 2 rules, one filtering the traffic to a server address and a second one giving highest priority to the user traffic. Configure a qos rule for destination ip condition with action drop: -> policy condition server1 destination ip 192.168.100.100 -> policy action drop disposition drop -> policy rule no_server1 condition server1 action drop log Configure a qos rule for any traffic with action giving priority 7 -> policy condition high_prio source ip any destination ip any -> policy action prio7 priority 7 -> policy rule traffic_prio condition high_prio action prio7 -> qos apply Configure a policy list based on previous step: -> policy list list1 type UNP traffic_prio no_server1 -> qos apply Configure the User Profile Mapping Table: -> aaa user-network-profile name unp_sample3 vlan 1# policy-list-name list1
Issue 01
HO. 9
939
Lets configure this device classification policy using the configured UNP UNP_sample3 for failed authentication on ports 7 and 8, when classification for success result, will assign user to UNP unp_sample1: -> 802.1x 1/7 supplicant policy authentication pass user-network-profile unp_sample1 block -> 802.1x 1/7 supplicant policy authentication fail user-network-profile unp_sample3 block -> 802.1x 1/7 non-supplicant policy authentication pass user-network-profile unp_sample1 block -> 802.1x 1/7 non-supplicant policy authentication fail user-network-profile unp_sample3 block -> 802.1x 1/8 supplicant policy authentication pass user-network-profile unp_sample1 block -> 802.1x 1/8 supplicant policy authentication fail user-network-profile unp_sample3 block -> 802.1x 1/8 non-supplicant policy authentication pass user-network-profile unp_sample1 block -> 802.1x 1/8 non-supplicant policy authentication fail user-network-profile unp_sample3 block
Check your configuration: -> show 802.1x device classification policies 1/7 -> show policy rules -> show policy list
HO. 10
Issue 01
940
LAB CHECK Connect one supplicant on 802.1x port, and make sure the client is classified based on the User Profile Mapping Table. Do the same for a non-supplicant user. Verify that client (supplicant) able to authenticate and classified based on the User Profile Mapping Table. Check UNP profiles and associated rules are matching specific user traffic with detailed information. Type/Perform the following: -> show active policy rules -> show active policy list -> show vlan port 1/7 Try to ping the server 192.168.100.100? Whats happened? Why? How to verify the reason of that? Now put your PC on port 1/11 that you will assign statically to vlan 1#. Again ping the server 192.168.100.10? Whats happened? Why? Now, change the rules traffic_prio and no_server1 configuration as follow: -> policy rule no_server1 no default-list -> policy rule traffic_prio no default-list -> qos apply Repeat the ping test from ports 1/11 and 1/7 or 1/8 and explain the new traffic behavior?
Issue 01
HO. 11
941
c) Use UNP mobile rules to associate a user with a more specific UNP Lets use now the capability of AOS switch to classify devices with UNP mobile rules. It allows the administrator to assign users to a profile group based on the source IP or source MAC address of the device. Next step will make you to create an UNP mobile rule configured with 172.30.#.0 as the source IP value and Employee as the user profile. Any devices connecting to port 1/5 with a source IP address that falls within the 172.30.#.0 network will be assigned to the Employee profile.
For this example, lets follow these commands: -> -> -> -> vlan 30 ip interface employee address 172.30.#.0 vlan 30 aaa classification-rule ip-address 172.30. #.0 user-network-profile name employee aaa user-network-profile name employee vlan 26
Check your parameters by using the following command: -> show aaa classification-rule ip-net-rule LAB CHECK Connect one device on port 1/12, after having configured an ip address falling in subnet 172.30.#.0 and make sure the client is classified based on the User Profile Mapping Table. Verify that client (supplicant) able to authenticate and classified based on the User Profile Mapping Table. Check UNP profiles and associated rules are matching specific user traffic with detailed information. Type/Perform the following: -> show aaa-device all-users -> show vlan port 1/12
HO. 12
Issue 01
942
Summary
This lab briefly introduced you to our AOS Network Access Control security features based on Access Guardian. In addition to the proactive functionality of Access Guardian, the Traffic Anomaly Detection (TAD) and Quarantine Manager and Remediation (QMR) features provide reactive network security solutions. These additional features are covered through another lesson.
Issue 01
HO. 13
943
HO. 14
Issue 01
944

8021 X

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

8021 X

Uploaded by

Copyright:

Available Formats

Alcatel-Lucent OmniSwitch Access Guardian

Alcatel-Lucent OmniSwitch Access Guardian

LAB NETWORK DIAGRAM

Access Guardian Supplicant and Non-Supplicant Authentication

Alcatel-Lucent OmniSwitch Access Guardian

Vlan 11 192.168.11.1 Vlan 21 192.168.21.1

Vlan 100 192.168.100.1

Vlan 12 192.168.12.2 Vlan 22 192.168.22.2

Vlan 100 192.168.100.2

Vlan 13 192.168.13.3 Vlan 23 192.168.23.3

Vlan 100 192.168.100.3

Vlan 100 192.168.100.4

Radius server 192.168.100.102 key: alcatel-lucent

Vlan 100 192.168.100.5

Vlan 100 192.168.100.6

Alcatel-Lucent OmniSwitch Access Guardian

Lab 1: Basic 802.1X Authentication

Alcatel-Lucent OmniSwitch Access Guardian

Alcatel-Lucent OmniSwitch Access Guardian

Alcatel-Lucent OmniSwitch Access Guardian

Alcatel-Lucent OmniSwitch Access Guardian

the OmniSwitch CLI Reference Guide and Network Configration Guide

Alcatel-Lucent OmniSwitch Access Guardian

Lab 2: Access Guardian Authentication

Alcatel-Lucent OmniSwitch Access Guardian

1. SUPPLICANT POLICY CONFIGURATION

Alcatel-Lucent OmniSwitch Access Guardian

Alcatel-Lucent OmniSwitch Access Guardian

2. SUPPLICANT POLICY CONFIGURATION

Alcatel-Lucent OmniSwitch Access Guardian

Alcatel-Lucent OmniSwitch Access Guardian

Alcatel-Lucent OmniSwitch Access Guardian Captive Portal

Alcatel-Lucent OmniSwitch Access Guardian

Alcatel-Lucent OmniSwitch Access Guardian Captive Portal

LAB NETWORK DIAGRAM

Access Guardian Supplicant and Non-Supplicant Authentication

Captive portal Authentication

Alcatel-Lucent OmniSwitch Access Guardian

Vlan 11 192.168.11.1 Vlan 21 192.168.21.1

Vlan 100 192.168.100.1

Vlan 12 192.168.12.2 Vlan 22 192.168.22.2

Vlan 100 192.168.100.2

Vlan 13 192.168.13.3 Vlan 23 192.168.23.3

Vlan 100 192.168.100.3

Vlan 100 192.168.100.4

Radius server 192.168.100.102 key: alcatel-lucent

Vlan 100 192.168.100.5

Vlan 100 192.168.100.6

Alcatel-Lucent OmniSwitch Access Guardian Captive Portal

Lab 1: Setup 802.1X Authentication

Alcatel-Lucent OmniSwitch Access Guardian

Alcatel-Lucent OmniSwitch Access Guardian Captive Portal

Alcatel-Lucent OmniSwitch Access Guardian

the OmniSwitch CLI Reference Guide and Network Configration Guide

Alcatel-Lucent OmniSwitch Access Guardian Captive Portal

Lab 2: Captive portal Authentication

Alcatel-Lucent OmniSwitch Access Guardian

Alcatel-Lucent OmniSwitch Access Guardian Captive Portal

Alcatel-Lucent OmniSwitch Access Guardian

Alcatel-Lucent OmniSwitch Access Guardian User Network Profile

Alcatel-Lucent OmniSwitch Access Guardian

LAB NETWORK DIAGRAM