Deploying an Identity Aware Network

Extreme Networks Application Note

Deploying an Identity Aware Network

Abstract: This document describes the building blocks and configuration tools provided

by Extreme Networks ® ExtremeXOS ® based switches and EPICenter ® network management

software to plan and deploy an identity aware network.

© 2010 Extreme Networks, Inc. All rights reserved. Do not distribute without Extreme Networks prior written consent.


Table of Contents

1. Introduction

2. References

3. Identity Aware Network

4. Identity-Management Case Study

4.1. Prime Corporation Enterprise Network

4.2. Identity Monitoring

4.2.1. Configurations for Backend Servers

4.2.2. Edge Switch Configuration

4.2.2.1. VLAN Configuration

4.2.2.2. AAA Module Configuration

4.2.2.3. LLDP Configuration

4.2.2.4. NetLogin Configuration

4.2.2.5. NetTools Configuration

4.2.2.6. Web/thttpd Configuration

4.2.2.7. Identity-Management (idMgr) Configuration

4.2.2.8. XML Client (xmlc) Configuration

4.2.3. EPICenter Configuration

4.2.4. Client Configurations

4.2.5. Tracking Identities of Desktop/Workstation Users

4.2.5.1. Information Available at the Edge Switch

4.2.5.1.1. show identity-management entries

4.2.5.1.2. show identity-management entries detail

4.2.5.1.3. show identity-management entries ipaddress

4.2.5.1.4. show identity-management entries mac

4.2.5.1.5. show identity-management entries domain

4.2.5.1.6. show identity-management entries vlan

4

4

5

7

7

9

9

9

10

10

10

10

11

11

11

12

12

21

21

21

22

23

24

25

26

27

4.2.5.2. Information Available in EPICenter

4.2.5.2.1. Dash Boards in the Default Home Page

4.2.5.2.2. Customizing the Home Page to Include Other Dash Boards

4.2.5.2.3. Logon Failures Displayed in the Dashboard

4.2.5.2.4. Detailed Information About Identities Discovered Across the Network

4.2.6. Tracking Identities of VoIP Phones



27

27

29

32

33

37

37

37


Table of Contents

5. Business Process Integration

5.1. Generating Reports Using EPICenter (for Compliance and Audits)

5.1.1. Successful Logons by User Name

5.1.2. Failed Logon Attempts by User Name

38

38

38

39

5.1.3. Successful Logon Attempts Reported by Edge Switches Across the Network

5.1.4. Failed Logon Attempts Reported by Edge Switches Across the Network

5.1.5. Successful Logon Indexed by MAC Address of Users/Identities

5.1.6. Failed Logon Attempts Indexed by MAC Address of Users/Identities

5.2. Integration with Custom Enterprise Applications

5.2.1. Retrieving Identity Entries from ExtremeXOS Based Switches

5.2.1.1. soapUI Installation and Initial Setup

5.2.1.2. Creating/Opening a SOAP/XML Session with an Edge Switch

5.2.1.3. Retrieving Details of Active Users from Edge Switch

5.2.2. Receiving Unsolicited Identity Events from Edge Switches

5.3. Integration with Universal Port Manager (UPM)

5.3.1. Edge switch Configuration

5.3.2. UPM Script: Block Traffic from Unauthorized Devices

5.3.2.1. Profile Definition

5.3.2.2. Verifying Profile Triggers and Results of the Script

5.3.3. UPM Script: Isolate Unauthorized Devices



6. Deployment Considerations

6.1. Memory Usage in the Switch

40

41

42

43

43

44

44

51

56

61

62

62

62

62

63

65

65

15

67

67


1. Introduction

This document describes the building blocks and configuration

tools provided by Extreme Networks ExtremeXOS

based switches and EPICenter network management

software to plan and deploy an identity aware network.

In the most basic form, an identity can be constructed

using the attributes in the credentials presented by a user

or device during the authentication or connection process.

Traditionally, credentials of users and devices have always

been identified using an account name and optional

password, and a realm. Microsoft Server technologies

introduce the concept of a domain, which is the realm the

user or device belongs to. In a typical Microsoft Server

based network, a domain also contains identities of

devices such as workstations, laptops, printers, and so on.

While these basic attributes of an identity are mostly

sufficient for management of users/devices, they fall short

of addressing some of the key demands on today’s

enterprise network:

• Reducing IT support costs in enterprises:

Shortening the time taken to troubleshoot and locate

the users or devices in the network, determine the

authentication method used and status of authentication,

and determine authorizations (such as VLAN

memberships) can drastically reduce the time taken

for IT support personnel to troubleshoot problems

reported by users.

• Reducing compliance and audit costs:

Detailed reports which include user logon and logoff

times, status of authentication, and authorizations

provided to access network and IT resources can aid

in internal audits and should be able to provide the

necessary data for compliance audits. Information

collected from the network needs to be archived so

that it can be easily retrieved at any point in time.

• Building custom enterprise applications which

effectively use information provided by the network

The Identity Management feature addresses these

requirements by:

1. Extending the definition of an identity to include the

following attributes:

• Windows Active Directory Domain Attributes:

account name, realm/domain

• Authentication method used: IEEE 802.1X, Webbased,

MAC-based

• MAC address of the client

• IP address assigned to the client

• NetBIOS host name of the client

• LLDP capability

• IP-address of the NAS (edge switch) device

• Time at which the user or device was discovered

• Logon and logoff time (if applicable)

2. Providing a network-wide view of identities in

EPICenter.

• Ability to collect and monitor identities across the

enterprise network

• Archival of user and device activities, which can be

retrieved easily at any time

• Detailed reports which can aid in preparing information

required for compliance and internal-audits

3. Industry standard interface and extensions to build

and integrate with custom applications.

• Well-defined XML APIs and Schema to retrieve

information from ExtremeXOS

• Ability to PUSH identity information from

ExtremeXOS to XML based

• Secure communication of identity information using

SSL/TLS

Section 3 Identity Aware Network provides an overview of

the feature and capabilities. A case study is discussed in

Section 4 describing the configuration and setup of all the

components in the network. Section 5 Business Process

Integration describes the procedures to retrieve information

in the form of reports, and how the ExtremeXOS XML

APIs/Schemas can be used to integrate with custom

applications.

2. References

1. Application Note: Using ExtremeXOS NetLogin with

Microsoft IAS http://www.extremenetworks.com/

apps/whitepaper?wpurl=/libraries/whitepapers/

ANExtremeXOSNetLogin_1644_01.pdf.

zip&Ctype=WhitePaper

2. ExtremeXOS Concepts Guide, Software Version 12.4

http://www.extremenetworks.com/services/

software-userguide.aspx

3. ExtremeXOS Command Reference Guide, Software

Version 12.4 http://www.extremenetworks.com/

services/software-userguide.aspx

4. ExtremeXOS InSite, Software Developers Kit http://

www.extremenetworks.com/solutions/Insite.aspx

© 2010 Extreme Networks, Inc. All rights reserved. Identity Aware Network—Page 4


3. Identity Aware Network

The diagram below exemplifies the concept of identity as explained in the previous section.

Figure 1: Attributes of an Identity



The table below lists the various attributes that make up an identity and the methods by which ExtremeXOS switches gather

and make this information available as an identity entry.

Table 1:

• Account Name

• Domain Membership

• VLAN Membership

• Device IP Address

• Discovered Time

• Logon and Logoff Times

• Kerberos Activity

• LLDP Capability

• Client MAC Address

• Client IP Address

• NetBIOS Host Name

User, device accounts and optional domain memberships are maintained in the user database server

(e.g. Microsoft Active Directory, Novell eDirectory, OpenLDAP based directories, etc.). Authentication

servers (typically running protocols such as RADIUS) validate the credentials presented by the clients

against these directories.

A. User/Device account name is determined using any of the authentication method (IEEE 802.1X,

OR WEB-based, OR MAC-based) employed by the client.

B. Domain/Realm membership is determined when IEEE 802.1X based authentication method is

employed.

Authorizations (such as VLAN memberships) can either be configured as part of remote access policies

enforced on the authentication servers (for e.g. Microsoft Internet Authentication Service) or can be

configured in the Network Access Server (NAS) – the edge switch acting as the authenticator.

This information is gathered from ExtremeXOS NetLogin upon successful authentication and authorization

of the client.

This attribute refers to the management IP address of the authenticator or the Network Access Server

(NAS). When reporting users and devices currently authenticated or discovered by an ExtremeXOS

switch, the device IP address is set to the switch management IP address. This is particularly useful

when tracking or locating users connected to a particular switch.

This attribute denotes the time at which a user or device was discovered by the ExtremeXOS switch.

The meaning of this attribute changes when used with an actual human user or a device. When a user

identity is reported, then the value of this attribute is set to the time at which the user was successfully

authenticated.

When a device identity is reported, then the value of this attribute is set to the time at which this

device was first detected. For e.g. discovery of a neighbor reported by LLDP.

NOTE: This attribute is available ONLY in the ExtremeXOS switch.

This attribute refers to the times at which the user/device was successfully authenticated (and

authorized) and has been logged out respectively. This information is available from ExtremeXOS

NetLogin and is applicable when the user or device identities are co-related using NetLogin entries.

ExtremeXOS switches are capable of snooping Kerberos traffic between clients and the Kerberos key

distribution/management servers employed in the network. Snooping Kerberos traffic helps in

determining successful logon by clients against the backend server managing identities in the realm/

domain. The account name and the realm in the protocol body in the packet helps in co-relating

information reported by ExtremeXOS NetLogin with the actual transactions between the client and the

domain servers.

ExtremeXOS switches can inspect the following packets: Authentication Service Request (AS-REQ),

Authentication Service Response (AS-REP), Ticket Grant Request (TGT-REQ), and Kerberos protocol

error packets.

This attribute denotes that a detected identity is LLDP capable and that ExtremeXOS LLDP has

detected the device as a neighbor.

This attribute refers to the MAC address of the client (detected using the source MAC address in

packets originating from the client). This information is available from the ExtremeXOS FDB Manager

process or ExtremeXOS NetLogin process.

This attribute refers to the IP address in use by the client. This is detected using the IP-MAC (ARP)

bindings from the ExtremeXOS FDB Manager process.

This attribute refers to the device name configured in the client, such as a computer using Microsoft

Windows XP Professional. This information is available in Kerberos packets exchanged between the

client and the domain servers.



4. Identity Management

Case Study

In this section we will walk through all of the configuration

steps and procedures required for bringing identity

awareness in edge switches as well as cover how information

about identities can be collected from switches across

the network in the network management system EPICenter.


The diagram below shows the various systems and devices

used by Prime Corporation along with users attached to

the edge switches.

A sample network topology comprised of an edge switch,

clients using different authentication methods, backend

servers and EPICenter (for central network management) is

used to illustrate identity awareness in Prime Corporation.

NOTES

A discussion about enterprise or campus network design is

beyond the scope of this application note. The network design

illustrated below is simplified to illustrate the features and

capabilities of ExtremeXOS Identity Management.

Figure 2: Prime Corporation Network Topology



The table below summarizes the various roles and functions performed by the devices in the network:

Table 2:

Summit ® X250e-24p

Microsoft Windows

2003 Server

Web Application Server

Edge Switch

Authentication Server and

Domain Controller

Sample Application Server

• Performs authentication of attached users and devices

such as phones using NetLogin

• Enabled with the identity management feature to track

user and device identities connected to the switch

• Provides network access to users and phones

• Multiple VLANs in the switch help in isolating users and

devices in different broadcast domains based on the

authorization process

• Contains the Microsoft Active Directory (AD)

• Configured as a domain controller

• Includes the Microsoft Internet Authentication Service

(IAS) to authenticate users and devices

• IAS provides the RADIUS server functions to communicate

with clients such as the Summit X250e-24p edge

switch and end users/systems equipped with 802.1x

based authentication

• Hosts Web-based SALES applications used by partners

to order products from Prime Corporation

CRM Application Server Sample Application Server • Hosts customer relationship management application

A summary of users and devices connecting to the edge of the network in Prime Corporation is given below.

Table 3:

Network User Role Notes

John Smith

Bob Stone

Alice Duff

Mary Hughes

00:00:00:FE:ED:01

00:00:00:FE:ED:02

Employee

Employee

Temp/Contractor

Temp/Contractor

MAC addresses of

Sample devices

• Works in the Sales organization in Prime Corporation

• Uses Microsoft Windows XP based PC and VoIP Phone

• Requires full access to network and resources such as file servers,

printers, application servers, internet, and so on

• Works in the engineering organization in Prime Corporation

• Uses Microsoft Windows XP based PC

• Requires full access to network and resources such as file servers,

printers, application servers, internet, and so on

• Helps Prime Corporation in developing a sales application

• Visits Prime Corporation to troubleshoot problems in the application server

• IT department provides a Microsoft Windows XP based Laptop for

temporary use (connected to the edge switch on port #17)

• Requires connectivity only to the Web application server

• Helps Prime Corporation in developing a CRM application

• Visits Prime Corporation to troubleshoot problems in the application server

• IT department provides a Microsoft Windows XP based Laptop for

temporary use

• Shares the laptop with other contractors such as Alice Duff

• Requires connectivity only to the CRM application server

• Used to illustrate identities discovered with MAC-based authentication only



4.2. Identity Monitoring

4.2.1. Configurations for Backend Servers

The following table lists the requirements and configurations to be completed in the backend servers.

Table 4:

3 IP Address: 192.168.0.10/24

Microsoft Windows

2003 Server

Web Applications Server

CRM Applications Server

Please refer to the steps and configurations described in the document “Application Note:

Using ExtremeXOS NetLogin with Microsoft IAS” to setup the server to perform the following

functions:

3 Remote Access Policy to authenticate John Smith (username: john_smith) and Bob Stone

(username: bob_smith) using EAP-MD5-Challenge. Upon successful authentication,

authorization for VLAN corp membership should be granted using Extreme-NetLogin-VLAN-ID

VSA.

3 Remote Access Policy to authenticate Alice Duff (username alice_duff) and authorization to

VLAN webapps upon successful authentication.

3 Remote Access Policy to authenticate Mary Hughes (username: mary_hughes) and

authorization to VLAN crmapps upon successful authentication.

3 Remote Access Policy to authenticate the following MAC addresses – 00:00:00:FE:ED:01,

00:00:00:FE:ED:02, and 00:04:96:28:01:8D using PAP. Upon successful authentication,

access to VLAN corpvoice should be granted using Extreme-NetLogin-VLAN-ID VSA.

3 IP Address: 192.168.1.10/24

3 Any operating system could be used

3 IP Address: 192.168.2.10/24

3 Any operating system could be used


We will now proceed to configure the Summit X250e-24p switch. It is recommended to keep the following information handy

in order to complete the edge switch configuration.

Edge Switch IP 10.127.2.18

Authentication Server IP 192.168.0.10

VLAN Name Tag IP/Subnet/Notes

corp 2 IP: 192.168.0.1/24

corpvoice 3

webapps 5 IP: 192.168.1.1/24

authvlan 7 VLAN used by NetLogin

crmapps 8 IP: 192.168.2.1/24

In addition to configuring the Identity Management module, the NetLogin module, VLAN and AAA modules will also need to

be configured. Configuration of the VLAN module will provide reachability to backend authentication servers, and will also

create various user VLANs in the switch. Configuration of the AAA module will provide the switch with one or more RADIUS

servers to contact for authentication. The NetLogin module will provide for all the authentication methods and uses the AAA

infrastructure to authenticate and authorize clients.



4.2.2.1. VLAN Configuration

configure vlan default delete ports 1-26

create vlan “authvlan”

configure vlan authvlan tag 7

create vlan “corp”

configure vlan corp tag 2

create vlan “corpvoice”

configure vlan corpvoice tag 3

create vlan “crmapps”

configure vlan crmapps tag 8

create vlan “webapps”

configure vlan webapps tag 5

configure vlan corp add ports 1 untagged

configure vlan crmapps add ports 3 untagged

configure vlan webapps add ports 2 untagged

configure vlan Mgmt ipaddress 10.127.2.18 255.255.255.0

configure vlan corp ipaddress 192.168.0.1 255.255.255.0

configure vlan authvlan ipaddress 192.168.100.1 255.255.255.0

configure vlan webapps ipaddress 192.168.1.1 255.255.255.0

configure vlan crmapps ipaddress 192.168.2.1 255.255.255.0

NOTES

• In this network topology, ports 1 through 12 are used for connectivity to the backend servers

• Ports 13 through 24 are used for client connectivity (and can be subsequently seen that NetLogin is enabled on these ports)

• None of the VLANs actually contain user ports

4.2.2.2. AAA Module Configuration

configure radius netlogin primary server 192.168.0.10 1812 client-ip 192.168.0.1 vr VR-Default

configure radius netlogin primary shared-secret encrypted “gt}xolg”

enable radius netlogin

4.2.2.3. LLDP Configuration

enable lldp ports 21




4.2.2.4. NetLogin Configuration

configure netlogin vlan authvlan

enable netlogin dot1x mac web-based

enable netlogin ports 13-16 dot1x

enable netlogin ports 21-24 mac

enable netlogin ports 17-20 web-based

configure netlogin ports 13 mode port-based-vlans

configure netlogin ports 13 no-restart

























configure netlogin add mac-list ff:ff:ff:ff:ff:ff 48 ports 21-24

NOTES

• NetLogin is configured to use the “authvlan”

• Local database authentication is NOT used in the edge switch

• 802.1x based authentication is configured on ports 13-16

• Web-based authentication is configured on ports 17 - 20 (and subsequently the NetTools module will also be configured to serve as

a DHCP server to assign IP addresses to clients temporarily for authentication purpose)

• MAC-based authentication is configured on ports 21 - 24

• Switch is configured to accept all MAC addresses on ports 21-24 with password set to use the MAC address itself (as a string)

4.2.2.5. NetTools Configuration

configure vlan authvlan dhcp-address-range 192.168.100.10 - 192.168.100.50

configure vlan authvlan dhcp-options default-gateway 192.168.100.1

4.2.2.6. Web/thttpd Configuration

enable web http

enable web https

4.2.2.7. Identity-Management (idMgr) Configuration

enable identity-management

configure identity-management ports 13-24

NOTES

• Identity Management is only configured on ports where clients are connected

• Enabling Identity Management on ports which provide connectivity to the rest of the enterprise could result in identity management

tracking possibly a large number of entries, which would be unnecessary. It is recommended that Identity Management be enabled

on ports used for connecting end systems directly or through port extenders like the ReachNXT 100-8t.



4.2.2.8. XML Client (xmlc) Configuration

create xml-notification target epicenter-target url http://10.127.4.202:8080/xos/webservice

configure xml-notification target epicenter-target user admin encrypted-auth YWRtaW46ZXBpY2VudGVy

enable xml-notification epicenter-target

configure xml-notification target epicenter-target add idMgr

NOTES

This is an optional configuration that can be done on the ExtremeXOS switch to notify clients (such as EPICenter or any other custom

Web-based application) about identity information. Information about identities is sent as events, using XML APIs to the target specified.

When EPICenter is used to monitor identities across the network, this configuration can be done by EPICenter on the ExtremeXOS switch

automatically.

4.2.3. EPICenter Configuration

In this section, we will go through the steps required to setup monitoring of edge switches (devices in EPICenter terminology)

for identities (network users in EPICenter terminology). The following are the prerequisites:

3 EPICenter (Release 7.1 or higher) is installed on a host with connectivity to the management port of the edge switch.

3 The edge switch is either discovered or added manually into EPICenter.

The steps required to enable identity monitoring in EPICenter are presented in the screen shots below. The actions to be

performed are listed after each screen shot.

Steps: Expand “Network Views” → Click “Tools” from main menu → Click “Options.”



Steps: In the “Options” dialog box that appears, click on “Network Users” tab → Click “Edit List of Devices.”

Steps: In the dialog box “Edit List of Devices” that appears, ensure that “Devices” is selected → Click “Next.”



Steps: Select the edge switch (in this case the Summit X250e-24p with management IP address 10.127.2.18) → Click on

“Enable monitoring on selected devices/ports.”

Steps: Select “System defined order” for the order devices on which the setup script is run from EPICenter → Click “Next.”



Steps: In the “Run Script Identity Management – Configuration” box: Do not change any of the default values for the global

and device specific settings that appear → Click “Next.”

Steps: In “Select your run-time settings.” screen, click “Next.”



Steps: In “Verify your run script information” screen, click “Run Script.” This step executes the configuration required on the

ExtremeXOS switch to send Identity Management events to EPICenter. Note that this step might change some configuration

in the Identity Management module on the ExtremeXOS switch, and we will correct it later.



Steps: Notice in this screen that EPICenter configures the ExtremeXOS switch. Although one could choose the option of

running this configuration script in the background (and close this configuration screen) and save changes to EPICenter later,

we have chosen the option to wait for the script to complete.



Steps: Click “Save results.”

NOTES

Notice that the screen also shows the configuration changes done on the ExtremeXOS switch to facilitate the notification of identity

information (events) to EPICenter. This is the same configuration that has been listed in “Section 4.2.2.8 XML Client (xmlc) Configuration.”



Steps: Click “Finish” to end the process of adding the edge switch into EPICenter for monitoring.



Steps: Finally, click on “Save Changes” to save the device (enabled for monitoring) into the EPICenter configuration.

NOTES

After this step, it is important to revisit the ExtremeXOS configuration and ensure that Identity Management is enabled only on the ports

that we are interested in. This is because EPICenter enables Identity Management on all the ports on the switch. Recollect that in this

topology we are interested in tracking identities only on ports that connect to the clients. This is to ensure that the switch does not track

a large number of backend servers that are in the upstream enterprise network.



4.2.4. Client Configurations

The following table summarizes the client configurations and connections used in this case study.

Table 5:

• IP Address, Default Gateway, Name/WINS Servers: Dynamically assigned by DHCP

• NetBIOS Host Name: workstation1

John Smith PC

John Smith VoIP Phone

Bob Stone Laptop

Laptop Used for

Web-based Authentication

Traffic Generators to

Simulate MAC-based

Authentication

• Authentication Method: IEEE 802.1X [Please refer to client configuration steps described in document

“Application Note: Using ExtremeXOS NetLogin with Microsoft IAS” for configuring the client to

perform authentication using EAP-MD5-Challenge.]

• Connected to edge switch on port #13

• IP Address, Default Gateway, Name/WINS Servers: Dynamically assigned by DHCP.

• Authentication Method: MAC-based


• IP Address, Default Gateway, Name/WINS Servers: Dynamically assigned by DHCP

• NetBIOS Host Name: laptop1

• Authentication Method: IEEE 802.1X [Please refer to client configuration steps described in document

“Application Note: Using ExtremeXOS NetLogin with Microsoft IAS” for configuring the client to

perform authentication using EAP-MD5-Challenge.]


• IP Address, Default Gateway, Name Servers: Dynamically assigned by DHCP

• Hostname: laptop2


• Traffic with source MAC addresses 00:00:00:FE:ED:01 and 00:00:00:FE:ED:02 are sent to ports

numbered 21 and 22 respectively

Once all the client configurations have been done, we can now allow all the clients to logon to the network depending on the

authentication method used. While some methods (such as IEEE 802.1X EAP-MD5-Challenge) require human/user intervention

to complete the logon process, others such as MAC-based authentication methods would only require the client to

generate traffic. In the subsequent sections, we will examine the discovery of identities and the information collected about

the same.

We will omit the steps required to verify the status of authentication of clients at both the edge switch and the backend IAS

server. Please refer to the document “Application Note: Using ExtremeXOS NetLogin with Microsoft IAS” for more comprehensive

details about the information available at the edge switch and the authentication servers for verifying and troubleshooting

the authentication process for various methods. Hence forth, we will assume that all clients have been successfully authenticated

(and authorized).

4.2.5. Tracking Identities of Desktop/Workstation Users

In this section we will examine the various attributes of human user identities and the identities of the devices they use. We

will also observe the co-relation of information done by the ExtremeXOS switch.


In this section, we will examine the various CLI commands provided by ExtremeXOS to retrieve information about user/

device identities. While ExtremeXOS CLI provides detailed information for monitoring, debugging and troubleshooting, it is

highly recommended to use EPICenter for a centralized view of identities throughout the network.



4.2.5.1.1. show identity-management entries

This command lists the identities discovered by the ExtremeXOS switch and provides the following information: Account/ID

Name along with domain/realm association, flags to indicate the source of discovery, port on which the identity was discovered,

IP-MAC bindings, and finally VLAN memberships.

X250e-24p.21 # show identity-management entries

ID Name/ Flags Port MAC/ VLAN

Domain Name

IP

------------------------------------------------------------------

000000feed01 -m-- 21 00:00:00:fe:ed:01 corpvoice(1)

-- NA --

000000feed02 -m-- 22 00:00:00:fe:ed:02 corpvoice(1)

-- NA --

alice _ duff -w-- 17 00:11:43:51:b9:63 webapps(1)

192.168.1.101(1)

bob _ stone -x-- 14 00:11:43:4c:90:6f corp(1)

PRIMECORP 192.168.0.155(1)

john _ smith -x-- 13 00:0d:88:68:8f:cc corp(1)

PRIMECORP 192.168.0.156(1)

laptop2$ --k- 14 00:11:43:4c:90:6f corp(1)

PRIMECORP.COM 192.168.0.155(1)

workstation1$ --k- 13 00:0d:88:68:8f:cc corp(1)


------------------------------------------------------------------

Flags:

k - Kerberos Snooping, l - LLDP Device,

m - NetLogin MAC-Based, w - NetLogin Web-Based,

x - NetLogin 802.1X

Legend: > - VLAN name or ID Name or Domain Name truncated to column width

(#) - Total # of associated VLANs/IPs

-- NA --- No IP or VLAN associated

Total number of entries: 7

In the subsequent sections, we will track only those entries that are highlighted in the output above.



4.2.5.1.2. show identity-management entries detail

This command includes all the information from the earlier command, and in addition shows the time at which the identity

was discovered by the ExtremeXOS switch.

X250e-24p.23 # show identity-management entries detail

- ID: “000000feed01”, 1 Port binding(s)

Port: 21, 1 MAC binding(s)

MAC: 00:00:00:fe:ed:01, Flags: -m--, Discovered: Thu Mar 25 14:43:53 2010

1 VLAN binding(s)

VLAN: “corpvoice”, 0 IP binding(s)

- ID: “000000feed02”, 1 Port binding(s)


MAC: 00:00:00:fe:ed:02, Flags: -m--, Discovered: Thu Mar 25 14:43:58 2010

1 VLAN binding(s)

VLAN: “corpvoice”, 0 IP binding(s)

- ID: “alice _ duff”, 1 Port binding(s)


MAC: 00:11:43:51:b9:63, Flags: -w--, Discovered: Thu Mar 25 14:45:30 2010

1 VLAN binding(s)

VLAN: “webapps”, 1 IP binding(s)

IPv4: 192.168.1.101

- ID: “bob _ stone”, 1 Port binding(s)

Domain: “PRIMECORP”


MAC: 00:11:43:4c:90:6f, Flags: -x--, Discovered: Thu Mar 25 14:32:57 2010

1 VLAN binding(s)

VLAN: “corp”, 1 IP binding(s)

IPv4: 192.168.0.155

- ID: “john _ smith”, 1 Port binding(s)

Domain: “PRIMECORP”


MAC: 00:0d:88:68:8f:cc, Flags: -x--, Discovered: Thu Mar 25 14:32:37 2010

1 VLAN binding(s)


IPv4: 192.168.0.156

- ID: “laptop2$”, 1 Port binding(s)

Domain: “PRIMECORP.COM”, NetBios hostname: “LAPTOP2”


MAC: 00:11:43:4c:90:6f, Flags: --k-, Discovered: Thu Mar 25 14:33:46 2010

1 VLAN binding(s)


IPv4: 192.168.0.155

- ID: “workstation1$”, 1 Port binding(s)

Domain: “PRIMECORP.COM”, NetBios hostname: “WORKSTATION1”


MAC: 00:0d:88:68:8f:cc, Flags: --k-, Discovered: Thu Mar 25 14:32:43 2010

1 VLAN binding(s)


IPv4: 192.168.0.156

------------------------------------------------------------------

Flags:



x - NetLogin 802.1X



Sections “4.2.5.1.3 show identity-management entries ipaddress” through “4.2.5.1.6 show identity-management entries vlan”

lists variations of the command to retrieve identities using different filter criteria.

4.2.5.1.3. show identity-management entries ipaddress

X250e-24p.28 # show identity-management entries ipaddress 192.168.0.155


Domain Name

IP

------------------------------------------------------------------


PRIMECORP 192.168.0.155(1)

laptop2$ --k- 14 00:11:43:4c:90:6f corp(1)


------------------------------------------------------------------

Flags:



x - NetLogin 802.1X





X250e-24p.29 # show identity-management entries ipaddress 192.168.0.156


Domain Name

IP

------------------------------------------------------------------


PRIMECORP 192.168.0.156(1)



------------------------------------------------------------------

Flags:



x - NetLogin 802.1X







4.2.5.1.4. show identity-management entries mac

X250e-24p.31 # show identity-management entries mac 00:0d:88:68:8f:cc


Domain Name

IP

------------------------------------------------------------------


PRIMECORP 192.168.0.156(1)



------------------------------------------------------------------

Flags:



x - NetLogin 802.1X





X250e-24p.30 # show identity-management entries mac 00:11:43:4c:90:6f


Domain Name

IP

------------------------------------------------------------------


PRIMECORP 192.168.0.155(1)

laptop2$ --k- 14 00:11:43:4c:90:6f corp(1)


------------------------------------------------------------------

Flags:



x - NetLogin 802.1X







4.2.5.1.5. show identity-management entries domain

X250e-24p.24 # show identity-management entries domain PRIMECORP


Domain Name

IP

------------------------------------------------------------------


PRIMECORP 192.168.0.155(1)


PRIMECORP 192.168.0.156(1)

------------------------------------------------------------------

Flags:



x - NetLogin 802.1X





X250e-24p.25 # show identity-management entries domain PRIMECORP.COM


Domain Name

IP

------------------------------------------------------------------

laptop2$ --k- 14 00:11:43:4c:90:6f corp(1)




------------------------------------------------------------------

Flags:



x - NetLogin 802.1X







4.2.5.1.6. show identity-management entries vlan

X250e-24p.33 # show identity-management entries vlan corp


Domain Name

IP

------------------------------------------------------------------


PRIMECORP 192.168.0.155(1)


PRIMECORP 192.168.0.156(1)

laptop2$ --k- 14 00:11:43:4c:90:6f corp(1)




------------------------------------------------------------------

Flags:



x - NetLogin 802.1X






4.2.5.2.1. Dashboards in the Default Home Page

The home page in EPICenter is designed to display a number of graphs showing useful statistics and events. The following

information is available on the EPICenter dashboard:

• Top 10 successful logon attempts by users across the network

• Top 10 successful logon failures of users

• Number of users successfully logged into the network reported by each edge switch (Device in EPICenter terminology)

across the network

• Number of users failed authentication (and authorization) and reported by each edge switch across the network

• Successful logon attempts indexed using the client MAC address

• Failed logon attempts indexed using the client MAC address

The dashboard is intended to provide administrators with a quick status of users in the network.



The screenshot included below shows the content that appears on the default home page of EPICenter, when an administrator

is logged into the application. Subsequent sections describe the steps to customize the home page to include other graphs.

Notice that the following dashboards are included by default:

• Top 10 Log Ons by User Name in Past 24 Hours

• Top 10 Log On Failures by User Name in Past 24 Hours

NOTES

Observe that all the users that were discovered (and retrieved using the command described in “Section 4.2.5.1.1 show identitymanagement

entries) are now displayed.



4.2.5.2.2. Customizing the Home Page to Include Other Dashboards

This section describes the steps required to customize the home page to include other dashboards.

Steps: Click “View” → Click “Show Dashboard Palette.”



NOTES

Notice that the palette appears at the bottom of the home page, and now there are options to include other dashboards in the

home page.



The screenshot shown below includes the dashboards to display the number of successful and unsuccessful logon attempts

across the network against the horizontal axis containing the various edge switches in the network.

NOTES

The dashboard lists events generated only by one edge switch (10.127.2.18) which is used in this case study. The dashboard could

include a summary from various edge switches in the network.



4.2.5.2.3. Logon Failures Displayed in the Dashboard

We will simulate two failed logon attempts for user Mary Hughes (username: mary_hughes) and examine the changes in

the dashboards. Notice that the number of failed logon attempts increments on the vertical axis.



4.2.5.2.4. Detailed Information About Identities Discovered Across the Network

EPICenter maintains information about identities (Users in EPICenter terminology) reported by edge switches across the

network. EPICenter places users/identities reported by edge switches into active and inactive sets. The active set contains

identities that are currently being tracked by switches (i.e. identities that were discovered and were not lost due to one of

logoff events, or FDB/MAC aging events etc.). The inactive set contains information about users/identities that are no

longer being tracked by the switches in the network. The active and inactive sets are combined together to provide more

comprehensive information of users in the network.

In the next two sections, we will examine both of these sets and the information that is available in EPICenter.

4.2.5.2.4.1. Information about Active Users

Steps: In the “Folder List”, Expand “Network Views” → Click “Users” → Select “Active Users” tab on middle frame.

The screenshots shown below display information collected for the following identities:

• User John Smith (john_smith)

• John Smith’s Workstation (workstation1)

• User Bob Stone (bob_stone)

• Bob Stone’s Laptop (laptop2)

• User Mary Hughes







4.2.5.2.4.2. Information About Both – Active and Inactive Users

Steps: In “Folder List” (available on the left frame), Click “Users” → Click “Inactive and active users” in the middle frame.

Notice that the middle frame in the page now contains multiple criteria available for filtering information gathered from

switches across the network. Administrators can choose to filter information based on the following criteria:

• User/Identity name

• MAC address of the identity

• Edge switch that has tracked or is currently tracking users/identities



4.2.6. Tracking Identities of VoIP Phones

Recollect that the case study network topology used can simulate three VoIP phones (with MAC addresses

00:00:00:FE:ED:01, 00:00:00:FE:ED:02, and 00:04:96:28:01:8D), and the setup allows for MAC-based authentication. The

identity for VoIP phone with MAC address 00:04:96:28:01:8D contains the LLDP capable attribute.


Refer to Sections “4.2.5.1.1 show identity-management entries” and “4.2.5.1.2 show identity-management entries detail” which

display information gathered about VoIP phones with MAC addresses – 00:00:00:FE:ED:01, and 00:00:00:FE:ED:02. The command

below retrieves information gathered about the VoIP phone with MAC address 00:04:96:28:01:8D.

X250e-24p.4 # show identity-management entries mac 00:04:96:28:01:8D


Domain Name

IP

------------------------------------------------------------------

00049628018d lm-- 23 00:04:96:28:01:8d corpvoice(1)

-- NA --

------------------------------------------------------------------

Flags:



x - NetLogin 802.1X







5. Business Process Integration

In the introductory of this paper, we stated that the goal of Identity Management using ExtremeXOS and EPICenter is to not

only to bring identity awareness in the network, but also to help organizations in preparing for compliance and internal audits.

Section 4.1 describes the usage of the report system available in EPICenter to generate a variety of reports. Reports can be

generated using different criteria depending on purpose of use.

Section 4.2 describes the methods by which information about identities available on edge switches can be retrieved using a

custom Web-based application. The section also describes the procedures to setup the edge switch to publish identity

information as and when they change to custom Web-based applications.


Reports with a variety of indexing criteria can be generated in EPICenter. The reports system can be accessed in “Folder

List” on left frame → Expand “Network Administration” → Click “Reports (HTML)” to start the Extreme Networks

Dynamic Reports program.

NOTES

• All the reports generated can be downloaded to the local host in the following formats: Comma Separated Values (CSV), which can

then be subsequently imported into Microsoft Excel, and eXtended Markup Language (XML)

• The default time period selected for report generation is 24 hours from current system time, but this can be changed

5.1.1. Successful Logons by User Name



Detailed information about user activity can be retrieved by clicking on the Username. In the next screenshot this is

illustrated by clicking on the username john_smith.

5.1.2. Failed Logon Attempts by User Name



5.1.3. Successful Logon Attempts Reported by Edge Switches Across the Network

Detailed information about all users/identities can be retrieved by clicking on a particular edge switch. The next screenshot

is used to display all identities reported by the edge switch used in this case study.



5.1.4. Failed Logon Attempts Reported by Edge Switches Across the Network

Details of failed logon attempts by users/identities reported by the edge switch can be retrieved by clicking on a particular

edge switch.



5.1.5. Successful Logon Indexed by MAC Address of Users/Identities

Detailed information about the logon attempts can be retrieved by clicking on a particular MAC address. The next screenshot

displays details of logon attempts recorded for John Smith’s workstation (using MAC address: 00:0D:88:68:8F:CC).



5.1.6. Failed Logon Attempts Indexed by MAC Address of Users/Identities

5.2. Integration with Custom Enterprise Applications

The data used to describe identities is represented using the eXtensible Markup Language (XML). XML has emerged as the

preferred technology for data representation for both Web-based and traditional software applications. This development

has accelerated the standardization of XML and the widespread support of XML libraries, utilities, and applications. XML

is increasingly the preferred foundation for integrating various enterprise applications with one another. XML extends

Hypertext Markup Language (HTML) by providing a new language toolkit. The new toolkit allows programmers to

develop their own markup languages, while automatically providing the benefit of being compatible with existing deployed

XML code.

In this section, we will discuss the methods by which third-party or custom applications can:

A. Retrieve information about identities tracked by edge switches.

B. Receive unsolicited events about identities by edge switches.

It is important to note that EPICenter uses both of these methods when monitoring edge switches. When an edge switch

(device) is first setup for monitoring, EPICenter retrieves information about all the identities being tracked by the switch

using the XML interface. Subsequently, ExtremeXOS switches publish changes to the identity-management database (new

identities discovered, user logoff, capability discovery such as LLDP, Kerberos activity, etc.) to EPICenter using the XML

client process.



5.2.1. Retrieving Identity Entries from ExtremeXOS Based Switches

In this section, we will explore the method by which an application can poll (if required periodically) an ExtremeXOS

based switch for retrieving identities tracked in the network. The edge switch will act as a server. We will use a tool called

soapUI, which, amongst a host of other features provides a very easy method to inspect and test WSDL based Web services.

The procedures and description in this section is intended to provide an overview of how to establish a SOAP/XML session

with an ExtremeXOS switch and retrieve information.

5.2.1.1. soapUI Installation and Initial Setup

Information about soapUI is available at http://www.soapui.org. Please refer to the download instructions provided on the

Web site.

NOTES

• This case study uses soapUI Version 3.5

• It is recommended to have a copy of the ExtremeXOS InSite SDK in the host on which soapUI is planned to be installed. This case

study uses the ExtremeXOS InSite SDK Release 12.4.1.7 (available at http://www.extremenetworks.com/solutions/Insite.aspx).

The rest of this section will explain the steps to install soapUI on a host. Open the soapUI installer program and follow the

steps given after each screen shot to complete the installation process.

Steps: Click “Next.”



Steps: Check “I accept the agreement” → Click “Next.”

Steps: Specify the program installation location → Click “Next.”



Steps: Accept all the default set of components that are selected for installation → Click “Next.”

Steps: Check “I accept the agreement” → Click “Next.”



Steps: Click “Next.”

Steps: Ensure that options are selected as shown above → Click “Finish” to complete the installation process.



Steps: When soapUI program starts, Right Click on the “Default Workspace” → Click “New soapUI Project.”

Steps: Enter the project name as shown or choose a custom project name → Click “Ok.”



Steps: Right Click on the project created → Click “Add WSDL.”

Steps: Click “Browse” to locate the WSDL files provided by the ExtremeXOS InSite SDK.



Steps: Select “switch.wsdl” from the list of WSDL files provided in the ExtremeXOS InSite SDK → Click “Open.”

Steps: Ensure that all the options are selected as shown → Click “Ok.”



5.2.1.2. Creating/Opening a SOAP/XML Session with an Edge Switch

Steps: Expand “switchBinding” under the project → Expand “openSession” → Double Click on “Request 1.”



Replace the contents of the request with the SOAP envelope provided below.

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:com=”http://

www.extremenetworks.com/XMLSchema/xos/common”>

<soapenv:Header/>

<soapenv:Body>

<com:openSessionRequest>



<session com:operation=”merge”>



<appName></appName>



<username>admin</username>



<password></password>



<xmlApiVersion></xmlApiVersion>



<sessionId></sessionId>



<timeout></timeout>



<accessRight></accessRight>



<extension>



</extension>



</session>

</com:openSessionRequest>

</soapenv:Body>

</soapenv:Envelope>



Steps: Click on the location bar → Click “[edit current].”



Steps: Enter the URL as https://<switch-management-ipaddress>/xmlServices → Click “Ok.”

NOTES

• Notice the use of “https” instead of “http” to secure information exchange between the edge switch and the application

• The edge switch has already been configured to enable the Web server (Refer Section 4.2.2.6 Web/thttpd Configuration)



Steps: Click “Submit request to specified endpoint URL.”

The edge switch now responds with a SOAP message containing a SessionID which can be used for 900 seconds (15 minutes).



Subsequent requests to the edge switch will have to use the SessionID returned by the edge switch.

5.2.1.3. Retrieving Details of Active Users from Edge Switch

In this section, we will format a request to retrieve the current set of active users being tracked by the edge switch.



Steps: Expand the “get” method → Replace the request to retrieve the list of active users with content provided below.

NOTES

It is important to replace the value of the sessionId tag with the value recorded earlier when the edge switch responded to the

openSession request.

Format for the request for a list of current active users:

<soapenv:Envelope

xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”

xmlns:com=”http://www.extremenetworks.com/XMLSchema/xos/common”

xmlns:swit=”http://www.extremenetworks.com/XMLSchema/xos/switch”>

<soapenv:Header>

<ns1:hdr xmlns:ns1=”http://www.extremenetworks.com/XMLSchema/xos/common”>

<reqId>1</reqId>

<sessionId>20af0000000019</sessionId>

</ns1:hdr>

</soapenv:Header>

<soapenv:Body>

<getRequest maxSize=”0”

xmlns=”http://www.extremenetworks.com/XMLSchema/xos/switch”>

<filter xsi:type=”ns2:UserIdentityData” xmlns=””

xmlns:ns2=”http://www.extremenetworks.com/XMLSchema/xos/idmgr”>

<datasetType>active</datasetType>

</filter>

</getRequest>

</soapenv:Body>

</soapenv:Envelope>



The edge switch now responds with the list of active users being tracked.

SOAP response from the edge switch:

<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”

xmlns:SOAP-ENC=”http://schemas.xmlsoap.org/soap/encoding/”

xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”

xmlns:xsd=”http://www.w3.org/2001/XMLSchema”

xmlns:ns1=”http://www.extremenetworks.com/XMLSchema/xos/l2protocol”

xmlns:xos=”urn:xapi”

xmlns:vlan=”http://www.extremenetworks.com/XMLSchema/xos/vlan”

xmlns:idmgr=”http://www.extremenetworks.com/XMLSchema/xos/idmgr”

xmlns:port=”http://www.extremenetworks.com/XMLSchema/xos/port”

xmlns:fdb=”http://www.extremenetworks.com/XMLSchema/xos/fdb”

xmlns:ns2=”http://www.extremenetworks.com/XMLSchema/xos/dhcp”

xmlns:ems=”http://www.extremenetworks.com/XMLSchema/xos/ems”

xmlns:aaa=”http://www.extremenetworks.com/XMLSchema/xos/aaa”

xmlns:snmp=”http://www.extremenetworks.com/XMLSchema/xos/snmp”

xmlns:system=”http://www.extremenetworks.com/XMLSchema/xos/system”

xmlns:event=”http://www.extremenetworks.com/XMLSchema/xos/event”

xmlns:ns4=”urn:ietf:params:xml:ns:netconf:soap:1.0”

xmlns:netb=”urn:ietf:params:xml:ns:netconf:base:1.0”

xmlns:switch=”http://www.extremenetworks.com/XMLSchema/xos/switch”

xmlns:com=”http://www.extremenetworks.com/XMLSchema/xos/common”

xmlns:upm=”http://www.extremenetworks.com/XMLSchema/xos/upm”

xmlns:xosacl=”urn:xapi/l2protocol/acl” xmlns:xoscfg=”urn:xapi/cfgmgmt/cfgmgr”

xmlns:xosfdb=”urn:xapi/l2protocol/fdb” xmlns:xospol=”urn:xapi/system/policy”

xmlns:xosvlan=”urn:xapi/l2protocol/vlan”>

<SOAP-ENV:Header>

<com:hdr>



<reqId>1</reqId>

<sessionId>20af0000000074</sessionId>

</com:hdr>

<event:eventHeader/>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<switch:getResponse>

<objects>

<object xsi:type=”ns2:UserIdentityData”>


<userName>bob _ stone</userName>

<domain>PRIMECORP</domain>

<portList>14</portList>

<modificationTimestamp>1269525859532</modificationTimestamp>

<eventType>na</eventType>

<authProtocolsUsed>netloginDot1x</authProtocolsUsed>

<numOfLocations>1</numOfLocations>

<creationTimestamp>1269525822399</creationTimestamp>

<location>

<port>14</port>

<portDisplayString/>

<macAddress>00:11:43:4c:90:6f</macAddress>

<lldpCapabilityInfo>0</lldpCapabilityInfo>

<netBiosHostName/>

<kerberosSnooping>false</kerberosSnooping>

<authMethod>netloginDot1x</authMethod>

<securityProfile/>

<securityViolations/>

<logonStatus>loggedOn</logonStatus>

<logonTime>1269525822389</logonTime>

<logOutTime>0</logOutTime>

<authFailTime>0</authFailTime>

<vlanInfo>

<vlan>

<name>corp</name>

<ipAddress>192.168.0.155</ipAddress>

</vlan>

</vlanInfo>


</location>

</object>



<userName>bob _ stone</userName>

<domain>PRIMECORP.COM</domain>




<authProtocolsUsed>none</authProtocolsUsed>



<location>

<port>14</port>


<macAddress>00:11:43:4c:90:6f</macAddress>


<netBiosHostName>LAPTOP2</netBiosHostName>

<kerberosSnooping>true</kerberosSnooping>



<authMethod>na</authMethod>

<securityProfile/>






<vlanInfo>

<vlan>

<name>corp</name>


</vlan>

</vlanInfo>


</location>

</object>



<userName>john _ smith</userName>

<domain>PRIMECORP</domain>




<authProtocolsUsed>netloginDot1x</authProtocolsUsed>



<location>

<port>13</port>


<macAddress>00:0d:88:68:8f:cc</macAddress>


<netBiosHostName/>

<kerberosSnooping>false</kerberosSnooping>

<authMethod>netloginDot1x</authMethod>

<securityProfile/>






<vlanInfo>

<vlan>

<name>corp</name>


</vlan>

</vlanInfo>


</location>

</object>



<userName>john _ smith</userName>

<domain>PRIMECORP.COM</domain>




<authProtocolsUsed>none</authProtocolsUsed>





<location>

<port>13</port>


<macAddress>00:0d:88:68:8f:cc</macAddress>


<netBiosHostName>WORKSTATION1</netBiosHostName>

<kerberosSnooping>true</kerberosSnooping>

<authMethod>na</authMethod>

<securityProfile/>






<vlanInfo>

<vlan>

<name>corp</name>


</vlan>

</vlanInfo>


</location>

</object>

</objects>

</switch:getResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

5.2.2. Receiving Unsolicited Identity Events from Edge Switches

The previous section explored the method by which an application can periodically monitor for identities being tracked by

an edge switch. However in some scenarios, it might be required to receive real-time events about identities from the edge

switch. This also alleviates the polling/monitoring overhead in the application.

ExtremeXOS switches can act as clients and can publish events to preconfigured application servers. Recollect from earlier

discussions that EPICenter is such an application that can receive unsolicited identity events from edge switches in the

network. In order to achieve this, the XML client process will need to be configured on the edge switch. The following

information will be required to complete the configuration of XML Client process on the edge switch.

Target Name

URL

Credentials

Helps in uniquely identifying a target application when more than one application is to be

integrated with the XML Client process in ExtremeXOS.

For e.g. monitor-authentication-failures

URL of the application to be integrated with, in the network.

For e.g. https://10.127.4.202/authfailures

Username and Password to authenticate with the application. These parameters are not

required if authentication with the application is not required.

For this example, we will consider that no authentication is required for the application.

create xml-notification target monitor-authentication-failures url

http://10.127.4.202/authfailures

configure xml-notification target monitor-authentication-failures user none

enable xml-notification monitor-authentication-failures

configure xml-notification target monitor-authentication-failures add idMgr



5.3. Integration with Universal Port Manager (UPM)

Universal Port is a flexible framework that enables automatic switch configuration in response to Event Management

System (EMS) event messages generated by the identity-manager process. Please refer to “Chapter 6: Universal Port” in the

document ExtremeXOS Concepts Guide for more details on the feature and how it can be leveraged to automate switch

configuration. In this section, we will discuss methods by which events generated by the “idMgr” process can be used as

triggers to run Universal Port Manager (UPM) profiles in specific scenarios.


The Event Management System in ExtremeXOS will have to be configured to create a filter that defines the event and a

profile that runs when the event occurs. The following configuration achieves the goals required to trigger a UPM profile for

Kerberos events. Note that for the purpose of illustration, we have only include one event (RecvKerberosTrig) amongst

many generated by the process.

* Slot-1 Stack.123 # show configuration “ems”

#

# Module ems configuration.

#

enable log debug-mode

create log filter kerberosevents

configure log filter DefaultFilter add events IdMgr severity debug-verbose

configure log filter kerberosevents add events IdMgr.RecvKerberosTrig

create log target upm unauth-hostnames

enable log target upm unauth-hostnames

configure log target upm unauth-hostnames filter kerberosevents severity Debug-Verbose

configure log target upm unauth-hostnames match Any

In the configuration show above, we have added a filter called “kerberosevents” to identity events that can be used to

trigger the UPM profile “unauth-hostnames”. The goal of the UPM profile “unauth-hostnames” is to identify means by which

unauthorized computers and laptops when plugged into the PRIMECORP enterprise network are identified, and are either

blocked or isolated.

5.3.2. UPM Script: Block Traffic from Unauthorized Devices

In this section, we will use a sample script to:

A. Identify unauthorized devices using the NetBIOS hostname: Prime Corporation uses a naming scheme to identify the

hosts managed in the network (For e.g. PRIMECORP-workstaion-1, PRIMECORP-laptop-1, and so on.). Any computer

that does not use the string “PRIMECORP” in the beginning of the hostname is identified an unauthorized host.

B. Block all traffic originating from the unauthorized devices: The MAC address of the device is used in an access-control

list to match (source address match) and subsequently deny any traffic.


The EMS event IdMgr.RecvKerberosTrig provides the following information in the form of variables which we will use in

the UPM script. Note that the table below lists only the variables that have been used in the script, while in reality many

other parameters are available for use.

Table 6:

EVENT.LOG_EVENT

EVENT.LOG_PARAM_3

EVENT.LOG_PARAM_4

EVENT.LOG_PARAM_6

Identifies the event name (in this case “RecvKerberosTrig”)

MAC address of the device

Port on which the device was discovered

NetBIOS Hostname of the device



Below is the sample script used to block all traffic originating from the device.

* Slot-1 Stack.290 # show configuration “upm”

#

# Module upm configuration.

#

create upm profile unauth-hostnames

enable cli scripting

configure cli mode non-persistent

if (!$match($EVENT.LOG _ EVENT,RecvKerberosTrig)) then

if ($match($EVENT.LOG _ PARAM _ 6,PRIMECORP) <= 9) then

create access-list block _ computer _ $EVENT.LOG _ PARAM _ 6 “ethernet-source-address

$EVENT.LOG _ PARAM _ 3 “ “deny ;count unauthorized _ devices”

configure access-list add block _ computer _ $EVENT.LOG _ PARAM _ 6 first ports $EVENT.

LOG _ PARAM _ 4

endif

endif

.


When the device is discovered via Kerberos snooping, the following information will be available in the EMS logs.

* Slot-1 Stack.284 # show log chronological

04/07/2010 00:45:23.97 <Verb:IdMgr.RecvKerberosTrig> Slot-1: Kerberos Discover trigger for

john _ smith@PRIMECORP/00:11:43:BF:6A:D0/1:2/1000014, IP 4.4.4.175, NB host “JS-PERSONAL”

04/07/2010 00:45:23.97 <Info:IdMgr.ReauthId> Slot-1: Identity “PRIMECORP\john _ smith” with MAC

00:11:43:BF:6A:D0, auth method netloginMac, reauthenticated on port 1:2

04/07/2010 00:45:23.98 <Noti:UPM.Msg.upmMsgExshLaunch> Slot-1: Launched profile unauth-hostnames

for the event log-message

NOTES

From the events, that, the IdMgr.RecvKerberosTrig event contains the MAC address (00:11:43:BF:6A:D0) of the device, Port (1:2) on

which it was discovered, and the NetBIOS hostname (JS-PERSONAL) which was snooped from the Kerberos packets. Further, it is

important to note that the UPM profile “unauth-hostnames” was executed/launched for the even log-message.

The following commands provide the status of execution of the UPM scripts:

* Slot-1 Stack.285 # show upm history

--------------------------------------------------------------------------------

Exec Event/ Profile Port Status Time Launched

Id Timer/ Log filter

--------------------------------------------------------------------------------

16 Log-Message(kerberos unauth-hostname --- Pass 2010-04-07 00:45:23

--------------------------------------------------------------------------------

Number of UPM Events in Queue for execution: 0

* Slot-1 Stack.286 # show upm history detail

UPM Profile: unauth-hostnames

Event: Log-Message(kerberosevents)

Profile Execution start time: 2010-04-07 00:45:23

Profile Execution Finish time: 2010-04-07 00:45:24

Execution Identifier: 16 Execution Status: Pass



Execution Information:

2 # enable cli scripting

3 # configure cli mode non-persistent

4 # set var EVENT.NAME LOG _ MESSAGE

5 # set var EVENT.LOG _ FILTER _ NAME “kerberosevents”

6 # set var EVENT.LOG _ DATE “04/07/2010”

7 # set var EVENT.LOG _ TIME “00:45:23.97”

8 # set var EVENT.LOG _ COMPONENT _ SUBCOMPONENT “IdMgr”

9 # set var EVENT.LOG _ EVENT “RecvKerberosTrig”

10 # set var EVENT.LOG _ SEVERITY “Debug-Verbose”

11 # set var EVENT.LOG _ MESSAGE “Kerberos %0% trigger for %1%@%2%/%3%/%4%/%5%,

IP %7%, NB host ‘%6%’”

12 # set var EVENT.LOG _ PARAM _ 0 “Discover”

13 # set var EVENT.LOG _ PARAM _ 1 “john _ smith”

14 # set var EVENT.LOG _ PARAM _ 2 “PRIMECORP”

15 # set var EVENT.LOG _ PARAM _ 3 “00:11:43:BF:6A:D0”

16 # set var EVENT.LOG _ PARAM _ 4 “1:2”

17 # set var EVENT.LOG _ PARAM _ 5 “1000014”

18 # set var EVENT.LOG _ PARAM _ 6 “JS-PERSONAL”

19 # set var EVENT.LOG _ PARAM _ 7 “4.4.4.175”

20 # set var EVENT.PROFILE unauth-hostnames



23 # if (!$match($EVENT.LOG _ EVENT,RecvKerberosTrig)) then

24 # if ($match($EVENT.LOG _ PARAM _ 6,PRIMECORP) <= 9) then

25 # create access-list block _ computer _ $EVENT.LOG _ PARAM _ 6 “ethernet-source-address

$EVENT.LOG _ PARAM _ 3 “ “deny ;count unauthorized _ devices”

26 # configure access-list add block _ computer _ $EVENT.LOG _ PARAM _ 6 first ports

$EVENT.LOG _ PARAM _ 4

done!

27 # endif

28 # endif

--------------------------------------------------------------------------------


* Slot-1 Stack.287 # show access-list dynamic

Dynamic Rules: ((*)- Rule is non-permanent )

(*)block _ computer _ JS-PERSONAL

(*)hclag _ arp _ 2 _ 4 _ 96 _ 27 _ 7b _ d6

LAG

(*)idmgmt _ ks _ tcp _ dst

(*)idmgmt _ ks _ tcp _ src

(*)idmgmt _ ks _ udp _ dst

(*)idmgmt _ ks _ udp _ src

Bound to 1 interfaces for application Cli

Bound to 0 interfaces for application HealthCheck-

Bound to 1 interfaces for application IdentityManager




* Slot-1 Stack.288 # show access-list dynamic rule “block _ computer _ JS-PERSONAL”

entry block _ computer _ JS-PERSONAL {

if match all {

ethernet-source-address 00:11:43:BF:6A:D0 ;

} then {

deny ;

count unauthorized _ devices ;

} }



* Slot-1 Stack.289 # show access-list dynamic counter

Vlan Name Port Direction

Counter Name Packet Count Byte Count

==================================================================

* 1:2 ingress

unauthorized _ devices 9

5.3.3. UPM Script: Isolate Unauthorized Devices

In this section, we will use a sample script to:

A. Identify unauthorized devices using the NetBIOS hostname.

B. Isolate/Move the port (on which the device was discovered) to a custom VLAN called “unauthvlan”.


The sample script used to move the port to a custom VLAN is given below:

* Slot-1 Stack.121 # show configuration “upm”

#

# Module upm configuration.

#

create upm profile unauth-hostnames

set var DISCOVERED _ VLAN corp

set var UNAUTH _ VLAN unauthvlan

enable cli scripting

configure cli mode non-persistent

if (!$match($EVENT.LOG _ EVENT,RecvKerberosTrig)) then

if ($match($EVENT.LOG _ PARAM _ 6,PRIMECORP) <= 9) then

configure vlan $DISCOVERED _ VLAN delete ports $EVENT.LOG _ PARAM _ 4

configure vlan $UNAUTH _ VLAN add ports $EVENT.LOG _ PARAM _ 4

endif

endif

.


The following commands can be used to verify the UPM script execution, and the results:

* Slot-1 Stack.117 # show upm history

--------------------------------------------------------------------------------

Exec Event/ Profile Port Status Time Launched

Id Timer/ Log filter

--------------------------------------------------------------------------------

3 Log-Message(kerberos unauth-hostname --- Pass 2010-04-07 01:39:23

--------------------------------------------------------------------------------


* Slot-1 Stack.118 # show upm history detail

UPM Profile: unauth-hostnames

Event: Log-Message(kerberosevents)

Profile Execution start time: 2010-04-07 01:39:23

Profile Execution Finish time: 2010-04-07 01:39:23

Execution Identifier: 3 Execution Status: Pass



Execution Information:



4 # set var EVENT.NAME LOG _ MESSAGE

5 # set var EVENT.LOG _ FILTER _ NAME “kerberosevents”

6 # set var EVENT.LOG _ DATE “04/07/2010”

7 # set var EVENT.LOG _ TIME “01:39:23.44”

8 # set var EVENT.LOG _ COMPONENT _ SUBCOMPONENT “IdMgr”

9 # set var EVENT.LOG _ EVENT “RecvKerberosTrig”

10 # set var EVENT.LOG _ SEVERITY “Debug-Verbose”

11 # set var EVENT.LOG _ MESSAGE “Kerberos %0% trigger for %1%@%2%/%3%/%4%/%5%, IP %7%, NB host

‘%6%’”

12 # set var EVENT.LOG _ PARAM _ 0 “Discover”

13 # set var EVENT.LOG _ PARAM _ 1 “john _ smith”

14 # set var EVENT.LOG _ PARAM _ 2 “PRIMECORP”

15 # set var EVENT.LOG _ PARAM _ 3 “00:11:43:BF:6A:D0”

16 # set var EVENT.LOG _ PARAM _ 4 “1:2”

17 # set var EVENT.LOG _ PARAM _ 5 “1000014”

18 # set var EVENT.LOG _ PARAM _ 6 “JS-PERSONAL”

19 # set var EVENT.LOG _ PARAM _ 7 “4.4.4.175”

20 # set var EVENT.PROFILE unauth-hostnames

21 # set var DISCOVERED _ VLAN corp

22 # set var UNAUTH _ VLAN unauthvlan



25 # if (!$match($EVENT.LOG _ EVENT,RecvKerberosTrig)) then

26 # if ($match($EVENT.LOG _ PARAM _ 6,PRIMECORP) <= 9) then

27 # configure vlan $DISCOVERED _ VLAN delete ports $EVENT.LOG _ PARAM _ 4

28 # configure vlan $UNAUTH _ VLAN add ports $EVENT.LOG _ PARAM _ 4

29 # endif

30 # endif

--------------------------------------------------------------------------------


* Slot-1 Stack.119 # show vlan

---------------------------------------------------------------------------------------

Name VID Protocol Addr Flags Proto Ports Virtual

Active router

/Total

---------------------------------------------------------------------------------------

corp 2 4.4.4.1 /24 ------------------------ ANY 1 /1 VR-Default

Default 1 -------------------------------------------- ANY 0 /0 VR-Default

Mgmt 4095 10.127.1.129 /24 ------------------------ ANY 1 /1 VR-Mgmt

nlvlan 7 ----------------------LN-------------------- ANY 0 /0 VR-Default

unauthvlan 10 -------------------------------------------- ANY 1 /1 VR-Default

---------------------------------------------------------------------------------------

Flags : (B) BFD Enabled, (c) 802.1ad customer VLAN, (C) EAPS Control VLAN,

(d) NetLogin Dynamically created VLAN, (D) VLAN Admin Disabled,

(E) ESRP Enabled, (f) IP Forwarding Enabled,

(F) Learning Disabled, (i) ISIS Enabled, (L) Loopback Enabled,

(l) MPLS Enabled, (m) IPmc Forwarding Enabled,

(M) Translation Member VLAN or Subscriber VLAN,

(n) IP Multinetting Enabled, (N) Network Login VLAN, (o) OSPF Enabled,

(O) Flooding Disabled, (p) PIM Enabled, (P) EAPS protected VLAN,

(r) RIP Enabled, (R) Sub-VLAN IP Range Configured,

(s) Sub-VLAN, (S) Super-VLAN, (t) Translation VLAN or Network VLAN,

(T) Member of STP Domain, (V) VPLS Enabled, (v) VRRP Enabled,



Total number of VLAN(s) : 5

* Slot-1 Stack.120 # show “unauthvlan”

VLAN Interface with name unauthvlan created by user

Admin State: Enabled Tagging: 802.1Q Tag 10

Virtual router: VR-Default

IPv6:

None

STPD:

None

Protocol: Match all unfiltered protocols

Loopback: Disabled

NetLogin: Disabled

QosProfile: None configured

Egress Rate Limit Designated Port: None configured

Flood Rate Limit QosProfile: None configured

Ports: 1. (Number of active ports=1)

Untag: *1:2(kerb _ port)

Flags: (*) Active, (!) Disabled, (g) Load Sharing port

(b) Port blocked on the vlan, (m) Mac-Based port

(a) Egress traffic allowed for NetLogin

(u) Egress traffic unallowed for NetLogin

(t) Translate VLAN tag for Private-VLAN

(s) Private-VLAN System Port, (L) Loopback port

(e) Private-VLAN End Point Port

(x) VMAN Tag Translated port

6. Deployment Considerations

6.1. Memory Usage in the Switch

The default memory size configured for identity-management is 512KB, and this is consumed from the system as soon as the

identity-management process starts in ExtremeXOS. The memory pool reserved is used for the following purposes:

• Tracking various user and device identities: This memory will be used throughout the lifetime of the identity. Events

such as identity aging will cause memory held by the process to be given back to the pool reserved for identity

management.

• Processing several events sent to the identity-management process from other processes such as NetLogin, LLDP, FDB

Manager, etc. This memory is used to handle events such as user logon notification by NetLogin, and is relinquished as

soon as the event has been processed.

The table below summarizes the memory consumption for a combination of users and devices.

Table 7:

User/Device

Authentication Method

Kerberos

Activity

LLDP

Average memory

required to track

one identity

Average memory required to

handle events related to one

identity from other processes

802.1X Web MAC

User + Workstation 3 3 1KB 4KB

User + Workstation 3 512 bytes 4KB

VoIP Phone 3 3 512 bytes 6KB

VoIP Phone 3 3 512 bytes 6KB

NOTES

These numbers for memory requirements are valid for ExtremeXOS 12.4.1, and are subject to change in later ExtremeXOS versions

depending on the amount of information included as part of an identity.



Memory usage in the identity-management process can be viewed using the “show identity-management statistics” command.

X250e-24p.69 # show identity-management statistics

Total number of users logged in : 8

Total number of login instances : 8

Total memory used : 3 Kbytes

Total memory used by events : 0 Kbytes

Total memory available

: 509 Kbytes

High memory usage level reached count : 0

Critical memory usage level reached count: 0

Max memory usage level reached count : 0

Current memory usage level

: Normal

Normal memory usage level trap sent : 0

High memory usage level trap sent : 0

Critical memory usage level trap sent : 0

Max memory usage level trap sent : 0

Event notification sent : 49

“Table 17: Identity Management Database Usage Levels” in the document “ExtremeXOS Command Reference Guide, Software

Version 12.4” provides details on the actions taken when the memory usage level reach high, critical, and maximum levels. The

database memory size can be configured to consume up to 48MB using the “configure identity-management database

memory-size”.

NOTES

The default database size of 512KB is selected to work well for a 48-port fixed configuration edge switch such as Summit X250e-48t,

Summit X450e-48p, etc. However, in chassis switches such as the BlackDiamond ® 8800 series family, and SummitStack, memory

requirements in the MSM modules (in the Chassis switches), Master and Backup nodes (in stacked environments) will increase based

on the density and/or the number of ports used to connect end users and systems. Hence, administrators are urged to take this into

account when tuning/configuring memory size for Identity Management.

www.extremenetworks.com

Corporate

and North America

Extreme Networks, Inc.

3585 Monroe Street

Santa Clara, CA 95051 USA

Phone +1 408 579 2800

Europe, Middle East, Africa

and South America

Phone +31 30 800 5100

Asia Pacific

Phone +65 6836 5437

Japan

Phone +81 3 5842 4011

© 2010 Extreme Networks, Inc. All rights reserved. Extreme Networks, the Extreme Networks logo, BlackDiamond, EPICenter, ExtremeXOS, Summit and SummitStack are either

registered trademarks or trademarks of Extreme Networks, Inc. in the United States and/or other countries. All other names and marks are the property of their respective owners.

Specifications are subject to change without notice. 1683_01 05/10

Deploying an Identity Aware Network

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?